There are inconsistencies with the order in which items run, the sql that runs within the queries and also the default return. The sql function also doesn't deal with table prefixes that could be set. In the scenario that raised this issue, the local environments were using the 'fast_404_validate_path_sql' function and the dev / test / stage / production environments (within Acquia cloud - which includes the db_query functionality within the settings.php file) using the 'fast_404_validate_path_drupal' function. The check for the menu router within the '_sql' function was not functioning on certain pages with multiple forward slashes, but dev+ environments worked as expected which highlighted the differences.

The 'fast_404_path_check' function checks if the db_query function exists and passes over to the 'fast_404_validate_path_drupal' if it does and 'fast_404_validate_path_sql' if it does not.

The 'fast_404_validate_path_drupal' checks:
- If the redirect module is enabled and there is a redirect in the redirect table for the given url (return true).
- Checks if the locale module is enabled and strips any language variable from the current path string.
- Looks for items within the menu router table (return true if item found).
- Looks for any url aliases for the current path (return true if item found).
Returns false if we haven't matched anything.

The 'fast_404_validate_path_sql' checks:
- Checks if the locale module is enabled and strips any language variable from the current path string.
- If the redirect module is enabled and there is a redirect in the redirect table for the given url (return true).
- Looks for items within the menu router table in a different method to the drupal check (return true if item found).
- Looks for any url aliases for the current path (return true if item found).
Returns true if we haven't matched anything.

In this patch, I've consolidated both routes into one single route to allow query sql and functionality in one function and the database querying to be done in a separate function which deals with where these sql queries should be ran. I've also dealt with the table prefixes.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

anthonyleach created an issue. See original summary.

anthonyleach’s picture

vasike’s picture

Indeed, because of this there were some issue for multilingual paths (locale path query)
But it seems the patch here (#2) has also a little issue about this for redirect check

So i think we should have locale check before any other check, so we have the right path to validate.

Here is the updated path and the interdiff file.
Thanks