The WooCommerce Product Block Editor
The new product editing screen replaces the metabox layout with a block-based, tabbed interface. It is faster to work in and it drops third-party metaboxes, which is the whole decision in one sentence.
What actually changed: product editing moved from one long page of metaboxes to a tabbed, block-based form — General, Pricing, Inventory, Shipping, Variations — built on the same block infrastructure as the post editor. The data model did not change. A product is still a product post with the same meta and the same taxonomies.
That last point matters more than any screenshot. Switching editors does not convert your catalogue, so the risk is entirely about which fields you can see, not about what is stored.
What it is and is not
It is not the block editor for pages. There is no free canvas, and it is not the block-based cart and checkout — that is a separate feature, covered in WooCommerce product blocks.
It is a structured form whose sections happen to be blocks, which is what lets extensions register fields into named slots instead of appending another metabox at the bottom of a very long screen.
| Classic editor | Block editor | |
|---|---|---|
| Layout | One page, stacked metaboxes | Tabs with grouped fields |
| Extension model | add_meta_box |
Registered blocks in defined slots |
| Third-party fields | Everything shows | Only migrated plugins show |
| Variations | Inside the product data box | Its own tab |
| Product types | All | Simple and variable; others fall back |
| Validation | On save | Inline, per field |
Why the tabbed layout helps
On a store with several extensions, the classic screen becomes a column of a dozen metaboxes in whatever order they registered themselves, with SEO fields, shipping fields and subscription settings interleaved by accident. Finding the stock field means scrolling past all of it.
The block editor groups by purpose, keeps the title and price in a fixed place, and validates as you type rather than on save. For anyone editing dozens of products a day that is a genuine time saving, and it makes the screen far less intimidating for a shop owner who did not build the site.
The compatibility problem
Here is the trade-off, stated plainly: the new editor does not render classic metaboxes. If a plugin has not been updated to register into the new editor, its fields are simply not on the screen.
The consequences are specific:
- Your SEO plugin's fields may be missing on products while appearing normally on posts.
- Custom field plugins that add product data through metaboxes show nothing.
- Extensions adding their own product tab in the classic product data panel may have no equivalent yet.
- Saving a product with hidden fields does not erase them. The values are not submitted, so they stay as they were. Switch back and they reappear.
That last point makes the switch reversible and low-risk to try. It does not make it safe to leave enabled while a field your store depends on is invisible to whoever edits products.
Enable or disable it
The toggle lives in WooCommerce → Settings → Advanced → Features, as an option for the new product editor. Turn it on there and the product screens change for everyone in the admin.
Individual products usually offer a link back to the classic editor for that product, which is the practical escape hatch when one item needs a field the new screen does not show.
If you are automating configuration, the underlying option can be flipped with WP-CLI:
wp option get woocommerce_feature_product_block_editor_enabled
wp option set woocommerce_feature_product_block_editor_enabled no
Check the current option name against your WooCommerce version rather than trusting any tutorial, including this one — feature flags get renamed between releases.
Product types it does not cover
Support has grown release by release, but it has never covered everything at once. Simple and variable products are the well-supported path. Grouped and external products, and anything a plugin defines — subscriptions, bookings, memberships — either fall back to the classic screen or lose their type-specific fields.
If a meaningful share of your catalogue is a plugin-defined type, the block editor is not ready for your store yet, whatever it does for the simple products. How variations behave in the new tab is worth checking specifically against your workflow — the underlying model is unchanged from adding product variations in WooCommerce.
Test the switch properly
Do this on a staging copy, not on the live store, and give it fifteen minutes:
- Enable the feature.
- Open your most complicated product — most variations, most extension data.
- List every field that is missing compared with the classic screen. That list is your decision.
- Edit something trivial, such as the description, and save.
- Switch back to the classic editor and confirm every hidden field still holds its old value.
- Check a product created entirely in the new editor appears correctly on the front end: price, stock, images, attributes, variations.
- Have whoever edits products daily try it before you decide for them.
If anything looks wrong on the front end rather than in the admin, it is worth confirming the products themselves are queryable — WooCommerce products not showing covers that separately.
Who should switch now
- A simple catalogue with few extensions → switch. The editing experience is better and there is little to lose.
- A store with several product-data extensions → wait until each one advertises support, and re-test after each major WooCommerce release.
- Non-technical staff editing products daily → strong argument for switching, once the field audit comes back clean.
- Heavy use of custom fields through a metabox plugin → stay on the classic editor until that plugin migrates.
Recheck after every major WooCommerce update, and keep the setting in mind when a shop manager reports that a field "disappeared". That is the first thing to ask about, and it is a two-second fix once you know where the toggle is — the general update discipline is in how to update WordPress plugins safely.
Frequently asked
- No. It reuses the block infrastructure but it is a structured product form, not a free canvas. You are filling in fields laid out as blocks, not composing a page.
- Only if the plugin has been updated for the new editor. Classic metaboxes are not rendered, so fields from an unmigrated plugin are invisible — the stored data is untouched and returns if you switch back.
- Yes. It is a toggle in WooCommerce settings, and on individual products there is usually a link to open the classic screen. Product data is stored the same way either way, so switching does not convert anything.