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?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tstoeckler’s picture

Hmm... 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...

Or does this have more to do with full page caching?

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.

Rob_Feature’s picture

Here's a suggestion on how you can test it (to mirror what I'm seeing):

  1. Turn on all caching (page and block)
  2. Drop the block on a page with the time display enabled
  3. Logout
  4. View the block and let it tick up for a couple minutes (2 or 3 should do it)
  5. Manually refresh the page and view the block's time

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.....

Rob_Feature’s picture

Has anyone tested this? I'd love to see if other can reproduce it....

tstoeckler’s picture

Yes, 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.

Jarry’s picture

I'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...

tstoeckler’s picture

Well, 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.

Jarry’s picture

Is 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...

tstoeckler’s picture

Well, 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.

tstoeckler’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Active » Needs review

Here'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.

Rob_Feature’s picture

Yes, 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?

tstoeckler’s picture

Oops! 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.

tstoeckler’s picture

Ok, this one applies to HEAD.

tstoeckler’s picture

Version: 7.x-1.x-dev » 6.x-1.x-dev
Status: Needs review » Needs work
FileSize
2.41 KB

Alright, the previous patch broke the 'Local time zone'. Committed this patch to D7.
http://drupal.org/commitlog/commit/12842/241741eaf779db2e35844686d7b5906...

Now on to D6.

tstoeckler’s picture

Version: 6.x-1.x-dev » 7.x-2.x-dev
FileSize
2.51 KB

Committed 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.

tstoeckler’s picture

Status: Needs work » Fixed

This was fixed in 7.x-2.x in #1246680: Form AJAX causes problems.

Status: Fixed » Closed (fixed)

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