Fatal errors - category.inc sometimes not loaded?

I have a fresh install of Drupal 6.8 upgraded to 6.9 for http://www.new.dast2dast.org
When viewing the web server's log files I found this entry repeatedly:

[16-Jan-2009 12:31:25] PHP Fatal error: Call to undefined function category_display_cont_load() in /home/hsphere/local/home/eapprais/new.dast2dast.org/modules/category/category.module on line 618
[20-Jan-2009 11:23:39] PHP Fatal error: Call to undefined function category_display_cont_load() in /home/hsphere/local/home/eapprais/new.dast2dast.org/modules/category/category.module on line 618

Under Category I have the following modules installed:
Category
Category display
Category menu
Category re-save
Wrapper book
Wrapper taxonomy

Please advise

Are you using any sort of caching on your site, and if so, what level of caching? If you are using Drupal's aggressive caching feature, try turning it off and see if this fixes the problem.

No I'm' not. Caching mode is disabled for the site. Block cache, optimize CSS & JavaScript files are enabled.

Any other thoughts?

Thank you

Hi,

I upgrade my site from D-5 to D-6. I also got this error.
As per my understanding this function is defined in category.inc but it is not called from category_init() so that this problem happens. Now what can i do.

Thanks,

I didn't see any problems like this myself. Which version of Category is that? (This issue was open for alpha4, but now we have beta3.)

On beta3, the file is included in hook_init() implementation.

Yes, this is happening in beta3. I seen hook_init() where category.inc is included.

When i put that code at top of the module, then problem is solved.

Hmm, it seems like hook_init() doesn't get called, but I can't see why. Are there any unusual modules on the site? Or perhaps aggressive caching mode? Or some weird code defining the MAINTENANCE_MODE constant/switch? Just guessing, and all seems unlikely to me... :-/ It would be nice, if you discover which module(s) affect the problem, or how to reproduce on a clean D6 + Category beta 3 install.

The same got recently reported for rc1 (at #559636: Fatal error: Call to undefined function category_node_get_categories() in * * * /category/category.module on line 883). Still no clue what really happens, and why the rest of us haven't seen such a problem.

Another duplicate: #566166: Fatal error

Now, this seems to affect more people, so let's investigate more. Information collected so far:

- At least 4 people get undefined function fatal errors on various function calls going to category.inc, while others (myself including) don't
- As confirmed above, including category.inc from top of category.module seems to help
- hook_init() implementation already loads the file, and since require() is used (not just include), we would know if it failed somehow.
- This means that on some configurations hook_init() doesn't fire before the function is called.

Now I got the idea, that perhaps some other modules call Category stuff (directly or through a wrapper module) in their own hook_init() implementation, and these modules run before Category (per weights, or just per name), so category.inc is not yet loaded.

If that's the case, we might consider moving the require() into hook_boot() - which should be similar to putting it simply on top of category.module (which is ugly in Drupal, but otherwise an option too).

Still, it would be nice to know what really happens, and how to reproduce the problem. So I suggest that all people affected by this post here a full list of modules enabled on the affected sites, so that we have some starting point for tracking/finding the actual source of the problem.

Edit - yet another duplicate: #271658: Call to undefined function category_node_get_categories() - this one have a bit of discussion too. Also links to #342131: Use of hook_init() causes problems for modules with autoloading URL arguments, which is another project, but might be related.

Edit2 - yet another duplicate: #397044: missing category.inc in category_nodeapi( )

Hello.

I just moved the code outside of the function, just below, and the error message went away for me.

I am using over 100 modules, All was okay till I installed the catergory mod, I then got an instant error message upon install that had to do with SQL not having enough time to execute, I have increased the MySQL wait_timeout on my server from 30 - 45 seconds which allowed the script the needed time to execute. That was solved.

I then was able to go ahead and create some containers, it was then after clicking on those containers I got the Fatal error: Call to undefined function category_get_categories() in /home/.../public_html/sites/all/modules/category/category.module

I then went and moved the line... $output['categories'] = category_node_get_categories($node); outside of the function, and I could view my content again.

If there are any updates about this, or any proper fixes, I am subscribing to this thread, i hope to hear of any updates to this issue.

I will add more information to help with a solution if I come across anything else.

Shanni

Well, if no-one provides come clue how to reproduce the problem (i.e. which modules might be interfering), then it's unlikely to be ever fixed. The fact that errors appeared after enabling Category doesn't say anything useful, as there's obviously some interference with an other module (no matter in what order they got enabled).

Being all keen to help with this, and so stop the bulk of similar bug reports, I tried really hard to find *any* way to reproduce this problem (doesn't happen on my install, doesn't happen with core modules etc.)

Playing with filepaths, chdir(), or system table results in either no errors, or a Fatal error on the require_once() in our hook_init() - so this is certainly not the case.

After a lot of digging in code and googling around etc., I managed to get this exact error message on a category edit page (and similar errors on all other node-related pages):
Fatal error: Call to undefined function category_get_category() in /home/jirux/test-webspace/test6/sites/all/modules/category/category.module on line 875
This is fresh Drupal 6.13 install with Category 6.x-2.0-rc1, and with Global Redirect module with the optional menu access checking enabled, and additionally with weight of Global Redirect changed to -1 (so that it runs it's hook_init() before Category). This fully confirms #342131: Use of hook_init() causes problems for modules with autoloading URL arguments, except that for Category this one module is not a problem, as it normally runs *after* our hook_init per alphabet (given no-one played with module weights, both modules have default weight of zero).

So Global Redirect is most probably not the culprit here, but certainly serves as an example what might be the problem: A module with either negative weight, or name in the range 'a-c', that calls menu stuff (like menu_get_item() as Global Redirect does) in their hook_init() implementation.

Now doing that in hook_init() is quite wrong, as bootstrap is not yet finished at that point (and even more wrong in a module with weight 0 or less), so that's not a fault of Category; but if there are such modules widely used, we might want to re-consider where our .inc is loaded, for the sake of improving the reputation of Category (although that would most probably mean loading the extra code on cached pages too :-/)

BTW - we may probably use a cleaner way of loading too - but that's pretty minor cleanup:
module_load_include('inc', 'category', 'category.inc');

I searched for any other modules that may be causing this problem under normal conditions, but despite browsing all Drupal contributed modules in the A-C range of names (plus numeric), downloading another 12 modules that likely do some magic in their hook_init() and reviewing that code, I didn't find anything even remotely possible to cause this. But then again, just *any* module is quite able to set negative weight in system table, and put a bomb in their hook_init(), so we're quite unlikely to find the source this way. Most likely it would be some kind of URL redirecting, access checking, fancy caching, or similar Drupal-wide stuff based on current page properties - anyone have such modules enabled?

------------------------

Our options:

1. Someone affected provides more information, so that we can track the source of the problem properly. Downside: Not much likely to ever happen.

2. Blindly fix it by moving the require_once() to top of category.module file. There are already a few modules doing that, we'll be sure that the include is loaded as soon as category.module is, and it was already confirmed to work (#9 above). Downside: It's a hack, we can't really test a fix if we can't reproduce the problem, and we'll load unneeded code on cached pages.

3. Close the issue, because it's somehow impossible to find any reproducible problem there. Downside: I know that people will report the same bug again, so this is not a solution at all ;-)

Today I tried a different approach - summarizing the reports I found in the queue so far:

taite11 6.x-2.0-alpha4:
edit category: category_get_category() in category.module on line 785
 --> hook_nodeapi(), load a category
edit container: category_get_container() in category.module on line 788
 --> hook_nodeapi(), load a container

kuldip zala 6.x-2.0-beta3:
similar

desiree (most probably 6.x-2.0-alpha4):
category_display_cont_load() in category.module on line 618
 --> RSS feed, existence of category_display module confirmed. This one is weird, and maybe unrelated.

Shanni73:
view(?) container: category_get_categories() in category.module
 --> No such a call is present in 6.x versions of category.module, and no line number reported, so all I can say is "weird".

brianbrown 6.x-2.0-rc1 (#559636):
category_node_get_categories() in category.module on line 883
 --> hook_nodeapi(), load regular node

wibbla 6.x-2.0-rc1 (#566166):
category_get_container() category.module on line 878
 --> hook_nodeapi(), load a container

cyclops2.0  6.x-2.0-alpha1 (#271658):
viewing nodes: category_node_get_categories() in category.module on line 824
 --> hook_nodeapi(), load regular node

kilrizzy (#271658):
confirms

imgfx (#271658):
confirms, inconsistent behavior

ejwensley (#271658):
confirms, suggests putting require() into a theme function (eeeek!)

AxelBernhardt 6.x-2.0-beta2 (#397044):
category_node_get_categories() in category.module on line 796
 --> hook_nodeapi(), load regular node (2 lines off, perhaps it wasn't exactly beta2, but there's no doubt)

So there's definitely a pattern: Except two unclear/possibly unrelated reports, it's always in hook_nodeapi() case 'load', so in other words something in the big world of Drupal modules calls node_load() somehow, before hook_init() fires. That's a wrong thing to do from such (other) modules, but we have already at least 5 pointers to this same bit of code from affected users, and 4 vague confirmations of the problem.

Based on that, a google search on cvs.drupal.org finally yielded something useful - so at last steps to reproduce:
- Fresh Drupal 6 install
- Category 6.x-2.0-rc1 installed
- Install Blog Theme module (I tried 6.x-1.4)
- Visit any node (frontpage shows just fine without errors)
Fatal error: Call to undefined function category_node_get_categories() in /home/jirux/test-webspace/test6/sites/all/modules/category/category.module on line 883

It's the Blog Theme module, who's at fault. This module installs with default zero weight, and the name starts with 'b', so it's hook_init() fires before ours. They check the path [arg(0), arg(1)], and once it's node/number or comment/number, they do a full node_load() as a part of their processing - which obviously calls our hook_nodeapi() prior to our hook_init() being run. This behavior is out-of-box, no tweaks or settings needed, and the module have a stable 6.x release - so this is a good candidate for a culprit here.

Obviously, there might be also other modules offending in a similar way. Although this is definitely not a fault of Category, I believe we can add a simple fix to avoid such problems (and we quite need IMO, because having issue queue full of Fatal Errors reported doesn't look good, whathever the real reason is).

So I suggest to just repeat the require_once() at the top of hook_nodeapi(). This will just ensure that the file is loaded when we need it, it definitely doesn't mean loading it when unnecessary (i.e. definitely not on cached pages). The require call does nothing if the file is already loaded, and performance-wise a quick check if a file is loaded is _nothing_ in the node_load() process (which is quite expensive by itself, and not much frequent).

I see that at least two other modules on my setup do a similar thing: event.module and views.module. They load their includes only when needed (not in hook_init() ), which might be a good idea for us too, but that would need quite a bit of research what's called from where across category package, so definitely out of scope for this issue. But at least, event.module is also a node-oriented module, and avoids this sort of problems. Let's take the same route in category.

Going to roll a patch.

It would be nice if the affected users confirmed, whether they have Blog Theme module installed (and best of all full list of modules, so that we can see whether there's some other pattern).

Patch attached. I tested, and it fixes the problem with Blog Theme module.

Additionally there's a bit of cleanup, in that we now switch from plain require_once() with complicated argument building, to module_load_include(). It does exactly the same thing in the end.

Edit: I also filed #582382: Blog Theme causes Fatal Errors in other modules, due to bad hook_init() implementation over at Blog Theme. Still not sure whether it's the only culprit, though.

Thanks for this, JirkaRybka. Committed to HEAD.

I don't have Blog Theme and I have no event module. All I had was views.