Can't get Boost to work on Drupal 7 / Cache settings

Hi,
We did experience the same behaviour. After examining the code we did alter the function boost_transform_url as listed below:

function boost_transform_url($url = NULL, $b_path = NULL) {
  global $base_root, $base_path, $language;

   $items = &drupal_static(__FUNCTION__);

  // Set defaults if none passed in.
  if ($url === NULL) {
    $url = $base_root . request_uri();
  }
  if ($b_path == NULL) {
    $b_path = $base_path;
  }
  $hash = $url . ' ' . $b_path;

  if (!isset($items[$hash])) {
    $parts = boost_parse_url($url, $b_path);
    if (!$parts) {
      $items[$hash] = array('cache_this' => FALSE);
      return $items[$hash];
    }
    $parts['base_dir'] = boost_get_normal_cache_dir() . '/' . $parts['host'] . $b_path;
    $parts['filename'] = $parts['base_dir'] . $parts['path'] . variable_get('boost_char', BOOST_CHAR) . $parts['query'];
    $parts['directory'] = dirname($parts['filename']);

    // Get the internal path (node/8).
    if (drupal_is_front_page()) {
      $parts['normal_path'] = variable_get('site_frontpage', 'node');
    }
    else {
      //$parts['normal_path'] = drupal_get_normal_path($parts['path']);
      
      //EH BEGIN FIX Patch Strip language prefix form path.
      $parts_path = $parts['path'];
      $langcode = $language->language;
      if (strpos($parts_path, $langcode . '/') === 0) {
        $parts_path = str_replace($langcode . '/', '', $parts_path);
      }
      // Get drupal system path.
      $parts['normal_path'] = drupal_get_normal_path($parts_path);
    }
     //EH END FIX 
   
// Get the alias (content/about-us).
    $parts['path_alias'] = drupal_get_path_alias($parts['normal_path']);
    // Get all args.
    $args = arg(NULL, $parts['normal_path']);
    // Prevent array warnings.
    $args[0] = empty($args[0]) ? '' : $args[0];
    $args[1] = empty($args[1]) ? '' : $args[1];
    $args[2] = empty($args[2]) ? '' : $args[2];
    $parts['args'] = $args;

    // Get content type.
    if (!empty($parts['normal_path'])) {
      $parts = _boost_get_menu_router($parts);
    }
    // See if url is cacheable.
    $parts = boost_is_cacheable($parts);
    $items[$hash] = $parts;
  }

  return $items[$hash];
}

(Thank you Erik Stielstra for helping with this issue)

One more addition: we did notice that http://mysite/nl/a path to public image.jpg was served through index.php which is a waste of precious resources.
We did add in .htaccess this rule where nl is our language code

  RewriteCond %{REQUEST_URI} \.(jpg|png|ico|gif|jpeg|bmp)$
  RewriteRule ^nl/sites/(.*) sites/$1

@eduh: can you explain your patch?

I managed the reproduce the bug in a multi-lingual site, but I don't understand the patch, so I can't commit it for now until I do more testing.

See also: #1151296: i18n front page pb

OK, I better understand the issue now. This is indeed the same as #1151296: i18n front page pb and the fix is similar. Please test that patch (or upgrade to the latest 7.x-1.x snapshot) and if not, re-open the issue.

Thanks!

Can't get it work. Although I think I reread well the installation instruction.
No pages are cached at all. Nothing in the boost folder and no tag in pages.
I use 18n prefix and installed the last dev of boost (2011/12/23 ISO8601)

@ rondev: the bug you describe does not seem related to this issue (in this issue, pages for some languages were being served OK, but not translations). Please open a support request with more information about your hosting environment.

Hello BlueDragon,

I just read your first post and I have exactly the problem (files are being cached but not used) and the same questions about max and min life time meaning !!
Did you manage to find those answers ?

Thanks

Nicolas

EDIT ########

Just want to leave some feedback since I finally manage to make it work for me.
In my case the line that was breaking it all was the RewriteCond of the #NORMAL code bloc of .htaccess file, see below (the one that is commented) :

# NORMAL
# RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
RewriteRule .* cache/%{ENV:boostpath}/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]

I think there is a problem with my %{DOCUMENT_ROOT} because there is a message on the .htaccess Settings page :
"Value of /htdocs/public/www is recommended for this server. Please open an boost issue on Drupal.org, since apache and php might not be configured correctly."

I've debugged it, the %{DOCUMENT_ROOT} variable returns /htdocs/web, I've tried to hard code the line instead of %{DOCUMENT_ROOT}, replacing it by /htdocs/public/www, /public/www, /htdocs/web, /web and without trailing slash also... it never worked.

In the end I don't understand what is the aim of this line since it works fine without it. Maybe I'll have to discover it the hard way some day :) but for now this is my only choice to leave it commented.

Finally, I'd like to say I'm a bit disappointed with Boost that I find less reactive than the core cache, I mean once the page is in the cache.
Concretely, with core caching only the text changes smoothly and instantaneously, with Boost the page disappears and slides from top to bottom when it loads.

I am not taking away the fact that with core caching the user must load the page the first time he visits it, whereas with Boost the page loads instantaneously from the first visit. That is why I stick with Boost for that particular website because users might not need to visit each page more than once. But it seems like with core caching the page stays in the web browser's cache when with Boost the page is always loaded again and again from the Boost cache folders... no ?

It would be really nice to be able to use Boost to prevent user from having to load the page the first time and then to use core cache once it's loaded. I understand that it might be technically impossible since everything happens right in the .htaccess file so before everything else... Or maybe I need to enable some cache headers in the generated html pages of Boost so that it stays in the web browser's cache and it won't even bother to call the .htaccess file anymore...

Nicolas