First argumented is expected to be a valid callback, 'blog_pathauto_page'

I've committed a two-part fix (don't add the menu entry if the function doesn't exist, and implementing that particular function to display a list of user blogs) to cvs. I don't use blogs normally, so I'd appreciate it if you could give it a try and make sure it works in your environment before I tag it for 4.6.

Thanks!

Sorry, my action was a little too speedy!

There are two issues involved here. One is that the path module allows one to "override" system paths (in this case, allowing pathauto to create a "blog" alias when generating index paths). I've always said that this is an issue that needs to be addressed in core, since it also applies to creating explicit aliases, but it's so easy to get yourself in trouble here with pathauto that I've added some exclusion code (currently ignoring attempts to create aliases named "user", "blog", or "admin").

Secondly, the way the index alias support is currently implemented, an index alias lists all items whose alias has that index alias as a prefix (clear?). Thus, the implementation of blog_pathauto_page listed each person's blog. However, doing this hid the default behavior of the "blog" URI, so I've removed that support.

Anyway, please try out the latest cvs version (you should remove the existing "blog" alias from your site to clean things up).

Thanks.

Similar problem, but with the error message

warning: call_user_func_array(): First argumented is expected to be a valid callback, 'taxonomy_pathauto_page' was given in g:\htdocs\drupal\www\includes\menu.inc on line 354.

This occurred when I tried editing the URL so

http://example.com/cat/subcat/page

was changes to

http://example.com/cat/subcat/

to see what would happen. That's when it died. I'll try the CVS fix and report back to see if it works for this problem too.

Short answer: update to the CVS got rid of my errors. CVS version runs great and is a tremendous addition to Drupal. Undying thanks!

Now the long answer which may be 100% irrelevant, but just trying to provide some useful feedback.

I apologize, but I'm just trying drupal and pathauto for the first time on a test platform and I'm not sure I tested this in the best way. I just deleted all aliases of all types, both the ones that I had created manually and the ones that Pathauto created before it died. MySQL client showed a single row with a single NULL value in the url_alias table, so no detritus from previous work.

Then I installed the CVS pathauto version.

Then I basically left all defaults in the text boxes, but checked everything else so
- verbose
- Create feed aliases
- Create index aliases
- Bulk generate index aliases
- Update action: Create a new alias, replacing the old one
- Bulk update node paths
- Bulk update category paths
- Bulk update user paths

Maybe that's not the right way to do it. Anyway, I ended up with the following where the first column is the return code (200 - page found; 404 - page not found), the alias, and the "system path" with the return code for that system path after it.

404 articles                    pathauto/taxonomy/articles  - 404
404 articles/climbs	        pathauto/taxonomy/articles/climbs - 404
200 articles/climbs-0           taxonomy/term/4 - 200
200 articles/climbs-0/feed      taxonomy/term/4/0/feed - 200
200 articles/climbs/tuolumne    taxonomy/term/6  - 200

Note that if I try
articles/climbs-0/tuolumne, that's 404

However, when I changed the default mask for page paths from [title] to [catpath]/[title] then everything worked as expected and the */climb-0/* paths were all 404 and the */climb/* paths, include /climbs were are 200.

It does not seem to be systematic as the previous user noted - some paths that start with /pathauto work and others are 404.

So, for me, that's great. A bit odd and not what I expected, but I suspect the "bug fix" for that may be documentation rather than code (if there's a pathauto "how to" my search of drupal didn't turn it up).

I don't have time to look too closely right now, but yes, wiping out all aliases, then updating index aliases before updating the other aliases will mean the index aliases you expect to see won't exist (because they are created based on the existing specific aliases). Try another update of index aliases and see how things work...

I'm not happy with the existing implementation of index aliases, and don't really recommend it. There's too much risk of creating aliases that override "real" paths, the patterns for different content types can lead to ambiguities, and conceptually it just feels like too much of a hack... I have some thoughts about a redesign of all this stuff, but I've got a day job plus I'm working on a contract, so it'll be a while before I can do any major work on pathauto.

As for a pathauto "how-to", I definitely recognize the need - please feel free to drop in your thoughts.

Thanks for the feedback!