Richard Korthuis

Hi @nurgiel @yclaes @rorymheaney

We just released a new version of our plugin, which should solve this issue. Please let us know if you still have any problems!

Hi @mitsuki

Thank you for using our plugin!

We are investigating the issue and hope to release a fix later today.

Hi @rorymheaney and @yclaes

Thank you for using our plugin!

We are investigating the issue and hope to release a fix later today.

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

Hi @neufeld

Thank you for using our plugin!

Sorry for the late reply, somehow I didn’t get a notification of this topic.

We are going to investigate your issue and try to release a fix as soon as possible!

Hi @adhitya03

Thank you for using our plugin!

Sorry for the late reply, somehow I didn’t get a notification of this topic. This topic is marked as resolved, does this mean you solved it already?

Hi @rorymheaney

Thank you for using our plugin!

Yes, you could use the wp_rest_yoast_meta/filter_yoast_meta filter like this:

/**
 * Add hid.
 */
function wpym_add_hid( $yoast_meta ) {
    foreach( $yoast_meta as &$meta ) {
        $meta['hid'] = $meta['name'] ?: $meta['property'];
    }

    return $yoast_meta;
}
add_filter( 'wp_rest_yoast_meta/filter_yoast_meta', 'wpym_add_hid', 10, 1);

N.B. I didn’t test this, so possibly you have to tweak it a little.

Please let us know if this is what you wanted!

@ivanhala

Yes, sure I can solve it by editing the plugin. But that is bad practice, you should never edit a plugin (because all your edits will get lost once the plugin is updated). So it would be best if the plugin owner can fix it and release an update.

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

Hi @yromara and @zaheerahmad

Thank you fro using our plugin!

As it appears automatic flushing of WooCommerce it quite easy. If you followed the steps above, they are already cached. Unfortunately they are cached with a wrong ‘object type’, this is because of the way the rest response is set up by WooCommerce. But we can fix this by using the wp_rest_cache/determine_object_type filter:

function wc_determine_object_type( $type, $cache_key, $data, $uri ) {
	if ( '/wp-json/wc/v3/products' === substr( $uri, 0, 23 ) ) {
		return 'product';
	}

	return $type;
}
add_filter( 'wp_rest_cache/determine_object_type', 'wc_determine_object_type', 10, 4 );

That’s all, now the product caches will be automatically flushed ??

Now for the categories…
Let’s start with adding it to the wp_rest_cache/determine_object_type filter:

function wc_determine_object_type( $type, $cache_key, $data, $uri ) {
	if ( '/wp-json/wc/v3/products/categories' === substr( $uri, 0, 34 ) ) {
		return 'product_cat';
	} else if ( '/wp-json/wc/v3/products' === substr( $uri, 0, 23 ) ) {
		return 'product';
	}

	return $type;
}
add_filter( 'wp_rest_cache/determine_object_type', 'wc_determine_object_type', 10, 4 );

Unfortunately they still aren’t automatically cached this way ?? This is again due to the fact that the rest response is set up differently than the ‘normal’ categories endpoint and that is causing the WP REST Cache plugin to not being able to detect the cache relations (i.e. which categories are in which cache). We do have an action you could hook into to detect those cache relations yourself, but after looking at it I have determined that we need to send more data to the hook to work with it in an efficient way (I have put it on our todo list).
So for now the only thing we can really do is flush all category caches whenever a category is edited/added/deleted:

function wc_flush_category_caches() {
	\WP_REST_Cache_Plugin\Includes\Caching\Caching::get_instance()->delete_cache_by_endpoint( '/wp-json/wc/v3/products/categories', \WP_REST_Cache_Plugin\Includes\Caching\Caching::FLUSH_LOOSE );
}

add_action( 'created_product_cat', 'wc_flush_category_caches', 10 );
add_action( 'edit_product_cat', 'wc_flush_category_caches', 10 );
add_action( 'delete_product_cat', 'wc_flush_category_caches', 10 );

Hi @shotagency

Thank you for using our plugin!

Yes, in theory this is possible (we just did a really small test), but you have to keep in mind that the WooCommerce REST API is using authentication so you must make sure the authentication headers are used to distinguish between caches.

We tested this with the products endpoint. First we registered the products endpoint so it would be cached (this is necessary since it is a custom endpoint):

/**
 * Register the WooCommerce endpoints so they will be cached.
 */
function wprc_add_wc_endpoints( $allowed_endpoints ) {
    if ( ! isset( $allowed_endpoints[ 'wc/v3' ] ) || ! in_array( 'products', $allowed_endpoints[ 'wc/v3' ] ) ) {
        $allowed_endpoints[ 'wc/v3' ][] = 'products';
    }
    return $allowed_endpoints;
}
add_filter( 'wp_rest_cache/allowed_endpoints', 'wprc_add_wc_endpoints', 10, 1);

And then we made sure the authentication headers were used to distinguish seperate caches. 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 ) {
    $cacheable_headers['wc/v3/products'] = 'authorization';
    return $cacheable_headers;
}
add_filter('wp_rest_cache/cacheable_request_headers', 'wprc_add_cacheable_request_headers', 10, 1);

You must also keep in mind that these caches aren’t flushed automatically when editing products (or any other types you might want to be cached). So either you have to flush the caches manually or you have to write the code to flush them automatically (I could give you some pointers on how to do that, so let me know if you need any help on that point.)
And a really important thing to keep in mind is that whenever you revoke a WooCommerce API Key, you have to flush the caches also, because otherwise the key will still work for already cached items (until these caches expire ofcourse).

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

Hi @andreescocard

Thank you for letting us know! We will add it to our todo list to check the compatibility with older WP versions.

Hi @sawasblog

Thank you for using our plugin!

The correct caches should automatically be cleared when a comment is added (or edited, or deleted, or …)

Hi @andreescocard

Thank you for using our plugin!

Yes it should be compatible with WordPress 4.7.2, although I must say that statement is purely based upon the fact that we use PHP Code Sniffer to test all our code and have it configured to check for the minimum supported WP version 4.7. We have not actually installed WP 4.7.2 to test it.
By the way, it is highly recommended to update you WordPress version since there have been several security fixes since then, starting with WP 4.7.3.

Can you tell us if there are any other differences between the two sites and if so what those differences are? Like different plugins installed?

Hi @jekiwijaya

Thank you for using our plugin!

The short answer to your question is: yes it is because you use /index.php?rest_route=/ instead of /wp-json/.

Is there any special reason why you are not using the ‘official’ REST URL prefix? We are checking the url if it starts with the result of the WordPress rest_get_url_prefix() function. This function does implement a filter to change wp-json to something else, so perhaps you could try and have it working by using that filter. I must say I have not tested it for your specific use case.
Either way, your question does have a valid point that we should perhaps not only check for wp-json but maybe also whether the query var rest_route is set. I am putting it on a to-do list ??

Hi @testcouch

We would like to keep the settings for the plugin as minimal as possible, to make it not too complicated. And since we don’t think many people will want to use the setting you are suggesting, we have decided to not add it. Hopefully the filter will also work for you ??

Hi @bobo_italy

Thank you for using our plugin!

We have investigated your issue and were unable to reproduce it. However we did find some strange (?) behaviour in WPML. We set-up a test site with two languages: English (default) and Dutch (/nl/). Now if we visit https://www.example.com/wp-json/wp/v2/posts it shows English posts, then opening https://www.example.com/nl/wp-json/wp/v2/posts it shows Dutch posts. So far as one would expect.
If we visit https://www.example.com/wp-json/wp/v2/posts?lang=nl it shows Dutch posts, if we then visit https://www.example.com/wp-json/wp/v2/posts it also shows Dutch posts. This is all with our caching plugin disabled. So it seems WPML is doing something strange, which maybe is also causing your issue? Just to be sure could you try your usecase with our plugin disabled?

If you don’t see your issue with our plugin disabled, could you check Settings > WP REST Cache > Endpoint API Caches and find the caches for /wp-json/wp/v2/posts and for /en/wp-json/wp/v2/posts and check the details, it will show you the cache contents. Are they indeed the same?