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.

Files: 
CommentFileSizeAuthor
#2 fix_broken_whitelist-1218954-1.patch609 bytesMark Theunissen
PASSED: [[SimpleTest]]: [MySQL] 35,633 pass(es).
[ View ]

Comments

Another solution

3. Clearing the cache should delete this whitelist variable.

StatusFileSize
new609 bytes
PASSED: [[SimpleTest]]: [MySQL] 35,633 pass(es).
[ View ]

Here's a patch to the update function that modifies the url_alias table, to make it rebuild the whitelist. Works in my testing.

Issue summary:View changes

Adding steps to repeat.

Status:Active» Needs review

Status:Needs review» Reviewed & tested by the community

Great report. Thanks for the patch.

I tested it and it works.

Issue tags:+D7 upgrade path

Tagging

Status:Reviewed & tested by the community» Fixed

Awesome, thanks for the fix!

Committed and pushed to 7.x.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Active

I 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:

# Starts the drush dance.
drush --nocolor --yes --uri=https://staging.dlp-intranet/ core-cron
drush --nocolor --yes --uri=https://staging.dlp-intranet/ cc all
drush --nocolor --yes --uri=https://staging.dlp-intranet/ features-revert-all
drush --nocolor --yes --uri=https://staging.dlp-intranet/ core-cron
drush --nocolor --yes --uri=https://staging.dlp-intranet/ cc all
drush --nocolor --yes --uri=https://staging.dlp-intranet/ features-revert-all

Not appealing.

Status:Active» Closed (fixed)

@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.

Issue summary:View changes

Clarification.