Open or closed the status doesn’t change

I did some more tests and saw that also the problem exist with authenticatd users.
The status is only updated after clearing the cache.

OK, I was surprised, since the new version explicitly addressed the caching.
Please uncheck the caching in your view. It is hidden under the 'Advanced' section in the third column of the View configuration screen.

changing to a normal bug. Also, 'Needs work' is only to be used if a patch is applied an reviewed.

@johnv I followed your advice and uncheck “caching” in my view (see the attachment).
And did some more research as result :

- When you visit the website form a new browser the status is correct.
- When you already visited the website and open the website in a new tab without closing your browser, or refresh the page then the status is incorrect.
This is for anonymous users.
- When you visited the website as authenticated user and you refresh the page or open the website in a new tab the status is correct.
- After clearing the cache the status is for everyone correct authenticated and anonymous user

Please check if the patch from 🐛 Views filter 'current open/closed status' does not work Needs review helps.

I tried the patch #6 but it didn't solved my problem.
I saw also that it failed for "PHP 8.1 & MySQL 5.7, D10.2.1 Patch Failed to Apply".

And our configuration is :
D10.2.4
PHP 8.2.16

You state that the problem is in views.
Let's verify your basic behaviour. Please test with a normal entity page view with the formatter setting 'Current status/Current status position' set to before or after the hours.
Both for anonymous and authenticated users.

As you asked I made a normal entity page view with the formatter setting 'Current status/Current status position' set to before or after the hours.
In attachement you the results after refreshing the page when the customer was closed.

Hmm, it seems there is a problem with public function getNextDay(int $time), which receives a Unix timestamp, and calls $status = $item->getStatus($time), that expects a HHMM time.

Please test the new -dev version and report back.
The problem was that the Season~isInRange() function was not correct. Therefor, the time wat replaced by a date early in the process, corrupting the isOpen() status.

Is it correct that today 19/4 there is a new release of the dev version ?

Indeed, but please do not use it . I am in the middle of a development.

Ok but we have now installed the dev version of 19/4 but leave it now like that until you give further instructions.

You can now use the most recent dev-version.

We updated to the latest dev version (see attachment) but the problem isn't solved.

Hello @johnv, the latest development version does not have such an error; it's working absolutely fine on my project.

"@Mav_fly, could you please provide detailed steps to reproduce the error that's occurring on your end?"

@Amandeep123 how to reproduce :

- We made a new content type “contact”
- In this content type we made a field “opening hours “ from office hours, in which we put the hours of our customer.
- Create a view block from fields content type “opening hours” where we get the field office hours.
Specifications block
Format of the field office hours --> “Status”
Caching --> “no”
- And then put this block in the leaderboard.

Hy @Mav_fly , I followed the step to reproduce the error and encounter the same error that you are facing .

Hi, Amandeep123 thanks for the feedback!

@johnv, you have any idea what the problem problem could be ?

@Mav_fly, no I don't,
I can test again. I have a test system with only Drupal, and the 2 standard caching modules (for authenticated and anonymous users - the latter gives me many headaches)

Do you have any other caching services in place, like Varnish or 'reverse proxy'?

@johnv I don't have this kind of cashing services.

The caching time was calculated incorrectly. Please test dev version.

A fix was committed in 🐛 Views filter 'current open/closed status' does not work Needs review . There is still a problem with caching for anonymous users. please disable the view's caching.

Hmm, disabling the cache does not help refreshing for anonymous users. Perhaps filtering must move from _pre_render to _post_render.

@johnv we installed the latest dev version as asked, but the problem stil exist :(

@Amandeep123 Did you test already the lastest dev version ?

There have already been new developments for this issue ?
Because I still have this problems in one of my projects.

Thanks in advance

No, maintainer is out of options to resolve this problem.

I think i missed a specific part of your use case. "- Create a view block [...] And then put this block in the leaderboard."

I never tested a block on a page, I only tested a page view and a node page.
If the block view was added to another page, we may then run into the general page_cache module problem 'anonymous cache is forever, until refreshed by a content change, which triggers a tag refresh'.

This should be sovled by now in version 23.
If you are using exception days, then a fix is just made in dev version.

@johnv i am still getting this issue. For anonymous user it is working in my case for both view(block) and page but for authenticated user office hours status is not getting updated for both view(block) and page.

Hi rahulkhandelwal1990,
This issue is about anonymous users.
We still have an open issue for authenticated users 🐛 Status field caching still broken Active
Anw the two of us have an open discussionin ✨ Rework displaying dynamic information to JS for persistent caching Active
Let's discuss over there.