Richard Korthuis

Hi @ctagupa

I will look into this and release a fix as soon as possible.

HI @ctagupa

You are correct. I tested it and it isn’t working correctly. We will try to release a fix as soon as possible.

Hi @fighter1

I am afraid your error is different from the error mentioned in the start post of this topic. As you can see in your error message, you get an error in wp-content/themes/themify-ultra/themify/themify-wp-filters.php. So this error seems to be related to your theme and not to our plugin.
I wanted to see if I could find the exact cause of your error, but unfortunately you are using a paid theme, so I don’t have access to the source of the theme. I am afraid I can’t help you with this error.

@jamesdigioia

Thank you, may I ask why you are using this plugin for the Yoast Meta and not the meta provided by our plugin? Just curious to know if there is something you are missing or would like different in our plugin.

For your information: We by the way did investigate this plugin prior to deciding to build our own. We did this for two reasons:
1. It hasn’t been maintained for quite some time.
2. It retrieves only very limited Yoast Meta, so not all meta generated by the Yoast SEO plugin.

I have some ideas about how we can help you run both plugins next to each other, but I will have to discuss this internally first.

Hi @jamesdigioia

Thank you for using our plugin!

I’m sorry but I am having trouble understanding your first question. You refer to another plugin:

the plugin overwrites the yoast_meta key provided by the Yoast plugin REST API integration upstream

Which plugin is that? If we know which plugin it is, we might have a look at it and see if we can prevent any issues between the plugins (no guarantee until we see the plugin ?? )

About the yoast_json_ld this is indeed a bug, which we are investigating and we are hoping to release a fix soon.

Hi @geochanto

It would probably have worked with the wp_rest_cache/determine_object_type if you first deleted the old caches. Not flushed/cleared, but actually deleted them (via Settings > WP REST Cache > Tab: Endpoint API Cache > Delete cache record). It is something we should probably reconsider, but at this point we do not update the object type once a cache has been stored.

Now about your code: great you have got it working for you. I do however have some remarks:

It seems like you either have added your filters to the mu-plugins/wp-rest-cache.php, which I must recommend you to not do that (see my first comment). Or you have made a copy of it. In this case I must recommend you to (at least) delete the lines:

$wp_rest_cache_api = new \WP_Rest_Cache_Plugin\Includes\API\Endpoint_Api();
$wp_rest_cache_api->get_api_cache();

Also in the refreshCache function you are checking twice for wp_is_post_revision($postId), in the first if-clause and in the third if-clause. So the third can be removed.

Hi @geochanto

Strange that you had to restart the server to see the caches in the admin area, but great it works now ??

This is probably the correct implementation for you:

function wprc_determine_object_type( $object_type, $cache_key, $data, $uri ) {
    if ('hardwood' === $object_type) {
        $object_type = 'product';
    }
    return $object_type;
}
add_filter( 'wp_rest_cache/determine_object_type', 'wprc_determine_object_type', 10, 4 );

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

Hi @geochanto

Are you sure the cache is working? Because I find it strange it would be working but not showing any caches in the admin area. You can check by looking at the response headers from the REST API, it should contain a x-wp-cached-call: served-cache header if the cache is working.

Calling the delete_cache_by_endpoint(...) function will probably not work, since that is using the same data as is used to display the caches in the admin area. So before trying to implement that we should try and investigate if the cache is indeed working and if so, why the data isn’t saved correctly to display in the admin area.

Where the caches are stored depends on whether or not you are using external object caching. The caches are stored using the transients API, which are stored by default in the wp_options table (search: SELECT * FROM wp_options WHERE option_name LIKE '%transient%wp_rest_cache%'). If however you are using an external object cache (like Redis or Memcached) it is stored in that object cache.
No matter if you use external object cache or not the plugin also stores some extra information in the wp_wrc_caches and wp_wrc_relations tables. There is a really small chance that the caches are stored but the extra information is not stored in those tables.
So could you check your wp_options table and the wp_wrc_caches table to see if there is anything saved? Hopefully from there we can investigate what is going wrong.

Hi @ctagupa

Thank you for using our plugin!

You raised a very good question. So we just released a new version of our plugin which adds a new custom endpoint /wp-rest-yoast-meta/v1/home which you can use to retrieve the Yoast meta for the homepage.

Please let us know if this solves your question ??

Hi @geochanto

Thank you for using our plugin!

First of all: you should not add your hooks to the /wp-content/mu-plugin/wp-rest-cache.php file. This file might be changed by a future version of our plugin and then your changes will disappear. You should add your hooks to code that isn’t changed with an update, most often your (child) theme’s function.php.

The plugin will try to detect the object types of entries in your endpoint, but this detection is not flawless. It will check for the existence of the fields id and type and use the type as the object type (or check for id and taxonomy in the case of a taxonomy). If those fields aren’t present it will not be able to detect the object type.

You can however ‘help’ the plugin to detect the correct object type by using the wp_rest_cache/determine_object_type filter (see the FAQ).

But even if the plugin doesn’t know the object type of the items in your endpoint, the caches should still be cleared whenever you click the Clear REST cache button.

@gripinfos good to hear the problem is solved ?? That plugin you were using is the legacy version of the WP REST API which is now merged into the WordPress core. In fact the github repository has been archived (see https://github.com/WP-API/WP-API). So you better not use it at all, since it is already part of WP core and has since been improved many times.

Hi @gripinfos and @klinuxkk

I just did a clean install of WordPress on a local Xampp install and installed and activated the WP REST Cache plugin. I checked the Endpoint API Caches tab and as expected nothing was cached yet.
Then I visited the rest API ( /wp-json/wp/v2/posts ), after that I revisited the Endpoint API Caches tab and this time a cache was visible.

So unfortunately I am unable to reproduce your problem. Did you install any other plugin? Which theme did you use? Are there any other aspects that might cause this?

Hi @jankapusta

Nice to hear, you problem is solved!

Please let us know if we can be of any more assistance.

Hi @jankapusta

Thank you for using our plugin!

Did you update to the latest version of our plugin? Because this error looks exactly what was caused by the WP security update 5.2.4 which we fixed in the latest version of our plugin.

Hi @gripinfos

I am sorry to hear updating didn’t solve you problem. Changing your php version shouldn’t be necessary, the plugin should work fine using PHP 7.2.

Could you check your server error log and see if there are some errors there? Unfortunately I am unable to reproduce the error so I am hoping your error log will help us determine the cause of the error.