Product Slider BlockFree downloadMenu

Does it work with my theme and plugins?

Find yours below. We ran 53 of them on a test shop with WordPress 7.1.4 and WooCommerce 11.2.1. Others we could only read about or could not test, and each card says which. This is what we saw, not a guarantee, and a name that is missing here is simply unknown.

53
tested on a test shop
8
documentation read only
6
not tested

Themes

Storefront

Tested, version 4.6.2

Storefront is WooCommerce's own classic theme, so it runs the hooks the shop-wide switches use without changing any of them.

What we found
  • With the list switch on, cards on the shop page are 231 pixels square and move to the next image under the pointer, drawn on a canvas.
  • With the product page switch on, the Stage takes the gallery's column, 324 pixels wide, with the summary beside it.
  • Choosing a colour in WooCommerce's own form moved the Stage to that colour's image.
  • The slider's Add to cart button moved the count in Storefront's header cart, from "0 items" to "1 item", without a reload.

Astra

Tested, version 4.14.2

Astra is on over a million sites by wordpress.org's count, and many are shops.

What we found
  • Shop page cards are 285 pixels square in Astra's four columns, and the hover morph drew on a canvas.
  • The Stage is 600 pixels wide on the product page, with the 552-pixel summary beside it.
  • WooCommerce's variation form changed the Stage's image.
  • The Product Slider block drew on a normal page, and its button put a product in the cart.

Kadence

Tested, version 1.5.2

Kadence prints its own link around a card's image, and our image goes inside it.

What we found
  • A card is 278 pixels square, and it stays square when the photo is landscape. On the first run such a photo left a white gap; the plugin now keeps the shape.
  • The hover morph drew on a canvas, under Kadence's own card hover.
  • The Stage is 591 pixels wide, beside a summary of the same width.
  • The variation form changed the Stage's image.
  • Kadence's card lifts its details over the bottom of the image on hover, and that covers the dots for a moment on some cards. The image still changes under it.

Blocksy

Tested, version 2.1.61

Blocksy builds its product cards without WooCommerce's usual image hook.

What we found
  • One image per card, 266 pixels square, with the morph on a canvas and a working link to the product.
  • On the product page the Stage is 556 pixels wide, with the summary in Blocksy's second column.
  • Blocksy's styled variation form changed the Stage's image.
  • The Product Slider block drew, and its button filled the cart.
  • With the switch on, Blocksy's own card image is hidden with CSS but still loads, one small extra image per card.

OceanWP

Tested, version 4.2.8

OceanWP has an image swap of its own, on by default in its product entry style, and a quick view button on the image.

What we found
  • Cards are 260 pixels square next to OceanWP's sidebar, with one image each after a fix in the plugin; on our first run the theme's image and ours were both there.
  • The image links to the product, and the morph drew on a canvas.
  • The Stage is 415 pixels wide, with the summary beside it.
  • Its variation form changed the Stage's image.
  • OceanWP's quick view button is on the theme's image, which the list switch hides. So there is no quick view on a card while the switch is on.

GeneratePress

Tested, version 3.6.1

The free GeneratePress keeps out of the way, and its default content column with a sidebar is narrow.

What we found
  • Cards are 163 pixels square in the default layout, and the morph still reads at that size.
  • The Stage is 355 pixels wide, beside a summary of the same width.
  • The form changed the image, and the slider's button filled the cart.

Neve

Tested, version 4.2.17

Neve lays out its product page with flexbox and gives the width to WooCommerce's gallery.

What we found
  • The Stage is 547 pixels wide, with a 547-pixel summary beside it.
  • Shop page cards are 243 pixels square with the morph on a canvas.
  • The variation form changed the image, and the slider's button filled the cart, shown by the Mini Cart block's count.

Botiga

Tested, version 2.5.1

Botiga is made for shops and comes with a header cart and an add to cart button that shows on the image.

What we found
  • The card morphed with Botiga's button lying over the image, at 255 pixels square.
  • The Stage is 555 pixels wide next to a summary of the same width, after a fix: Botiga gives its column only to .woocommerce-product-gallery, a class the plugin now adds.
  • The slider's button moved Botiga's own header count without a reload.

Twenty Twenty-Five

Tested, version 1.5

In a block theme nothing runs through the classic shop hooks.

What we found
  • Cards are 375 pixels square in the Product Collection block, and the morph drew on a canvas.
  • The Stage replaced the gallery block, 512 pixels wide with the form beside it.
  • Going to page 2 of the shop happens in place, with no page load, and the new cards morphed too. On our first run they did not; the plugin now starts cards that arrive later.
  • The Mini Cart block's count moved when the slider's button was used.
  • The product's structured data still had its image.

Twenty Twenty-Four

Tested, version 1.6

Twenty Twenty-Four is still on half a million sites by wordpress.org's count.

What we found
  • Cards are 344 pixels square, with the morph on a canvas.
  • The Stage is 512 pixels wide, with the form to its right, and the form changed its image.
  • The Product Slider block drew on a page, and the Mini Cart block's count moved.

Flatsome

Not tested

Flatsome is a paid theme, and we don't test what needs a licence.

What we found
  • Nothing has been run on Flatsome.
  • Unknown. Blocksy and OceanWP, which print their own cards, needed changes in the plugin that name them. Flatsome may need the same.

Page builders

Elementor

Tested, version 4.3.5

Short answer: the shop-wide switches work, as they don't care what built the page around them.

What we found
  • With both active, cards on the shop page are 251 pixels square and morph.
  • The Stage is 547 pixels wide beside the summary, on the classic product page that Hello prints.
  • A page built in the block editor shows the Product Slider, with Elementor active.
  • A block cannot be placed inside an Elementor page.
  • In Hello Elementor our Product Slider with Wide alignment came out 1300 pixels wide on a 1280-pixel screen. Use the default width there.

Divi

Docs read, not run

We don't have a Divi licence, so this page is what its documentation says and not a test.

What we found
  • Nothing has been run on Divi.
  • Unknown until someone runs it.

Bricks

Docs read, not run

Bricks needs a licence, so nothing here was run.

What we found
  • Nothing has been run on Bricks.
  • Unknown until someone runs it.

Colour swatches

Variation Swatches by CartFlows

Tested, version 1.0.14

Swatch plugins sit on top of WooCommerce's form, and they matter here because the Stage listens to that form.

What we found
  • Clicking a swatch moved the Stage from the first image to that colour's image.
  • Nothing else on the shop or the slider changed with the plugin on.

Variation Swatches for WooCommerce (Emran Ahmed)

Tested, version 2.6.2

This is the most used of the plugins with this name, at 300,000 installs by wordpress.org's count.

What we found
  • A click on a button swatch moved the Stage to that colour's image.
  • The plugin's scripts raised no errors with the Stage on the page.

Variation Swatches for WooCommerce (AovUp)

Tested, version 2.2.9

A plugin with the same name as two others, and a different markup: its swatches are .tawcvs-swatches .swatch.

What we found
  • A click on a label swatch changed the Stage's image.
  • The hover morph on the shop page and the slider's button were not affected.

Additional Variation Images Gallery

Tested, version 1.4.3

This plugin replaces WooCommerce's gallery so each variation can have several images.

What we found
  • The Stage showed on the product page, and the plugin's gallery did not.
  • WooCommerce's form changed the Stage to the variation's main image.
  • The extra images you attached per variation in this plugin don't appear in the Stage. It reads the product's gallery and each variation's main image.

Languages

Polylang

Tested, version 3.9.1

We ran free Polylang 3.9.1 with English and German set up.

What we found
  • With two languages on, every check passed in the default language: morph, Stage, form, slider and cart.
  • No script errors, and no PHP notices from the plugin.
  • Not tested: Polylang for WooCommerce, which translates products. It needs a licence.
  • The plugin has no wpml-config.xml yet, the file Polylang's docs say it reads for text saved in a block.

TranslatePress

Tested, version 3.3.8

TranslatePress rewrites the whole page on its way out, so it could have touched the settings the blocks keep in the HTML.

What we found
  • On /de/shop/ cards morphed on a canvas.
  • The Stage's settings held /de/wp-json/wc/store/v1/ and /de/cart/.
  • The slider's button on /de/compat-slider/ added to the same cart as the English page.
  • Everything passed in the default language too.
  • We ran it with no translations entered, so what its editor does to a block's text was not looked at.

WPML

Docs read, not run

WPML needs a licence, so this is from its documentation and not a test.

What we found
  • Nothing has been run on WPML.
  • The plugin has no wpml-config.xml.
  • How the Store API add to cart keeps the language and currency with WooCommerce Multilingual is unknown.

Currencies

CURCY Multi Currency

Tested, version 2.2.20

Prices in the slider and the Stage are printed on the server, and a variation's price is kept in the page for the Stage to use.

What we found
  • The slider showed $61.60 for a product of €56.
  • The Stage showed $207.90 – $218.90 for the product.
  • Choosing a swatch in the Stage showed $207.90, the chosen variation's price.
  • The cart button worked as before.

FOX Currency Switcher (WOOCS)

Tested, version 1.5.6

FOX was long called WOOCS, and people still search for it by that name.

What we found
  • Slider prices went to dollars, $61.60 where it was €56.
  • The Stage's price range read $207.90 – $218.90, and a chosen variation $207.90.
  • The JSON with the variations in the page held dollar prices too.

WooPayments Multi-Currency

Docs read, not run

We don't create accounts for a test, so WooPayments was not run.

What we found
  • Nothing has been run on WooPayments.
  • Unknown: a variation's price in the Stage in the caching mode.

Other plugins

YITH WooCommerce Wishlist

Tested, version 4.19.1

YITH's heart can sit on top of a product's image in a list, which is exactly where the morph happens.

What we found
  • The shop page had 12 wishlist buttons with 12 morph cards, and the morph still ran.
  • The product page had the Stage and the wishlist button.
  • No script errors.
  • For a logged-out visitor its call to /wp-json/yith/wishlist/v1/lists/ answers 401 in the console. That is its own call, and it stopped nothing in our checks.

TI WooCommerce Wishlist

Tested, version 2.14.0

We ran TI's plugin at its defaults on version 2.14.0, on Storefront, and looked for its buttons next to our cards and our Stage.

What we found
  • 12 buttons with 12 cards on the shop page.
  • The Stage and the button side by side on the product page.
  • It wrote early-translation notices of its own to the debug log, and none from our plugin.

WPC Product Bundles

Tested, version 8.7.8

A bundle has its own product type and form.

What we found
  • The bundle's page had the Stage, the bundled products' list and the form.
  • Ordinary products kept working in the shop and the slider.
  • We did not add a bundle to the cart through the slider's button. It uses the Store API, and how the plugin takes that was not checked.

PPOM Product Add-Ons

Tested, version 34.0.12

We ran PPOM 34.0.12 on the shop, with no fields set up on the products in the test.

What we found
  • All the checks passed with the plugin on: morph, Stage, form, slider and cart.
  • Not tested: the slider's button on a product with a required field. It adds through the Store API and does not show the fields.

YITH Product Add-Ons

Tested, version 4.34.1

Version 4.34.1 was active through every check, with no add-on options set on the test products.

What we found
  • The Stage, the form and the slider's button all passed with the plugin on.
  • Not tested: add-on options actually on a product, or changing the image from an add-on option.

Subscriptions for WooCommerce

Tested, version 2.1.1

This is the free plugin of that name, and not WooCommerce's paid Subscriptions.

What we found
  • Ordinary products kept their morph, Stage and button with it on.
  • The product page's form was not disturbed.
  • Not tested: an actual subscription product.

WooCommerce Subscriptions

Not tested

This extension needs a licence, and the pages we read do not say how its products behave with a block's button.

What we found
  • Nothing has been run on it.
  • Unknown.

WooCommerce Product Bundles

Not tested

A paid extension, not run here.

What we found
  • Nothing has been run on it.
  • Unknown.

WooCommerce Product Add-Ons

Docs read, not run

A paid extension.

What we found
  • Nothing has been run on it.
  • Unknown how a product with only optional add-ons behaves with the direct button.

Yoast SEO

Tested, version 28.8

The worry with replacing a gallery is what it does to structured data.

What we found
  • The JSON-LD still held one Product, named Fuchsia blazer, with its main image.
  • The og:image tag held the same image.
  • Not tested: Yoast WooCommerce SEO, its paid add-on. A rich results check on a live site is the last word, and we can't run that on a local one.

Rank Math

Tested, version 1.0.280

We activated Rank Math 1.0.280 without running its setup wizard, so the settings are what activation leaves.

What we found
  • The JSON-LD held one Product with its main image.
  • Morph, form, slider and cart passed.
  • Not tested: Rank Math's own schema after its setup. No og:image was in the page in the state we ran.

Caching

LiteSpeed Cache

Tested, version 7.9.2

LiteSpeed Cache is on seven million sites, and its optimisation settings run on any server.

What we found
  • With Lazy Load Images on, LiteSpeed leaves our images alone. They carry data-no-lazy and skip-lazy, which it honours, as a placeholder drawn on a canvas would be a blank.
  • With Load JS Deferred on Delayed, jQuery comes after our script. The Stage now waits for it, so the variation form changes the image; before a fix it never did.
  • JS Combine and CSS Combine left our script modules alone. The morph, Stage, slider and cart all passed in a block theme and in Storefront.
  • Not tested: its page cache, which needs a LiteSpeed server, and the QUIC.cloud services, which need an account.

WP Rocket

Docs read, not run

We don't have a licence, so this is from WP Rocket's docs.

What we found
  • Nothing has been run on the paid plugin.
  • Unknown what Delay JavaScript Execution does to script modules.

W3 Total Cache

Tested, version 2.11.0

We turned on three things on version 2.11.0: page cache with disk storage, minify, and lazy loading under User Experience.

What we found
  • No placeholders on our images, with lazy loading on.
  • Morph, Stage, form, slider and cart all passed in Storefront.
  • The cart button fetches a fresh nonce each time, so a cached page does not break it.
  • Our page cache check was by logged-out visits with the option on; we did not measure hits in this setup.

Autoptimize

Tested, version 3.1.17

We turned on JS and CSS optimisation with aggregation, HTML optimisation and "Lazy-load images?" on version 3.1.17.

What we found
  • Our images were not replaced with placeholders.
  • Aggregation did not touch the blocks' script modules, and the morph ran.
  • WooCommerce's form changed the Stage's image with JS aggregated.
  • The Store API button worked, and the header count moved.
  • Not tested: its image CDN option, which rewrites image addresses to another origin. If you use it, read the page on CDNs here.

WP Super Cache

Tested, version 3.1.4

The classic page cache.

What we found
  • A cached page answered with the plugin's footer comment.
  • The slider's button added to the cart from it, and the count moved.
  • Morph, Stage and form behaved as usual.

WP-Optimize

Tested, version 4.7.0

WP-Optimize cleans the database, caches pages and compresses images.

What we found
  • The blocks and the switches passed with it on in Storefront, without a script error.
  • Its first run wrote database errors of its own to the log, about a table of its task manager, and none from our plugin.
  • Not tested: its minify and premium lazy load.

Jetpack Boost

Tested, version 4.8.1

We ran Boost 4.8.1 without a connection.

What we found
  • With deferred scripts: morph, Stage, form, slider and cart all passed.
  • With concatenation on: morph and the Stage's canvas still ran, as script modules are apart from it.
  • Not judged: Concatenate JS. WooCommerce's own form failed with wp.template is not a function there, with the plain gallery as well, as its files did not load on our port-based site.
  • Not tested: Image CDN and Critical CSS, which need a connection to an account.

Speed Optimizer (SiteGround)

Tested, version 7.8.5

SiteGround's plugin has the sharpest finding of this whole test.

What we found
  • Morph, Stage, form and slider all passed with Combine JavaScript Files and Lazy Load on.
  • The slider's button still adds to the cart.
  • With Combine on, a page holding WooCommerce's Mini Cart block fails with Cannot use import statement outside a module. It fails the same with our plugin deactivated. On that page neither the Mini Cart's count nor the classic header count moved.

Image plugins

LazyLoad by WP Rocket

Tested, version 2.4.1

A small free plugin that replaces image addresses with a placeholder.

What we found
  • None of our images were replaced with a placeholder.
  • With every upload slowed by 1.5 seconds and the pointer on a card from the start, the canvas drew the photo.
  • The rest of the page's images stay with the plugin.

Smush

Tested, version 4.3.5

Smush's lazy load is free, and on by choice.

What we found
  • No placeholders on our images with Lazy Load on.
  • With images slowed by 1.5 seconds and the pointer already on a card, the canvas drew the photo.
  • Morph, Stage, form, slider and cart passed.
  • Not tested: bulk compression, which keeps files and addresses, and its CDN, which is a Pro feature. A CDN needs CORS; see the page on it.

EWWW Image Optimizer

Tested, version 8.9.1

EWWW has two ways of touching our markup, and we ran each on version 8.9.1.

What we found
  • With Lazy Load on, our images were left alone, as skip-lazy is on its list.
  • With picture rewriting, all 36 images on the shop page were inside picture, and the browser's choice was a .jpg.webp file.
  • The canvas drew from that WebP file, as the class stays on the img.
  • Not tested: its Easy IO CDN, which needs an account. See the page on CDNs.

WebP Express

Tested, version 0.25.16

WebP Express can rewrite image tags to picture tags through its Alter HTML option.

What we found
  • All 36 images of the shop page became picture elements with a WebP source.
  • The stack kept its shape, and the morph drew on the canvas.
  • The Stage and its thumbnails behaved.

Converter for Media

Tested, version 6.7.1

This plugin rewrites at the server and not in the HTML, so a page keeps its .jpg addresses.

What we found
  • Image tags and addresses stayed as WordPress wrote them.
  • The canvas drew them as it does on a site without the plugin.
  • Not tested: serving actual converted files. A WebP sent for a .jpg address would be drawn as any other image, but we have not watched it.

a3 Lazy Load

Tested, version 2.7.9

In a3 Lazy Load's code skip-lazy and a3-notlazy are always in the classes it skips.

What we found
  • No placeholders on our images at its defaults.
  • A card's second image was there when the pointer came.
  • Its placeholder image got a wrong address on our test site, which runs on a port: a 404 in the console. It stopped nothing, and is unlikely on yours.

ShortPixel Image Optimizer

Not tested

ShortPixel works through an API key from an account, and we don't make accounts for a test.

What we found
  • Nothing has been run on ShortPixel.
  • Unknown.

Imagify

Not tested

Imagify works through an account, so it was not run.

What we found
  • Nothing has been run on Imagify.
  • Unknown.

Images on a CDN

Tested, version simulated CDN

A browser won't let a canvas read an image from another origin unless the server says so.

What we found
  • With the header: the plugin asks once per origin, then loads the images with crossorigin, and the canvas drew the morph. Before a fix it fell back to a plain fade.
  • Without the header: images stay as they are, and the card changes with a fade. Nothing goes blank.
  • The Stage, the slider and the cart passed in both.
  • Without the header the probe leaves one CORS message per origin in the browser's console. It is harmless.
  • Pro's Product Tape, Orbit and Index have their own front-end code, and did not get the probe in this test.

Jetpack Site Accelerator

Docs read, not run

Jetpack's Site Accelerator, once called Photon, needs a connection to a WordPress.com account and a public site, so we could not run it.

What we found
  • Nothing has been run on it.
  • Unknown whether it sends CORS headers.

Cloudflare Polish

Docs read, not run

Cloudflare's docs say Polish "keeps the same image URLs, and does not require changing markup of your pages".

What we found
  • Nothing has been run on it.
  • Mirage and Rocket Loader are other Cloudflare features that do rewrite pages. They were not covered.

Cart and checkout

WooCommerce Mini Cart

Tested, version 11.2.1

WooCommerce has two ways to keep a cart count current, a block and a classic fragments script, and the plugin's button speaks to both.

What we found
  • The block's count went from 0 to 1 with no reload.
  • The header counts of Storefront and Botiga, which use fragments, moved too.
  • WooCommerce's classic cart widget, which refreshes through the same fragments, filled on every free theme we ran.
  • With SiteGround's Combine JavaScript Files on, the block stops working, with or without our plugin.

Checkout blocks and HPOS

Tested, version 11.2.1

The blocks don't read or write orders, so HPOS should not matter.

What we found
  • The product added by the slider's button appeared as a row in the Cart block.
  • The Checkout block loaded.
  • The Store API placed the order, which came back as "processing", and the order table wp_wc_orders held it.
  • We placed the order through the Store API call the Checkout block uses, without filling in its form by hand.

Side Cart WooCommerce

Tested, version 2.8.2

A side cart watches for WooCommerce's add to cart events and slides in.

What we found
  • The cart slid open after the slider's button, the body getting xoo-wsc-cart-active.
  • WooCommerce's own button on the shop page does the same, for comparison.
  • Its count, .xoo-wsc-items-count, moved with no reload.
  • A plugin issue and not one with the blocks: the error above, from class-xoo-helper.php, until an admin has loaded a page.

FunnelKit Sliding Cart

Tested, version 1.9.1.2

Version 1.9.1.2 ran at its defaults, set from the command line, without going through its setup.

What we found
  • No conflict: morph, Stage, form, slider and cart all passed.
  • Header counts moved.
  • Not tested: the cart sliding open.

XT Floating Cart

Tested, version 2.8.14

The lite version of this floating cart, 2.8.14.

What we found
  • Its count moved after the slider's button, with no reload.
  • Morph, Stage and form were not affected.
  • Not tested: an opening animation or panel after adding.

FunnelKit Funnel Builder

Tested, version 3.17.0.1

Funnels change what happens after the cart, and the blocks work before it.

What we found
  • The shop, the product page and the slider's button all behaved with no funnel set up.
  • The cart filled from the slider as usual.
  • Not tested: an actual funnel.

CartFlows

Tested, version 3.3.0

CartFlows is on 200,000 sites by wordpress.org's count, and takes over checkout with flows of its own.

What we found
  • Its plugin being on changed nothing in the shop-side checks: morph, Stage, form and slider.
  • Not tested: its flows and checkout pages.

Product filters

WooCommerce Product Collection

Tested, version 11.2.1

In a block theme the shop's next page arrives in place, with no page load.

What we found
  • After clicking "next page" there was no reload, 16 new cards came in, and the first morphed on a canvas.
  • Prices and links on them stayed as WooCommerce rendered them.
  • Not tested: WooCommerce's Product Filters block, which uses the same kind of replacement.

HUSKY Products Filter

Tested, version 1.4.7

HUSKY, long known as WOOF, filters by its URL parameters and can do that in place.

What we found
  • A filtered shop page listed the right six products, starting with Check blazer.
  • Those cards morphed on a canvas.
  • The form, the Stage and the slider were not affected.
  • Not tested: its Ajax mode.

YITH Ajax Product Filter

Tested, version 5.24.0

This is the case the plugin's watcher is for.

What we found
  • Clicking a filter brought in six cards, with no page load.
  • The first of them morphed on a canvas.
  • The rest of the checks passed in Storefront.

Product Filter by WBW

Tested, version 3.4.8

A filter takes setting up in this plugin's own screens, and we did not build one.

What we found
  • Being active, it changed nothing in Storefront's shop, product page or slider.
  • Not tested: filtering.

Filter Everything

Tested, version 1.9.7

Filter Everything filters more than products, and works from filter sets you build.

What we found
  • All the checks passed in Storefront with it on.
  • Not tested: a filter set.

FiboFilters

Not tested

FiboFilters isn't on wordpress.org, and we did not run it.

What we found
  • Nothing has been run on it.
  • Unknown.