Reimagining catalog management

During Automattic’s Radical Speed Month, @gigitux and I set out to see how far we could push the catalog management experience in four weeks. What we’re sharing here is the proof of concept that came out of it: a working rebuild, live behind a feature flag in core, that we’d like the WooCommerce community to break, stretch, and tell us about. Nothing in this post is a release commitment. The point of putting it in front of you now is to find out what we got right, what we got wrong, and where the API surface needs to give before any of this gets serious.

The catalog problem we wanted to break open

Catalog management is one of the most important activities a WooCommerce merchant does. It’s also the one where the experience has slipped furthest behind merchant expectations. Years of feedback have pointed at the same shortlist: better search and filtering, proper bulk editing across many products at once, a richer quick-edit flow, and a way to inspect and edit variations without clicking into every parent product.

The clearest evidence of the gap is the ecosystem itself. More than 50 extensions exist today specifically to patch these workflows — quick-edit expansions, bulk editors, spreadsheet-style grids, custom column managers. That’s not a healthy “extensible by design” signal. It’s a sign that core is asking merchants to assemble their basic workflow from third-party plugins.

The question we wanted to answer in four weeks: now that WordPress core ships DataViews and DataForms as primitives, can the All Products screen be rebuilt natively on top of them without losing what the extension ecosystem has been quietly compensating for?

What we built in four weeks

The proof of concept lands three pieces:

A native DataViews table. The All Products list rebuilt in table mode, with customizable columns, scanning, sorting, and filtering that doesn’t require a plugin to be useful.
Hierarchical rows for variations. Parent products expand inline to show variations as child rows, and bulk actions operate on parents or on selected children.
Quick edit and bulk edit, on top of the core modal pattern. Two of the longest-standing merchant requests, built with primitives WordPress core already provides, so the experience feels native rather than bolted on.

The video shows those pieces working together in the prototype: configuring the DataViews table, expanding variable products into child variation rows, and using quick edit and bulk edit from the native modal flow.

What’s not ready yet — and what comes next

We want to be upfront: this is a proof of concept, not a finished feature. The most important limitation today is performance at scale. We focused on validating the core experience rather than optimizing for large catalogs. As a result, stores with a high number of products and variations will need further performance work beyond the POC.

The three threads we see as the next chunk of work:

Performance. Both the DataViews-level rendering and the interaction layer on top — including how item selection behaves — need to get smoother before this can hold up on very large catalogs with thousands of products and variations.
Extensibility. Today’s table works as a first-party experience. The next major piece is turning it into a stable, predictable surface that extensions can build on, including the quick and bulk editing flows.
Bulk edit, hardened. What we’ve shipped covers the common cases. The next pass is making bulk edit more robust, more thoroughly aligned with core conventions, and explicitly designed for extensions to integrate against.

None of these are blockers for trying the experience today. All of them are reasons we’re inviting feedback now rather than later.

We want your eyes on this

Whether you’re a merchant managing your own catalog, an agency or freelancer building Woo stores for clients, an extension developer shipping into this surface, or a community member who simply cares about how WooCommerce evolves — your input on this experiment is what we most need.

Some of the things we’d most like to hear:

From merchants and builders: does this experience hold up against the way you actually manage products today? Where does it save you time, and where does it get in your way?
From extension authors: what would it take for the integration patterns you rely on today to translate cleanly onto a DataViews-native table? Which hooks, filters, and customization points matter most for the work you do?
From everyone: the rough edges. The “this confused me for ten seconds” moments. The behavior that surprised you. The thing you went looking for and couldn’t find.

Migration and API work isn’t part of this proof of concept, but the planning for it is happening now, and the earlier we hear from people who use and extend this surface, the better the eventual shape gets.

How to try it

Playground demo, fastest path in: Open the demo. It spins up WooCommerce nightly with the feature flags pre-enabled and sample products imported.
On your own site: Setup instructions live in Epic #64414 — WooCommerce nightly, Gutenberg, the Beta Tester plugin, and the relevant feature flags.
Feedback: The fastest way is the 2-minute survey built directly into the product — look for the interactive badge next to the “Products” page title and it’ll take you straight there. You can also leave a comment on Epic #64414 or on this post. Bugs, paper cuts, extension integration questions — all of it lands in the right place.

One response to “Reimagining catalog management”

Diego

May 21, 2026

My comment is, as always, about extensibility. I had to extend the bulk edit features in several occasions, and it will be crucial to be able to do the same thing with the new editor. Specifically:
1. Adding fields to the editor (in my case, both and fields are needed). The editor itself can take care of rendering them, I would rather not reinvent the wheel with React or other unnecessary stuff.
2. Intercepting the “bulk edit” operations.
3. Reading the extra fields, in order to perform the necessary operations against the affected products and variations.

As I discussed extensively during the Checkout Summit in Sicily, the old approach of “try this snippet, try this script” won’t be effective with the new, complex, script-heavy interfaces. Due to that, the developer documentation will have to describe the exact steps to implement such extensions, with consistent results.