i18n front page pb

Interesting... On my multilingual site it's exactly the opposite: the http://www.mysite.com is cached (but not served from the cache) and the other ones like http://www.mysite.com/fr or http://www.mysite.com/en are not cached at all. :-O

Attached patch should provide some basic url language prefix support.
I didn't do extensive tests since I was just playing around with boost to check whether it fits my needs.
Thus it's likely that there are still some issues left.

I just tested the patch in #4 and it works.

Thanks a lot.

I had the same issue and tested/reviewed the fix. Committed to 7.x-1.x. Thanks for the patch!

Hmm... Just updated to latest -dev release (on a site that doesn't use any multilingual features), and I'm now getting the following warning on every page request:

Notice: Use of undefined constant LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX - assumed 'LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX' in boost_parse_url() (line 373 of ../drupal7/sites/all/modules/boost/boost.module).

If I simply add quotation marks around that constant, the warning is gone.

--- boost.module (saved version)
+++ (current document)
@@ -370,7 +370,7 @@
   parse_str($parts['query'], $parts['query_array']);
 
   // Check if language prefix for urls is enabled.
-  if (variable_get('locale_language_negotiation_url_part') == LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX) {
+  if (variable_get('locale_language_negotiation_url_part') == 'LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX') {
     // Get languages grouped by status and select only the enabled ones.
     $languages = language_list('enabled');
     $languages = $languages[1];

Ouch there must be something wrong.
Could it be that locale.inc isn't loaded at that point of the bootstrap?

@geerlingguy: Adding quotation marks may make the warning vanish but the problem still persists. LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX is a constant, adding quotation marks makes out of a constant a string. But what we really need is the (value of the) constant which is defined in locale.inc.
If the constant isn't load at that point of the bootstrap I think we should replace the constant with 0 and add a comment that tells us that this value has to be the same as the one of LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX.

Notice: Use of undefined constant LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX - assumed 'LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX' в функции boost_parse_url()

Sorry. I see in prior post answer. Wait solvation.

I try replace LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX with value 0 and i get another error

Fatal error: Call to undefined function language_url_split_prefix() in /data/www/htdocs.mogd7/sites/all/modules/contrib/boost/boost.module on line 378

Edit: i try add

require_once DRUPAL_ROOT . '/includes/locale.inc';

just before

  // Check if language prefix for urls is enabled.
  if (variable_get('locale_language_negotiation_url_part') == 0) {
    // Get languages grouped by status and select only the enabled ones.
    $languages = language_list('enabled');
    $languages = $languages[1];
    list($language, $parts['path']) = language_url_split_prefix($parts['path'], $languages);
  }

and i still get same error.

I think this patch can work:

# This patch file was generated by NetBeans IDE
# It uses platform neutral UTF-8 encoding and \n newlines.
--- HEAD
+++ Modified In Working Tree
@@ -370,7 +370,7 @@
   parse_str($parts['query'], $parts['query_array']);
 
   // Check if language prefix for urls is enabled.
-  if (variable_get('locale_language_negotiation_url_part') == LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX) {
+  if (drupal_multilingual() && variable_get('locale_language_negotiation_url_part') == LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX) {
     // Get languages grouped by status and select only the enabled ones.
     $languages = language_list('enabled');
     $languages = $languages[1];

Not the most elegant, but this would do the trick:

   // Check if language prefix for urls is enabled.
-  if (variable_get('locale_language_negotiation_url_part') == LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX) {
+  if (defined('LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX') && variable_get('locale_language_negotiation_url_part') == LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX) {

The bug only occurs when the locale module is not loaded. I had to test on a blank site to reproduce the bug (disabling locale/i18n wasn't enough, although I guess some other module was causing locale.inc to load).

What I'm really concerned about is the fact that locale.inc sometimes isn't loaded.
If this is the correct behaviour, means this is triggered by some sort of configuration, I think the new check with defined() is a good way to go.
Has already someone the insight when or why locale.inc is load or not?

Seems to me that locale.inc is loaded only from locale.module (in hook_init, hook_language_types_info and a few other hooks), so it seems normal that we get that warning when the locale module is not enabled.

I'll commit my patch from #13 for now and see if we get further feedback before closing the issue.

#15 Confirmed: I don't have locale enabled on my site.

Thanks for figuring this out.
I took a look too and it looks like we could have another problem here. The locale module doesn't implement hook_boot(), but it implements hook_init().
The locale.api.php say's somewhere:

... However
* modules implementing hook_boot() should be aware that language initialization
* did not happen yet and thus they cannot rely on translated variables. ...

I guess boost uses hook_boot() (I'm not sure, I don't use it yet) to do the necessary operations and that's simply to early to rely on the include of the locale module.
The question now is if boost_parse_url() is used at boot time. If so we can't rely on the constant nor use the function language_url_split_prefix() - means we've to include the locale.inc on our own.
Unfortunately an additional include could affect the performance.
If language_url_split_prefix() is used after hook_init() it should be fine to use the defined() check.

What are the opinions here?

Boost uses hook_init(), not hook_boot(). And reading from the description of hook_boot, it seems like hook_init is the right thing to do.

The function in hook_init() basically determines if the page needs to be cached. Once the cache is generated, it's the rewrite rules in the .htaccess which bypass completely PHP.

Thank you very much for the clarification :)
This means we're really close to theoretical approve the approach of using defined().
One last question at this point, is there a need to consider the module weight? The locale module has a weight of 0, according to this documentation boost has -90.
As far as I know hook_init() is invoked by using module_invoke_all('init'); which uses module_implements() and this again ensures the modules that actually implement the hook are loaded. This means we should be on the safe side when we use defined() as the locale module should be loaded (if enabled) when boost_init() is called.
Please correct me if I'm wrong! :)

Thank you, bgm et al, I just updated Boost to the latest released version of 7.x-1.x-dev, which seems to include that patch, and the warning is now gone.

@ das-peter : yep, sounds right. The language itself is set in the bootstrap, so I think we're safe on that side too, and no need to worry about the weights.

Although someone reported a related issue in #1370776: Fatal error: Call to undefined function language_url_split_prefix() in boost.module on line 377, but that bug is not directly related (occurs while posting content as a non-anonymous user). I'll close this issue for now since it seems OK.

Thanks for all the feedback!

I have committed havran's fix from #12, since there were still issues being reported in #1370776: Fatal error: Call to undefined function language_url_split_prefix() in boost.module on line 377.

Same problem here with the last dev version.

If I clean the cache, the front page is shown. But Boost saves a blank page to it's cache folder.

So the next visit render a blank page (if no language prefix is present).

Edit : when I go to the front page, after cleaning the cache, then I'm redirected to the front page with the default language prefix. So Boost store a blank page with no prefix (file _.html) and the complete page with the prefix (file en_.html)...

Deactivate Boost solves temporary my issue.

@ dedisoft: what you describe sounds like a different bug. Please open a new issue with more detailed information, and how to reproduce it on a test site.

@ dedisoft: see #1401442: Doesn't redirect to default language prefix

Thanks

I have the same issue :
Front page is ok (mysite.net) and working with Boost
but all the other pages are ko (mysite.net/fr/page1 , mysite.net/en/page2 ...) and working without Boost !

I use i18n module with the latest dev version of Boost module.

Is there any specific configuration for Boost or i18n modules to work together ?

>>> problem solved > bad .htaccess

Same problem here as Marvine...