Richard Korthuis

Hi @mastababa

Thank you for using our plugin!

I tested your issue using the endpoint for posts (/wp-json/wp/v2/posts?_embed=&page=1&per_page=80) and did some requests to multiple pages. They were all cached nicely. I then edited one of the posts and the caches were flushed as expected. So I am unable to reproduce your issue.

Did you use filters to alter the output of the endpoint (i.e. did you strip out the id or type field)? If you visit the Settings > WP REST Cache > Endpoint API Caches tab, do you see the correct post type in the column Object Type for the specific endpoints?

Hi @4samy

Thank you for using our plugin and sorry you are experiencing this issue.

We haven’t had any other mentions of this issue and are also not able to reproduce it. So it seems to be something specific to your setup. Did you change any of the default settings of our plugin? Did you use any of the hooks supplied by this plugin? And did you try disabling all other plugins to see if it isn’t a conflict with another plugin?

Hi @prestonwordsworth

Thank you for using our plugin!

Yes this is intended behaviour. Those calls in the wp-admin are done using a WP nonce, which means the output can be different per user and therefore isn’t cacheable.

Hi @brunolohl

Thank you for using our plugin and sorry you are experiencing this error.

We just released a new version of our plugin which should resolve the problem, can you please update and test it?

Hi @ac-1

Thank you for using our plugin!

No when you are using Redis you don’t have to enable the Memcache(d) option, since that option has to with a specific implementation of Memcache(d), Redis doesn’t have that issue.

Hi @flegma

We just released a new version of our plugin which should solve your issue.

Hi @flegma

Thank you for using our plugin!

I have been able to reproduce the bug and have found a solution. I hope to release a new version of our plugin soon with this fix.

Hi @dominic_ks

Thank you for using our plugin!

You are absolutely right, this was a bug in our plugin. I just released a new version to resolve this bug.

Hi @hassantafreshi

$object_type is the type of the object with ID $post_id (the name of that variable is maybe not very well chosen ??). Meaning: if $post_id refers to a post of a (custom) post type, $object_type is the slug of that (custom) post type. But if $post_id refers to a (custom) taxonomy term, $object_type is the slug of that (custom) taxonomy.

Some example to hopefully make it more clear:

Example 1:
We have a page with ID = 42:
$post_id = 42
$object_type = 'page'

Example 2:
We have an event (= custom post type) with ID = 43:
$post_id = 42
$object_type = 'event'

Example 3:
We have a category with term ID = 44:
$post_id = 44
$object_type = 'category'

Example 4:
We have an event category (= custom taxonomy) with ID = 45:
$post_id = 45
$object_type = 'event_category'

Hi @hassantafreshi

At this point we do not have a function for that. The reason you need to specify it, is because the object type can be a post type or a taxonomy. So based only on the ID we can not say for sure what the object type is (a page can have the same ID as a term)

Hi @hassantafreshi

You could use this:

\WP_REST_Cache_Plugin\Includes\Caching\Caching::get_instance()->delete_related_caches( $post_id, $object_type );

Where $post_id in your case would be $page_id and $object_type is the post type of the item (so 'page' ?).

Hi @hassantafreshi

Thank you for using our plugin!

First of all we use the Transients API to store our caches instead of the Object Cache because we want persistent caches regardless of any persistent cache plugin being installed. However if a persistent cache plugin is installed the transients API will use the wp_cache_get and wp_cache_set functions.

Now to your question: will there be any conflicts? I don’t think so because we use different cache keys. Only if those keys would match a conflict would occur. The odds of that happening are very limited since all our cache keys start with wp_rest_cache_ and then a hash of the requested URI. Since all your caches are prefixed with efb there will be no conflicts.

Hi @richardaubin

Thank you for using our plugin!

Indeed POST requests aren’t cached by default. We only cache GET requests by default. This is because with the WordPress REST API (as with other API’s) you use GET to retrieve data, this is data that can be cached. POST is used to create new records (or in case of the WordPress REST API) to update existing records, usually this isn’t data you want to be cached, since each POST call adds or changes data and therefore the response of the REST API. So to sum it up: GET is to retrieve data, POST should not be used to retrieve data.
So a pitfall you might encounter by adding POST as an allowed request method is that the POST request of for instance the /wp/v2/posts endpoint is also cached and any additional calls might not have the expected result, since a cache result is returned and no code is executed (i.e. no post is added or updated).

Hi @johnferz

Thank you for using our plugin!

I don’t see anything wrong with the code from your first post, it should work just fine. The fact that you are getting the error in your last post and the error that is now visible on your?rest?endpoint also suggests that our code is trying to?cache?it.The reason you are getting the error from your last post probably has to do with the changes you described in the posts you have since deleted (I did receive a mail about them, so I was able to read them). I suspect that your changes caused an incorrect?cache?entry and that is where the error is coming from. I would suggest you delete all?cache?records, so the invalid?caches?get deleted. To do so visit Settings >?WP?REST?Cache?> Clear?Caches?and be sure to check the “Delete all?caches”.
The current fatal error on your endpoint has to do with incorrect code, where you use $this. Look at that code and fix the error.

Hi @ctagupa

Thank you for using our plugin!

Yes that is possible using the filter wp_rest_cache/timeout For example like this:

/**
 * Set a different cache timeout for the posts endpoint.
 *
 * @param int $timeout The timeout as set in the settings.
 * @param array $options An array of options, containing the current uri, the object type, the request headers and the request method.
 *
 * @return int
 */
function wprc_set_posts_timeout( $timeout, $options ) {
	/**
	 * Available keys in $options are: uri, object_type, request_headers, request_method
	 */
	if ( 'posts' === $options['object_type'] || '/wp-json/wp/v2/posts' === $options['uri'] ) {
		$timeout = MONTH_IN_SECONDS;
	}
	return $timeout;
}

add_filter( 'wp_rest_cache/timeout', 'wprc_set_posts_timeout', 10, 2 );