Hello,

i did change my pager links in template.php (mytheme_pager_link()) to www.domain.tld/somenode/page/1 (wordpress style). Boost creates the cache file for www.domain.tld/somenode only, not for somenode/page/1, somenode/page/2 and so on.

How do i include the pager links?

Best wishes,
root66

CommentFileSizeAuthor
#5 boost-897970.patch2.64 KBmikeytown2

Comments

mikeytown2’s picture

I set the path in boost_init()

...
  //set variables
  if (isset($_REQUEST['q'])) {
    $GLOBALS['_boost_path'] = $_REQUEST['q'];
  }
  else {
    //front page
    $GLOBALS['_boost_path'] = '';
  }
  // Make the proper filename for our query
  $GLOBALS['_boost_query'] = BOOST_CHAR;
  $query = array();
  foreach ($_GET as $key => $val) {
    if ($key != 'q' && $key != 'destination') {
      $query[$key] = $val;
    }
  }
  $GLOBALS['_boost_query'] .= str_replace('&', '&', urldecode(http_build_query($query)));

What does $_REQUEST['q'] and $_GET['q'] output on those pages?

root66’s picture

I do have to rewrite the URL, so drupal gets the page variable:

RewriteRule (.*)/page/([0-9]*)$ $1&page=$2 [L,QSA]

Now the cache file for each page is created, but it is not loaded. I think it's because i can't change the %{QUERY_STRING}. For www.domain.tld/someview/page/123 there's no %{QUERY_STRING}, but after my rewrite it's &page=123.

RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html\.gz -s

mikeytown2’s picture

what gets saved in the cache folder when you hit the pager?
somenode/page/1
OR
somenode?page=1

root66’s picture

somenode_page=1.html

mikeytown2’s picture

Status: Active » Needs review
StatusFileSize
new2.64 KB

give this a shot; be sure to enable the new setting

root66’s picture

Now there's a new cache-subdirectory called "page" containing files like 1_.html, 2_.html, 3_.html (for each page), but the htaccess rule doesn't redirect to them.

Thanks for your help so far!

mikeytown2’s picture

put this

RewriteRule (.*)/page/([0-9]*)$ $1&page=$2 [L,QSA]

below the boost rules; they where above correct?

root66’s picture

It's working now. The problem was the %{HTTP_HOST} in the boost rules, because my test server runs at port 8080 and there's no caching directory named host:port. It's 'host' only (without the port). Is there a mod_rewrite variable which contains the hostname only, without the port?

mikeytown2’s picture

one way to find out; run this

echo str_replace('    ', '    ', nl2br(htmlentities(print_r($_SERVER, TRUE))));
mikeytown2’s picture

Title: Pager links not cached » Support clean pagers: ?page=1 => /page/1
Category: support » feature
Status: Needs review » Reviewed & tested by the community
Andrew Gorokhovets’s picture

+1

mikeytown2’s picture

Status: Reviewed & tested by the community » Fixed

committed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Mentor.37’s picture

Version: 6.x-1.x-dev » 7.x-1.0-beta2

Here same problem with drupal 7, how can i solve it?

Anonymous’s picture

Have you been through the thread above? In particular, what if anything is being created in the cache ?

Mentor.37’s picture

I'm on drupal 7 with and the post is for drupal 6 so the patch is not working.
With Clean Pagination I have problems with blog and taxonomy terms. The problem is the same of this.

I'm using Clean Pagination to have my pagers from www.site.com/blog/user?page=1 to www.site.com/blog/user/page/1 and Boost only caches file for www.site.com/blog, not for www.site.com/blog/user/page/1.

Same problem with taxonomy.
If I have www.site.com/taxonomy_term and www.site.com/taxonomy_term/page/1 Boost only cache taxonomy_term.

Anonymous’s picture

What I meant when I wrote, have you gone through the thread, is what have you got in your cache being generated. Is the additional rewrite rule working? have you read this post on the pagination module appearing to conflict with boost and global redirect

#1285824: what would you do for the front page?

Mentor.37’s picture

I have no problem with global redirect.
I added without success the additional rewrite rule.
The problem only exists for taxonomy and blog, for the frontpage all works without problem.
For example for frontpage i have:

www.site.com/frontpage
www.site.com/frontpage/page/1
www.site.com/frontpage/page/2

and in cache folder i have the file:

frontpage_.html

and the folder:

frontpage/page

with subfolders:

1
2

But with blog and taxonomy terms i do not have the folders in cache.

Anonymous’s picture

If the rewrite rule is removed then does the front page fail to cache?

Mentor.37’s picture

With or without rewrite rule there is no problem for the frontpage.

Mentor.37’s picture

Any help?

Anonymous’s picture

Status: Closed (fixed) » Postponed (maintainer needs more info)

So the original fix worked with a pager on the front page but not under differing pages and the rewrite rule does nothing for any situation (so can be excluded), so we go back to the time honoured boost debug, which is

  1. Does drupal place anything in the cache for these pages at all? (even the first page or a folder)
  2. Visiting these pages is there ever a cookie called DRUPAL_UID set? (use firebug)
  3. Have any PHP errors been spotted in the logs for these pages e.g. taxonomy_.html already exists or cannot create a folder /taxonomy/
Mentor.37’s picture

The pager on the front page works without problem without any fix.
The ohter pages do not works with and without rewrite rule.

For other questions:
1: For these pages drupal only place in the cache the first page
2: Yes in the not cached pages there is the DRUPAL_UID cookie
3: In the log there are not any error

Thank's for your help.

Anonymous’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

The DRUPAL_UID cookie is set when a drupal session is opened, it would appear from the information you provided that on the uncached pages one of you modules is starting up a drupal session for an anonymous user (possibly because they want to store the page number), this is therefore not a boost issue but one caused by the modules involved that should set their own cookie rather than initiate a drupal core function.

Effectively one of the modules involved is "fake" logging in a user so boost disables as otherwise boost could do things like display private user information like cached versions of edited pages.

Mentor.37’s picture

Sorry, my error, i was logged-in in other tab, there is not DRUPAL_UID cookie for cached and not cached pages.
Sorry.