Richard Korthuis

Hi @mustafamsy

Thank you for using our plugin!

Since I don’t know much about your custom endpoint I will do my best to help you, but I might be wrong:

I assume you have already made sure the custom endpoint is being cached by our plugin? If not you can find out how to do this in our FAQ here.
Now if you have done this our plugin will try to determine the object type in your endpoint. Chances are it is unable to do so, in this case on the cache overview page (Settings > WP REST Cache > tab: Endpoint API Caches) you will see the object type for your endpoint as unknown. Please read our FAQ here, to see how you can make sure it is detected correctly.
Once the object type is detected correctly our plugin will automatically flush the correct caches upon post edit/publish.

I hope this will help you.

Hi @gtsvetanov

We just released a new version of our plugin, which solves this issue.

Hi @papazetis

We just released a new version of our plugin, which solves this issue.

Hi @jdbosley

Thank you for using our plugin and thank you for bringing this to our attention. We will fix this in our next release.

Hi @jdeevega

If you are considering a different solution, then yes this plugin could be a solution. However, you could also consider using the Yoast SEO REST API which was introduced in Yoast SEO 14.0. See: https://developer.yoast.com/blog/yoast-seo-rest-api-endpoint/

That REST API in fact does the same as our plugin (only slightly different).

Hi @gtsvetanov

Thanks for the explanation. I didn’t realize you have to invalidate the Cloudflare caches from within WordPress, then it makes sense you need all posible url’s. However, I don’t like the idea of our plugin storing all url’s for a single cache by default, since this isn’t something the majority of our users will be needing and it is storing extra information in the database.
My initial thought was to fire a hook once the cache key is generated with the cache key and the original url. But here we are running into the issue that it is executed from a must use plugin and therefore no other code is executed if there is an active cache. So that is not an option.
Another option would be to make it a setting where you can choose if all url’s for a single cache should be saved or not. That way we don’t store it if it is not needed, but it would still be available for cases like yours.

Ofcourse then still we would have to fire a hook every time a cache is invalidated, so you can hook into it to invalidate the Cloudflare caches.

I am going to put this on our todo-list ??

Hi @gtsvetanov

I understand your issue and have investigated your patch. I see you added a filter wp_rest_cache/cache_key_params for this. However, I don’t think this will work.

The results of the filter are saved to an option, this is because the caching is done via a must use plugin before other plugins or the theme is loaded. So if we wouldn’t save it as an option but use the filter straight away, it would never be used, since the filters can not have been added yet (unles you use a must use plugin which is loaded before our plugin).

Now let’s assume you hit this endpoint for the first time at at 05:02 AM on 01-Sep-2020. Since there is not yet a cache available the must use plugin can not return a cache, so all code (from other plugins and theme) is executed and the filter is applied, so now your date would be saved to the option field as 2020-09-01 and it would be used for the cache key.
Now we hit the endpoint again at 03:42 AM on 02-Sep-2020. The must use plugin will retrieve the option field and it is set as 2020-09-01 and used for the cache key. It will find a cache for this cache key and return it. No other code is executed, so the option field will not be set to the current date until the old cache expires or a call to WordPress is done which isn’t cached and does trigger the option field update.
So as you can see there is a slightly bigger chance the cache is invalidated a little sooner, but there still isn’t a guarantee it is invalidated immediately on the new day.

I am going to discuss your issue with my colleague and see if we can come up with a working solution without always adding the date to the cache key (since this is only wanted for your specific use case and it should not be default behavior).

Hi @gtsvetanov

I am still not sure what the issue is? So Cloudflare CDN treats the urls as different “pages”, but why should our plugin treat them differently when in fact these url’s are all the same “page”? Without our plugin WordPress also treats these url’s all the same way.
In my opinion it is Cloudflare who is acting strange, since technically there isn’t anything different for these url’s they all contain exactly the same content, so they should all be treated the same way. If content for url 1 is invalidated for some reason, then the content for url’s 2 to 4 should also be invalidated. Which is exactly what our plugin does.
We deliberately build it this way in order to avoid unnecessary caches. Why have 4 caches when in fact they are all the same?

Hi @sabyasachinag

I am not sure which plugin you are refering to? Could you post a link to it?

Having said that: our plugin is focussed on WordPress REST API that is available in WordPress core, so chances are it will not work with your plugin.

Hi @papazetis

Thank you for using our plugin! And thank you for mentioning this bug, we will be fixing this in our next release.

Hi @gtsvetanov

Thank you for pointing this out. We will be fixing this in our next release.

Hi @mustafamsy

Thank you for your kind words!

Hi @gtsvetanov

I’m trying to understand your issue. Am I correct that you want to invalidate caches by using a url? If so we have a function for that which you can use (and it will take all of your example url’s to flush the correct cache), for instance:

\WP_Rest_Cache_Plugin\Includes\Caching\Caching::get_instance()->delete_cache_by_endpoint( '/wp-json/wp/v2/endpoint?original=1&a=2' );

Hi @gtsvetanov

Thank you for using our plugin!

I am not sure why you would need to change the cache key to include the current date? If you want the caches to expire evry day, you can simply change the cache timeout (Settings > WP REST Cache > Cache timeout) to 1 day and the caches will expire every day without addding the date to the cache key. Or am I missing your point?

And why would sha1() be better than md5()? If it was about security, yes sha1() is better, but we aren’t encrypting any secure data here. And compared on speed md5() is the best choice. So please share your knowledge and maybe we can change it.

Hi @guid33

Sorry for the late reply, I was out of the office for 6 weeks and my colleague was really busy in the meantime.

Custom endpoints aren’t automatically cached, but you can simply add them as explained in our FAQ.