It appears that url aliases no longer work. I noticed this while working on revising the SimpleTest for the path module. So the tests are doing good before the framework is setup.

Anyway I had beeradb check it and also found that it didn't work for him.

CommentFileSizeAuthor
#4 module_list_bootstrap_default.patch579 bytesDavid_Rothstein

Comments

beeradb’s picture

beeradb commented

subscribe

boombatower’s picture

boombatower commented
Priority: Normal » Critical

I think this is critical since aliases are a commonly used feature and it doesn't seem to work at all.

catch’s picture

catch
he/him
Primary language English
commented

Confirmed here as well. You can add a path alias, and drupal_lookup_path() finds it, but viewing the node (or taxonomy term) generates a 404.

David_Rothstein’s picture

David_Rothstein commented
Status: Active » Needs work
StatusFileSize
new module_list_bootstrap_default.patch579 bytes

I checked the CVS logs and it seems this was caused by http://drupal.org/node/196862 (I confirmed that reversing the patch there makes the problem go away).

However, I don't think that patch is the ultimate cause of the problem. I think it's actually a deeper problem having to do with the module_list() function, which just happened to be exposed by that patch.

For example, here is a patch that (at least for me) makes the URL aliases work again. It's definitely NOT the right thing to do in the long run! But it's a starting point for a fix, and a demonstration that some weirdness with module_list() seems to be the ultimate cause of this bug...

David_Rothstein’s picture

David_Rothstein commented

In particular, there seem to be two problems with module_list():

1. It does its internal caching in a rather odd way, by storing everything in the same static $list variable (regardless of what type of module list it is generating; e.g. $bootstrap = TRUE or FALSE). This means that when you call it normally (without asking it to do a refresh), it returns whatever module list it happened to generate last time, which is not necessarily the list you wanted!

2. For the life of me I can't figure out why $bootstrap = TRUE is the default value for this function...

Basically, I think the combination of the above two problems is what leads to this bug. The issue referenced above added a module_exists('path') check, which evidently occurs at the right place in the sequence to trigger this problem. The check winds up being done against the wrong list of modules and erroneously returns FALSE, thereby causing URL aliases never to happen.

Anonymous’s picture

Anonymous (not verified) commented
Status: Needs work » Closed (duplicate)

I'm marking this as duplicate with #222109: module_list() should be rewritten as 2 functions: module_list() and module_list_bootstrap(). The patch at #4 in this issue isn't appropriate because the module_list cache becomes useless with it. We can take care of the $bootstrap default value in #222109: module_list() should be rewritten as 2 functions: module_list() and module_list_bootstrap().

David_Rothstein’s picture

David_Rothstein commented

Sure, sounds reasonable -- after all, the other issue is older. And yup, I know the patch in #4 isn't good... that's why I marked it "code needs work"! ;) As I said, it was just a quick demonstration to show that module_list()'s caching is the root cause of the problem, not an actual fix.

I'll continue discussion at the other issue.