Propagating changes of wp_post fields to cache – who is responsible?
-
Hi,
generally speaking – who is responsible for keeping the cache up to date with the original content? Is it the caching plugin, the plugin authors, or the site owner using hooks and filters (if so, which ones)?
Our problem: we use a plugin that allows reordering of posts ( for doing this, it changes the “menu_order” field ). After enabling the redis-cache plugin, reordering does not work correctly any more. The new post order does not show because the changed menu_order value is not propagated to the cache ( i.e. the cache key wp:posts:[POSTID] remains unchanged). See https://www.ads-software.com/support/topic/reordering-fails-when-used-with-object-cache-php-redis-in-this-case/ for a detailed report.
Of course, flushing the cache would work, but it is surprising that this is necessary. Now I am afraid that, similar to the problem with our broken sort order, we will face multiple similar problems with other plugins. Actually I thought that wordpress core and/or the caching plugins that implement object-cache.php would detect and propagate changes of posts and post_meta.
If this is not the case then this would mean that it is a matter of luck whether or not each of the plugins I use is handling the cache correctly – right? Or does it depend on the methods that are used to change post and post_meta fields? I wonder how to resolve this so I can benefit from caching, but without having to inspect each and every plugin I use …
Regards Ulrich
-
Thank you for taking the time to respond! Actually I did look into the FAQ before posting, but did not find information relating to this specific problem. ( OK, there is the generic recommendation to “contact the support team of the plugin regarding the issue and ask them to ensure object cache compatibility …” etc – I did so, up until now without response)
Regarding this specific case, where information from a core table ( wp_posts.menu_order field) is used, I assume that the plugin is writing directly into the wp-posts table with SQL so there is no chance for any caching solution to get informed about the change.
So the only solution I can think of is to clear the cache after each reordering activity, right? This would require the presence of a specific hook/filter at the “stupid” plugin’s side that is executed when a write activity occurs. If there is such a hook/filter, I could use it to perform a cache invalidation. But would it be possible to empty just the wp.posts cache subtree instead of completely invalidating the whole cache?
- The topic ‘Propagating changes of wp_post fields to cache – who is responsible?’ is closed to new replies.
