No matter what I do, the stockapi table is not populated with symbols, and thus nothing is fetched in cron run.

I configured the user quotes, and pressed 'save', and it got saved correctly into the {stock} table:

mysql> select * from stock;
+-----+----------------+
| uid | symbols        |
+-----+----------------+
|   1 | GOOG YHOO MSFT |
+-----+----------------+
1 row in set (0.00 sec)

But looking at the stockapi table I get

mysql> select * from stockapi;
Empty set (0.00 sec)

I also can't find anywhere in stock.module code where it calls stockapi_save(), so I see why this happens. There is nothing in the watchdog as well. Screenshot attached.

Please point me to what I am missing..

Thanks.

CommentFileSizeAuthor
#5 yh.patch864 bytesyhager
stock.png21.83 KByhager

Comments

kbahey’s picture

kbahey commented
Status: Active » Closed (fixed)

Probably your host is preventing opening sockets to remote sites due to security reasons.

yhager’s picture

yhager commented
Status: Closed (fixed) » Active

No, this is not the case, everything is running on localhost, and all ports are open.

yhager’s picture

yhager commented
Title: {stockapi} table is empty » Does not work with PHP 'allow_url_fopen = Off'
Project: Stock » Stock API
Priority: Critical » Normal
Status: Active » Needs review

This wasn't an issue with openning sockets, rather with calling file_get_contents with a URL parameter.
I've had 'allow_url_fopen' set to off, since this is less secure (see http://lwn.net/Articles/203904/).

I've solved this for now by setting it to On, but please consider using curl instead:

  $curl = curl_init($url);
  curl_setopt($curl, CURLOPT_RETURNTRANSFER, TRUE);
  curl_setopt($curl, CURLOPT_FOLLOWLOCATION, TRUE);
  $contents = curl_exec($curl);
  curl_close($curl);
kbahey’s picture

kbahey commented

Curl is not available in all installations.

There is also drupal_http_request().

If you have a working, tested and properly formatted patch that provides an option on whether to use file_get_contents, or curl, I will included.

Better make the option self discover what is available, and default to that too.

I will wait for the patch.

yhager’s picture

yhager commented
StatusFileSize
new yh.patch864 bytes

Well, having drupal_http_request() for us, I see no reason to using something else.

I hope the patch is fine, it works for me.

kbahey’s picture

kbahey commented
Status: Needs review » Needs work

drupal_http_request() uses fsockopen() and fwrite()/fread(), which some PHP configurations may have blocked too.

Better have 2 options, the default would be drupal_http_request() and another selectable option (radio button), with the file_get_contents().

This way backward compatibility is maintained.

Curl can be left off for a future patch, if someone needs it.

So, please redo the patch with the two options above.

yhager’s picture

yhager commented

drupal_http_request() is the way drupal core handles HTTP requests (see aggregator.module). I see no reason why the stockapi module should behave differently. I think it will just add redundant clutter to the UI of the stockapi if you were to add a selection box of the http request method.

As a matter of fact, I can't think of reason to build a setup that will block fsockopen(), but will allow openning a URL with fopen().

kbahey’s picture

kbahey commented
Version: 5.x-1.0 » 5.x-1.x-dev
Status: Needs work » Fixed

I redid the patch to have error checking and watchdog logging.

Fixed.

yhager’s picture

yhager commented

Great, thanks.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.