Richard Korthuis

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 );

Hi @isabelle09876

If our plugin will effect your LCP load time depends on whether or not you are using WP REST API calls to build your page. But to be honest, it will probably not help you, and you should probably be looking for something like WP Supercache, W3 Total Cache or similar.

@mastababa Since there is no new cache generated it seems your call isn’t coming through to WordPress. Unfortunately htere isn’t much our plugin can do in this case.

Hi @ajmalapiacademy

Thank you for using our plugin!

Indeed our plugin does not cache the WooCommerce REST API out-of-the-box. We only cache the default WordPress REST endpoints and not any custom endpoints created by plugins (or yourself). You can however tell our plugin to cache custom endpoints. See our FAQ on how to do so.

Having said that, 4 years ago I did a little proof-of-concept on how to cache the WooCommerce REST API, pleas check out my posts there to have a kickstart in how to cache those endpoints.

Hi,

I wouldn’t do a wp_update_post if there is no need to actually update it. Instead you can tell our plugin to clear the related caches:
\WP_REST_Cache_Plugin\Includes\Caching\Caching::get_instance()->delete_related_caches( $post_id, $post_type );

Hi @mastababa

Thank you for using our plugin!

Are you using a custom endpoint for this post type or de default WordPress endpoint (i.e. /wp-json/wp/v2/<post-type-slug>)?
In the last situation the cache should automatically clear, unless you are using something different than the default WP function (like wp_update_post or update_post_meta ) for updating the post. Or if you are filtering the output of the endpoint using the _fields parameter, in that case you should include the fields id and type (or id and taxonomy in case of a taxonomy-endpoint). These fields are needed for our plugin to detect the correct object type of the items in the endpoint.
In case you are using a custom endpoint, you probably have to help our plugin detect the items inside the endpoint (see our FAQ)

Hi @rbagheri48

Thank you for using our plugin! And sorry for this late reply and the fact that you are experiencing this issue.

We haven’t had any mention of this issue before, and to be honest I don’t think the problem lies in those settings. Changing those settings doesn’t do much that would explain WordPress going down.
Could it be that you have the “Max number regenerate caches” setting set to a high number? Or maybe the number of caches you have set can not be regenerated within those 5 minutes (causing two regenerate processes to run at the samen time)? I think you have to search the problem there, the server is probably getting more request simultaneously than it can handle. Try using a larger interval or a smaller number to be regenerated each run.

Hi @kimarkf01,

Thank you for using our plugin!

The endpoint you are refering to is a custom endpoint, not something that is provided by WordPress core. Therefore it is not cached out-of-the-box. See our FAQ “I have created a custom WP REST endpoint, will the plugin cache this endpoint?” and “Can I register my own endpoint for caching?” on how to make our plugin cache the custom endpoint.

Hi @blurredj

Thank you for using our plugin and sorry you experienced those warnings.

We just released a new version of our plugin which should solve this problem.