Hi dear maintainers,
I just started using this module and found out that it wasn't working. when I clicked the "refresh now" link in the settings page, the page refreshed but nothing changed and the status is still "Never Fetched".
I'm testing this on my dev environment using Xampp.
I took a look at module's code and I found that this part of code of .module file is not working:

345.  $browscapfp = fopen($browscapfile, "w");
346.  fwrite($browscapfp, $browscap->data);
347.  fclose($browscapfp);
349.  $a = parse_ini_file($browscapfile, TRUE);
  // $a is empty here
350.  if ($a) {

the condition is false so nothing is updated.

I don't know why this is happening, if any more information is needed I will be more than happy to provide to get the module work.
Thanks

Comments

My guess is that the original fopen is failing because fopen is disallowed (or disallowed from opening remote sites) in your configuration of php.

Really there is no good reason to use fopen and we should use drupal_http_request.

Thanks for your guess greggles.

I think that's not the problem because I have checked and the file was created. so I think fopen is working in this case and the problem lies in line 349, somehow the parse_ini_file function is not working! any idea?

Is it a valid ini file? If the file downloads and the webserver can read it then the next guess is that the file is somehow malformed - though I doubt that's the case.

Yes I double-checked the file and it is valid. I have narrowed the problem down this much and still nothing... maybe I'm wrong, have to triple check everything.

Thanks

I've seen this problem too. I believe that it's related to php version 5.3 -- see here:
http://code.google.com/p/phpbrowscap/issues/detail?id=11

I got the browser version fetching to work by changing line 349 from:

$a = parse_ini_file($browscapfile, TRUE);

to
$a = parse_ini_file($browscapfile, TRUE, INI_SCANNER_RAW);

Interesting.

@Arashk are you also using php 5.3?

@timbos - are there any negative consequences to adding that parameter under php 4.x? It looks like that optional parameter was added in 5.3.0, so we may create notices or something if we add this and run it under php 5.2 or lower.

@timbos - Thanks for this useful tip, that was the exact problem, problem solved. You helped a lot... :x

@greggles - Yes my php version was 5.3 .

Status:Active» Needs review
StatusFileSize
new25.56 KB

are there any negative consequences to adding that parameter under php 4.x? It looks like that optional parameter was added in 5.3.0, so we may create notices or something if we add this and run it under php 5.2 or lower.

Err... I don't know: not sure if PHP will overlook the extra parameter or not (I don't have an install of php4 at my fingertips to try with right now). The page that I referenced above does suggest adding a test to see which version of PHP is installed and using an appropriate call to the parse_ini_file() function. Perhaps the attached patch, which works with my php 5.3, will solve things?

subscribing - i'm also experiencing this under php 5.3

Status:Needs review» Reviewed & tested by the community
StatusFileSize
new631 bytes

That patch is HUGE. It's probably comparing your working version against a different, ancient, CVS branch.

Here's the isolated patch. I'm setting it to RTBC: 'works for me' - and happens to be equal to the change which Gary Keith committed to his github repo for phpbrowscap, yesterday.
(See link in #5)

I think an alternative is to use http://api.drupal.org/api/function/drupal_parse_info_file which not only is safe across php 5.2/5.3 but *also* is available on most hosts. Apparently some hosting companies disable parse_ini_file in their php configuration for security reasons.

@roderik - can you test that out and perhaps provide a patch?

Thanks for your work on this issue.

Title:Code for fetching last version breaksUpdate parse_ini_file for php 5.3
Status:Reviewed & tested by the community» Fixed

Now fixed: http://drupal.org/cvs?commit=414988

I kind of feel like this is worth a new release. Anyone else have feelings on that?

Agreed. Because with the current stable version, you don't "see" the bug. Users get no feedback on why this is happening and get frustrated or think the whole thing isn't working.

On another note: you want me to assign this ticket to myself and set it to 'postponed', before it closes?
Then I'll remember to do your #11 request sometime. Probably by the time something freezes over, because "stuff works for me now so there's other things to tend to" :)

Title:Update parse_ini_file for php 5.3Consider using parse_info_file
Status:Fixed» Active

Sure, active is probably more accurate than postponed. Feel free to assign yourself.

Assigned:Unassigned» roderik

.

Bump...
Any word on new version?

Thanks,

I have the above problem too.
I have installed the version 6.x-1.x-dev of 2 September 2010 but that problem was remained.
I have the next code in my brosecap module:
if (version_compare(PHP_VERSION, '5.3.0', '>=')) {
$a = parse_ini_file($browscapfile, TRUE, INI_SCANNER_RAW);
}
else {
$a = parse_ini_file($browscapfile, TRUE);
}
but seems it doesn't work.

PHP 5.3.3 with Suhosin-Patch (cli) (built: Aug 29 2010 10:25:06)

Sorry, I was wrong, after updating it works.

It works but with the next problems.
It doesn't recognize crawlers, in the one side.
In the another side, in spite of the first, after activation "Do not log visits from search engines and crawlers" it doesn't log anithing into "Top referrers", "Recent hits" and etc.

subscribing

I can confirm it works for me too (on PHP 5.3) with the last dev version. I think it's worth a new release ;)

Title:Consider using parse_info_fileValues returned as bool with PHP < 5.3 should also be bool with PHP >= 5.3
Status:Active» Needs review
StatusFileSize
new1.96 KB

The current solution for PHP 5.3 changes the results previously returned by browscap_get_browser().

Previously 'true' and 'false' string values present in downloaded browscap.ini file where returned by browscap_get_browser() as boolean values. With the current solution for PHP 5.3 these values are returned as strings 'true' and 'false'.

This is already causing trouble in modules that relay on Browscap. There is at least one serious issue in "Mobile Theme" related to this: #854538: PHP 5.3 -> always mobile version.

The attached patch fixes this issue making Browscap return bool values for PHP pre 5.3 and pos 5.3.

About the suggestion on #11 from greggles to use drupal_parse_info_file() instead of parse_ini_file(): the results from drupal_parse_info_file() seemed to be very different from the ones from parse_ini_file() widening the gap between pre PHP 5.3 and pos PHP 5.3 results instead of removing the gap.

Works for me (using Mobile Tools that wasn't working before (same bug as #854538: PHP 5.3 -> always mobile version)). Thanks a lot !

Installed 6.1.x.dev on php 5.3.3. Clicking "refresh now" returns "Couldn't check version: missing schema". Applied the patch from #22, with no improvement.

/me too.
I had the problem with the ";" within the title being interpreted as a comment. I've tried using the preg_replace fix but for some reason it didn't work. I've tried the INI_SCANNER_RAW fix (though without the "bool" part of the fix so far), but now I get the "missing schema" error mentioned by sterndata.
This is on php-5.3.3, drupal 6.

Ruth

Status:Needs review» Reviewed & tested by the community

preg fix does not work
The array walk code + the modification to the parse_ini function for PHP 5.3 does work no problems.

Tested on the latest 6-dev version

StatusFileSize
new1.69 KB

I've deleted some code and added a very simple fix. Should work a bit faster this way.

Attached patch for latest 6.x-1.x-dev release.

It works like a charm for me.

Status:Reviewed & tested by the community» Needs review
StatusFileSize
new2.33 KB

Ooops, just found out that parse_ini_string was introduced in PHP 5.3. reverted some changes.

subscribe

I still see this issue with the recommended version. PHP-5.3 is getting more widespread. When will there be a release to fix this bug? I also tested the dev version. It fetches the browscap data, but nothing is classified as crawler, ever. I also noticed, that the latest hits log sometimes stopps untill i deactivate the browsecap module. I can provide additional information about my setup, if needed.

roam have you try the #29 patch?

@#32 spacereactor:
The patch from #29 works for me. Please release this as a stable version.

Status:Needs review» Needs work

Setting this to "needs work" since we need a new stable release to fix this.

Version:6.x-1.1» 6.x-1.x-dev
Assigned:roderik» Devin Carlson
Status:Needs work» Needs review

I found out that the latest version of the Acquia Dev Desktop allows you to easily switch between PHP 5.2 and 5.3.

From my own testing there doesn't appear to be any issues with Browscap 7.x, so I'll test the fix in #29 and get it committed (if it fixes the issue).

I think this issue is the root cause of the problems I was having here: #1163504: Boolean evaluation - everything is a crawler.

I am running v7 though (on PHP 5.3.4), and this patch applies to v6. I manually changed the two lines of the import code using the lines from the patch and reimported the data. This has now resolved my issue with the boolean evaluations.

Devin, I noted that you have not encountered this issue with Browscap 7 so am confused as to what is different between my install and yours.

Version:6.x-1.x-dev» 7.x-1.x-dev
Priority:Normal» Major
StatusFileSize
new8.12 KB

A patch for 7.x-1.x which cleans up the import.inc file and makes the changes outlined in #29.

Version:7.x-1.x-dev» 6.x-1.x-dev
Status:Needs review» Patch (to be ported)

Committed to 7.x-1.x.

Status:Patch (to be ported)» Needs review
StatusFileSize
new8.1 KB

Backport of #37.

Status:Needs review» Fixed

Committed to 6.x-1.x.

Status:Fixed» Closed (fixed)

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