Fatal error: Call to undefined function user_access() in modules/browscap/browscap.module on line 99

This error occurs from time to time and we cannot seem to pin it down.


venusrising’s picture

Priority: Normal » Major

This is printing in our feed and at the bottom of the page

venusrising’s picture

If permission for admin are not selected to bypass it throws an error.
It also throws an error to the RSS feed for the homepage

rfay’s picture

I have this as well. Drupal 6.24.

rfay’s picture

Workaround: Uncheck "Enable user agent log" in the settings.

Devin Carlson’s picture

I think I finally managed to figure this out.

hook_exit() runs at the end of each page request and runs even for cached page views. If the page is cached then Drupal may still be in bootstrap mode and certain modules may not yet be loaded (in the case of this error, user.module).

I can think of a few ways to fix this, but I'm not sure which fix is best.

  • Remove the ability to bypass browscap monitoring (not good since it was one of the most requested features).
  • Only enable monitoring on non-cached pages (not good since I'm sure most people want to use monitoring with cached content).
  • Use drupal_load() to ensure that user.module is loaded when trying to check user permissions (good but I'm not sure how much additional load this create on each page request).
  • Do a module_exists('user') and allow monitoring to be bypassed when user.module is loaded (on uncached pages) and record every user agent (even if they have bypass permissions) when they view cached content.

If anyone has any suggestions, I'd very much appreciate them. In the mean time, the error can be bypassed by disabling user agent logging as rfay mentioned.

izmeez’s picture

Same issue with 6x-1.4 on login page, using logintoboggan. Revert to 1.3 no problem.
imho, with WSOD this is critical to using this update of the module.

Devin Carlson’s picture

Version: 6.x-1.4 » 7.x-1.x-dev
Assigned: Unassigned » Devin Carlson
Status: Active » Needs review
2.14 KB

After giving this some more thought, I think that the best approach would be to attempt user agent recording both during init() and during exit(). That way, "processing" such as checking for user access, can occur during init() before recording the user agent on non-cached pages but recording would also happen during exit() to catch user agents visiting cached pages.

In order to prevent duplicate recordings, a static variable in a helper function could track if recording has already happened in init() and prevent another recording from happening during exit(). This will still prevent authenticated users from being accidentally recorded as an authenticated user will not get served a cached page.

The only "issue" with this implementation is that giving anonymous users the ability to bypass user agent monitoring will not work on cached pages, but, to my knowledge, there is no way around that and there isn't much point to not recording anonymous users.

Devin Carlson’s picture

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

Committed to 7.x-1.x.

Devin Carlson’s picture

Status: Patch (to be ported) » Needs review
2.57 KB

Backport of #7.

Devin Carlson’s picture

Status: Needs review » Fixed

Committed to 6.x-1.x.

Please test the latest git checkouts (or -dev releases after they are built) and to confirm that this issue is solved.

izmeez’s picture

I can confirm the new 6.x-1.x-dev update appears to work with no more WSOD.

Status: Fixed » Closed (fixed)

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

gransar’s picture

@rfay there is no settings anymore... this error prevents dashboard from loading..

rfay’s picture

@gransar you don't mention what version you're using. This should be resolved in all current versions.