Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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
Comment #1
gregglesMy 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.
Comment #2
Arashk CreditAttribution: Arashk commentedThanks 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?
Comment #3
gregglesIs 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.
Comment #4
Arashk CreditAttribution: Arashk commentedYes 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
Comment #5
timbos CreditAttribution: timbos commentedI'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);
Comment #6
gregglesInteresting.
@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.
Comment #7
Arashk CreditAttribution: Arashk commented@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 .
Comment #8
timbos CreditAttribution: timbos commentedErr... 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?
Comment #9
aaron.r.carlton CreditAttribution: aaron.r.carlton commentedsubscribing - i'm also experiencing this under php 5.3
Comment #10
roderikThat 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)
Comment #11
gregglesI 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.
Comment #12
gregglesNow fixed: http://drupal.org/cvs?commit=414988
I kind of feel like this is worth a new release. Anyone else have feelings on that?
Comment #13
roderikAgreed. 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" :)
Comment #14
gregglesSure, active is probably more accurate than postponed. Feel free to assign yourself.
Comment #15
roderik.
Comment #16
WiredEscape CreditAttribution: WiredEscape commentedBump...
Any word on new version?
Thanks,
Comment #17
jamesbrown CreditAttribution: jamesbrown commentedI 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)
Comment #18
jamesbrown CreditAttribution: jamesbrown commentedSorry, I was wrong, after updating it works.
Comment #19
jamesbrown CreditAttribution: jamesbrown commentedIt 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.
Comment #20
Crom CreditAttribution: Crom commentedsubscribing
Comment #21
Simon Georges CreditAttribution: Simon Georges commentedI can confirm it works for me too (on PHP 5.3) with the last dev version. I think it's worth a new release ;)
Comment #22
rsevero CreditAttribution: rsevero commentedThe 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.
Comment #23
rsevero CreditAttribution: rsevero commentedMarked a few issues as duplicates of this one:
#980864: Enabling browscap for device detection in mobile tools renders blank pages for my entire website
#923374: Boolean values are being stored as strings 'true' and 'false'
#919578: browscap_is_crawler is broken
#929718: Error on the first fetch of user agent data
Comment #24
Simon Georges CreditAttribution: Simon Georges commentedWorks for me (using Mobile Tools that wasn't working before (same bug as #854538: PHP 5.3 -> always mobile version)). Thanks a lot !
Comment #25
sterndata CreditAttribution: sterndata commentedInstalled 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.
Comment #26
rivimey/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
Comment #27
Taz CreditAttribution: Taz commentedpreg 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
Comment #28
aosodoev CreditAttribution: aosodoev commentedI'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.
Comment #29
aosodoev CreditAttribution: aosodoev commentedOoops, just found out that parse_ini_string was introduced in PHP 5.3. reverted some changes.
Comment #30
jzornig CreditAttribution: jzornig commentedsubscribe
Comment #31
vzsze CreditAttribution: vzsze commentedI 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.
Comment #32
spacereactor CreditAttribution: spacereactor commentedroam have you try the #29 patch?
Comment #33
vzsze CreditAttribution: vzsze commented@#32 spacereactor:
The patch from #29 works for me. Please release this as a stable version.
Comment #34
vzsze CreditAttribution: vzsze commentedSetting this to "needs work" since we need a new stable release to fix this.
Comment #35
Devin Carlson CreditAttribution: Devin Carlson commentedI 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).
Comment #36
akoepke CreditAttribution: akoepke commentedI 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.
Comment #37
Devin Carlson CreditAttribution: Devin Carlson commentedA patch for 7.x-1.x which cleans up the import.inc file and makes the changes outlined in #29.
Comment #38
Devin Carlson CreditAttribution: Devin Carlson commentedCommitted to 7.x-1.x.
Comment #39
Devin Carlson CreditAttribution: Devin Carlson commentedBackport of #37.
Comment #40
Devin Carlson CreditAttribution: Devin Carlson commentedCommitted to 6.x-1.x.