Richard Korthuis

Hi @ple33

Thank you for using our plugin!

I’m sorry you are experiencing this issue. Unfortunately we did not yet have had the time to test our plugin with the latest version of Yoast SEO, which came out yesterday morning. We will investigate the issue today and hopefully be able to release a fix as soon as possible.

Hi @johancarleborn

Thank you for using our plugin!

I don’t see anything wrong with your example, it isn’t working?

Hi @arindam4u

The optimum setting is something we cannot determine for you as it greatly depends on your host server. A lightweight server will only be able to process a few requests at a time, while a more advanced server can easily manage hundreds of requests at a time. So this is something you would have to discuss with your hosting company or would have to test.

Hi @rifatspir

Correct, our plugin doesn’t cache the WooCommerce REST API until someone follows these tips. We are working on a add-on to support the WooCommerce REST API, this add-on will however be a paid version (sorry we can’t make everything for free ?? ) and at this time I do not have a timeline on when it will be available.

• This reply was modified 4 years, 10 months ago by Richard Korthuis.

Hi @triloworld

Thank you for using our plugin!

All we do is output to the REST API what Yoast SEO would output to the frontend in a normal WordPress set-up. We do not change anything in this output, so if something is incorrect it most probably is due to Yoast SEO returning it incorrectly. So you would have to check if you can change this using Yoast SEO.

We do have a filter where you can change the output of our plugin wp_rest_yoast_meta/filter_yoast_meta, see our FAQ. But I would check Yoast SEO first, that would be a more solid solution.

Hi @brnteka

Thank you for using our plugin!

You are actually asking two different things (flushing and regenerating), so I am going to answer them seperately.

Yes it is possible to flush all caches of a specific post type programmatically. For instance if you would like to flush all caches of a post type products you can do so like this:
\WP_Rest_Cache_Plugin\Includes\Caching\Caching::get_instance()->delete_object_type_caches( 'products' );
But I must say: why would that be needed? If you update the post using WordPress core function the caches should be flushed automatically. Isn’t this the case in your situation? Or are you updating the posts with a direct database query?

About regenerating: we don’t have the option to regenerate specific post type caches, but we do have the option to automatically regenerate flushed (or expired) caches. See our FAQ on how to set this up.

Hi @tenderfeel

Thank you for your clear description of what you already did! You are talking about var_dump’s in sources/wp-rest-cache.php, just to be sure (I am not sure if you are aware of it): this file is copied to /wp-content/mu-plugins upon plugin activation. So if you want your var_dump’s to work you would have to put them in /wp-content/mu-plugin/wp-rest-cache.php.

You say for the other domains only 2 to 4 are displayed, this almost sounds like the must use plugin isn’t loaded, which would be very strange and something out of our control, since it is WordPress core functionality. My guess it you would have to focus on that part, the loading of the /wp-content/mu-plugin/wp-rest-cache.php.
Either that file isn’t loaded OR WordPress is at this point saying the WP REST Cache plugin isn’t active.

Hi @austyfrosty

Thank you for using our plugin!

Yes the object type is needed to correctly invalidate caches when those objects get updated. Our plugin needs at least the fields id and type to correctly identify the object type (and taxonomy in case of a taxonomy endpoint). So if you would change your call to wp-json/wp/v2/posts/?_fields=title,id,type it would work perfectly.

If you really don’t want to add the necessary fields, you can always add your own logic to determine the correct object type, by using a filter. See our FAQ on how to do it.

Hi @alriksson

In theory yes it will improve your wp-admin with Gutenberg. However since we haven’t made many Gutenberg-enabled websites yet, we haven’t tested it fully.

Hi @tenderfeel

Thank you for using our plugin!

I just did some tests, I installed WordPress locally on example.local and also made it available on somethingelse.local. I then did some REST requests on somethingelse.local and those requests were cached as expected.
I even double checked our code and there is no reason why the requests wouldn’t be cached, we don’t look at the url, only at the request path (i.e. /wp-json/custom/v1/***).

What makes you say it isn’t cached? How did you check this?

Hi @marija1206

Thank you for using our plugin!

First of all: custom post types are supported, we use them all the time ?? I did a test and installed the Pods plugin and create a custom post type. I then created some posts and visited the REST endpoint, everything was cached as expected. I then edited one of the posts and the correct caches were cleared, so everything seems to be working fine.

If you look up the cache for the custom post type under Settings > WP REST Cache > Endpoint API Caches, is the Object Type detected correctly?

Hi @mattiasf

Thank you for using our plugin!

First of all: sorry for not getting back to you any sooner. For some reason we did not get notified of your topic so I only noticed it by coincidence today.

I have investigated your issue and you are correct. The request URI isn’t parsed correctly when it contains double slashes. We will fix this in our next update (we just did a new update which unfortunately does not yet contain this fix).

Hi @shyamla

Sorry for not getting back to you any sooner. We did some extensive testing but were unable to reproduce your situation. Unfortunately that makes it impossible for us to determine the cause and implement a fix for it.
Did you by any chance find the cause?

This thread has been marked as resolved due to lack of activity.

You’re always welcome to open a new topic.

Thanks for understanding!

Hi @engdahl

Thank you for using our plugin!

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