I've run into an issue that causes Fast 404 to mistakenly determine that a path is invalid if the path is a path defined in the Redirect module and also a path that has a language prefix in the first segment of the URL query string.

Let's say that I have French enabled as a locale on my site that is an English language site by default.

I want to redirect this URL: https://www.mysite.com/fr/pageone
To this URL: https://www.mysite.com/pagetwo

If I have Fast 404 enabled, it will fail, but the following redirect would work.

Redirect this URL: https://www.mysite.com/pageone
To this URL: https://www.mysite.com/pagetwo

The reason why the first example fails and the second one succeeds is because in the fast_404_path_check() function in fast_404.inc, it doesn't normalize the path query string variable before querying the {redirect} table. It searches for "fr/pageone" instead of just "pageone". This will fail because the language prefix is not actually stored as part of the path in the {redirect} table, which is consistent with the other tables that store paths.

The fix for this appears to be actually quite simple. Fast 404 does normalize the path before checking the {menu_router} and {url_alias} tables. For some reason, it makes an exception for the {redirect} table. All you have to do is move the few lines of code that queries for a redirect path to run after the path has been normalized and it works.

I've attached a patch for this.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hyperlinked created an issue. See original summary.

hyperlinked’s picture

Status: Active » Needs review