Most stores I take over that sell anything by color already run a swatch plugin, bought years ago and renewed ever since. WooCommerce color swatches now live in core as of 10.9, which changes what that renewal buys you. The announcement is on the WooCommerce developer blog, by Albert Juhé Lluveras, and the short version covers a new Color / Image attribute type, a feature flag for block themes, and swatch rendering in the Product Filters chips plus the Variation Selector of Add to Cart + Options.
The way I see it, this is a staged rollout where the block theme requirement does the filtering for you. Classic themes get nothing. Block themes also get nothing where it counts if the Single Product template still uses the classic add-to-cart block, because the swatches only render in the newer Add to Cart + Options block. So the work this month is an inventory and a decision per store, then the toggle. I’ll go in that order.
Turning on WooCommerce color swatches, step by step
Check the theme, then the add-to-cart block
The feature flag only appears when the active theme is a block theme, starting with the 10.9 release. If the client is on classic PHP templates, swatches are off the table for now, and the swatch plugin stays. On a block theme, open the Single Product template and look at which add-to-cart block it uses. In the comments on the announcement, the WooCommerce author confirmed the swatches only apply to Add to Cart + Options, and there are no immediate plans to bring them to the classic Add to Cart with Options block.
One more check while you’re in that template: the gallery. A commenter on the same post traced a missing gallery update to the classic Product Image Gallery block, and swapping in the new Product Gallery block fixed it, because Add to Cart + Options only talks to the new gallery. Two checks and you know whether the feature will even be visible on this store. Block-based product screens have been arriving piecemeal for a while, and the product editor beta went through its own cycle of that before it left core.
Enable the flag and change the attribute
On a store that passes both checks:
- Settings, Advanced, Features: toggle Color swatches for attributes
- Products, Attributes: edit the Color attribute and set its type to Color / Image
- Configure terms: set a HEX color or pick a media image for each term
The type is stored internally as wc-visual, and the whole feature is opt-in: attributes you don’t touch keep rendering plain text chips. The wc- prefix on the slug is deliberate, so the new type doesn’t collide with swatch plugins that register their own attribute types. Keep that in mind for later.
Check the three places swatches render
Three places show the swatch: the Chips display of Filter by Attribute, the List display of the same filter (a small swatch beside the term name), and the Variation Selector chips on the product page. Each swatch is a circle filled with the HEX value or the image. Test all three on staging, on a filtered archive and a variable product, before you tell the client it works. If you want to poke at it ahead of your store’s release line, nightly builds are on GitHub.
The parts that are not one click
The biggest one is data. Your existing swatch plugin stored its colors in term meta under its own keys, and switching the attribute type to wc-visual imports none of it. You either retype every color through the new admin fields, or you script an audit so nobody retypes the wrong hex twice. I’d script the audit and still set the values through the admin, because I don’t want to guess WooCommerce’s storage format for a feature this new.
<?php
/**
* Audit which Color terms have a value to migrate.
* Run with: wp eval-file audit.php
*/
function bbioon_audit_swatch_terms( $taxonomy = 'pa_color', $old_meta_key = 'old_plugin_color' ) {
$attribute = wc_get_attribute( wc_attribute_taxonomy_id_by_name( 'color' ) );
if ( ! $attribute || 'wc-visual' !== $attribute->type ) {
WP_CLI::log( 'The Color attribute is not the wc-visual type yet.' );
return;
}
$terms = get_terms(
array(
'taxonomy' => $taxonomy,
'hide_empty' => false,
)
);
if ( is_wp_error( $terms ) ) {
WP_CLI::log( $terms->get_error_message() );
return;
}
foreach ( $terms as $term ) {
$old = get_term_meta( $term->term_id, $old_meta_key, true );
WP_CLI::log( sprintf( '%s (term %d): %s', $term->name, $term->term_id, '' !== $old ? $old : 'nothing stored' ) );
}
}
bbioon_audit_swatch_terms();Save that as audit.php and run wp eval-file audit.php. Replace the meta key with whatever your plugin uses (grep its folder for get_term_meta and you’ll find it in a few minutes). wc_get_attribute returns the attribute as an object with a type property, which is how the script knows the migration has started.
Then think about overlap. If the old plugin stays active and it also replaces variation dropdowns or styles the archive filters, you can end up with two swatch layers or a markup fight. Pick one renderer per attribute, test with the plugin deactivated, and only remove it once the product page and the filters both look right without it. Since the new type is namespaced under wc-, the two can coexist without register callbacks colliding.
One failure mode already showed up in the wild. A store owner reported a critical error on the attribute terms screen in WooCommerce 11.0.1: another plugin returned null from the manage_{$taxonomy}_custom_column filter while VisualAttributeTermAdmin::render_term_visual_column() declared a string return type. Woo loosened the return type, and the fix shipped in 11.1. The general lesson holds regardless: always return a string from those column filters, even an empty one.
Finally, do an accessibility pass, because swatches swap text for color. Check with a screen reader that a swatch still announces the term name, Olive rather than a hex value, and give image swatches real alt text if you use them for patterns. Color as the only cue is a WCAG 1.4.1 problem. Ten minutes on one product page covers most of it.
If you want a hand with this, checking which stores qualify and moving their swatch data off a plugin, that’s work I do. Send me the inventory and I’ll tell you which ones are worth switching this quarter.
On a client site this week I’d run the two template checks on staging, flip the flag only where Add to Cart + Options and the new Product Gallery are already in place, and migrate one attribute by hand to see how the admin feels. Everything else keeps its swatch plugin until the flag comes off.
