The open now is currently being calculated server-side. That leads to logical problems with caches like boost or other proxy-caches. The result is cached as-is even when the result should be not open.

A possible solution would be to implement this check in JavaScript dynamically. Any other solutions to this problem?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anybody created an issue. See original summary.

Anybody’s picture

Project: Opening hours » Office Hours

Sorry the module we used is 'office hourse', not 'opening hours' - so moving to the right project.

Anybody’s picture

I'll now try to solve this via JS because it would be wrong to influence the whole page caching just for the open / closed functionality. A dynamic indicator seems best.

johnv’s picture

Ok. In D8 we are solving this with the new Cache API.

Anybody’s picture

I invested 2 hours to port the logic to JavaScript and expose the required date information so that the open / closed functionality is now re-calculated in the client.
I kept the PHP as-is where possible to make the JavaScript degradate gracefully. So the status is still being calculated in PHP for clients who don't support JS. Both status texts are being output into DOM but the non-matching one is hidden by PHP and JavaScript. The JS recalculates the status and hides / shows the current correct status even if the wrong one is being returned from cache.

I ensured that the functionality also works with multiple instances on the same page, for example in views.

Please test a lot and provide feedback. One day I'd be happy to see this as part of the module for perfect behaviour on statically cached pages :)

Patch attached.

Anybody’s picture

Patch was missing the office_hours.block.js file. Corrected patch attached!

johnv’s picture

Ah, I already missed this file.
Why do you need an extra js-file?
[EDIT] Oh, I understand. I prefer using then the names office_hours.formatter.js and ~widget.js

johnv’s picture

effectively, we are moving code from PHP to JS, aren't we?

johnv’s picture

And the same goes for the $next variable from formatter.inc.

johnv’s picture

I removed the 'open' code from includes/office_hours.formatter.inc. In fact, the 'next day' has the same problem with external caches.

  • johnv committed 2b1a7a4 on 7.x-1.x authored by Anybody
    Issue #2919519 by Anybody: 'Open now' formatter fails with boost /...
johnv’s picture

Title: "Open now" fails with boost / caches » "Open now" formatter fails with boost / caches
Version: 7.x-1.x-dev » 7.x-1.8
Status: Needs review » Fixed

This is fixed. Thanks.
I guess we need another issue for the 'next day' formatter.

Anybody’s picture

Thank you very very much! Great to see this in action :)
Is a new stable release planned containing this?

johnv’s picture

I released 1.9 yesterday.
P.s. JS-files have been renamed and moved into js directory.
If you feel to test the 'open next' formatter, be my guest :-)

Do you agree that this move is not needed in D8, where I have implemented a #cache tag?

Anybody’s picture

Thank you @johnv. Regarding D8 I'm not sure. If the pages are cached statically the "now open" logic has to be recalculated every time, so it might also be nice to do this in the browser via JS instead. I have not used this in D8 yet.

johnv’s picture

Status: Fixed » Closed (fixed)

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

Liam Morland’s picture

Content with class element-invisible will be read to users of screen readers, so they will hear both the closed and the open message. It is better to give a class which applies display: none since that is hidden from everyone.

johnv’s picture

Status: Closed (fixed) » Active
johnv’s picture

Component: Code » Code - formatter
Anybody’s picture

Status: Active » Needs work

I'll create a patch for #18. Furthermore I saw that the script seems buggy, we have a case where it shows close while it should be open. Please help to correct this. The JS code was based on the former php code.

Anybody’s picture

@johnv: Ok I finally found the reason and solution. The problem was that the JS calculation was not compatible with the "group" / "compress" options and because it needs the raw days array for calculation.
Furthermore I fixed the accessibility bug.

Could you please review and commit, because currently the indicator is broken!

Anybody’s picture

Issue summary: View changes

PS: Could you enable automated testing for this branch and issues perhaps?
That would help to see if the patch applies correctly. Thanks!

johnv’s picture

I dont know what I did, but the automated testing is now enabled weekly. Is it ok like this?

Anybody’s picture

Hi @johnv, thank you! Please select "Run on commit and for issues" instead. I suggest in combination with "Stable" core.

Anybody’s picture

Version: 7.x-1.8 » 7.x-1.x-dev
johnv’s picture

Done.

  • johnv committed 026eeae on 7.x-1.x authored by Anybody
    Issue #2919519 by Anybody, johnv: OpenNow formatter fails with boost /...
johnv’s picture

Version: 7.x-1.x-dev » 7.x-1.9
Status: Needs review » Fixed

Committed . Thanks. I renamed a variable.
Please re-open if there is still a problem.

Anybody’s picture

Great, thank you!!

Status: Fixed » Closed (fixed)

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