Block View dated content never updates (to remove old events)

This happens to me too, even though I turn off views block caching, it still cache the block for anon users

Yeah I wish that too,hopefully have time checking it again this weekend and will try to help fixing it,

Is this for block displays only? Does it apply when you filter on time values other than 'Now'?

Are you sure this is specific to time filtering at all? This issue may be a duplicate of #2708485: Views Row caching still caches rows when cache plugin is 'none', which is fixed after D8.1.3

I tried to reproduce this and could. Just not sure if this is a bug or a feature of page_cache.

Since the page_cache module stores the entire page and invalidates the entire page as one (not per block like dynamic page cache), having no-cache on this block would basically mean having no-cache on any page that has this block. So you might as well turn of page_cache and rely on dynamic_page_cache.

Btw the content updates fine is there is a hit on any of the cache tags for the block (an update of a node for example), it just doesn't update based on time.

@artatac have you tried switching the cache settings for the View to time-based and setting both options to '1 minute' or 'never'?

@artatac so just to make sure we understand the issue correctly.

An anon user is on the site.

There's x # of events

and the date on the event is d/m/y

the block is setup that it sorts by date > today

if a new event is added the block does not update with that new event?

Or the date doesn't change?

"block view of content with a date field with filter Date > now never updates block for anon users."

Steps to reproduce.

I expect to see views change for all users.

1. I just made an 8.4 site.
2. I made a basic Content Type with a Date.
3. I made a view and a block. I sorted by date and filtered by Date > now.
4. I put it in the main content display.
5. I had two computers standing by that were ANONYMOUS USERS, while I stayed logged in as an admin on the same system that I'd just used to create the sandbox.
6. They could see the content; I could see the content.
7. I made a bunch of content entries and set their dates at five minute intervals.
8. The first one dropped as expected but thereafter they failed to update on the anonymous users.

In fact I see views change only for my user.

#fldc17

The anonymous view of @thedanceguy 's steps to reproduce

Steps to reproduce.

I expect to see views change for all users.

1. I just made an 8.4 site.
2. I made a basic Content Type with a Date.
3. I made a view and a block. I sorted by date and filtered by Date > now.
4. I put it in the main content display.
5. I had two computers standing by that were ANONYMOUS USERS, while I stayed logged in as an admin on the same system that I'd just used to create the sandbox.
6. They could see the content; I could see the content.
7. I made a bunch of content entries and set their dates at five minute intervals.
8. The first one dropped as expected but thereafter they failed to update on the anonymous users.

In fact I see views change only for my user.

Have a problem that fits this issue and wanted to share my workaround in case it helps anyone.

On my site I have a list of nodes of type x that are ordered by a date field very similar to what others describe above, when a new node is added the list does not update for the anonymous user. Digging through the code it seems like the page cache was getting in the way also touched on above.

To work around this issue I have leveraged the rules module and created a rule that subscribes to the publish event of type x on top of that I created a new action (patch here) that will invalidate a cache tag(s).

Basically I set the rule to invalidate the tag of the page where my view was hosted.

1. Add new rule
2. Add a new Node is published Condition( Data selector set to "node")
3. Add a new Node is of type Condition ( Data selector set to "node", CONTENT TYPES set to "your node type")
4. Add Action: Cache Tag Invalidator (CACHE TAG(S) TO INVALIDATE set to "the cache tag for the page that hosts your view")

I hope this helps someone.

Aaron

This looks related (or maybe wholly due to) #2352009: [pp-3] Bubbling of elements' max-age to the page's headers and the page cache

Yes, that issue will fix this as page cache will then respect the max age set by the view.