Requires are unanchored

I believe the style of that require_once is the same as a core and a lot of other popular modules. Can you find examples of modules/core where it uses the anchor as you describe?

#259623: Broken autoloader: convert includes/requires to use absolute paths

That's what I was looking for. So, yes, let's fix this to be like core.

@gpk - how does this look?

@everyone else - tests? please?

I just tested the patch and it still generates the same error, the only difference is that now there's an additional ./ in the error message.

Before:

require_once(sites/all/modules/pathauto/pathauto.inc) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in /home/user/html/sites/all/modules/pathauto/pathauto.module on line 85.

After:

require_once(./sites/all/modules/pathauto/pathauto.inc) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in /home/user/html/sites/all/modules/pathauto/pathauto.module on line 85.

I'm willing to test this further if anyone comes up with other ideas. Its really killing me to have php errors showing up every 45 minutes in my logs. Ok, well not really killing me, but yeah, its bucking the flow of the tao...

:/

it doesn't relate to a page/node/or any other normal "live site" functionality. This php error appears in watchdog only DIRECTLY AFTER a "Cron Complete" message. There is no other information I can supply at this point other than the error message that's already been outlined. Its only happening on a production server so I'm not too keen on enabling php backtrace.

i run cron via crontab. i added the snippet, but it generated too much stuff in watchdog i couldnt track down the one case where the value may have been different. My site is live and gets about 2000 hits an hour, so it makes this snippet impossible to use for debugging.

maybe i should try it wrapped in an if statement that only prints watchdog if the value is anything else than the expected value.... i'll try it and get back to you.

The current working directory is "/" just before the error occurs. I wanted to double check to see if any rogue modules had somehow changed the cwd during a cron run, but it appears to not be a factor.

I added the following inside the foreach loop of includes/module.inc:module_invoke_all (called by drupal_cron_run)

function module_invoke_all() {
  [...]
  foreach (module_implements($hook) as $module) {
    $function = $module .'_'. $hook;
//debug
    $cwd = getcwd();
    $path_to_drupal = '/home/user/domain.com/www/';
    if ($hook == 'cron' || $cwd != $path_to_drupal) {
      watchdog($hook, "$module cwd $cwd");
    }
//end debug
  [...]

The results generate the following in watchdog

	php	01/06/2009 - 19:25	require_once(sites/all/modules/pathauto/pathauto.inc ...
	product_types	01/06/2009 - 19:25	uc_product cwd /	
	product_types	01/06/2009 - 19:25	uc_product cwd /	
	product_types	01/06/2009 - 19:25	uc_product cwd /	
	product_types	01/06/2009 - 19:25	uc_product cwd /	
	product_types	01/06/2009 - 19:25	uc_product cwd /	
	product_types	01/06/2009 - 19:25	uc_product cwd /	
	node_info	01/06/2009 - 19:25	uc_product cwd /	
	node_info	01/06/2009 - 19:25	simplenews cwd /	
	node_info	01/06/2009 - 19:25	audio cwd /	
	node_info	01/06/2009 - 19:25	poll cwd /	
	node_info	01/06/2009 - 19:25	forum cwd /	
	node_info	01/06/2009 - 19:25	blog cwd /	
	cron	01/06/2009 - 19:25	Akismet cron started at 19:25:22.	
	cron	01/06/2009 - 19:25	Cron run completed.
	cron	01/06/2009 - 19:25	states cwd /home/user/domain.com/www
	cron	01/06/2009 - 19:25	cclinks cwd /home/user/domain.com/www
	cron	01/06/2009 - 19:25	uc_store cwd /home/user/domain.com/www
	cron	01/06/2009 - 19:25	uc_roles cwd /home/user/domain.com/www
	cron	01/06/2009 - 19:25	uc_cart cwd /home/user/domain.com/www
	cron	01/06/2009 - 19:25	simplenews cwd /home/user/domain.com/www
	cron	01/06/2009 - 19:25	....

Note that before the "cron run completed" the entries actually match the expected $path_to_drupal so the change to "/" occurs after cron.

Any ideas how i can find out more exactly when that happens or who's causing it???

the message from previous comment "Akismet cron started at 19:25:22." seems suspicious to me, but I dont know how or where to debug this any further.

I've narrowed it down to the php function register_shutdown_function!

Functions that are registered to run at the end of the cron.php script seem to have cwd set to "/".

The offending code that ends up calling pathauto happens after cron, so pathauto is getting executed after all cron runs via one of 8 methods of my drupal install (including core and modules) that registers a shutdown function.

There is a register_shutdown_function('drupal_cron_cleanup'); that is registered during drupal_cron_run(). I put a debug statement inside drupal_cron_cleanup() and sure enough, the cwd in that function is "/".

But nothing is really called in cron_cleanup, so, I'm thinking the most likely candidate is the akismet_cron_shutdown function which is registered during akismet_cron() run, cause it does a whole bunch of stuff.

more to come, maybe...

@jrguitar - the symptoms you had in #337615: require_once failure on cron with modules that have a register_shutdown_function were really similar to this. So, I directed you over here. At this point, your symptoms/causes are totally different from the original point of this issue :(

So...can we move the discussion back over there =D ?

ok. moving it back...

Is there a reason we're not simply using module_load_include()?

The attached patch uses this for 6.x... and absolute paths for 5.x-2.x, though a bit differently than the previous one.

For 6.x I agree we should use module_load_include.

These look good to me.

Alright. Unless someone else posts negative comments (or you beat me to it ;)), I'll commit these later, when I'm home. :)

gpk: But DRUPAL_ROOT isn't available in D6. Are you suggesting we go about this in a different way than #16, or... ?

I'm guessing he wasn't.

Committed to 6.x-2.x, 6.x-1.x, and 5.x-2.x.