call to undefined function pathauto_get_placeholders

Ok, I have the answer. I also have a work-around, but I don't know what the right fix is. First, here's the code in pathauto.module for pathauto_menu():

function pathauto_menu($may_cache) {

  $items = array();
  if ($may_cache) {
    $items[] = array(
      'path' => 'admin/settings/pathauto',
      'title' => t('Pathauto'),
      'description' => t('Configure how pathauto generates clean URLs for your content.'),
      'callback' => 'drupal_get_form',
      'callback arguments' => array('pathauto_admin_settings'),
      'access' => user_access('administer pathauto'),
      'type' => MENU_NORMAL_ITEM,
    );
    $items[] = array(
      'path' => 'admin/build/path/delete_all',
      'title' => t('Delete all aliases'),
      'callback' => 'drupal_get_form',
      'callback arguments' => array('pathauto_admin_delete_confirm'),
      'access' => user_access('administer url aliases'),
      'type' => MENU_LOCAL_TASK,
    );
  }
  else {
    // Include any extensions installed in the pathauto directory
    $pathauto_path = drupal_get_path('module', 'pathauto');
    include_once("$pathauto_path/pathauto.inc");
    include_once("$pathauto_path/pathauto_node.inc");
    include_once("$pathauto_path/pathauto_taxonomy.inc");
    include_once("$pathauto_path/pathauto_user.inc");
    include_once("$pathauto_path/contrib/pathauto_node_event.inc");
    include_once("$pathauto_path/contrib/pathauto_node_i18n.inc");
    unset($pathauto_path);
  }

  return $items;
}

Here's what I believe is happening: When using XML-RPC, the normal initialization process is changed and the hook_menu() functions aren't called. Therefore, the includes aren't executed and the pathauto_get_placeholders() function is not defined.

The work-around is to move the includes to a "normal" position, say, at the top of the file. This solved the problem for me. I have no idea what the advantage is of delaying the includes—keep in mind that the module file isn't loaded unless the module is enabled (only the info file is always loaded).

I don't know if this is a pathauto bug or a Drupal core bug. The Pro Drupal Development book suggests that there are two places to insert initialization code: in hook_init() and hook_menu(). hook_init() doesn't always work because it is called before some Drupal functions are defined; the book's advice if this occurs is to move the code to hook_menu(). If this is correct usage of hook_menu(), then XML-RPC calls should also call hook_menu(). If this is not true, then pathauto needs to be fixed—plus the Drupal core should consider adding something like hook_post_init(), which would be called after all the core initialization was complete.

The other reasons to use hook_menu instead of _init is that _init loads the code on every page which slows the performance of the site and also means you can't use the module with "aggressive" caching.

Your problem is an interesting one, though. I certainly want this to work for remote blogging tools.

Can you try this - move those functions inside of hook_init inside

function pathauto_init() {
if (function_exists('drupal_set_content')) {
// we don't do this in hook_menu to ensure the files are already included
// Include any extensions installed in the pathauto directory
$pathauto_path = drupal_get_path('module', 'pathauto');
include_once("$pathauto_path/pathauto.inc");
include_once("$pathauto_path/pathauto_node.inc");
include_once("$pathauto_path/pathauto_taxonomy.inc");
include_once("$pathauto_path/pathauto_user.inc");
include_once("$pathauto_path/contrib/pathauto_node_event.inc");
include_once("$pathauto_path/contrib/pathauto_node_i18n.inc");
unset($pathauto_path);
}
}

What's the advantage of placing the includes in pathauto_init() vs. placing them at the top of the file? Doesn't Drupal load enabled modules and then call their 'init' method? If so, then the include statements would be executed at almost the same place in the initialization sequence.

As you mention, pathauto_init() forces the module to be loaded even for cached pages. So it seems placing the includes at the top of the file (outside hook_ini()) is a better solution. I haven't noted any problems since I made that change.

P.S. If you'd like to experiment, get w.bloggar (a free blogging tool). Under the blog choices, it includes Drupal, which makes it easy to set up.

I believe it's mostly a style matter and that putting it in the _init is the , but the if(function_exists()) test I added should reduce the amount of time that it's run.

Your sentence was cut off, but I'm not sure if I would understand it if it weren't.

With code in hook_init:
With cached pages: module loaded, include files not loaded(?)
With non-cached pages: module loaded, include files loaded

With code at top of file:
With cached pages: module not loaded, include files not loaded
With non-cached pages: module loaded, include files loaded

Please correct me if I'm wrong; I'm no Drupal expert (just following along in the Pro Drupal Development book). It seems that the hook_init approach adds a performance penalty. I'd be willing to sacrifice on style.

Just my 2 cents. It's your module, so feel free to fix it however you think best.

Find a core module or file that does it your way and I'll do it your way.

Here's a slightly different approach.

I've got the includes in their own function and then, in the three places that need functions from the includes, I call that function.

I believe this is the best solution to the problem and will result in very minimal amount of code being loaded, but I would appreciate testing from folks that use remote blogging tools and/or cron to import nodes.

Looks like there is a problem which is great to highlight it and improve the wonderful functionality.
Am I understanding that there's a fix or are you guys arguing over the correct manner in which a test is to take place?

Not exactly. First, I hope I wasn't coming across as arguing. Apologies if I was. Second, we were "discussing" the best way to fix the problem, not the best way to test the fix.

Find a core module or file that does it your way and I'll do it your way.

Again, not arguing—or even pushing for my approach. I'd love to know what the best solution is.

I did take on your challenge and looked at all core modules. None had includes at the top, but none had includes in a hook_init() method either. So that doesn't settle anything.

I've got the includes in their own function and then, in the three places that need functions from the includes, I call that function.

I did find examples in the core modules where people did this. This delays loading code until needed ("lazy" loading), so it sounds fine to me.

On another topic, I noticed that Rasmus Lerdof start talking about the cost of include_once as opposed to include. I also found a PHP performance write-up by Ilia Alshanetsky http://www.ilia.ws/ that also discusses the "_once" penalty as well as the penalty of relying on the include path.

So if you want to optimize your code even further and since there are six includes, you could do this:

1. Inside your first include file, set $pathauto_include_files_loaded = true;
2. Before calling the chunk of code that includes the files, write: if (isset($pathauto_include_files_loaded)) _pathauto_include(); This saves a function call. I call isset() to avoid any possibility of an error if the variable is undefined. And using '@' to suppress an error message (as in if (@$pathauto_include_files_loaded) ...) also carries a performance penalty.
3. Use 'include' instead of 'include_once'.

Since the files are always relative to the pathauto module, you could also use an absolute path to avoid the penalty of the include path:

$pathauto_path = dirname(__FILE__);
include "$pathauto_path/pathauto.inc";
...

This also avoids the overhead of drupal_get_path(), which looks like a rather expensive call.

I'll admit I wrote this off the top of my head, so no guarantees. And to be clear: these are just suggestions.

I'll try your patch and see what happens.

OK, I tried your patch. The patch failed on line 325, but I finished the changes by hand. Works fine.

Then I tried:

function _pathauto_include() {
  $pathauto_path = dirname(__FILE__);
  include_once("$pathauto_path/pathauto.inc");
  include_once("$pathauto_path/pathauto_node.inc");
  include_once("$pathauto_path/pathauto_taxonomy.inc");
  include_once("$pathauto_path/pathauto_user.inc");
  include_once("$pathauto_path/contrib/pathauto_node_event.inc");
  include_once("$pathauto_path/contrib/pathauto_node_i18n.inc");
}

That worked fine, too.

Finally I added this to pathauto.inc:

$GLOBALS['pathauto_include_files_loaded'] = true;

and changed each of the three functions to use:

  global $pathauto_include_files_loaded;
  if (!isset($pathauto_include_files_loaded)) _pathauto_include();

and then changed include_once to include and everything still worked fine!

@freixas - thanks very much for your detailed response and thorough research.

While sometimes I can be curt in issue discussions, I certainly don't do it to be rude.

The suggestions you provide are very interesting. It's not the typical way in Drupal to include files, but perhaps it's time we changed that ;)

Can you please provide your suggestions as a patch file? That will make it easier to test. I'm hesitant to use the dirname(__FILE__); construct simply because it hasn't seen as much testing as the current method, but what the heck - this is only a beta!

For more on how to create a patch in the drupal standard way: http://drupal.org/patch/create

fixing title

The patch greggles provided in comment #9 seems to work nicely when automatically creating nodes during cron runs.

I only say 'seems' as I've been hacking around on some other modules and haven't had a chance to run the patch through the wringer, so to speak. Hopefully sometime next week I'll be able to compare greggle's patch vs. freixas' suggestions.

Thanks to both.

Sorry, I don't seem to get any notification when this issue is updated. I have a feed subscription, but the only thing the feed gave me for this issue is the initial bug report entry. Is there a way to get notified when a new entry is made?

I'll try to prepare a patch ASAP, but it's the weekend right now...

Sure, if you visit the issues page for any project: http://drupal.org/project/issues/pathauto at the top is a link to subscribe which you can then use to subscribe to "None" "Own issues" or "All issues". If you visit http://drupal.org/project/issues/subscribe-mail you can change your preferences for all projects. I visit that page occasionally and click the "All projects" "Own Issues" button to be sure to get followups to my issues in any project.

I committed my patch since it works even if it's not quite optimal.

@freixas - I'll welcome a patch to improve performance whenever you can provide it.

Bit late to the party as I see you've already marked this as fixed, but I might have found a minor issue issue with your (greggle's) patch in #9 (caveat: I applied the patch by hand) - The _pathauto_include(); function needs to be added to pathauto_admin_settings() as well, else only the general settings fieldset is displayed for the settings page.

Quite right - thanks for the catch!

Here's the optimized includes patch.

I tried following all the patch-generation instructions, but I got a little lost on what to do when one doesn't use CVS or SVN to check out the module code.

I grabbed version 1.44.4.23 using the CVS viewer, added my changes and did a quick test to verify that the module still worked. I then made a patch and was able to apply it on a copy of the 1.44.3.23 module, so the patch at least worked for me.

This may still be the right fix, but matters seem to be a bit stranger than has been discussed so far.

I have been constructing an automated drupal setup script. Last night it was all running just fine on Fedora Core 6. Today, I am seeing the bug that is being described here. But the weird part is that I see it only on Fedora 7, not on Fedora Core 6.

Fedora Core 6 shipped with php-5.1.6, while Fedora 7 shipped with php-5.2.2. I am wondering if there may have been come change in the underlying behavior of PHP that is causing this problem to be exposed.

Applying the sequence of patches in the discussion (ignoring the small redundancy in the second patch) got me past the pathauto_get_placeholders issue, and then left me at an unresolved call to token_get_values in pathauto.inc.That may be a known issue. I haven't checked for that yet.

I really suspect a change in php behavior here... That doesn't make this a bad patch, but it would be comforting to know what is really going on here.

I was getting this error when I tried doing the bulk update on the admin/content/node page until I added pathauto_include() to the pathauto_node_operations_update function.

@EvanDonovan - patch please?

Sorry, since this time last year, I upgraded our site to Drupal 6.x, so I don't actually remember the context in which this happens. Feel free to close.

Ok then - going back to fixed for now.