Problem
After upgrading a site to Drupal 7, aliases are not generated in links, or anywhere drupal_lookup_path() is called.
To reproduce, upgrade a site that has URL aliases to Drupal 7. View a page that outputs anchor links using the l() function or any other function, and notice that the links go to the system paths rather than the path aliases.
Reason
After upgrading, the variable path_alias_whitelist is corrupted, it is set to an array with a blank string as a key:
$ drush vget path_alias_whitelist
path_alias_whitelist: Array
(
[] => 1
)
Because the whitelist is empty, no aliases are found in drupal_lookup_path()
Workaround
As soon as you save any alias, the whitelist is regenerated and all aliases are once again output correctly.
You can also call drupal_path_alias_whitelist_rebuild() manually.
Cause
In update_fix_d7_requirements(), we add a field 'source' to the 'url_alias' table, as it's required in order for Drupal to bootstrap. The actual migration of the url aliases from their old column 'src' to the new one 'source' only happens in system_update_7042(). So when Drupal 7 bootstraps for the very first time and creates the whitelist, it runs the following query on this table (from the function drupal_path_alias_whitelist_rebuild()):
SELECT DISTINCT SUBSTRING_INDEX(source, '/', 1) AS path FROM {url_alias}
Since source is NOT NULL and the table is full with aliases, you get an empty string returned from this query, that results in the whitelist corruption you saw above.
Summary
In the update process, empty columns are tacked onto the url_alias table that cause the whitelist variable to become corrupt, before the url_alias table's schema is altered correctly for Drupal 7.
Solutions
1. Check for empty values in the drupal_path_alias_whitelist_rebuild() function, either in the query or in foreach().
2. Regenerate the whitelist in an update function.
Comment | File | Size | Author |
---|---|---|---|
#2 | fix_broken_whitelist-1218954-1.patch | 609 bytes | Mark Theunissen |
Comments
Comment #1
Mark Theunissen CreditAttribution: Mark Theunissen commentedAnother solution
3. Clearing the cache should delete this whitelist variable.
Comment #2
Mark Theunissen CreditAttribution: Mark Theunissen commentedHere's a patch to the update function that modifies the url_alias table, to make it rebuild the whitelist. Works in my testing.
Comment #2.0
Mark Theunissen CreditAttribution: Mark Theunissen commentedAdding steps to repeat.
Comment #3
Mark Theunissen CreditAttribution: Mark Theunissen commentedComment #4
clemens.tolboomGreat report. Thanks for the patch.
I tested it and it works.
Comment #5
Mark Theunissen CreditAttribution: Mark Theunissen commentedTagging
Comment #6
webchickAwesome, thanks for the fix!
Committed and pushed to 7.x.
Comment #8
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedI still have this problem:
I am installing a Drupal 7.22 website through drush in jenkins. I enable an install profile and a list of features. After running multiple drush cc all, I still have this error.
Going through the admin UI in Admin > Development > Performance > Clear all caches does not fix either.
This fix the problem once a blue moon:
Not appealing.
Comment #9
clemens.tolboom@Sylvain Lecoy from your notes in #8 I don't read you are upgrading from a Drupal 6 version. Furthermore you do not specify your problem.
So I guess your problem is something different.
Feel free to report a new issue and add a link here.
This issue is committed / closed long time ago so it's mostly best to report a new issue anyway.
Comment #9.0
clemens.tolboomClarification.