Richard Korthuis

Hi @ctagupa

Thank you for using our plugin and sorry for the late reply.

This issue is caused by the fact that Yoast has done some significant changes in their latest version, causing our plugin to not being able to retrieve all data anymore. We fixed this for the standard WordPress endpoints in the latest version of our plugin. But the custom home endpoint (/wp-json/wp-rest-yoast-meta/v1/home) is not yet working. We have to investigate how we can fix this.

Hi @imokweb

Thank you for using our plugin and sorry for the late reply.

This issue is caused by the fact that Yoast has done some significant changes in their latest version, causing our plugin to not being able to retrieve all data anymore. We fixed this for the standard WordPress endpoints in the latest version of our plugin. But the custom home endpoint (/wp-json/wp-rest-yoast-meta/v1/home) is not yet working. We have to investigate how we can fix this. Can you confirm that is the endpoint you are having issues with?

Hi @mibrahim-1

Thank you for using our plugin!

Unfortunately at the moment we do not really have any hooks or functions that would work for you.

1. Flush api cache for a specific user: You would have to find the caches for a specific user, so you would have to find them by request header. However the way we have implemented it, the request headers were never intended to be used as a means to find the cache record. They are stored as a json encoded string, so hard to query by.
2. Even without the limitations as mentioned under 1, this would be difficult, because you would have to have the old token to find the correct cache records.
3. No there isn’t any hook for that, if it weren’t for the limitations as mentioned under 1. we could have considered adding such a hook, but at the moment I don’t think there is any use for it?

The correct implementation of such a plugin in combination with our caching isn’t that easy. We did have some plans to implement an addon for this specific plugin, but that was a long-term plan which has now been postponed even further because of plans to implement WP REST API authentication into WordPress core: https://github.com/wp-api/authentication

Hi @mohnas

Thank you for using our plugin!

The problem with your code is the <id> in 'shipping/zones/<id>/locations'. Our plugin does a string comparison and since the actual call will not have<id>` in it, but rather an actual id (so a number) it will not be able to match it correctly.

At this point I can only advise you to strip the last part: /<id>/locations, however this will mean all calls starting with shipping/zones will be cached.

Hi,

Sorry for the late reply. I have investigated the issue and you are absolutely right. Those calls should not be cached. We will fix this in our next update. We did not do any of the checks you suggested, but we checked for the existence of the X_WP_Nonce request header. Those are authenticated calls and can not be cached when there is no authentication on the cached response.

Hi @central4allgmailcom

There is no such thing as a silly question ?? But since you are asking I am assuming this plugin isn’t something for you. This plugin is useful if you are creating a headless/decoupled website and want the Yoast SEO meta data in the REST API.

Hi @romkaltu

This a resolved topic, please open your own new topic if you need any help.

Hi @altoscameron

Thank you for using our plugin!

No, at this point we do not have a hook for when a cache record is cleared. We never had the need, since the cache clearing is done on default WordPress hooks (like save_post, delete_post, …). I do however understand your question and want to discuss internally if we can add such a hook. What parameters would be useful to you, which should be returned by the hook? I.e. what information do you need to clear the laravel cache?

Hi @jhotadhari

Thank you for using our plugin! And also thank you for reporting this issue, even though it is indeed more of an aesthetic issue, we still like to fix it. So thanks for reporting it ??

Hi @billerr

Thank you for using our plugin!

I am sorry to hear you are having trouble using our plugin and I must say I don’t have a straight answer for you what might be causing this. So I have some questions for you in order to help you debug this issue:

• You did not change anything to the default WP REST API endpoint? So it is still accessed via for example https://example.com/wp-json/wp/v2/posts ?
• Could you check your database and see if the wp_wrc_caches and wp_wrc_relations tables are there? (Keep in mind the wp_ prefix might be different)
• Could you check your wp_options table for the values of the following options:
  – wp_rest_cache_allowed_endpoints
  – wp_rest_cache_rest_prefix
  – wp_rest_cache_allowed_request_methods

Hi @arifba

Thank you for using our plugin!

At this point we do not have any mechanism to distinguish between different users / roles. We do have plans to build an addon for support of authentication methods and distinguishing between the users / roles. This is however a long-term plan, so don’t expect it soon ??

There is one way you could do this, but keep in mind this isn’t the cleanest method. You could cache the authentication header with the cache, so a different authentication header for the same endpoint will result in a seperate cache record. This can be done in two ways:
1. Go to Settings > WP REST Cache and add authorization to the Global cacheable request headers.
2. Use the hook wp_rest_cache/cacheable_request_headers to specify per endpoint which request headers should be used:

function wprc_add_cacheable_request_headers( $cacheable_headers ) {
    // add the authorization header for the pages endpoint
    $cacheable_headers['wp/v2/pages'] = 'authorization';
    return $cacheable_headers;
}
add_filter('wp_rest_cache/cacheable_request_headers', 'wprc_add_cacheable_request_headers', 10, 1);

Please keep in mind that when you delete or reset a authentication token, the caches aren’t flushed automatically. So they can still request the cached data with the invalid authentication token. You would have to flush the specific cache records manually (or programmatically).

Hi @beltranrengifo

Thank you for using our plugin!

In your screenshot I see only one expired cache and it is marked “Expired”. Expired means it has an expiration date with a timestamp > 0. If it would have had an expiration date with timestamp = 0, it would have been marked as “Flushed”. So somehow this cache record is getting a wrong expiration date OR the cache record has indeed expired. Could you delete the cache record and then have it regenerated by calling the endpoint? Next check what expiration date is in the database table wp_wrc_caches in the column expiration. I’m interested in that date/time and the date/time you did the actual request. Please also check the cache settings for the setting of the Cache timeout.

Hi @sawasblog

Thank you for using our plugin!

Yes you can make our plugin cache your custom endpoint, but you will have to add some code to make it do so. See our FAQ “Can I register my own endpoint for caching?”

Hi @jhotadhari

Thank you for using our plugin and your kind words!

I understand your issue, but I don’t think we will be implementing something to skip all requests from the wp-admin, since there are situations where you do want to cache those requests. However I will discuss with my colleagues your suggestion of adding a filter so you can implement your own rules using a mu-plugin (I am glad you already understand it should be a mu-plugin and not a normal plugin ?? )

Hi @ple33

The issue was caused by an extensive rebuild of the Yoast SEO plugin, which meant some of the functions we were using were no longer available. We just released a new version of our plugin which should solve the error for you.

Please let us know if you still have any issues.