Not all caches are cleared for post type when updating a post

Same issue here since the last update queries like below are not (always) cleared after new post or update and somehow have a “unlimited” expiration:

/wp-json/wp/v2/posts?_embed=1&categories=3&page=1

Hi @dominic_ks and @imc67

We just released a new version of our plugin, which should solve this issue. Please let us know if it is solved or not.

Hi @rockfire,

Thanks for getting back to us on this. I’m still seeing the same issue here. I have just noticed that when the request has a query string the “Object Type” isn’t set, maybe this is contributing to the problem?

Cheers,

Hi @dominic_ks

Yes this may defintely be contributing to the problem. But to understand the situation correctly, can you answer the following questions?

– Is it happening to the default posts endpoint?
– Is it also / still happening when you don’t use a query string? So for request to /wp-json/wp/v2/posts ?
– What version of WordPress and what version of our plugin are you using?

Hi @rockfire,

Finding it a little bit difficult to get consistent results here, but I am definitely seeing the following, and these seem to be the case with both CPTs and the default posts endpoint:

• Cached requests containing a query string are not flushed when a post of that type is updated, unless that post was in the result of the request – this one seems to be intentional by you guys though? Since when I look at WP_Rest_Cache_Plugin\Includes\Caching::save_post() since you only call WP_Rest_Cache_Plugin\Includes\Caching::delete_object_type_caches() if the post is new. Assuming that is your intention, I don’t think this works well since some other cached requests may now be invalid based on the post that was just change (my original issue on this thread).
• I think that this issue with the “Object Type” not being set seems to only be happening when the request has a query string that contains the _fields parameter.

Cheers,

Hi @dominic_ks

Regarding the flushing of caches upon an update of a post: Yes you are right we only flush related caches, since we want to flush as little caches as possible. However you do have a valid point that other caches might become invalid base upon the type of edit. We have to investigate if we can improve this process any further, without flushing too many caches each time a post is edited.

Regarding the “Object Type” nog being set when using the _fields parameter: Yes, when you use the _fields parameter all other fields not specified in that parameter are stripped from the REST API response. However our plugin needs at least the fields id and type (or taxonmy for a taxonomy endpoint) to determine the correct object type. So if you don’t have those in your _fields parameter the plugin is unable to correctly determine the object type. To determine the correct cache relations it might even need more fields (i.e. post_type, slug, status and/or _links).

Hi @rockfire,

Thanks for that. Yes I can confirm you’re spot on with the _fields param, if I ensure id and type the Object Type is always set.

One additional question on this – I was also experiencing the same issue with a custom route I had added to the cache using the wp_rest_cache/allowed_endpoints, now I understand the above, I don’t find it surprising that an Object Type isn’t set for these. Is there a way that I can add an Object Type using a filter or do I need to implement something to clear these caches myself?

Re: the flushing of caches upon an update of a post – do you think in the meantime while you consider this point we could have a filter to determine if all object type caches should be cleared on an update event?

Cheers!

Hi @dominic_ks

Yes, you can use the wp_rest_cache/determine_object_type filter to add the correct Object Type. See the FAQ for an example of how to use it.

Re: the flushing of caches upon an update of a post: you could in the meantime ofcourse do something like this:

add_action( 'save_post', 'wprc_flush_object_type_caches', 10, 3 );
function wprc_flush_object_type_caches( $post_id, $post, $update ) {
	if ( $update ) {
		\WP_Rest_Cache_Plugin\Includes\Caching\Caching::get_instance()->delete_object_type_caches( $post->post_type );
	}
}

Hi @rockfire,

Thank you so much for your help here, I think with those last couple of bits I’m now set up with exactly what I need.

Don’t know if you want to leave this open pending whatever you choose for the question of what action to take when updating a post but feel free to close otherwise.

Thanks again,

You’re welcome! I will mark this topic as resolved and add the issue of the flushing of caching upon update of a post to our todo list.

Cool, one thing more just to chip in actually, might not be something you need to do anything about, but in case anyone else reads:

I initially had issues using the wp_rest_cache/determine_object_type filter – I found this was because I had deleted caches where previously the Object Type was “unknown” and were still in the DB marked as deleted. I deleted all of these rows from the DB manually and then it worked fine after that.

Cheers,

Hi @dominic_ks

Just a little explanation about those ‘deleted records’ and why they were still in the database. Because we use the transient API we can not simply bulk-delete caches, we have to delete them one-by-one. This can take quite some time when there are a lot of caches to be deleted. So instead of doing that immediately (and having the user wait for it) we mark them as deleted (so our plugin will not return the cache) and schedule a cron job to clean them up at a later time. Once the cron has run the deleted caches should be deleted from the database too.
You deleting those records from the database means the transients will not be deleted. This isn’t a big issue, because at some point they will expire and be deleted.

Hi @rockfire,

Thanks for the explanation, it makes sense. This is only on a dev site so not a big issue either way, I was only deleting them to make it easier for testing but I shall watch out for that anyway!

Cheers and thanks again,