Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I'm using boost successfully on a high traffic website, with just one minor glitch. As I understand it, Boost applies to anonymous users only, and should have no effect on logged in users? I find that even when logged in, it still serves up the cached version of the front page, rather than the current one.
The problem is that the frontpage appears to show that I am not logged in, when in fact I am. When I browse to any other part of the site, it does revert to the correct behaviour- so this problem effects only the front page.
Comment | File | Size | Author |
---|---|---|---|
#69 | boost-305071.patch | 3.14 KB | mikeytown2 |
#68 | boost-305071.patch | 2.1 KB | mikeytown2 |
#67 | boost-tg.patch | 1.5 KB | tg |
#61 | boost-305071.patch | 3.68 KB | mikeytown2 |
#60 | boost-305071.patch | 3.68 KB | mikeytown2 |
Comments
Comment #1
chrism2671 CreditAttribution: chrism2671 commentedI should point out that boost has given us at least 3x the traffic capacity on the same server, and rising- what a great plugin!
Comment #2
drupdrips CreditAttribution: drupdrips commentedI second your enthusiasm about using boost .. it is so good for that initial first impression for a new visitor and also so important for the home/front page to show up under 2 secs. Not to mention of the additional load it helps to shave off from php processing except for those logged in users / and query string pages.
However I have found this module needs some careful consideration of your user's anticipated behaviors and you have to test for each of those cases and tweak in some places to get desired results.
For the problem you mention, I want you to try the following and let me know the results.
If you go to the page where you normally login, do this :
1) use firefox
2) go to the login page (without actually logging in yet), and pull up the cookie information from FF browser menu Tools->options->Privacy-> Show cookies.
3) Do you see a cookie from your domain.com ?
If the answer to 3 is no, then I know what it is. otherwise I'd say check your htaccess rules and make sure you are following the installation document for this. I am using lighttpd for my webserver so I am not using htaccess rules, but it should work if you have set it up as mentioned in the document.
Comment #3
chrism2671 CreditAttribution: chrism2671 commentedThere are cookies there. However, attempting to log out does not actually seem to allow me to logout (and redisplay the login screen) on the front page- rather, it displays the 'logged in' page, and on other pages is displays the 'logged out' page. navigating back to the front page still displays the 'logged in' page, and you have to click Log out at least one more time to achieve the desired effect.
Very strange!
Comment #4
drupdrips CreditAttribution: drupdrips commentedA few more quick things to check :
(1) Check that you are not generating a logout.html in your cache/domain.com/0/ folder.
If you are, and I was too, - go to domain.com/admin/settings/performance/boost and put "logout" without any quotes as one of the pages not to cache.
(2) check that you are setting appropriate Response Headers in the browser
with - no-store, no-cache, must-revalidate, post-check=0, pre-check=0. Verify from firebug.
(3) Also in the above post when I asked you to try and see if you have a cookie to begin with, make sure you CLEAR your browser cache, before you land on your first page with the login block (if this page was generated as a cache page earlier). The reason: Your true anonymous visitor visiting first time will not have a cookie from this domain to begin with when he lands on your cached front page or another cached page that has the login block. (If the logon block was generated as a page after going to "/user" path then you get a cookie since /user path follows php invocation and will not serve a cached page, but otherwise when the login block is part of a cached page and this is the first page that the visitor comes to try and login, make sure to clear your prior cookies for true test results). The first login in this case is bound to fail - as a result of a drupal core behavior that should not be overridden such as by hacking session.inc.
Let me know what you find.
Comment #5
wwwoliondorcom CreditAttribution: wwwoliondorcom commentedThanks, I have the same issue and will test also.
Comment #6
gawrion CreditAttribution: gawrion commentedSubsribing too! The same problem with my site.
"I find that even when logged in, it still serves up the cached version of the front page, rather than the current one."
I know that my session is active (going deeper result in right displayed pages) and i only see logged out state of front page after logging in, but its annoying form me and ununderstandable for not smart users. After some time passes by, the front page displays right..
My .htaccess file:
# BOOST START
Header add Expires "Sun, 19 Nov 1978 05:00:00 GMT"
Header add Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
AddCharset utf-8 .html
RewriteCond %{REQUEST_METHOD} ^GET$
RewriteCond %{REQUEST_URI} ^/$
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP_COOKIE} !DRUPAL_UID
RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0/index.html -f
RewriteRule ^(.*)$ cache/%{SERVER_NAME}/0/index.html [L]
RewriteCond %{REQUEST_METHOD} ^GET$
RewriteCond %{REQUEST_URI} !^/cache
RewriteCond %{REQUEST_URI} !^/user/login
RewriteCond %{REQUEST_URI} !^/admin
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP_COOKIE} !DRUPAL_UID
RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0%{REQUEST_URI} -d
RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0%{REQUEST_URI}/index.html -f
RewriteRule ^(.*)$ cache/%{SERVER_NAME}/0/$1/index.html [L]
RewriteCond %{REQUEST_METHOD} ^GET$
RewriteCond %{REQUEST_URI} !^/cache
RewriteCond %{REQUEST_URI} !^/user/login
RewriteCond %{REQUEST_URI} !^/admin
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP_COOKIE} !DRUPAL_UID
RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0%{REQUEST_URI}.html -f
RewriteRule ^(.*)$ cache/%{SERVER_NAME}/0/$1.html [L]
# BOOST END
Comment #7
lelizondo CreditAttribution: lelizondo commentedI'm having the same problem, I'll move the version to the one I'm using. Steps to reproduce:
1. Make sure boost it's caching the frontpage and other pages and it's active. Then
2. Login in the frontpage
3. Logout immediately
You won't see the page as a anonymous user but as the user you used to login. If you move to other page you'll know you're an anonymous user, if you try to access /logout you'll get a 404.
Don't know if this is related to http://drupal.org/node/197786, I've tried a couple of the solutions in that post, #61 and #129 but I'm still having the same problems.
Comment #8
mikeytown2 CreditAttribution: mikeytown2 commented@lelizondob
2 Questions:
ETags?
Is mod_headers enabled on your host?
Comment #9
lelizondo CreditAttribution: lelizondo commentedOK, that was fast.
mod_headers IS enabled
ETags: Do Nothing
Comment #10
mikeytown2 CreditAttribution: mikeytown2 commented@lelizondob
Try setting it to None; I got the location wrong so manually edit the htaccess file like so
Place FileETag None Above FilesMatch.
Comment #11
lelizondo CreditAttribution: lelizondo commentedNo, that didn't work. I'm just uploaded a video to show you exactly what the problem is, the video is less than 30 secs.
http://www.screencast.com/t/GkDwTqgB
Thanks
Comment #12
mikeytown2 CreditAttribution: mikeytown2 commentedCool vid!
Just wondering what happens when you hit the logout button that is on the admin menu top bar?
Comment #13
lelizondo CreditAttribution: lelizondo commentedit's the same behavior. I should have done that in the video.
Comment #14
mikeytown2 CreditAttribution: mikeytown2 commentedDo you have something that you can check what cookies are set? The cookie to look for is DRUPAL_UID.
Comment #15
lelizondo CreditAttribution: lelizondo commentedI'm using Firefox's webdeveloper add-on to inspect the cookies and I'm seeing 8 cookies just after I hit logout, if I refresh the page I know I'll get rid of the admin_menu and the login block will show up again.
If I refresh I see the same cookies. If I login now I see:
Comment #16
mikeytown2 CreditAttribution: mikeytown2 commentedThroughout the login logout process what happens to the DRUPAL_UID cookie?
Comment #17
lelizondo CreditAttribution: lelizondo commentedDon't know exactly what you mean but If I login I get a cookie (actually 2, one with www.mydomain.com and another with domain.com) if I logout I don't.
Comment #18
mikeytown2 CreditAttribution: mikeytown2 commentedThe DRUPAL_UID cookie controls if you hit the Boost cache. Seems like it's still set and doesn't get removed until the next page load.
Comment #19
mikeytown2 CreditAttribution: mikeytown2 commentedTry this, sets the cookie to way back...
Comment #20
lelizondo CreditAttribution: lelizondo commentedI applied the code, ran update.php, cleared the cache (both drupal and boost) but still having the same problem.
Comment #21
mikeytown2 CreditAttribution: mikeytown2 commentedCan I get a play by play of that cookies status?
Example:
Logged out - No Cookie
Logged in - Cookie
Logged in - Cookie
Logged in - Cookie
Logout button pressed - Cookie
Logged out - Cookie
Next page after logged out - No Cookie
Comment #22
lelizondo CreditAttribution: lelizondo commentedLogged Out - No cookie
Logged in - Cookie
Logout button pressed - NO cookie
Refresh after logout button pressed - No cookie
node/x after I hit refresh - No cookie
Comment #23
mikeytown2 CreditAttribution: mikeytown2 commentedSo at this stage
Logout button pressed - NO cookie
It appears like your still logged in.
OK so the cookie is getting cleared. For some reason then, your browser is caching the logged in page. You tried the solution in the other issue and it still doesn't work correctly. What happens when you use a different browser?
Comment #24
lelizondo CreditAttribution: lelizondo commentedI've used firefox on ubuntu, firefox on mac, safari on mac and chrome on mac and I get the same behavior. I also hacked drupal with no result.
Comment #25
mikeytown2 CreditAttribution: mikeytown2 commentedIs it possible there is some sort of network cache involved? Try enabling this setting under boost:
Turn off clean URLs for logged in users.
Makes the URL's for logged in vs logged out be completely different.
Comment #26
lelizondo CreditAttribution: lelizondo commentedNo, that didn't work, maybe because the frontpage has the same value for both, but doing it with other pages didn't work either.
Comment #27
mikeytown2 CreditAttribution: mikeytown2 commentedThis code might be related to the issue
Try this patch
Comment #28
mikeytown2 CreditAttribution: mikeytown2 commentedAnother patch that shouldn't be so destructive to the cache
Comment #29
lelizondo CreditAttribution: lelizondo commentedTried the patch and didn't work. I left the code from #18 and #19 on, don't know if I have to remove them before I apply the last patch.
Comment #30
mikeytown2 CreditAttribution: mikeytown2 commentedTry this patch... don't put it into production its more of a "see if I'm barking up the right tree" kind of patch
Comment #31
lelizondo CreditAttribution: lelizondo commentedSorry to take that long, somehow my Linux Server just crashed, I don't want to point fingers to boost but it was enabled. Anyway, I applied the patch to HEAD and now IT WORKS! I will confirm this with other users and other browsers but I think it's a step forward.
Thanks for all your help.
Comment #32
mikeytown2 CreditAttribution: mikeytown2 commented@lelizondob
So the above patch "Fixes" the issue correct?
Can you verify that the cache is being generated and served with this hack? I'll start to work on a cleaner solution then what I have here. I'm glad we found the root of this bug!
Comment #33
mikeytown2 CreditAttribution: mikeytown2 commentedComment #34
lelizondo CreditAttribution: lelizondo commentedNo, the problem is still there, I just didn't know until a few hours latter.
I just created a video that will explain better, but basically I logout when I hit submit and I see the login block, but if I click on two or more pages and then go back to the frontpage I see myself logged in, if I click logout I get Access Denied because I was logged out.
http://www.screencast.com/t/u7KIuv52YiI
Comment #35
mikeytown2 CreditAttribution: mikeytown2 commentedWhen you see the login block after logging out, is that page in the cache? Is there the boost code at the bottom of the html? Good video btw!
Comment #36
mikeytown2 CreditAttribution: mikeytown2 commentedPlan B is to do a client side forced refresh on logout using javascript most likely; I'm assuming that reloading the page makes the problem go away correct?
So on user logout, inject javascript into that html that takes advantage of the reload() function inside the window.location object. I can probably just call location.reload(); and it will work. If I can put it in the head and have this work then that would be ideal, user sees a flash.
Comment #37
lelizondo CreditAttribution: lelizondo commentedNo, just when I logout that page isn't in the cache. I forgot to mention that. When I start navigating in the site those pages are in the cache. I'll try the javascript option on monday, but I'll will configure another site in a few more hours with boost and see how it goes.
Comment #38
mikeytown2 CreditAttribution: mikeytown2 commentedCan you try this without the patch I gave you?
Login
Logout
Press F5 (force refresh)
After the forced refresh, does the page have the admin bar at the top?
Comment #39
lelizondo CreditAttribution: lelizondo commentedI tried and the page after the refresh does not have the admin bar and the page it's being generated by boost since I can see the boost print at the bottom of the source code.
Comment #40
mikeytown2 CreditAttribution: mikeytown2 commentedK cool, that means the javascript trick has a good chance of working.
Comment #41
mikeytown2 CreditAttribution: mikeytown2 commentedGive this a spin... hopefully it works
Comment #42
mikeytown2 CreditAttribution: mikeytown2 commentedI would really like to get this fix in 1.14; tagging as a release blocker for now.
Comment #43
lelizondo CreditAttribution: lelizondo commentedI've just installed boost on another site that I'm launching this next Monday and it's working great, I'm using 1.13 and I don't have any problem at all.
I'm worried about this because now I don't know if the problem is boost or the drupal cache. I'll try the patch in #41 tomorrow in the site with the problem (the one in the video).
Comment #44
mikeytown2 CreditAttribution: mikeytown2 commentedBoost fixes issues with core sometimes because it effects how the cache works.
Comment #45
lelizondo CreditAttribution: lelizondo commentedWait a minute, forget what I've said about not having problems in this new site. I'm having the same problems, even worst. After I click logout I still see the page as if I were logged in (with the admin menu) and the page is not being generated by boost. If I hit refresh the page gets generated by boost and the admin menu goes away.
I'll try the patch in and I'll post the result in a few minutes. I'll do this with the following settings:
Drupal Cache: Disabled
Minimum cache lifetime: None
Block cache: Disabled
Optimize CSS files: Enabled
Optimize JS files: Enabled
Boost - HTML - Default minimum cache lifetime: 10 min
Servers URL or Name: %{SERVER_NAME}
Document Root: %{DOCUMENT_ROOT}
ETag Settings: Do Nothing
I tell you this because I want to make sure I have boost configured correctly and this will not affect the result of the patch.
Comment #46
lelizondo CreditAttribution: lelizondo commentedbtw, I have a simple question. does 'drush cache clear' also clears boost cache?
Comment #47
mikeytown2 CreditAttribution: mikeytown2 commentedDon't think it does.
Comment #48
lelizondo CreditAttribution: lelizondo commentedNo, drush does not clear the boost cache.
I'm trying this in another site but it's not working, after I hit logout I still see the admin menu as I were logged in and boost and there's not 'boost print' on the source code. If I hit refresh the admin menu does not go away, if I hit logout I get 404. Now there's no way to get rid of the admin menu even thought I'm logged out, refreshing the page does not work at all.
Comment #49
mikeytown2 CreditAttribution: mikeytown2 commentedDrush can if you set the Ignore cache flushes to disabled, but then you will be loosing the cache a lot more often then one might like.
So my little hack doesn't do the trick then. Try this patch. If this doesn't work I can try Plan C... which has the potential to be unstable if done incorrectly.
Comment #50
lelizondo CreditAttribution: lelizondo commentedOne more thing before I try the patch. If I hit logout when I am in admin/* I get redirected to the frontpage (as I should) and the admin_menu goes away and the page it's generated by boost, the problem is when I hit logout on the frontpage or any other node.
Comment #51
mikeytown2 CreditAttribution: mikeytown2 commentedCool. Plan C is to use the trick I recently learned from this thread #619934: CRON generates a "Page not Found" error...
In short if $_SERVER['REDIRECT_STATUS'] == 302 && Referrer == logout then inject the reload javascript. I have a feeling the javascript is being put in the 302 redirect that one gets after using the logout button.
Comment #52
lelizondo CreditAttribution: lelizondo commentedHaven't tried the patch but I changed the status. My mistake, I'm testing right now.
Comment #53
lelizondo CreditAttribution: lelizondo commentedI just tried the patch and it doesn't work, the bad news is that when refreshing the frontpage doesn't give me the cached page, I still see the admin menu.
If I logout from admin/* I'm redirected to the frontpage with www.domain.com/?nocache=1. Then if I visit another page boost gives me the cached page, then if I go back to the frontpage now it's only www.domain.com and the admin_menu it's still there as if I were logged in.
One important thing about this site I'm patching right now is that I use panels in the frontpage but it isn't cached by panels. Don't know if that's actually important.
Comment #54
lelizondo CreditAttribution: lelizondo commentedI've just discovered that I'm using poormanscron 1.x and according to my status page I should be using the 2.x branch. I don't think that's a problem but it's getting late and I don't want to discover that it was just a stupid thing I was doing so I better inform you about this.
Comment #55
lelizondo CreditAttribution: lelizondo commentedI'm also using memcache and the memcache module, it's correctly configured. I read that it is possible to have both installed, am I right?
Comment #56
mikeytown2 CreditAttribution: mikeytown2 commentedYeah memcache should work & I don't think poormans will effect this.
Comment #57
lelizondo CreditAttribution: lelizondo commentedjust changing status
Comment #58
mikeytown2 CreditAttribution: mikeytown2 commentedI don't think it would be that important. Plan D is to set a cookie on logout that then gets checked on the client side, if it exists then kill cookie and refresh page... after that I'm starting to run out of ideas. Anyway patch for Plan C will arrive in the next day or so; got other things to do.
After looking at this I think Plan C will work.
http://api.drupal.org/api/function/user_logout/6
http://api.drupal.org/api/function/drupal_goto/6
'HTTP_REFERER' == logout && 'REDIRECT_STATUS' == 302 will be the trigger for the javascript refresh injection. Fairly sure the javascript was pointless (in it's current form) after looking at drupal_goto & user_logout.
Comment #59
mikeytown2 CreditAttribution: mikeytown2 commentedLocal testing and Plan C will not work...
which leaves me with the plan D. I think adding a url variable called boost-logout set to 1 and then using javascript to see if that exits & if it does, redirect to the homepage. Hopefully this does it. If not, I'm out of ideas on how to fix this... well I could try a mod of this (use a cookie instead and don't inject any url variables) but hopefully this works.
Got 1 more idea, set a meta tag to prevent the browser from caching the front page.
http://www.pacificnet.net/~johnr/meta.html
hook_preprocess_page() $variables['head']
Comment #60
mikeytown2 CreditAttribution: mikeytown2 commentedUsing the meta tag way, which I like a lot better.
Comment #61
mikeytown2 CreditAttribution: mikeytown2 commentedComment #62
mikeytown2 CreditAttribution: mikeytown2 commentedHeads up I am able to reproduce this bug finally after adding these lines to the bottom of my htaccess file
Bad idea, don't use
Header unset ETag
.Comment #63
mikeytown2 CreditAttribution: mikeytown2 commentedThis patch fixes the issue
#550488: Turn off mod_expires for all .php files
Comment #64
lelizondo CreditAttribution: lelizondo commentedI just came back and I'm lost, don't know now if I should apply the patch in #550488: Turn off mod_expires for all .php files or the ones in #59, #60 and #61
Comment #65
mikeytown2 CreditAttribution: mikeytown2 commented#550488: Turn off mod_expires for all .php files is the answer, #7
Comment #66
lelizondo CreditAttribution: lelizondo commentedcool. it seems like the problem is solved when I applied the patch in #550488: Turn off mod_expires for all .php files thanks for all your support
Comment #67
tg CreditAttribution: tg commentedthis patch you mentioned didn't fix it for me:
#550488: Turn off mod_expires for all .php files
however, I was able to fix it, see my patch
basically what it does: don't remove the cookie immediately, set it 0, then at the following request remove it.
this way the browser doesn't show the cached still logged in page, as before.
Comment #68
mikeytown2 CreditAttribution: mikeytown2 commenteddid some tweaks to this that should make it better... in short if the cookie exists but your not logged in, remove the cookie; should fix the rare occurrence of the cookie getting stuck as well as this bug.
Comment #69
mikeytown2 CreditAttribution: mikeytown2 commentedchanged the API for boost_set_cookie, takes UID instead of user object; makes the way this works easier to understand.
Comment #70
mikeytown2 CreditAttribution: mikeytown2 commentedcommitted
Comment #72
lelizondo CreditAttribution: lelizondo commentedis this really working? I just updated to the latest version and the pages are not being generated by boost (I don't see the boost tags) but maybe is just some misconfiguration. Can anyone confirm please?
Note: I updated the .htaccess with the new configuration boost provided and also with the patch in #550488: Turn off mod_expires for all .php files
Comment #73
mikeytown2 CreditAttribution: mikeytown2 commented@lelizondob
Can you describe in more detail what is wrong? Best way to test boost is to use a different browser; although with the new version of boost, it's fairly aggressive when it comes to getting rid of the boost cookie. Also be aware that one of the settings does allow you to turn off the boost tags now; sets a http header instead (this is not the default in case you where wondering).
Stating that you just updated to the latest version of boost, was boost working before? If yes how old was your previous version of boost?
Comment #74
lelizondo CreditAttribution: lelizondo commentedThere's nothing wrong besides the fact that I don't see the boost tag at the end of the source code. I'm aware of the new option and I double checked that it is configured properly.
The only doubt I have is how to configure the Etag Settings, currently it's configured to "Set FileETag 'None' - Do not send an etag"
The version I was using before was 1.0-rc2 (with the patch inf #69), didn't realize it was that old till now that you ask.
I don't want to make a big deal of this since I updated in a mirror site, not the production one, but it has the settings from the live site and it's also running the Secure Site module, this could be affecting boost, I'm aware of that.
I'll update the production site in a few hours and let you know if there's a problem, if not, I'll be more than glad to close this issue myself.
Comment #75
mikeytown2 CreditAttribution: mikeytown2 commentedOne thing to be aware of is the 'gz' directory has been nuked in the latest version of the rules. In your case I highly recommend getting the rules from the boost-rules page and not from htaccess1.txt. The generated rules will work in your case then.
Comment #76
lelizondo CreditAttribution: lelizondo commentedI'm getting the rules from the boost page.
Comment #77
lelizondo CreditAttribution: lelizondo commentedIt works great. Thanks. I'm closing this.