Add Cache key generation hook

Hello,

I’ve made a second topic called Save accessed URLs for a cache key where I’ve asked for additional functionalities but I’ve already made them for me. If you wish you can use add it to your code and release them as new version of the plugin. Because my git repository is private you can find my changes here as a patch – https://pastebin.com/SBi76fQs

Once again – Thank you for your amazing work because this plugin saved me a lot of time.

Best regards,
Georgi!

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.

Hello @rockfire

The issue with daily invalidation and setting different cache timeout is because I’ve made few custom endpoints (I’m using wordpress as headless cms) to get the daily information by server time.

For example:
– https://example.com/wp-json/wp/v2/delivery-days?day=current – which is returning current delivery day by date. Every cached url is set to cache from the first hit. If you hit this endpoint at 05:02 AM on 01-Sep-2020 the cache will expire on 05:02 AM on 02-Sep-2020 but for me the information is not valid. As you can understand there is more than 5 hours gap between cache and actual information.

About sha1 vs md5 this may help. Also I have a bad experience with md5 collision while processing a big amount of data and hash it with md5.

I’ve tried the plugin and how it works few days before I create this topic.

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).

Hello @rockfire

Yep it’s a known issue for me. First hit in the new day always returns the old information (because of MU plugin and setting combo) but next hits are okay which is better than waiting cache to timeout.

I’ve tried with creating a custom MU plugin and it works better but this will cause many more issues ??

In fact – I won’t update the plugin on my side or if there is something I want I will perform a manual merge but I think that plugin customers have to gain the ability to add/remove something from cache keys. Because every developer knows better how his caching must work depending of other logic.