[i18n] language prefix doesn't get recognized

In my tests, module works fine with language suffixes (domain.com/en, domain.com/es...) using URL detection method, so no patch is required.

Perhaps there are some specific use cases where the patch is required; more information would be needed to test them properly.

Patch #1 works fine for me.

I just were going to post same solution, before faced this post.

I was having the same issue and can confirm that the patch in #1 solves the problem.

+1, it works for

url_alias

To handle redirect module as well, you have to move the portion of code and replacing $_GET['q'] by $q as well.

Sorry, didn't found how to remove a joined file...
My previous patch didn't work very well...
This one is better !

Patch in #9 is confusing this issue. Hiding it to maintain focus on patch in #1.

Could I get a list of steps to recreate this on a vanilla Drupal 7 site please? Useful information would be modules enabled, configuration set and any aliases/redirects put in place. Thanks!

Steps to reproduce:

1. Install Fast_404, put the required config part to the settings.php and set $conf['fast_404_path_check'] = TRUE;

2. Do the steps to enable multilanguage support in Drupal: enable Locale module, add a second language, set the detection method to URL (prefix), configure some content type (article, for example) to enable multilanguage support.

3. Create a node of this content type, assign a second language and some URL alias to it.

4. Try to go to the created node using both url alias and prefix. For example, if the second language was Spanish and url alias was ejemplo-article, then try to go to localhost/es/ejemplo-article. If reproduced correctly, you will be getting a 404 error for an actually existing page.

My best guess is that $conf['fast_404_path_check'] being set to TRUE somehow breaks URL alias table lookup if language prefix is in use.

I tried to get this to work following your instructions - using a vanilla D7 site:

• Enabled pathauto, token, fast_404, locale
• Added $conf['fast_404_path_check'] = TRUE; to settings.php
• Added Spanish
• Turned on URL detection (by path prefix)
• Added multilingual support to 'Article'
• Created new Article with custom URL alias (ejemplo-article) and set language to Spanish
• Was able to view es/ejemplo-article without it 404ing.

Was your test on a vanilla site - I'm wondering if there are other module conflicts here that we can sort out.

Well, that's odd. I've tried it a second time to make sure I haven't messed up something and was able to reproduce it without any problems again very quickly. Also looking at steps you've taken I can't see anything done wrong, so you should be actually getting this error. Maybe more detailed steps to reproduce will help. Alternatively we can actually try a copy of my test website I've configured to reproduce this error (using the instructions provided below). You can get it here: http://3dg.me/fast404_test.zip

Prerequisites: I'm using a wamp server 2.5 on Windows 8 x64 to run test Drupal installation. The required modules are just Drupal 7.34 vanilla core and fast_404. Token, Pathauto, etc. are not really necessary as I was able to get this error with just Drupal and fast_404.

1. Install Drupal using Standart profile during installation dialog.
2. Enable modules: Fast_404 and Locale.
3. Copy entire config section from fast_404's README.TXT file to your settings.php, make sure that $conf['fast_404_path_check'] = TRUE;
4. Add a second language at admin/config/regional/language/add
5. Enable detection method: URL at admin/config/regional/language/configure
6. Enable multilanguage support for Article type at admin/structure/types/manage/article
7. Create a new Article with custom URL alias (ejemplo-article) and set its language to Spanish.
8. Try to view the article created using URL alias with language prefix.

If you will not be getting 404 page even on my test installation then it probably will mean that issue is webserver-specific.

Thanks again for your steps - I followed them and installed your test website but to no avail. It looks like this is a wamp/windows issue. If the patch in #1 fixes these issues for you then I'm happy to merge them in - especially since there aren't really any functional changes.

I'm going to throw out the question of platform used to #2085049: Code correction for fast_404_validate_path_drupal() to see if this is at all related. Ideally I'd like to address this and #2123775: Use normal db placeholders to avoid DXWTF in one fell swoop to add in named placeholders and replace the $_GET['q'] references from them.

Thank you. One probably important thing to keep in mind that it is not exactly a wamp/windows-only issue, because on my wamp/windows setup I only repeated what we've been getting in our webhosting environments, and I was not the only one. So, it's more of "some part of Linux and Windows webserver configurations". For example, my website that also got that error runs on Apache/2.2.3, PHP 5.2.17 and MySQL 5.5.27 on Linux.

Just curious, what setup you are using for testing?

Still, fixing it all along with two issues you have posted above probably will do the trick. Keep up good work :)

I'm going to leave this at Needs Work for a bit to see if a patch comes in. If one doesn't surface in a week I'll just fix it up myself and commit. The patch should address:

• Rename $q to $query to make it less ambiguous
• Replace appropriate instances of $_GET['q'] with $query
• By applied against the HEAD of 7.x-1.x branch
• Be locally tested to ensure it doesn't break anything (in lieu of actual Drupal tests which I'm keen to write soon!)

The environments I've tested the current code on are:
Acquia Cloud
My local NGINX (nginx/1.4.4)/PHP-FPM (PHP 5.4.17) / MySQL (5.5.20) homemade install on a mac. Maybe this is a PHP 5.2 issue?

If you used the advanced installion for module and the code in the BOTTOM of settings.php the language prefix will not recongnized.

function fast_404_validate_path_drupal() {

  // Check if path_redirect module is installed.
  if (db_query("SELECT name FROM {system} WHERE type = 'module' AND status = 1 AND name = 'path_redirect'")->fetchField()) {
    // Check if path exits in path_redirect table.
    $query = $_GET['q'];
    if (db_query("SELECT rid FROM {path_redirect} WHERE ? LIKE source", array($_GET['q']))->fetchField()) {
      return TRUE;
    }
  }

  $sql = "SELECT path FROM {menu_router} WHERE ? LIKE CONCAT(path, '%')";
  $res = db_query($sql, array($_GET['q']))->fetchField();
  if ($res) {
    return TRUE;
  }
  else {
    $sql = "SELECT pid FROM {url_alias} WHERE ? LIKE CONCAT(alias, '%')";
    $res = db_query($sql, array($_GET['q']))->fetchField();
    return $res == 0 ? FALSE : TRUE;
  }

  return FALSE;
}

so the function is checking the path_redirect then menu_router then url_alias then tell you sorry your page not found.

Interestingly enough, I couldn't replicate this manually. However, when writing tests for #2384811: Write tests the alias would trigger fast_404.