Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
Before boost was enabled, users that have persistent login turned on, don't need to log in again when revisiting the site (without logging out).
Now users need to login again and it seems persistent login is not working anymore.
My current setup is:
Boost 6.x-1.13
Drupal 6.14
Apache 2.0
PHP 5.2.6
Mysql 5.0
Thanks.
Comment | File | Size | Author |
---|---|---|---|
#7 | boost-617886.patch | 1.7 KB | mikeytown2 |
Comments
Comment #1
mikeytown2 CreditAttribution: mikeytown2 commentedHmmm, I haven't experienced this my self. How long is the persistent login set for? Using core (default 2 weeks?) or another module to do this? Any other tips you can provide me for replicating this bug?
The one thing that comes to mind is ETags,
http://drupal.org/node/545908#rules
Set it to None, save, & then copy the new rules over the old rules in your htaccess file.
If you know how to look at headers, check for etags before doing this. Let me know if this setting removes the etag, It's a fairly new setting so verification by multiple people is always nice.
Comment #2
h3000 CreditAttribution: h3000 commentedHi mikeytown2,
The Etag setting was set to "Set FileETag 'None' - Do not send an etag".
I tried changing the setting to "Do Nothing" and it now works.
Thanks!
Comment #3
BlueIrisNina CreditAttribution: BlueIrisNina commentedHi mikeytown2,
I had the Etags set to none and it wasn't working (I checked .htaccess on the server and it was in the file). I moved it outside of the Boost code and now it works.
Nina
Comment #4
mikeytown2 CreditAttribution: mikeytown2 commentedWould you mind testing the location of the etag for me?
Try it at the top of the rules
Try it at the bottom
Try it by breaking out and back in of the mod_rewrite section
Comment #5
BlueIrisNina CreditAttribution: BlueIrisNina commentedHi,
I am having a little trouble figuring out if everything is getting cleared but here's what I got for results and what I did to clear.
Where it was before I tested (by itself above the Boost code) I got a 'D' -as opposed to an 'F' when I had it in there through Boost - when I ran YSlow. The three things it didn't pick up and still had misconfigured tags was my favicon and my aggregated .js and .css files.
When I moved it to top of Boost rules I got a 'B' with only the favicon coming up as misconfigured. Before testing this I flushed the caches, cleared the Boost cache page and ran cron (this must clear it all out, right? : )
I then moved it to the bottom, ran cron and flushed and again a 'B'.
I then broke it out with your code in the rewrite section and again 'flushed and ran' and again a 'B'.
I am having the problem as the other person in this thread with this flushing while updating... I have found that if I am working on my style sheets and Boost is on I need to "un-aggregate them" and still flush and sometimes run (cron) to see the updates.
Is there an easier way?
Nice module BTW. Really helped me out with the speed. This is my first Drupal site. It's still running a bit slow (3.02 secs on the home page) but far, far better than it was. YSlow indicates I should have some far future expiring headers. I noticed in the Boost code there is something about expires and it's set at 1978 and another setting I believe looks like 2 weeks out. Is there something I should do to far expire my jpgs and gifs?
Sorry if I sound inept - this is all new stuff to me...
Thanks,
Nina
Comment #6
mikeytown2 CreditAttribution: mikeytown2 commentedWith the original placement of the Etags by this module you where having issues with logged in users being logged out correct?
Here's a post that deals with long cache times for other objects; may not be 100%, its a little old... things change fairly quickly around here.
http://drupal.org/node/185075#comment-1560198
Also be aware that ETags are not "Evil" like yslow would make you believe. If I can set an Etag for just the boosted cache, some very good things happen in terms of reducing the load on your server. Server will send out a 304 instead of the file saving you bandwidth. Only when that file has changed (browser & server know due to the etag) will the new file be sent out. This is a nice side effect of the static cache; ETags are useful for webpages. The yslow rule in regards to ETags is mainly for server clusters. Either way try it with this setting in boost
Set FileETag 'MTime Size' - Useful in server clusters
as this is the correct way to do ETags in a cluster, and it might make YSlow be quiet on the subject.Example code placement for correct ETags
If you could test this, I would appreciate it.
Comment #7
mikeytown2 CreditAttribution: mikeytown2 commentedPatch for moving the etag to the top position.
Comment #8
mikeytown2 CreditAttribution: mikeytown2 commentedcommitted