I'm surprised I haven't seen this mentioned so it may be something specific to my site...but:
We're using the clock block (6.x-1.x-dev) on a page which anonymous users view and automatically is refreshed every 15 minutes or so (using a browser plugin).
The problem appears to be that the clock block is cached and, when the browser refreshes, the clock displays an incorrect time: it displays the time the page was cached as it's starting time (and then starts running up via .js from that point) rather than the actual time. As soon as the caches are cleared or cron runs, a refresh shows the proper time.
As an example:
- Cron runs at 2pm
- Page with clock loads at 2pm
- .js starts counting up, so it shows the correct time
- At 2:15pm the page properly shows 2:15 as the time because the .js counted up, HOWEVER, then at 2:15 the page refreshes and...
- ....at this point, the clock displays 2pm again, and starts counting up again
So, I'm not sure if the answer is to simply disable caching on the block? Or does this have more to do with full page caching?
Not sure how to address this, I'd help write a patch if I knew where to look. Any ideas?
Comment | File | Size | Author |
---|---|---|---|
#14 | 1192246-clock-page-cache-D6.patch | 2.51 KB | tstoeckler |
#13 | 1192246-clock-page-cache-3.patch | 2.41 KB | tstoeckler |
#12 | 1192246-clock-page-cache-2.patch | 2.35 KB | tstoeckler |
#11 | 1192246-clock-page-cache.patch | 24.3 KB | tstoeckler |
Comments
Comment #1
tstoecklerHmm... actually the block shoudn't be cached at all.
See here: http://drupalcode.org/project/clock.git/blob/refs/heads/6.x-1.x:/clock.m...
I guess that could be an explanation, not really sure what to do about that.
I'll have to think about this more and tinker with it a bit, especially because I'm almost 100% sure I've used this module on sites with page caching enabled before.
Comment #2
Rob_Feature CreditAttribution: Rob_Feature commentedHere's a suggestion on how you can test it (to mirror what I'm seeing):
The result should be that you see the time on the block go backwards a little bit (assuming that, by chance, the cache didn't just refresh for some reason). It should reset the clock to the time that the page/block was cached and then start running again.
I think maybe this issue has existed all along...the difference is we're using it in a way that actually exposes the problem (by auto-refreshing the page it's on) where as other people probably wouldn't be doing that, so no one would ever notice it.
Give it a test and please report back.....
Comment #3
Rob_Feature CreditAttribution: Rob_Feature commentedHas anyone tested this? I'd love to see if other can reproduce it....
Comment #4
tstoecklerYes, I tried and I can reproduce this. The question is, how to solve this problem. It's not the block cache, because that is disabled as stated above.
Comment #5
Jarry CreditAttribution: Jarry commentedI'm having this issue with 6.x-1.6 too, and it looks really strange: as I move around menu-items of my web, I see different time in clock-block (probably because pages or parts of them have been cached in different time). If I disable page-cache, problem dissapears. So it looks "clock" is incompatible even with "normal" page-cache...
Comment #6
tstoecklerWell, there's one way out, that I thought of, that I'm not really sold on, though:
We could simply store the offset to UTC in a JavaScript variable and then calculate the clock via JavaScript, instead of PHP. I don't see how that would degrade, though.
Comment #7
Jarry CreditAttribution: Jarry commentedIs really clock in "Clock-module" calculated with php, every time it needs to be updated? I thought it was done by js (jQuery Timers)...
But this should be definitelly taken seriously. I'd even vote for changing priority to "major". Page-cache is too important for me to sacrifice it for the cost of correct time. On the other side, clock-block where time shows random +/-15min value is actually of no use for me. Pitty, because I really like this module...
Comment #8
tstoecklerWell, currently the initial time is calculated in PHP, and then the time is incremented via JavaScript.
I guess there really is no way to solve this problem for people without JavaScript, so maybe #6 is the way to go.
Comment #9
tstoecklerHere's a patch. I rolled it for 7.x-1.x but there really shouldn't be any difference between D6 and D7 in clock.js. I assume the patch won't apply though, because the D7 version has different wrapping (because of the JS closure), so you'll have to apply it manually. If that isn't as easy as I'm assuming, and you don't have a D7 testing environment for this module, please say so, and I'll roll a separate patch.
I tested it locally and it works as expected. My initial concerns about this approach were bogus, this is how it should have been done from the start.
Please review! Thanks.
Comment #10
Rob_Feature CreditAttribution: Rob_Feature commentedYes, please post a D6 patch if you wouldn't mind. If you're confident it fixes the issue maybe just roll it into the dev?
Comment #11
tstoecklerOops! I just now realized I forgot to post the D7 patch. Will hopefully commit this to D7 later and then post a D6 patch. I'd like to test it at least before committing it to D6 and I'm not sure I'm going to get to that tonight.
Comment #12
tstoecklerOk, this one applies to HEAD.
Comment #13
tstoecklerAlright, the previous patch broke the 'Local time zone'. Committed this patch to D7.
http://drupal.org/commitlog/commit/12842/241741eaf779db2e35844686d7b5906...
Now on to D6.
Comment #14
tstoecklerCommitted the attached patch to D6 (this time with a proper commit message).
http://drupal.org/commitlog/commit/12842/92f609aa8a628a95b127f44d8c6e27e...
Moving to 7.x-2.x. That code is still in flux currently, but I want to make sure I/we remember to fix this at some point.
Comment #15
tstoecklerThis was fixed in 7.x-2.x in #1246680: Form AJAX causes problems.