[Resolved] CRED and Views caching

[Author]

Posts

[thomasL-2]

Hi there,

I use Views and CRED for a membership site. I'm wondering how that will affect the caching feature of Views.

Users will multiple times per day create/submit posts via CRED which will be moderated and ultimately published. It says here https://toolset.com/documentation/user-guides/front-page-filters/how-to-use-views-parametric-search-on-large-sites/ that changing the status of a post will invalidate a View cache.

On a membership site with user-generated content posts will basically be updated/changed all day long - how will that effect the View cache clearing/functionality?

BTW: Is there a way to disable the default caching feeature and re-implement it with a custom clearing frequency? E.g. "clear cache every 4 hours" (regardless of any post changes).

Cheers,
Thomas

[Beda]

Yes, it will invalidate the cache, as the CRED forms basically use WordPress actions to perform the communication to the Database.

And after all, you do not want to see cached data after any user performs an update on the website, correct?

Related to the native Views cache invalidation that happens all 24 hours, this can not be modified as we do not have any documented filters for this.

But since we can manually disable this completely with wpv_filter_disable_caching, we should also be able to further customize this, the problem is there is no documentation for this I could find

I need the assistance of the Developers for this, please await my reply here.

[thomasL-2]

Hi,

OK, thanks. So for now such user-generated websites build with CRED and Views will basically have no cache functionlity at all (as each CRED user-submission will clear the cache), right?

Cheers,
Thomas

[Beda]

No, they have cache functionality, but of course when you update a Post that is queried in such a View, it will invalidate that View's cache, this is the correct behaviour, since you want to display the new data correctly.

[thomasL-2]

Yes, I get that. It's basically no cache functionality therefore though, as each user-submission will clear the cache (and invalidate it that way), no?

[Beda]

No cache functionality would mean, it's not there.

But it is. Since you update a Post, it will invalidate the Cache, for that View related to those Posts.

Let's say you have no CRED, but do that in the Backend. It also would be the same, it would invalidate it.
We need to grab the new data when a post is updated, there is no way so far to grab it from the cache, since that data did not exist as until you submitted it.

But the feature is still there, and it works, but it must invalidate the cache on the update.

Of course, if you have a heavy content submit on the website, no cache feature will cache anything, I mean, even another Cache dedicated Plugin, must invalidate this, otherwise it would simply present the user with outdated data.

[thomasL-2]

Yes, that's what I was referring to. Therefore, a setting to disable the submission-cache clearing altogether for a View AND set a fixed frequency for the cache clearing would be great for user-submission sites!

[Beda]

I see.

But can you explain how you would deal with the problem that cached content is not updated?

The next issue you will have is that a user submits content and controls it, and he won't see it updated eventually

Or worse, he updates an important data and the reader would see it only after cache is invalidated, or the site viewed in a new session.

I do not thin we will enable such a setting, but as mentioned I will get more details on the filter, so you could customise this on your end.

[thomasL-2]

You're right, I haven't though about the user getting confused by not seeing his changes. I guess such a feature would indeed be useless therefore...

Cheers,
Thomas

[Beda]

OK, I see now we agree on this point of the problematical update process.

A last word I wanted to add using the information the Developers gave me.

The complex thing about caching is knowing when to invalidate the cache.

Views invalidates as soon as ANY content that might get affected by the changes is submitted.
(sorry, my previous info is therefore wrong)
So yes, we invalidate the Views output every time a post (not only a post of a type related to that View) is submitted.

Because in Views, even if you are listing, say Pages, you can also render information about a parent post type, or a fixed post... So updating a post will invalidate the frontend cache of every View.

Another thing to notice is that we only cache Views whose content is totally static and independent from the environment.
That means that just checking the "Do not include current post in the query" checkbox means that this very View will never get cached, as the "current post" is not a fixed thing.
So all in all, caching is only used in very few moments.

The wpv_filter_disable_caching just sets if the current, or all, View(s) are(is) cacheable or not, it does not interact with the cache itself.

And the caching deletion mechanism is hooked into the right native and custom actions we perform when updating content, so it can not be disabled right now.

You can either use as it is, or disable it for every View using that filter, that is all.
We do not offer a way to serve old, inaccurate or deprecated data, and according the Developer we will not plan to do so - for the obvious reasons.

You can not list a number of posts and risk that one of them is now removed, not only because the user who removed it with a CRED link might get confused: imagine a third user following a link to a deleted post. Your site becomes untrusty.

So far, to conclude, the cache mechanism is disabled on most Views natively, it is when you update anything on the site relate to the content, and this can not be changed.

[thomasL-2]

Thanks for the details. I agree that this is the best way to handle Views in a reliable way.

Cheers,
Thomas