Hello,

(I know Boost for D7 is still very much in dev, so am raising this as a heads-up rather than to whinge)

Not sure if this ought to be a bug report or a feature request, but this is an issue that doesn't seem to happen with the D6 version of Boost so I'm going to call it a bug report. This is a follow-on from the following ticket, which I'm not going to add to since it's classified as Closed:

http://drupal.org/node/1169044

The user in that ticket was having problems with the "redirect" module, but I've had the same issue with a site's homepage. To reproduce:

(With Drupal 7.0 and latest Boost 7.x-1-x head from github)
1) Create a page at /page-alias
2) Designate that node as the homepage
3) Turn on Boost
4) Logged-out users visiting /page-alias will Boost's cached version of that page, which is blank except for the "Cached by Boost..." message. Instead, they should be redirected to the cached homepage, or served Boost's cached version of the homepage.

So as a workaround, we can add /page-alias to the list of exceptions, but that's not ideal. It'd be great if someone could please have a look at this. Thanks for a great module!

Comments

billspreston’s picture

Edit: Sorry, I didn't mean github. I meant http://drupalcode.org/project/boost.git

joelstein’s picture

Title: Better handling of redirection needed » Bypass caching on redirects
Status: Active » Needs review
StatusFileSize
new365 bytes

Another way to see this in action is to enable the core Search module, then as an anonymous user, visit /search. The first time you'll get redirected. The second time you visit that URL, you'll get a blank page with the Boost comment in the source HTML.

By implementing hook_drupal_goto_alter, we can disable caching anytime a user would be redirected. That way, the URL which issues the redirect won't result in a blank cached page.

The attached patch does just this.

ParisLiakos’s picture

StatusFileSize
new493 bytes

I had the same problem and solve it with a much simpler way.
joelstein's patch is more the drupal way but i am attaching my change that make me solve this.that would work in any empty data page and not just pages that user got redirected from drupal_goto()

bgm’s picture

Status: Needs review » Fixed

This might also fix #1401442: Doesn't redirect to default language prefix.

I've committed joelstein in #2 to 7.x-1.x.

I'm tempted to commit rootatwc's patch in #3 as well, but there might be (rare?) situations where we might want to cache a blank page (I could be convinced otherwise).

Thanks for the patches (and sorry for the slow response).

joelstein’s picture

Thanks!

Status: Fixed » Closed (fixed)

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

ram4nd’s picture

Status: Closed (fixed) » Patch (to be ported)

I'm tempted to commit rootatwc's patch in #3 as well, but there might be (rare?) situations where we might want to cache a blank page (I could be convinced otherwise).

Rare situations like? I would rather have the redirection(what drupal would normally do) instead of showing a blank page.

devvmh’s picture

Issue summary: View changes

+1 to rootatwc's patch. I've just updated my website from D6 to D7 and this is a huge headache for me without rootatwc's patch (since I still need to manually specify the urls to have it not cache).

I've got a website mostly indexed by 300+ aliased taxonomy terms, but about a dozen of those are redirects to other terms, websites, or static pages. None of the dozen redirects work without either stopping Boost on that page manually in config, or by using rootatwc's patch.

For now I've patched Boost, but I'd love to see this committed!

I haven't looked into it yet myself, but is there a way of differentiating an empty $data for a blank page from an empty $data for a redirect?

Also, I'd argue that my use case is more "normal" - people use redirects a LOT. If someone for some reasons wants a white screen of death, and they want it to be cacheable by Boost, I say they should be the ones patching Boost, not me. Does that seem reasonable?

Thanks to everyone who posted in this thread - it's helped me immensely!

rp7’s picture

+1 for rootatwc's patch as well.

If I'm correct, the patch in #2 does not fix this issue if the Redirect module (https://drupal.org/project/redirect) is used. This module does not use drupal_goto(), but adds the PHP "Location" header directly.