Richard Korthuis

Hi @djibs13

Thank you for using our plugin and for reporting this issue. We are investigating it and hope to release a fix as soon as possible

Hi @goodhub

Did you test it with localhost?

I just did a test on a clean WordPress 5.5.1 install, with only our plugin installed and activated. It is working as expected: the posts endpoint is cached without any additional code and editing a single post only flushes the caches related to that post.

Hi @dominic_ks

No unfortunately the plugin is in a private bitbucket repository at this moment. We do have plans to make it publically available, but we first have to tackle some issues (we use bitbucket pipelines for deployment which we don’t want public (yet)).

Hi @goodhub

Thank you for using our plugin!

Your issue is really strange because the default WordPress endpoints (like the one for posts) should be cached automatically and the flushing of those caches upon editing a post should also work out of the box.

Have you tried disabling all other plugins and returning to a default WordPress theme? It seems like there is some sort of conflict. And which WordPress version are you running?

Hi @dominic_ks

Thank you for using our plugin!

Unfortunately at this time we don’t have a function to query a cached item by its cached request headers. You could however do this yourself, all you need to know is that the cached request headers are stored json encoded in the column request_headers of the table wp_wrc_caches.

Now if you only have the authorization header set to be cached and you use basic authorization you could have a query like this:
SELECT cache_key FROM wp_wrc_caches WHERE request_headers = '{"Authorization":"Basic V1BfUkVTVF9DQUNIRV9URVNUOlRISVNfSVNfTk9UX1JFQUw="}'
If you cache multiple request headers it would be something like this:
SELECT cache_key FROM wp_wrc_caches WHERE request_headers LIKE '%"Authorization":"Basic V1BfUkVTVF9DQUNIRV9URVNUOlRISVNfSVNfTk9UX1JFQUw="%'
Next you can loop through the cache keys you get from running this query and delete them one-by-one:
\WP_Rest_Cache_Plugin\Includes\Caching\Caching::get_instance()->delete_cache('<cache_key>');

Hi @fedegonzal

Thank you. Unfortunately I am still unable to reproduce the problem as both endpoints are cached fine on my local testing environment (see here).

Hi @fedegonzal

Thank you for your feedback. I have tried creating a custom post type with the Pods plugin and giving it a name with a hyphen in it. However, the caches do not expire immediately on my local test environment. So either you have some extra settings which cause this, or there is a conflict with some other plugin.
I see the Pods plugin has a component Migrate: Packages to export your pods. Would you be willing to create an export of the custom post type you are having this issue with? If you don’t want to publish it on this open forum, you can also email it to plugins [at] acato [dot] nl.
Also a list of all you active plugins would be helpful to find the cause of this problem.

Hi @mustafamsy

Ok, so it is not about existing items that are updated, but it is about new items not added. That is in fact caused by the unknown object type. Usually I would point you to our FAQ about helping our plugin determine the correct object type. You could do something like this:

function wprc_determine_object_type( $object_type, $cache_key, $data, $uri ) {
	if ( $object_type !== 'unknown' || strpos( $uri, 'app_data/v1/data' ) === false ) {
		return $object_type;
	}

	return 'ads';
}
add_filter( 'wp_rest_cache/determine_object_type', 'wprc_determine_object_type', 10, 4 );

However now we have a small problem and that is that your endpoint doesn’t contain one single object type (like for instance the wp-json/wp/v2/posts endpoint), but it contains multiple object types (ads, post, page, …). So what is the correct object type? If you only want the endpoint to be flushed when new ads are added, the above code will work fine. But if you want it to be flushed when new ads and new posts are added, unfortunately our plugin can not do this for you.

What you could do is use the above code for ads and then add some custom code for other post types. I haven’t tested it, but something like this should work:

function flush_cache_upon_new_post( $post_id, $post, $update ) {
    if( !in_array( $post->post_type, [ 'post', 'page' ] ) || !$update ) {
        return;
    }
    \WP_Rest_Cache_Plugin\Includes\Caching\Caching::get_instance()->delete_cache_by_endpoint( '/wp-json/app_data/v1/data' );
}
add_filter('save_post', 'flush_cache_upon_new_post', 10, 3);

Hi @mustafamsy

Ah I responded too quickly without looking closely enough to the output of your endpoint. Adding the type isn’t the solution and isn’t necessary. Most probably all the different posts within your endpoint are detected correctly. I have tested this locally by recreating your endpoint and indeed all seperate posts are detected and when I edit one of those posts the endpoint is in fact cleared. So eventhough the object type states unknown the automatic flushing is working correctly.

A little explanation: When caching an endpoint the plugin tries to determine the object type of the endpoint, but it also loops through all the records within the endpoint to determine the relations within the endpoint. Now if one of those relations is edited, the endpoint is flushed.
So for your endpoint: all the posts of the post type ads are recognized and saved as relations, but also the settings page of post type page is recognized and saved as relations. It even recognizes more, like the categories you have selected within ACF within your settings page. Now if one of the ads, or the settings page, or any of the other relations is edited, the cache of the endpoint will be flushed.

So now my question for you is: Are you sure automatic flushing isn’t working correctly, because (as I stated above) it is working on my local test environment?

Hi @mustafamsy

Thank you for your email. I have had a look at the output of your endpoint and I see what the issue is:

Default WordPress endpoints don’t have the field post_type, in stead they have the field type. Our plugin uses that field to determine the correct object type. Since you are already looping through all the posts in your endpoint, I guess the easiest solution would be to add the field type (which would be the same value as the post_type field), so:
$ads_post[$v]->type = $ads_post[$v]->post_type;

Which makes me think that we might have to improve our plugin and add the field post_type as a way to automatically determine the correct object type. I will put it on our todo list.

@mustafamsy Strange… Could you post the output of your custom endpoint so I can have a look at that? If you don’t want to share it on a public forum like this, you could email it to plugins [at] acato [dot] nl

Hi @csacchetti

Thank you for using our plugin!

The problem is caused by your _fields parameter. You are limiting the number of fields returned by the REST API, which is perfectly fine. But in order for our plugin to correctly determine the correct object type we need the fields id and type (for a (custom) post type) or id and taxonomy (for a (custom) taxonomy). So in your case if you would add the type field to your _fields parameter, everything should work fine again.

Hi @mustafamsy

Looking at your code I would think it should work fine. If you visit Settings > WP REST Cache > tab: Endpoint API Caches, what do you see in the column Object Type for your custom endpoint?

Hi @csacchetti

Could you please open your own topic, so we can help you?

Hi @imc67

Thank you for using our plugin and your kind words!