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!
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | no_white_page_if_redirect-1176534-3.patch | 493 bytes | ParisLiakos |
| #2 | boost.module.diff | 365 bytes | joelstein |
Comments
Comment #1
billspreston commentedEdit: Sorry, I didn't mean github. I meant http://drupalcode.org/project/boost.git
Comment #2
joelstein commentedAnother 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.
Comment #3
ParisLiakos commentedI 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()
Comment #4
bgm commentedThis 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).
Comment #5
joelstein commentedThanks!
Comment #7
ram4nd commentedRare situations like? I would rather have the redirection(what drupal would normally do) instead of showing a blank page.
Comment #8
devvmh commented+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!
Comment #9
rp7 commented+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.