• Resolved arey

    (@arey)


    Hello.

    I had a problem when using the W3 Total Cache 2.7.4 plugin with Polylang Pro 3.6.1 in WP 6.3.5. When using the Synchronize this post function in Polylang (https://polylang.pro/doc/synchronized-posts/), the W3 Total Cache plugin ERRORALLY automatically clears the ENTIRE site cache (even if all checkboxes for clearing are disabled in the plugin settings).

    After searching for information on the Internet, it became clear that this problem is relevant when using the Polylang plugin (Pro or FREE) with some caching plugins.

    Having studied a similar problem with another caching plugin, it became clear that representatives of the Polylang team recommend solving this problem on the side of the caching plugin:

    https://ww.wp.xz.cn/support/topic/auto-purge-rules-for-publish-purge-always-executed/
    https://ww.wp.xz.cn/support/topic/auto-purge-rules-for-publish-purge-always-executed-2/

    The LiteSpeed ​​Cache plugin team has given a recommendation on how to solve this problem when using their LiteSpeed ​​Cache plugin.

    Are you aware of this problem? Can you suggest a solution to the problem on the side of the W3 Total Cache plugin, so that when using the Synchronize function this post does NOT clear the entire site cache?

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Contributor Marko Vasiljevic

    (@vmarko)

    Hello @arey

    Thank you for reaching out and I am happy to help!
    So the problem is that the other plugin is calling w3tc_flush_all(); and not using the post_id or post_url

    It’s usually done by w3tc_flush_all / w3tc_flush_posts calls.
    You may block those by canceling their functionality by adding hooks to w3tc_preflush_posts / w3tc_preflush_all actions.
    W3TC UI buttons send $extras as [ ‘ui_action’ = ‘flush_button’ ] value, this one
    can be used to still allow flushing by UI button.
    Here is the example code:

    add_filter( 'w3tc_preflush_posts',
    function( $do_flush, $extras ) {
    if ( isset( $extras['ui_action'] ) && $extras['ui_action'] == 'flush_button' ) {
    return $do_flush;
    }

    return false;
    },
    99999, 2 );

    add_filter( 'w3tc_preflush_all',
    function( $do_flush, $extras ) {
    if ( isset( $extras['ui_action'] ) && $extras['ui_action'] == 'flush_button' ) {
    return $do_flush;
    }

    return false;
    },
    99999, 2 );

    Alternatively, callstack can be analyzed to filter only some specific plugins by analyzing
    result of debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS ).
    But that’s a bit slower solution and tends to stop working on plugin updates.

    So there are two solutions. The first one is programmatic as shown above, and the other one is to suggest the mentioned plugin not to use flush_all and modify the behavior of their plugin and not purge all cache in these cases.

    Thanks!

    Thread Starter arey

    (@arey)

    Thank you.

    This helped to solve the problem with erroneous clearing of the entire cache when working with the Polylang plugin.

    Please tell me, if I use this code, will automatic cache clearing in the W3 Total Cache plugin work as usual (after publishing/editing posts, as well as when deleting expired junk cache, etc.)?

    Plugin Contributor Marko Vasiljevic

    (@vmarko)

    Hello @arey

    Thank you for your feedback.

    Yes, this only prevents other plugins from calling the actions.

    Glad to know it’s working for you!

    Thanks!

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘W3 Total Cache WRONGLY clears the ENTIRE cache when using the Polylang plugin’ is closed to new replies.