Use drupal_http_request for determining version information

That is a server configuration setting that is preventing the fopen() function from accessing HTTP protocol. You could check to see if CURL is enabled and would then be able to modify the timeago_get_version() function to use CURL instead of fopen() for streams.

If you're on a shared host, you may not be able to modify the fopen() allowed wrappers, or it may be something you'll need to check with your provider to see if it's something they can enable for you.

This is not actually an error with Commons or Drupal, but server configuration. Will leave as postponed for the time being for continued support if needed. If not needed or if you can change server config settings, feel free to close the issue.

As a follow up, timeago could use the drupal http request API function possibly instead of fopen. This api call uses stream_socket_client instead of fsocketopen or fopen.

http://api.drupal.org/api/drupal/includes!common.inc/function/drupal_htt...

I have a folder in my sites/all/libraries folder called "timeago", which contains jquery.timeago.js.

The correct location for the TimeAgo library is profiles/commons/libraries.

Does the error persist if you upgrade to Commons 7.x-3.2 and run update.php?

I am running into this same issue.

I've tried re-adding the contents but nothing works :(

I ran into the same timeago, libraries issues as described here where when I enabled the libraries module so that I could use another module that depended on it. The timeago method seemed to break. I tried several attempts to fix it and actually found one that worked. And I needed it to work as the 'timeago' error was breaking all javascript on the site which is probably a whole other issue.

Attempt # 1

Before I describe this, let me tell you that the source code was correctly calling in the jquery.timeago.js and timeago.js files in that order. So I am not sure why enabling the libraries module would break anything.

Anyway, I moved the timeago library from profiles/commons/libraries, where it was initially, into the sites/all/libraries. This did nothing but cause more errors. No problem, then I should be able to just switch it back!?

Attempt # 2

I moved the timeago library back to profiles/commons/libraries and the same errors from attempt 1 were still present. So I disabled the libraries module to see if I could at least get rid of the new errors that attempt 1 caused. Disabling it did not remove the erros, but finally caused an error that I could work from. It said a the jquery.timeago.js file was not found in profiles/commons/modules/contrib/timeago. I don't know why it would look in the module folder when it's supposed to be a separate library, but that's where it was looking.

Attempt # 3

Since the site was looking in the module folder for the file, I decided to go against common practice and placed the jquery.timeago.js inside the timeago folder. This cleared up the error allowing the rest of the javascript on the page to run without error.

Attempt # 4

I figured since the error was now gone, I should try enabling the libraries module and the module that originally depended on the libraries module. I enabled both modules and now the site seems to be working properly again. I flushed cache and ran cron just for extra measure. With the jquery.timeago.js inside the timeago module folder, I can get back to work.

Indeed, on a fresh install of Commons packaged via build-commons-dev.make, I see that the timestamps in the activity stream are not being turned into "...ago" format.

I did a fresh install of Commons 7.x-3.0, where the TimeAgo rewriting worked, to compare the markup we're getting currently (since there are no JavaScript errors in the console).

Here's a screenshot of the differences in the markup which suggest that there's been a change in the time format being output in the activity stream's title property.

I am getting the same errors as the original post, running commons 7.x.3.2 .
I tend to agree with comment #1 that it's a server config problem in my case, since i only see the error after i migrated to a new server host.
All the same, i'm wondering if anyone has suggestions what server misconfiguration is causing the problem and how i might fix it? I have tried adding this to my .htaccess, with no effect.

php_value allow_url_fopen On

EDIT:

OK, got my situation fixed; it was a server configuration.
In my case, i have to run PHP as a CGI, by adding these lines to my .htaccess

Action application/x-pair-sphp5 /cgi-sys/php-cgiwrap/incite/php5.cgi
AddType application/x-pair-sphp5 .php

Which then means that I have to set up my php config variables NOT in my htaccess file but in a cgi-bin/php.ini file . So I added this line to php.ini

allow_url_fopen       = On

and that fixed this error for me.

hope this can help someone else, or i can also delete this comment from the thread if it's off topic of the original issue....

I to ran into this issue and can confirm that by setting the allow_url_fopen = On in my php.ini and clearing caches had worked.

EDIT - the above server config cleared up the errors but I am running into the same errors now with timeago not formatting correctly.

Edit #2 - Digging further I'm seeing that the markup for the dates no matter where they are in the site is:
<span class=​"timeago" title=​"2013-05-15T09:​21:​27-07:​00">​<span class="timeago" title="2013-05-15T09:21:27-07:00"><span property="dc:date dc:created" content="2013-05-15T09:21:27-07:00" datatype="xsd:dateTime">Wed, 2013-05-15 09:21</span></span>

This makes me think it's not just an activity stream issue but more likely an issue with what we're feeding into the date field.

As already mentioned in a number of comments, the use of drupal_http_request() is preferred over fopen() as fopen() is disabled on many servers.

Also, drupal_http_request() has additional benefits, such as user-configurable proxy server support (HTTP proxy provides a simple administration interface for doing so).

Try the attached patch.

i get the following error after patch # 14.

Fatal error: Call to undefined function timeago_get_version() in /home/xxxxxx/public_html/xxxxxx/profiles/commons/modules/contrib/timeago/timeago.install on line 43

I managed to fix by changing the hardcoded URL in the module from http://timeago.yarp.com/jquery.timeago.js to the path to the file on my site. Now all the error messages have gone when clicking into Configuration area.

The patch in #14 has an inconsistency, leading to the error pointed out by @brayo4.
The function name got an underscore added at the start of the name, but all of the function calls kept the old name without an underscore

$version = timeago_get_version($path);
function   _timeago_get_version($path, $options = array()) {
-----------^^^

removing the underscore allows it to run.

However, I'm not totally sure how to test a change in an .install file.
is it sufficient to disable and re-enable the module?

I have done the following to attempt to test the patch:
1. removed the underscore from the function name timeago_get_version
2. disabled and then enabled timeago
3. removed allow_url_fopen = On from my php config

and everything seems to be working fine, with the (modified) patch installed.

++ #11. Adding allow_url_fopen = On in fpm/php.ini was my solution.

#20 is a reroll of #14 with function name change.

Well now I'm not sure what's going on. I applied the patch in #14 a month ago and everything seemed to work fine. In the last few days, i created a dev and stg version of my site, and that seems to have introduced an error with the http_request (on all three versions dev, stg, and prod).

I now get an error when I go to the status page (admin/reports/status)
Notice: Undefined property: stdClass::$data in timeago_get_version() (line 110 of /usr/www/users/incite/incite7/profiles/commons/modules/contrib/timeago/timeago.install).

which I traced to the drupal_http_request() call returning an error value -1002 "missing schema".
Which is because the $path is of the format libraries/timeago/jquery.timeago.js and NOT a fully qualified uri.

Changing the call in line 110 to include file_create_url has fixed the issue for me.

<?php
$file = drupal_http_request(file_create_url($path))->data;
?>

But I'm not sure why it seemed like it was working and then a month later threw an error. Did I make a config change that broke things? Or is this a bug in the patch with the conversion from fopen to http_request?
Edit: the more i think about it, it's probably likely that i never looked too closely at the status page when i applied the original patch, so I just didnt notice the error until now that I was using the status page a lot because of my env changes.

patch attached per the issue I raised in #21.

Committed #22 to dev. Thanks.