NO BUG: WooCommerce Product Gallery thumbnail slider fails to initialize with WP Rocket Delay JS on early user interaction

Browser: Chrome 110
OS: macOS / Windows / Linux / etc.
URL: https://staging47.thedrops.eu/en/product/the-drops/
Video: Jam

Hi Bricks team,

I’ve found what appears to be a race condition in the Bricks WooCommerce Product Gallery when WP Rocket’s “Delay JavaScript Execution” feature is enabled.

Issue

When loading a single product page normally, the Product Gallery and its thumbnail slider initialize correctly.

However, when the user interacts with the page very early during page load — for example, by moving the mouse immediately while the page is loading — the main WooCommerce product gallery initializes correctly, but the Bricks thumbnail slider does not initialize.

The thumbnail container remains at:

<div class="brx-product-gallery-thumbnail-slider" style="opacity: 0;">

The thumbnail images themselves are present in the DOM and have valid src/srcset attributes. The problem is specifically that the thumbnail FlexSlider is never initialized.

How to reproduce

  1. Enable WP Rocket → Delay JavaScript Execution.

  2. Open a WooCommerce single product page containing the Bricks Product Gallery with thumbnail slider enabled.

  3. Reload the page and immediately move the mouse while the page is loading.

  4. The main product gallery loads, but the thumbnail slider remains invisible/uninitialized.

  5. Reload the page without interacting during the initial page load.

  6. The gallery and thumbnails initialize correctly.

The issue is consistently reproducible based on the timing of the initial interaction.

Diagnostics

In the broken state:

const s = document.querySelector(
    '.brx-product-gallery-thumbnail-slider'
);

console.log({
    opacity: s.style.opacity,
    flexViewport: !!s.querySelector('.flex-viewport'),
    flexControlNav: !!s.querySelector('.flex-control-nav'),
    flexDirectionNav: !!s.querySelector('.flex-direction-nav'),
    wrapperStyle: s
        .querySelector('.brx-thumbnail-slider-wrapper')
        ?.getAttribute('style'),
    sliderData: window.jQuery
        ? jQuery(s).data('flexslider')
        : null
});

Returns:

opacity: "0"
flexViewport: false
flexControlNav: false
flexDirectionNav: false
wrapperStyle: null
sliderData: undefined

jQuery and FlexSlider themselves are both available:

console.log({
    jquery: typeof window.jQuery,
    flexslider: typeof window.jQuery?.fn?.flexslider
});

Returns:

jquery: "function"
flexslider: "function"

The main WooCommerce Product Gallery is also initialized correctly:

product_gallery: present
main flexslider: present
thumbnail flexslider: undefined

So this does not appear to be caused by jQuery or FlexSlider failing to load.

Suspected cause

Looking at bricksWooProductGalleryEnhance(), the Bricks thumbnail slider appears to depend on this event:

jQuery(document.body).on(
    "wc-product-gallery-after-init",
    function () {
        jQuery(
            ".brx-product-gallery-thumbnail-slider"
        ).each(function () {
            let settings = jQuery(this).data(
                "thumbnail-settings"
            );

            if (settings) {
                jQuery(this).flexslider(settings);
                jQuery(this).css("opacity", 1);
            }
        });
    }
);

It looks like there is a race condition where wc-product-gallery-after-init can fire before the Bricks thumbnail initialization listener has been registered.

If that event is missed, there doesn’t appear to be a fallback that checks whether the main gallery has already initialized while the thumbnail slider has not.

This would explain why the issue only occurs when WP Rocket releases delayed JavaScript very early due to user interaction.

Confirmed workaround

In the broken state, manually running the following immediately fixes the thumbnail gallery:

const $thumb = jQuery(
    '.brx-product-gallery-thumbnail-slider'
);

$thumb.each(function () {
    const settings = jQuery(this).data(
        'thumbnail-settings'
    );

    if (settings) {
        jQuery(this).flexslider(settings);
        jQuery(this).css('opacity', 1);
    }
});

After running this:

  • thumbnails are positioned correctly;

  • the thumbnail slider works;

  • navigation works;

  • synchronization with the main gallery works.

This suggests all required dependencies and settings are available and that only the thumbnail initialization itself has been missed.

Possible fix

Would it be possible for Bricks to make the thumbnail initialization more defensive?

For example, after registering the gallery handlers, Bricks could check whether a .woocommerce-product-gallery has already been initialized while its corresponding .brx-product-gallery-thumbnail-slider does not yet have a FlexSlider instance.

Conceptually:

if (
    mainGalleryIsInitialized &&
    !thumbnailSliderIsInitialized
) {
    initializeThumbnailSlider();
}

This would make the Product Gallery less dependent on catching the one-time wc-product-gallery-after-init event at exactly the right moment.

At the moment I’ve implemented a small fallback that performs this check and initializes only missing thumbnail FlexSlider instances, which resolves the issue while keeping WP Rocket Delay JavaScript enabled.

It would be great if this could be handled natively by Bricks.

Thanks!

Hi @Jamesnp ,

Thank you for the detailed report and investigation.

We reviewed the initialization flow. Under the normal WooCommerce script lifecycle, Bricks registers its gallery handlers and the thumbnail slider initializes correctly. The issue occurs when WP Rocket’s Delay JavaScript Execution changes that lifecycle: during early interaction, WooCommerce can complete the gallery initialization before the Bricks integration is available to receive the event.

Since this timing change is introduced by Delay JavaScript Execution, we believe it should be handled by WP Rocket’s script execution and compatibility logic rather than by adding a WP Rocket-specific recovery path to Bricks.

As a workaround, please exclude the Bricks WooCommerce integration script from Delay JavaScript Execution:
/themes/bricks/assets/js/integrations/woocommerce.min.js

Depending on the WP Rocket configuration, its WooCommerce and FlexSlider dependencies may also need to be excluded. WP Rocket support should be able to advise on the smallest safe exclusion set.

We recommend sharing this thread and your reproduction steps with WP Rocket. If the same problem can be reproduced without delayed JavaScript execution, or WP Rocket identifies a Bricks-side issue under the normal script lifecycle, we’ll be happy to investigate it again.

Regards,
Jenn