Fatal error: Call to undefined function rules_include()

patch drupal with simpletest? simpletest is a module ...

is the Rules module enabled?

Same problem with pressflow core

Is because rules module is installed with an higher weight as is submodules. This is in rules.install . Should it be so ?

OMG, Simpletest for D6 needs a core patch ...
Works for me on a standard Drupal, when patching core and enabling Simpletest. The module weight only determines the hook execution order, so that is not the cause of the problem.

Having the same problem Only with PHP5.3. What I did to solve this is manually set rules* modules to inactive in DB and reactivate them in module admin page.

Spoke too soon, the problem somehow has returned after working for awhile, no changes performed.

For my case it does not seems to be simpletest related (disabled). Having the exact same site running perfectly under PHP 5.2. Am testing out the site under PHP 5.3 and getting "Fatal error: Call to undefined function rules_include() in rules_admin/rules_admin.sets.inc".

To replicate, just using PHP5.3 and enable the rules_admin module, you will get WSOD with the above error.

I was just blessed with this error on my development environment, completely and utterly out of the blue (hadn't been working with rules admin for at least 4 weeks).

All site pages just started giving me a wsod. Was unable to disable the module with drush (because some site features depend on it, and i didnt want to disable the features..) so I had to manually set the status of rules_admin module in the {system} table to 0, load a page (which loaded fine), then reset the status back to 1, and load a page (loaded fine).

Strange. I'd say this problem may not occur as when the rules_admin.sets.inc is getting included, drupal must have been bootstrapped, and so the rules module must be loaded - as rules_admin depends on it.

Question: On which pages does that error occur? Only the rules-admin rule-sets pages or others too?

For my case, WSOD on every pages as long as rules_admin is enabled, but only on PHP5.3. I've tested the site under another PHP 5.2 server and downgrade the problematic one, the problem no longer appear.

In my case, the error showed up in any page request, including admin screens and front page. PHP 5.2

Sry, guys. I really have no idea what's the cause for this problem. I've searched for rules_admin.sets.inc, but it only gets included via the menu system, thus at that point Drupal has to be loaded. Also that's only the case for the rules admin UI.

So maybe you use any module / performance thingie that goes and includes all files? Perhaps you can somehow identify how or what includes the file. That would help.

Yeah, its really impossible to test why this happens, once it does, cause its so random. If it happens again i'll try to run through the process with xdebug.

We'll I hit this issue again, and wasn't exactly successful in stepping through... no idea where best to set the breakpoint, and its waaaay to early after a long night of hacking to continue to step through this right now... but, the root of the problem seems to be related to lazy module loading, interfering with drupal menu workings....

FWIW, adding the following line of code just before the call to rules_include() in rules_admin.sets.inc solves the error.

require_once drupal_get_path('module', 'rules'). '/rules.module';

Thank you jrguitar21 for your tip in item #21. It solved this problem for me tonight.

I have little further information to offer about where this bug might be coming from. In my case I was debugging a user module that was throwing a bizarre and frustratingly intermittent menu router error. It was in the process of turning off and on recently installed modules that I came across the same error at the top of this thread. I was only able to get pages to display again by including the tip from #16. I would suggest that this be added to the development version to prevent others from having this problem in the future.

(Also, I eventually found that the bizarre menu router problem was being caused by a slightly mis-typed include_once directive. Since often the file in question had been include before, the chance of hitting the include with the error was very low and hence appeared to be intermittent. End of a long day with both major bugs seemingly solved...) Cheers!

Sounds like a bug in the menu system then? The question is what triggers that.

My hunch / reasoning was that due to caching or the menu cache getting "out of sync" or something (eg perhaps after copying a database down from production to development?) the menu-item's include gets run at a lower bootstrap level than "normal", when all modules would be loaded. Of course I have no way to prove this right now, just a hunch.

I'm seeing this too.

Looking at the code, executing rules_include('rules_admin') ultimately just loads rules_admin/rules_admin.inc, which could be done much cleaner like this:

include_once('rules_admin.inc');

Sorry, fat-fingered the last patch X-)

#21++ better solution than #16.

BTW, I've just this evening come across other modules that have had issues of random things happening when dealing with menu system. Since this file gets included directly from the menu system, my hunch is that this is yet another instance of funky business from the menu system.

#775362: og_forum: access checking fails, if menu_get_item() runs before og_init()
#285696: array_keys error

I had this issue too (only when moving a site to a different server), #21 solved it. Agreed that an include_once() makes the most sense here.

At least we'll have todo a clean include statement not relying on the php include being set, ala the above

require_once drupal_get_path('module', 'rules'). '/rules.module';

Still I think something else is wrong here and this is just a try to fix the symptom, I guess the underlying problem also causes #1027034: Call to undefined function rules_get_items() on updating from 1.3 to 1.4.

fago,

Your comment #24 caused a light bulb to go off in my head. If one were to review my postings to drupal.org over the past six weeks or so, one might notice a consistent theme about trying to track down an elusive menu router problem in my custom modules. I finally seemed to resolve that last week and have not had any problems since.

In my case, I originally had coded my modules akin to:

  // Header area
  $module_path = drupal_get_path('module', 'xyz');
  $module_name = 'xyz';
  include_once($module_path . '/include/' . module_name . '.abc.inc');

  // Functions defined in file

It was incredibly perplexing about where the error might be. It only showed up occasionally and in a seemingly inconsistent manner. I finally solved the problem by replacing the drupal_get_path call with the following:

  $module_path = dirname(__FILE__);

Apparently, somewhere in the /admin/build/modules and update.php process the function drupal_get_path() is not yet defined in the bootstrap process. At this point, I do not recall exactly where in the process this occurred. However, I finally found that it was undeclared in reviewing trace logs with the highest level of reporting enabled. Obviously, most of the time drupal has initiated itself and drupal_get_path() is available. There are some cases though where it apparently is unavailable when the files for a module are read (I suspect in building the menu router table).

I would suggest replacing the call to drupal specific functions in the header area with only pure PHP functions. This cleaned up my problem and when I saw your comment about 'require_once drupal_get_path(', it made me wonder if the rules module is not having the same problem.

Hopefully this insight is a help. Cheers!!

Rewrote patch to base off of #16, as requested in #24. However, I still believe what Damien says is true. *Somehow* rules module isn't loaded at the time this file is processed, and performance-wise it makes no sense at all to include the Rule module file, just to use a single function that does nothing more than wraps include functionality.

Could we use module_load_include? I'm currently not experiencing the issue anymore, to be able to test this, but I'd now suggest something like:

module_load_include('inc', 'rules_admin', 'rules_admin');

Create the patch from the right directory :/

>+require_once drupal_get_path('module', 'rules'). '/rules.module';

That might fix this symptom, but not the problem. Then it's really silly to have to include the .module file of a dependency. We need to find the cause of this instead of wasting our time with fixing symptoms.

Lets break this down:

• The "rules_admin.sets.inc" file is identified as the file to load for a given menu item.
• Because of an apparent bug in Drupal, under certain circumstances when "rules_admin.sets.inc" is loaded it has not yet loaded "rules.module" so the rules_include() call fails.
• At the top of this file the "rules_admin.sets.inc" file executes rules_include('rules_admin');
  • This requires the "rules.module" file to be loaded.
  • The "rules_include"() function goes through a process to decide what to do.
  • Because the 'rules_admin' argument is passed to the function, it then runs the following line: $files = array(drupal_get_path('module', 'rules_admin') .'/rules_admin.inc');
  • This adds the full path to the "rules_admin.inc" file from the "rules_admin" module to an array.
  • It then runs include_once() over the array of files, which in this case is just the "rules_admin.inc" file.
  • End result: "rules_admin.inc" is loaded from the same directory as the file the load request came from, "rules_admin.sets.inc".
• Alternative #1:

  •  include_once(drupal_get_path('module', 'rules'). '/rules.module');
    rules_include('rules_admin'); 

  • Same end result.
  • "Solves" the problem by loading another file first.
  • Adds additional function calls thus adds even more processor time.
• Alternative #2:
  • include_once(drupal_get_path('module', 'rules_admin'). '/rules_admin.inc');
  • Same end result.
  • It still executes drupal_set_path(), which is unnecessary for files in the current directory.
• Alternative #3:
  • include_once('./rules_admin.inc');
  • Same end result.
  • No unnecessary function calls.
• Remember how at Drupalcon 2010 Rasmus Ledorf complained about Drupal's over-use of code to identify file paths? This is a perfect example.
• Create a separate issue for Drupal core to identify the root of the problem, but there are still sites out there for which Rules broke because of this completely unnecessary obfuscation and we'd appreciate the patch from #21 to be committed.

I'm not willing to add work-a-rounds for obscure core-bugs, and if you really have an interest in the bug being fixed you are able to create an issue for core yourself. Then you are not supposed to RTBC your own suggestion.

Anyway, your suggested alternative #2 looks ok to me (also see #24), so please report whether this fixes the problem.

Like a number of the other contributors to this thread, I too have been having strange menu router "troubles" as I have updated to Drupal 6.20 about a month ago. As a result, I have spent quite a bit of time trying to debug ("unsuccessfully" quite often) the seemingly random menu_router errors that have popped up. Coupled with an upgrade to PHP 5.3 and the associated reference-by-value vis-a-vis reference-by-value problems, I have updated several contributed modules on my website.

From this experience, I have a few insights that might help. These include:

1) When referencing core include or require files, do NOT assume that Drupal necessarily is running from what we know as DRUPAL_ROOT in D7. Drush and a few users sometimes perform operations from further down in the directory tree. Hence, one should always explicitly build the path relative to a DRUPAL_PATH (which of course does not exist in D6) or its equivalent.

2) To solve a problem in the devel module with drupal root definition, I created a function devel_drupal_root() that is attached in thread #752366: Fatal error: Call to undefined function decode_entities() in devel.module in item #27. You might want to test that out and use something similar to it in setting your own base from which to build up a complete path for the include files.

3) At some point in the menu/module/theme rebuild process, drupal is not in a fully booted state. From my TRACE logs, I noticed much to my surprise that drupal_get_path() (which is part of the common.inc file) was not yet defined. Hence, my call to the equivalent of druapl_path / [module_name] / include / xyz.inc was returning spurious values which were then entered into the menu_router table.

Of course, in fully booted state, Drupal has defined drupal_get_path and nothing appears to be wrong with the inclusion path. Hence, for my own modules, I have resorted to explictly checking that drupal_get_path() exists and if necessary building equivalent constructs from the name and location of the source code file.

For my own modules at least, this close attention to include paths and what is defined when has eliminated the menu_router problems that I was seeing with these modules. I hope this helps others in tracking down menu_router troubles.

Cheers!!

RTBC Alternative #3

Forgetting the bug in the core menu system, #3 looks to me like a code enhancement that reduces the number of instruction sets required in order to include a file in the same directory. It also, just happens to double as a fix for a bug being experienced by your module's clever include system not playing well with core. ;)

Could you please elaborate your reasoning behind NOT using a direct include_once ? Its not clear how something this straightforward could get labeled as a work-around for a core bug and disregarded so easily.

I created an issue for the core bug that leads to this: #1043656: Menu cache refresh does not execute after a full bootstrap, causing some includes to fail

ad #32:
I think the reasoning was to provide an easy way to include UI related functions for any module building upon rules. Anyway, I'm fine with using simple include statement (independent of the menu bug).

However, probably best would be using something like that?

require_once dirname(__FILE__) . '/rules_admin.inc';

Fago,

I think that should fix most of the cases (absent a fix of the menu bug regarding drupal_root). It works for me.

Cheers!!

I have this problem. It appeared when I moved a live site to a new host and switched from Acquia D6 to Pressflow. Can anyone tell me which patch I should apply? #34 is not a patch and it seems to differ from the patch in #21. Help would be much appreciated.

So how do we fix it?

@AntiNSA:

According to #34, and looking at patch in #26, for placement.

In, rules_admin.sets.inc, you should replace the line that says:

rules_include('rules_admin');

with

require_once dirname(__FILE__) . '/rules_admin.inc';

please test it, report back and roll a patch if you're so inclined ;)

ok, I finally committed the solution outlined in #34.

#34 worked for me. Thanks Fago!

Updated component.