For over a decade, WooCommerce Catalog Management has been the “messy drawer” of the platform. If you’ve spent any time managing a store with more than a hundred products, you know the pain: the “All Products” screen feels like a relic. It’s slow, it lacks deep filtering, and managing variations feels like navigating a maze. Consequently, the community has filled this gap with over 50 extensions just to handle basic bulk editing.
But things are finally shifting. During Automattic’s Radical Speed Month, a new proof of concept (POC) dropped that aims to rebuild the entire WooCommerce Catalog Management experience natively. This isn’t just a UI facelift; it’s a fundamental architectural shift leveraging WordPress core’s DataViews and DataForms primitives.
The Architect’s Critique: Why Core is Reclaiming This Space
When an ecosystem relies on 50+ plugins to fix a single screen, it’s a sign that core isn’t doing its job. We’ve seen this before with the legacy block editor and early variation management. Specifically, the gap between merchant expectations and the native “All Products” screen has become a bottleneck for store owners trying to scale. Furthermore, the previous approach required too many page reloads, which is why technical debt usually starts piling up right at the catalog level.
The new POC lands three major shifts:
- Native DataViews Table: A completely customizable list with built-in sorting and filtering that doesn’t need an extra plugin to be functional.
- Hierarchical Variation Rows: Parent products now expand inline. You can finally see and edit child variations without the “click-wait-edit-back” cycle.
- Core Modal Workflows: Quick edit and bulk edit are being moved into the native modal pattern, making the experience feel integrated rather than “bolted on.”
Technical Breakdown: DataViews and Extensibility
The use of @wordpress/dataviews is a smart move. It allows the WooCommerce Catalog Management screen to stay agnostic of where the data comes from—whether it’s the REST API or an internal store. However, from a developer’s perspective, the “next step” is the one that matters: the API surface. For this to truly succeed, it needs stable Hooks and Filters that third-party extensions can actually use.
If you’re looking to dive into how these components work, the official DataViews documentation is your best starting point. Below is a conceptual example of how a field might be defined in this new environment:
{
id: 'price',
label: 'Price',
render: ( { item } ) => <ProductPrice value={ item.price } />,
elements: [
{
type: 'filter',
operators: [ 'is', 'isNot', 'greaterThan' ],
},
],
}The Bottleneck: Performance at Scale
I’ve seen plenty of “shiny” UI updates break down the moment they hit a database with 10,000 SKUs. The current POC is honest about this: performance at scale isn’t there yet. Rendering thousands of rows in a React-based table often leads to “race conditions” during selection or laggy scroll behavior. Therefore, the interaction layer needs a serious refactor before this hits production. We already saw similar challenges when the variation gallery was moved to core.
Look, if this WooCommerce Catalog Management stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway: Try it Now
This rebuild is currently behind a feature flag in the WooCommerce nightly builds. It’s a “break it now so we don’t fix it later” situation. If you’re an agency or an extension author, you need to get your eyes on this today. The way we handle WooCommerce Catalog Management is about to change forever, and getting ahead of the API shift is the only way to avoid a migration nightmare next year.
“},excerpt:{raw:
