• Resolved ulicgn

    (@ulicgn)


    We have been using RCPO successfully for a while now, in combination with the paid version real-category-manager.

    For performance reasons, we wanted to use an object cache ( in this case we use a redis server and Till Krüss’ well-known redis plugin (https://de.www.ads-software.com/plugins/redis-cache/) The plugin implements the object-cache.php dropin which is then used by wordpress automatically.

    However, as soon as we enable the object cache, the reordering does not work any more. Means: I can still reorder the posts in the backend, but the new order does not show in the frontend.

    The previous post here, https://www.ads-software.com/support/topic/how-to-purge-litespeed-cache-automatically-after-reording-posts/ , reported similar problems.

    By comparing the database and the redis cache content the reason becomes obvious: when reordering in the GUI, RCPO updates the wp_posts table ( field menu_order is changed ), but the cached version remains unchanged.

    I am not sure whether this is a problem of RCPO or of the caching plugin. My assumption was that wordpress core and cache plugins would ensure that changes of wp_posts are propagated to the cache. Is this not true? Is it necessary to implement for a plugin to implement filter hooks that are called for cache purges after changing posts? If so, it would be wise to purge only the entries of the changed posts, not the whole cache …

    Regards, Ulrich

    ( Also reported at https://www.ads-software.com/support/topic/propagating-changes-of-wp_post-fields-to-cache-who-is-responsible/ – not specific to RCPO but with a broader scope )

    • This topic was modified 1 year, 6 months ago by ulicgn.
Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter ulicgn

    (@ulicgn)

    It seems as if RCPO is writing the new values of menu_order directly into the posts table , so no caching solution whatsoever will be able to detect this change. So RCPO can not be used in combination with an object cache … right? Is there a filter/hook that can be executed either for each post that is changed, or generally after each reorder operation? This would at least allow to create a custom filter that invalidates the cache if a write operation has occured.

    Plugin Author Matthias Günter

    (@mguenter)

    Hey @ulicgn !

    Attached, you will find a pre-release of the plugin. This solves the problem you mentioned. You can simply upload this version to your WordPress and replace it with the current version (Plugins > Add new > Upload Plugin; Screenshot). When the next version of the plugin incl. the pre-released feature is available for all users, you will see it as a normal update in your WordPress.

    Download pre-release: https://storage-dev-1.owlsrv.de/prereleases/cbe58471-c4cd-482a-bf42-cb51d7e47d68/real-custom-post-order-1.3.51-4949-plugin.zip

    This prerelease adds two new features:

    1. Automatically clears the post cache (object cache) for reordered posts: https://developer.www.ads-software.com/reference/functions/clean_post_cache/
    2. Added a hook RCPO/Updated when reordering is done
    Thread Starter ulicgn

    (@ulicgn)

    Hallo @mguenter ,

    I very much appreciate that you tackled the caching problem and even created a prerelease version. Thanks for that!! Also, using clean_post_cache to invalidate only the changed items seems like the best solution, and the additional hook might prove useful , too – just to be sure …

    I will certainly give it a try and report how it works! However I am not so sure any more whether or not we can actually use the object cache in production. I was assuming that WP core would handle the object cache “automagically”, like it does with transients. Since this assumption is wrong, we would now have to check each and every plugin for object cache compatibility (which is probably too much hassle) or use the cache with a very short lifetime only, which partly defeats its purpose.

    Anyway, it is helpful to know that at least RCPO will now work well with our cache. ( So far, we did not identify other plugins with similar caching problems, but I assume there will be more. )

    Thanks and best regards

    Ulrich

    Thread Starter ulicgn

    (@ulicgn)

    Just a short update – it works as planned. I installed the prerelease version and checked the cache content of the affected posts immediately after a reordering operation: they are invalidated after reordering and have the new menu_order value as soon as they get recreated in the cache. This means that the new order is now shown correctly in both frontend and backend. In my use case, it was not necessary to implement the hook. Thanks!

    @mguenter FYI

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Reordering fails when used with object-cache.php ( redis, in this case)’ is closed to new replies.