Support » Plugin: WP REST Cache » Not all caches are cleared for post type when updating a post

  • Resolved dominic_ks

    (@dominic_ks)


    I’m having some issues with caches being cleared when I expect and I think I’ve found why, it looks like in the following scenario:

    • I make a request to /wp/v2/posts, which returns 10 posts, and these 10 posts are all recorded in the DB in the wrc_relations table
    • If one of those 10 posts is edited the cache for /wp/v2/posts is cleared
    • If a new post is created the cache for /wp/v2/posts is cleared
    • If I update what is essentially post #11 /wp/v2/posts is not cleared – is this correct?

    If that final point is correct it seems like this could cause some issues since I might have made a change that would cause post #11 to replace one of the 10 initially cached, e.g. I could change the publish date.

    I had assume that creating or editing any post would clear all caches for that post type… Assume you’ve not done that for performance reasons but wondering what you think about this scenario…?

Viewing 13 replies - 1 through 13 (of 13 total)
  • 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

    Plugin Author Richard Korthuis

    (@rockfire)

    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,

    Plugin Author Richard Korthuis

    (@rockfire)

    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,

    Plugin Author Richard Korthuis

    (@rockfire)

    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!

    Plugin Author Richard Korthuis

    (@rockfire)

    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,

    Plugin Author Richard Korthuis

    (@rockfire)

    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,

    Plugin Author Richard Korthuis

    (@rockfire)

    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,

Viewing 13 replies - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.