Forum Replies Created

Viewing 3 replies - 1 through 3 (of 3 total)
  • While investigating a different Breeze-related issue, I happened to review parts of the plugin code and noticed that Breeze’s Lazy Load feature rewrites image tags quite aggressively. It replaces the original image src with a placeholder and moves the real image URL to a custom attribute. It also modifies srcset attributes. I am not certain that this is the cause of your issue, but it made me wonder whether Cloudflare Polish might sometimes be seeing the placeholder image rather than the original image during processing.

    As a quick test, it might be worth disabling only the Breeze Lazy Load feature while keeping the rest of Breeze enabled, then checking whether Cloudflare Polish starts behaving consistently. If that changes the behavior, it could help narrow down the source of the problem and provide useful information for the Breeze developers.

    Thread Starter istudio1991

    (@istudio1991)

    I have tested Breeze 2.5.4 and the issue still appears to be present. After reviewing the code, I noticed that scheduled posts (future → publish) appear to trigger the following cache-related actions:

    do_action( 'breeze_clear_varnish' );
    Breeze_PurgeCache::breeze_cache_flush();
    Breeze_MinificationCache::clear_minification();

    However, the behavior does not seem to be equivalent to the manual “Purge All Cache” action, which appears to follow a different code path and results in the homepage being refreshed immediately.

    As a suggestion, it may be worth reviewing whether scheduled posts could trigger the same cache invalidation workflow as the manual “Purge All Cache” action, particularly in environments using Cloudflare Enterprise Edge Cache? Of course, I may be missing some implementation details, but I wanted to share this observation in case it helps identify the root cause.

    Thread Starter istudio1991

    (@istudio1991)

    Thank you for your response. No, I have not yet contacted Cloudways Support. Since I was able to identify a workaround, I wanted to provide you with additional information first. The issue appears to be related to scheduled posts not triggering the same cache purge process as manually published posts.

    As a temporary workaround, I added the following snippet:

    add_action('transition_post_status', function($new_status, $old_status, $post) {

    if (
    $old_status === 'future' &&
    $new_status === 'publish' &&
    $post instanceof WP_Post &&
    $post->post_type === 'post'
    ) {
    wp_schedule_single_event(time() + 60, 'function_delayed_breeze_purge', [$post->ID]);
    }

    }, 999, 3);

    add_action('function_delayed_breeze_purge', function($post_id) {

    if (class_exists('Breeze_CloudFlare_Helper')) {
    Breeze_CloudFlare_Helper::reset_all_cache();
    }

    do_action('breeze_clear_varnish');

    if (class_exists('Breeze_PurgeCache')) {
    Breeze_PurgeCache::breeze_cache_flush(true, true, true);
    }

    }, 10, 1);

    After adding this snippet, scheduled posts started appearing on the homepage without requiring a manual “Purge All Cache” action.

    This suggests that, in my environment, scheduled posts may not be triggering the same Breeze cache invalidation workflow that is executed when a post is published manually or when “Purge All Cache” is clicked.

    I hope this information helps your investigation.

    Please let me know if you would still like me to open a Cloudways support ticket and I will be happy to do so.

    • This reply was modified 6 days, 6 hours ago by istudio1991.
Viewing 3 replies - 1 through 3 (of 3 total)