For more than ten years, WooCommerce Catalog Management has been the junk drawer of the platform. If you’ve run a store with more than a hundred products, you already know the “All Products” screen feels old. It’s slow, the filtering is shallow, and working with variations means a lot of clicking around. So the community filled the gap, and there are now over 50 extensions that exist mostly to handle basic bulk editing.
That is starting to change. During Automattic’s Radical Speed Month, a new proof of concept (POC) showed up that rebuilds the WooCommerce Catalog Management experience natively. It goes deeper than a new coat of paint, because it’s built on WordPress core’s DataViews and DataForms primitives.
Why core is taking this screen back
When an ecosystem needs 50+ plugins to fix one screen, core isn’t doing its job. We went through the same thing with the legacy block editor and with early variation management. The distance between what merchants expect and what the native “All Products” screen gives them has turned into a real problem for stores trying to grow. The old approach also leans on constant page reloads, which is why technical debt tends to pile up right at the catalog level.
The new POC changes three things:
- Native DataViews table: A customizable list with sorting and filtering built in, so you don’t need another plugin just to make it usable.
- Hierarchical variation rows: Parent products expand inline. You can see and edit child variations without the click, wait, edit, go back routine.
- Core modal workflows: Quick edit and bulk edit move into the native modal pattern, so they feel like part of WordPress instead of something bolted on.
DataViews and extensibility
Using @wordpress/dataviews is a good call. It lets the WooCommerce Catalog Management screen stay agnostic about where the data comes from, whether that’s the REST API or an internal store. As a developer, though, I care most about what comes next: the API surface. For this to work, it needs stable Hooks and Filters that third-party extensions can actually build on.
If you want to see how these components work, start with the official DataViews documentation. Here is a conceptual example of how a field might be defined in the new setup:
{
id: 'price',
label: 'Price',
render: ( { item } ) => <ProductPrice value={ item.price } />,
elements: [
{
type: 'filter',
operators: [ 'is', 'isNot', 'greaterThan' ],
},
],
}Performance at scale is the weak spot
I’ve watched plenty of shiny UI updates fall over the moment they meet a database with 10,000 SKUs. The current POC is upfront about this: performance at scale isn’t there yet. Rendering thousands of rows in a React table tends to cause race conditions during selection and laggy scrolling. The interaction layer needs a proper refactor before this ships. We ran into similar problems when the variation gallery moved to core.
If WooCommerce Catalog Management work is eating your dev hours, I can take it off your plate. I’ve been working with WordPress since the 4.x days.
Try it now
The rebuild sits behind a feature flag in the WooCommerce nightly builds. It’s the stage where breaking things is cheap. If you run an agency or maintain an extension, look at it now. WooCommerce Catalog Management is going to work differently, and getting ahead of the API changes is the easiest way to avoid a painful migration next year.
