Introducing a brand-new product creation experience powered by Blocks

While the WC Core product management experience has served our user base well over the past few years, customer expectations are constantly evolving, and our product must evolve along with them. Users now demand an effortless and intuitive experience similar to the tools they use in their everyday lives. In addressing this demand, WooCommerce is balancing the needs of those who prioritize a simplified experience with those who prize our industry-leading flexibility.

In response to these challenges, we embarked on a journey to redefine the product creation experience. Our goal is to empower users with a new experience that makes them feel in control, helping them seamlessly navigate between the two sides of the spectrum: from creating a basic product to a product requiring multiple options and additional customization. It should feel like a superpower.

After going through a few proofs of concepts, we have landed on an experience that is implemented using Block APIs. In this blog post I will go over some of the main points: the design, the form, and how to extend it.

The design

The new experience is split up into tabs and sections, which makes it easier to find specific product details. It doesn’t matter if they’re added by WooCommerce or a third-party extension

Thanks to logically arranged tabs, all fields and settings live in one place. For example, under Pricing, users will find list price, sale price, tax settings, and fields added by plugins like Price by Quantity or Name Your Price.

This structure helps the form grow together with the store. No matter how many plugins are installed, all of them have a relevant space on the screen. Our goal was to reduce user confusion, improve feature discoverability, and create a scaffolding for greater flexibility.

The new experience is more than just the form. It comes with the full Block editor that merchants can use to create compelling product descriptions. The descriptions can be pure text or contain multiple videos and blocks.

The Form

As mentioned in the introduction, we have built the new form using the Blocks API. This allows us to leverage the power of blocks, templates, and patterns to make laying out the form simple and also easy to extend (more on that below).

When using the new experience, you will quickly realize it doesn’t feel like a Blocks editor, but more like a normal form. We have made several modifications to disable/change some of the default block behavior to align with the product creation needs. Each field and section that you see is still its own block, or a block with nested blocks.

For example: As seen in the first screenshot, we were able to make use of the existing Columns block in order to split the pricing fields into two columns.

Extending the Form

Extending the form will look and feel very similar to extending the Block editor; you can do so by creating a new block and modifying the editor template to include the newly created block. You can also re-use existing blocks provided by WooCommerce, such as the Tab and Section blocks. We’re also exploring providing support for reusable field blocks, such as a text field or type-ahead field. If you are not already familiar with extending the block editor, you can follow this ‘create a block’ tutorial to learn more.

While for the most part, extending and registering blocks for the product editor is the same as the block and site editors on WordPress, there are currently two key differences to keep in mind for blocks in this context.

First, the block has to make use of the entity data store via `useEntityProp` instead of relying on the `save` callback. This is because a product is an object of keys and values and not a linear piece of content like posts or pages. Using the entity data store within the `edit` render method will correctly modify the product object and without it, the block won’t change the product.

const [ newProductProperty, setNewProductProperty ] = useEntityProp( 

Secondly, the form is rendered using a predefined editor block template, meaning the user can’t add additional fields on the fly as in the block or site editors. In order to add new fields, a plugin can modify the template by the use of hooks and some helper functions. The API for this is very manual at the moment (as shown in the example below), as a plugin will have to inject their own block somewhere within the template stack. We will be exploring ways to simplify this, and suggestions are welcome.

// find the 'Basic details' section and add our block to the end of it.
foreach ( $template as $tab_index => $tab ) {

  $tab_properties = $tab[1];

  if ( 'general' === $tab_properties['id'] ) {
    $tab_sections = $tab[2];
    foreach ( $tab_sections as $section_index => $section ) {

      $section_properties = $section[1];

      if ( 'Basic details' === $section_properties['title'] ) {

        $section_fields = $section[2];
        // add our block to the end of the section
        $section_fields[] = [

        // update the template with our new block
        $args[ 'template' ][ $tab_index ][2][ $section_index ][2] = $section_fields;

Using templates to lay out the form does give us a lot of flexibility and will allow plugins to create their own customized templates for specific product types.

Trying it out

With the release of WooCommerce 7.8 we have added a New product editor feature flag under WooCommerce > Settings > Advanced > Features. Once you enable this, you can go to Products > Add New and view the new editor.

Keep in mind, this new editor only supports simple products for now, and you will be redirected to the existing editor if you’re editing unsupported product types. Support for other product types is coming, starting with variable product support being added next.

If you want to start experimenting with extending the editor, you can start with this product block example. However, as mentioned above, the API for this is still in flux, so the way blocks are injected into the editor is likely to change.

Next steps

Our next step is to continue to build out the core features to reach parity with the existing experience. One of the initial items is adding support for variations and other product types.

We also plan on updating our documentation, provide concrete examples, and migrate a couple of our Woo-owned extensions to test extensibility.
We will continue the communication as these updates occur. 

In the meantime, we are keen for you to start using and extending the new editor. If you have any questions or suggestions, please use Github Discussions under the “WooCommerce Product Block Editor” category. 

We are excited about this first big step of improving the experience of managing products and aligning with the direction of WordPress! We hope you are too!

13 responses to “Introducing a brand-new product creation experience powered by Blocks”

  1. Thanks for the (huge) work, i was reading the current status of this through the RoadMap this morning, and now the dedicated article comes. Keep it up !

  2. Thanks for the heads up. I’ve been trying to avoid blocks altogether, because I find them too complicated to implement and maintain, but I guess that I will have to look into this eventually.

    If it can help you planning the documentation, in my case I will have to do the following:
    1. Add extra fields on the edit product page. They refer to pricing, in my specific case.
    2. Populate the extra fields from #1 with the data from the product.
    3. Update the product with the custom data when the user saves the changes.
    4. Show or hide the fields depending on the product type or other criteria.
    5. Keep full compatibility with the classic editor for the time being.

    Points #1 to #4 of the above are already implemented and work perfectly with the classic editor. In fact, the integration working fine for a decade. I really hope that I won’t have to write hundreds of lines of code (PHP, JS, Webpack, scripts), like I had to do for the Analytics, to re-implement the same integration. 😅

    1. Lourens Schep Avatar
      Lourens Schep

      Hi Diego, thanks for the example use case, we will certainly keep this in mind as we work on our documentation.
      We plan on creating several follow up blog posts over the coming months with more detailed examples.
      Also as mentioned in the blog post above, we are looking into creating some generic blocks for easy re-use by plugins. This would help alleviate having to write custom blocks yourself, and would be mostly configurable by PHP.

    2. Considering how muchi “pioneering” I’ve done in WooCommerce, I would have to disagree with that. However, my area of focus is not the UI, but the backend, therefore I don’t need to do frontend development that much.

      1. No hard fillings Diego, it was a joke, i am really impressed of amount of your useful plugins

        1. Worry not, I didn’t take it as an insult. 😄

  3. Very good idea! Add a dynamic Custom fields in other tab will be great!

    Also, what i dream about and implemented manually already in a few websites (using ajax), is to save only current edited value (if this is possible) like for example when i click save on Current Custom field tab it save just this meta, not whole post object.

  4. Is there a full, working example yet for extending the editor with some custom fields? Diego hinted at this, but is there a pre-existing way to handle hide/show of certain areas. For example, if Name Your Price mode is enabled for a simple product then I will need to hide the default pricing fields and show much own (for suggested and minimum price fields).

    1. I did more than just hinting. 😄
      I must show a ton of other settings myself, as 70% of my plugins extend product properties, and I must be able to do that seamlessly. This is why I highlighted that I wasn’t a fan of the “10X more code to do the same thing” that I had to write for the reports. Some people don’t believe, but I’m not making it up.

      My request, and expectation, would be that the core is designed with integrations in mind and provide an EASY way to do what other developers have been doing until now, WITHOUT having to “jump through hoops”.

      It’s a known fact that I don’t like JavaScript as a language. I like it even less when the scripts are “packed, compiled and bolted shut”, because that prevents anyone from figuring out how to extend them. There are no simple actions and filters to inject, alter, or remove logic and/or content. One must follow a specific procedure, use specific tools, often in specific versions, and compile the code in a specific way. Trial and error, which could suffice with the “old” architecture, is not viable in these conditions, hence the absolute need for a SIMPLE architecture, with clear and complete documentation.

    2. Lourens Schep Avatar
      Lourens Schep

      We don’t have a full working example yet, this is next on our priority list as we migrate some internal plugins and see what limitations we may run into.

      We are also aware of the scenario you mentioned above, and will keep that in mind as we publish examples.

      1. Looking forward to the example as I would say right now it doesn’t look extensible at all. And to echo Diego again, I would also love to see this approached with an eye towards compatibility/extensibility.

  5. I really hope there’s going to be an option to opt out of this so that we can continue using the non-block based interface. Also, It obviously goes without saying, that it needs to be 100% compatible with all the existing hooks and functions for adding fields within the editor interface.

  6. sian500 Avatar

    I’m also hoping we can opt-out until all 3rd party devs and page builders have caught up. I work with Divi and a bunch of premium 3rd party plugins to extend Woocommerce. This type of major change scares me! Sounds great on any brand new build but for all my current clients who’s sites run shops with custom fields, date pickers etc. this could create a ton of work for me that my clients may not want to pay for!

Leave a Reply

Your email address will not be published. Required fields are marked *