Scenario:
- Drupal 10 installation using the standard profile (Drupal 8 and 9 may exhibit the same effect).
- Content Types:
- Article Content Type with a Block Field (Referenced: Block).
- News Content Type with a Date Field (Future Publication).
- Views Block: Lists content from News in a table. Filtered by "Less than or equal to" Future Publication (date field). Cache set to "None." Display set to show all content (not limited to a specific quantity to avoid testing errors).
- Create a block using the News view and place it in a region (typically in an unrendered region, for testing, possibly in the footer).
- Browser and Proxy Cache Maximum Age: No caching.
Steps:
- Create various content:
1 Article with a reference to the block (views block).
2 News items with past dates.
1 News item with a date in the near future.
- Open the article as a guest.
- Let time pass, and the content is not updated.
Content gets updated when:
- Clearing the entire cache.
- Creating any page (regardless of content type).
Content does not get updated when:
- Waiting.
- After running the CronJob.
- Creating a taxonomy
Note: This is just an example to reproduce the issue. Problems occur whenever block data is dynamic. It doesn't matter whether the block is from a module with cache set to 0.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | av_cache_flush_v1.zip | 4.79 KB | heavystonehead |
| #3 | av_cache_flush_v2.zip | 5.41 KB | heavystonehead |
Comments
Comment #3
heavystoneheadApparently the problem is permanently solved if you trigger the following as a guest. (once)
$this->cacheBackend->invalidateAll();I don't understand it. After you've done that, you can add new views, new content types and it updates everything immediately (Blocks). The question now is, does that fix it or does it break something?
I generated the codes in the attachment with claude.ai and modified them slightly. You can generate a token URL (/admin/config/system/av-cache-flush), first save the form so that you can use the link afterwards, then run it as a guest (without logging in). V1 only has the code mentioned above and V2 deletes even more caches or executes various codes to delete various caches. (if necessary, look at CacheFlusher.php - flushCache / flushAllCaches)
Comment #4
cilefen commentedThe issue is that cached content in Views blocks doesn’t invalidate on the basis of the current date, correct?
It definitely doesn’t, and I don’t know whether this is expected behavior. Neither date nor time are available cache contexts.
We work around this with various tricks.
Comment #5
cilefen commentedThe workarounds we use usually are setting the max-age cache option. For that to really work you need #2352009: Bubbling of elements' max-age to the page's headers and the page cache. If what I am writing here makes sense with this issue I think it may be a duplicate of #2968485: Views' cache with relative date filter is not invalidated when needed. Can you verify?
At a minimum this needs a title and summary update.
Comment #6
heavystoneheadThe main problem is that blocks do not update, as in the example when a news list is displayed where content is only supposed to be visible in 1 minute, i.e. in the future, and the 1 minute passes, it is not displayed afterwards. The effect is particularly noticeable as a guest. (Time less than or equal to now)
I have had various situations, but they all lead to the same problem:
- A block created using a module where max-age was set, it should not actually save this, but it has no effect and is cached
- Calendar list, using view, here the cache option was removed, but it is saved here too
- Various other variations using some caching modules, e.g. to deactivate the cache of a page, but here too this did not lead to the desired result
The problem here is more that when you are logged in, the pages are sometimes actually updated, but as a guest they remain old. As written above, the guest only has a fresh page if the cache is completely emptied or new content is created, and it doesn't matter what content it is, i.e. it can be of any content type, it can also be contextless. A cron job does not trigger an update with the Drupal Core crone jobs.
Strangely enough, if I execute the code I posted, i.e. once, then I can create new future news and when the time passes this is immediately displayed.
I haven't done a long-term test yet, but whether I create content or new views with blocks and integrate them, everything is up to date, that's mindblowing and don't understand the mechanics.
Note: The focus here should be on the guest, i.e. an unregistered user.
I think it's basically the same as the post you linked: https://www.drupal.org/project/drupal/issues/2352009
max-age manipulation is not the solution here.
Comment #7
cilefen commentedThis seems a duplicate of #2968485: Views' cache with relative date filter is not invalidated when needed, correct?
Comment #8
heavystoneheadThis is the same case, but it does not only affect views but all blocks that are dynamic. It is also possible that a block has been created that has nothing to do with the views module.
Comment #9
cilefen commentedThe fact remains that there is neither a date nor a time cache context in Drupal. Max-age is a way to implement this but using it requires #2352009: Bubbling of elements' max-age to the page's headers and the page cache to work.
The steps to reproduce involve Views or I am missing something.
There could be something for this issue to be about that doesn’t duplicate other issues, but what will that be?
Comment #10
catchIt would be possible to add date/time cache context, maybe different versions with per hour and per 15 minute granularity. Should be added to auto-placeholdered cache contexts if we do that.
Comment #11
cilefen commentedComment #12
heavystoneheadI tried to make the effect reproducible, so I used a block of module views. But it basically affects everything. I created a custom block that fills a slider via an interface and doesn't update. Or at least it does when logged in, but not when guest.
custom block like this:
https://www.drupal.org/docs/creating-modules/creating-custom-blocks/crea...
I wanted to test it again today:
- Currently it was 2:43 p.m. and I set the time to 2:45 p.m.
- Entry in list as: Admin not visible; Guest not visible
- It was now 2:45 p.m. - Entry in list as: Admin visible; Guest not visible
- As a guest I triggered $this->cacheBackend->invalidateAll(); and entry in list as: Guest was visible
now
- Currently it was 2:50 p.m. and I set the time to 2:52 p.m.
- Entry in list as: Admin not visible; Guest not visible
- It was now 2:52 p.m. - Entry in list as: Admin visible; Guest visible!!!
the positive effect after $this->cacheBackend->invalidateAll(); only lasts for a certain time. Today's test was again with old symptoms. That means that a certain time after $this->cacheBackend->invalidateAll(); everything is always displayed live, as it should.
Comment #13
valthebaldI suggest to mark this a duplicate of #2352009: Bubbling of elements' max-age to the page's headers and the page cache and #2968485: Views' cache with relative date filter is not invalidated when needed