WooCommerce Just Killed a Paid Extension and Gave You the Feature Free

Variation galleries are in core as of 10.9 — behind a flag that 11.0 may flip for you.

For roughly a decade, giving each product variation its own set of images meant buying something. Woo's own Additional Variation Images extension, or one of the dozen third-party plugins that grew up around the same gap, or a theme that bundled its own incompatible version of it.

As of WooCommerce 10.9, it's in core. Free. Every variation in a variable product can carry its own ordered gallery, and the extension it replaces is being retired from the Marketplace entirely.

The catch is that it ships switched off, behind a feature flag with a genuinely awful name:

wc_feature_woocommerce_additional_variation_images_enabled

And the reason this is worth your attention today rather than whenever you get to it: the rollout plan calls for WooCommerce to start flipping that flag on for a random 5% of stores — and when it flips, it deactivates the standalone plugin on its way past. That phase was slated for 11.0, which lands imminently.

The release notes gave this a line. The developer blog gave it a post. Then the conversation moved on to HPOS query optimization and the Product Editor retirement, and it slipped under the water.

Here's the whole picture: what shipped, where the data lives, how to detect it from your own code, and what I'd do about it before 11.0.

What actually shipped

WooCommerce merged the functionality of its own Additional Variation Images extension into core, starting with WooCommerce 10.9 (released 23 June 2026). This follows the same "more in core" pattern used for the Brands merge back in 9.4 — take a feature that essentially every serious store needs, stop charging for it, and fold it into the platform.

The behaviour is what you'd expect. Each variation carries an ordered set of images beyond the single featured image variations have always had. A shopper picks "Walnut / Large" and the gallery swaps to that variation's full image set.

In the admin, the variation's featured image and its gallery are managed as a single ordered list, with the first item automatically promoted to primary. That's a nicer model than the extension's split fields, though the Woo team has been candid that this first pass of the admin UI is rough. They deliberately shipped the plumbing and left polish for follow-up releases rather than block the merge on a redesign.

Note the phrasing throughout: shipped, but off. The feature is disabled by default for every store.

Turning it on

Three ways, depending on your temperament.

The admin route. WooCommerce → Settings → Advanced → Features, toggle Variation gallery.

WP-CLI, which is what you want for staging automation or a deploy script:

wp option update wc_feature_woocommerce_additional_variation_images_enabled 'yes'

REST, if you're driving a fleet of stores from somewhere else:

PUT /wp-json/wc/v3/settings/advanced/wc_feature_woocommerce_additional_variation_images_enabled
Content-Type: application/json

{ "value": "yes" }

One thing to know before you flip it anywhere near production: enabling the core feature automatically deactivates the standalone Additional Variation Images plugin if it's installed. That's deliberate conflict avoidance, not a bug. But if you have deploy tooling that asserts on the active-plugin list, or a monitoring check that alerts on unexpected deactivations, it will fire.

Where the data lives

This is the part that matters most for anyone with custom code, and it's genuinely well-designed.

Variation galleries are stored in _product_image_gallery — the same postmeta key WooCommerce already uses for galleries on parent products. Core didn't invent a new storage location. If you've written anything that reads product galleries generically, the shape is already familiar.

The legacy extension's key, _wc_additional_variation_images, is preserved on disk after migration. Core does not delete it. Third-party code that reads it directly keeps working, and you retain a rollback path to the extension without data loss.

For variations that haven't been migrated yet, there's a compatibility bridge in core — LegacyVariationGalleryCompatibility, under src/Internal/VariationGallery/. Read the caveat carefully, though, because a maintainer was explicit about its limits: there is no remapping at the _product_image_gallery postmeta read level. If your code calls get_post_meta() directly against that key on an unmigrated variation, you get nothing. The bridge operates higher up. Go through the product API, not the meta layer.

REST API from day one

Unlike the Brands merge — which shipped without REST endpoints and irritated a lot of integrators — variation galleries are exposed through the REST API immediately.

On the v3 product variations endpoint, the gallery lives in gallery_image_ids, in the same shape parent products use. It is read and write, accepting an array of attachment IDs.

The critical detail: the featured image still lives separately in image. The unified list you see in the admin is a UI convenience, not the API contract. If you're syncing a PIM or a marketplace feed, you're writing two fields.

PUT /wp-json/wc/v3/products/123/variations/456

{
  "image": { "id": 8801 },
  "gallery_image_ids": [8802, 8803, 8804]
}

Detecting the feature from your own code

If you maintain a plugin, a theme, or an integration that touches product images, you need to branch on this. Woo maintainers confirmed the following.

Is the feature on?

$enabled = get_option( 'wc_feature_woocommerce_additional_variation_images_enabled' ) === 'yes';

Compare against the string. On a store that has never touched the setting the option may be absent entirely, in which case get_option() returns false — which is not 'no', and a loose comparison will bite you.

There is also the more idiomatic FeaturesUtil::feature_is_enabled() path using the slug variation_gallery, which is the slug core exposes in the system status payload. The raw option check above is what maintainers pointed people at directly, so if you want the belt-and-braces version, check the option.

Has the data migration finished?

$completed_at = get_option( 'wc_variation_gallery_migration_completed_at' );

This returns a timestamp — and it carries a sharp edge that deserves its own paragraph.

The timestamp is written once, when the first migration completes, and is never re-stamped or cleared. If a merchant enables the feature, disables it, then re-enables it later, the migration does not run a second time and completed_at still holds its original value. So this option answers "did a migration ever finish on this store," not "is the data currently in sync." Do not build a reconciliation routine that treats it as the latter.

Remotely, over REST:

GET /wp-json/wc/v3/system_status

Look for the string variation_gallery inside settings.enabled_features. Present means on, absent means off. That's the cleanest check for anything running outside the WordPress process — a SaaS integration, a monitoring job, an agency dashboard tracking which client sites have flipped.

How the migration works

When you enable the feature on a store running the old extension, WooCommerce schedules an Action Scheduler job that copies legacy gallery data into the canonical location. It processes 250 variations per run, re-queueing itself until it's done.

The job is idempotent — re-running against already-migrated variations is a no-op, gated by sentinel meta.

Two practical consequences.

First, on a large catalogue this is not instantaneous, and it runs on Action Scheduler, which means it depends on WP-Cron or a system cron actually firing. If you have a store with thirty thousand variations and a cron setup that has been quietly broken since March, you'll enable the feature and watch a partially-migrated catalogue render inconsistently while you wonder what went wrong. Verify Action Scheduler is healthy before you flip the flag, not after.

Second, Woo's own guidance is to test the migration on staging first, and that guidance is worth taking literally rather than as boilerplate. Clone production, migrate, spot-check.

The direction of risk in custom code is worth stating precisely. Code that reads _wc_additional_variation_images should keep working, because the legacy meta survives. Code that writes to _product_image_gallery on variations is where the exposure sits — core now reads from that key, so anything that was previously writing there for its own purposes is suddenly writing to a location core cares about.

Storefront and theme compatibility

Galleries work with both the classic single-product template and the block-based Product Gallery, across old and new block combinations. Theme overrides of single-product/add-to-cart/variable.php are supported.

The specific behaviour Woo asked testers to hammer on is the reset path: when a shopper clears their variation selection, does the gallery return to the parent product's images correctly? If your theme overrides that template, that's the first thing to check.

The other realistic breakage surface is anything that manipulates the gallery DOM after load. PhotoSwipe lightboxes, custom sliders, quick-view modals, infinite-scroll product grids that reinitialise galleries. This class of code has historically been fragile around variation image swapping — the extension itself had to be rearchitected years ago because re-initialising Flexslider on a swapped gallery broke it. If you ship or use anything in that category, test it.

The rollout — and a genuine open question

The published plan has three phases:

10.9 — ships the feature, opt-in only, off by default.
11.0 — a 5% canary, via a database updater that flips the option for a randomly selected slice of stores.
11.1 — 100% enablement, once the canary clears.

Maintainers were clear that this is the default plan and could be amended based on feedback or problems.

Here's the part I haven't seen anyone note, and it's the reason this article has some urgency.

WooCommerce 11.0's published pre-release developer notes do not mention the variation gallery canary at all. They cover performance work, email and account changes, analytics, the Product Editor removal, phone validation hooks — but the canary that was slated for exactly this release isn't in them.

That could mean several things. It might be an intentional omission because a silent database-updater flip isn't really "developer-facing" in the way an API change is. It might mean the canary slipped. It might simply be that the notes weren't exhaustive.

What it definitely means is that you should not assume the canary is not coming just because it isn't in the notes, and you should not assume it is coming just because it was on the roadmap. Treat it as unresolved and monitor the developer blog.

The timing sharpens this. WooCommerce 11.0 was originally set for 28 July 2026, then postponed to 4 August 2026 after a fatal error surfaced in RC1 testing from a new performance feature. So 11.0 is landing imminently, with the canary status ambiguous.

If you are an agency with client stores on auto-update, that's the scenario to think about: a background database updater flipping a feature on for a random 5% of your portfolio, deactivating a plugin as it goes.

What I'd actually do this week

If you run the Additional Variation Images extension. Clone to staging, enable the flag, let the migration run, and verify galleries against production. You want to find migration problems on your schedule rather than on the canary's. Subscribers don't need to do anything for billing purposes — Woo will handle subscription cancellation and refund/credit when the extension is retired at 100% rollout, and will email at the canary and 100% milestones.

If you run a third-party variation-images plugin — Emran Ahmed's, WPC's, PluginEver's, a theme-bundled one — you get no automated migration. Core migrates from Woo's own extension only. Your data is in a different meta key and you'll need your own migration, or you wait for that plugin's author to ship compatibility. Start that conversation now.

If you build plugins or integrations. Add the feature detection above. Audit for direct _product_image_gallery writes on variations. If you have a REST integration, decide how you handle gallery_image_ids before a customer's store flips underneath you.

If you're building a new store. Turn it on. You get the feature for free, you skip a plugin dependency, and you're storing data in the location core is standardising on.

If you have a large, complex, heavily-customised catalogue. Don't flip it on production yet. But do put a staging test on the calendar before 11.1, because the decision to enable eventually stops being yours.

One adjacent thing

WooCommerce 10.9 also introduced native colour and image swatches, built on a new attribute type called wc-visual, with term data stored in wp_termmeta. It's a separate feature with a separate flag, but it addresses the other half of the same problem — variation imagery and variation selection UI have both been plugin territory for a decade, and core is taking back both at once.

If you're auditing your stack for what a plugin still earns its place doing, do both audits in the same sitting.

The primary sources are Marco Lucio Giannotta's roadmap post "Bringing Variation Galleries into Core" on the WooCommerce developer blog (19 May 2026) and GitHub Discussion #65147, where maintainers answered the detection and migration questions directly.