Announcing the Product Collection Block

karolmanijak Avatar
karolmanijak

•

We are excited to announce a significant update to our product grid system. We are beginning the process of shifting toward making the Product Collection Block the new default product grid block. This change is part of our commitment to continuously improve our platform and provide merchants with the best possible tools to manage their stores. 

We will not be immediately deprecating the legacy product blocks, and these will continue to be supported in stores that are already using them. However, we encourage you to learn about the new Product Collection Blocks and what they can offer.

What Does This Mean for You?

The Product Collection Block will replace several of our existing product grid blocks, including:

What happens if I’m using the existing product grid blocks?

If a store already has existing product grid blocks in use, you may continue using those. However, when setting up a new product grid, you will now see the Product Collection Block instead of the Product Grid blocks in the inserter.

Before:

Several blocks offering overlapping features and different interfaces		After
The Product Collection block along with more specific collections, under one unified interface.

Additionally, all the collections will be available when inserting Product Collection block:

Why the Change?

The Product Collection Block is designed to cover and even exceed the use cases of all the above-mentioned blocks. It offers enhanced navigation, responsiveness, granular control over the overall layout, and more robust filtering options. Plus, it uses server-side rendering, ensuring no blinking or content jumps when loading the page on the frontend.

However, we acknowledge that there might be a couple of features missing from the current Product Collection Block, such as the “Show Sorting Dropdown” option in the All Products block and the lack of frontend reloading when using current frontend filters. We are working on addressing these issues with the introduction of Collection Filters blocks.

Benefits of moving to the Product Collection Blocks

Performance Enhancement: The Product Collection block improves performance by enabling enhanced navigation and pagination without requiring a full page reload. This exception applies unless third-party blocks are used as inner blocks. Additionally, the block is responsive, meaning it adjusts dynamically to accommodate different screen sizes.

Flexible Configuration: The block provides greater control over the overall layout, allowing merchants to define products per page, set the number of pages, include or exclude pagination, “No results” content, and choose between List/Grid layouts.

Advanced Filtering Options: The Product Collection block allows merchants to apply a variety of filters to determine which products are displayed, including Price Range, Categories, Tags, Product Attributes, Handpicked Products, On Sale, Featured, Keywords, Stock Status, and Created Date. Moreover, ordering options are also available.

Control Over Inner Blocks: Merchants have more control over the Product Template layout and inner blocks. They can edit the layout in the Editor using blocks, rather than controls in Inspector Controls.

Active Development and Support: The Product Collection block is actively supported and developed, meaning it benefits from regular bug fixes and feature updates.

Extending the Product Collection Block

We are building this feature out with the expectation that third party developers leverage its extensibility and build out unique solutions to solve for a spectrum of use cases in the e-commerce world.

Frontend Hooks support

There’s a Compatibility Layer available on the frontend for archive templates to extend. Compatibility Layer applies the same filters to Product Collection block as to Products (Beta):

In addition to the above, Product Collection uses the same inner blocks to build a product template (e.g. Product Price or Product Title). Nothing changes in terms of the extensibility of those elements.

Plans

The Product Collection Block is designed to be extensible, and we plan to give third-party developers the opportunity to register custom collections and filters. This will open up a world of possibilities for customization and enhancement, making the block even more powerful and adaptable to your specific needs.

Feedback

We’re looking forward to your feedback!

5 responses to “Announcing the Product Collection Block”

  1. 99w Avatar
    99w

    For the old blocks other than All Products, there was the ‘woocommerce_blocks_product_grid_item_html’ hook which could be used to filter the block output and allow developers to modify the display, we used it to ensure plugins we’d created that display stuff via ‘woocommerce_after_shop_loop_item’ still did the same when using those blocks, like products by category.

    With the ‘compatibility layer’ is the above no longer needed? From my understanding of that it seems like just the original woocommerce_after_shop_loop_item would be needed and not anything via woocommerce_blocks_product_grid_item_html? Is that correct?

    Also: “The Compatibility Layer disables when the WooCommerce Single Product, WooCommerce Product Attribute, WooCommerce Product Taxonomy, WooCommerce Product Tag, WooCommerce Product Search Results or WooCommerce Product Grid block is added on the page.”

    Why is this? Let’s say you’ve got some custom stuff displaying via woocommerce_after_shop_loop_item, a user adds a single product block to the page, then adds the new products by category collection block below or is somewhere else on the page, from the information above it seems like the custom stuff displayed via woocommerce_after_shop_loop_item wouldn’t be there in that block as there is a single product block on the page, why does it disable in this scenario?

    Reply
    1. karolmanijak Avatar
      karolmanijak

      > For the old blocks other than All Products, there was the ‘woocommerce_blocks_product_grid_item_html’ hook which could be used to filter the block output and allow developers to modify the display, we used it to ensure plugins we’d created that display stuff via ‘woocommerce_after_shop_loop_item’ still did the same when using those blocks, like products by category.
      > With the ‘compatibility layer’ is the above no longer needed? From my understanding of that it seems like just the original woocommerce_after_shop_loop_item would be needed and not anything via woocommerce_blocks_product_grid_item_html? Is that correct?

      Blocks like “Products by Category” and others based on AbstractProductGrid (https://github.com/woocommerce/woocommerce/blob/trunk/plugins/woocommerce/src/Blocks/BlockTypes/AbstractProductGrid.php) supported `woocommerce_blocks_product_grid_item_html` as they offered limited Editor flexibility. Filter allowed for output modifications. Product Collection is pretty flexible and we hope one can achieve the expected outcome based on Editor experience and Gutenberg features.
      If, for some reason, that isn’t the case, you can still use the `render_block` hook, which should allow to filter the HTML of the block. But we strongly advise approaching extensibility with the new Gutenberg APIs.

      > we used it (`woocommerce_blocks_product_grid_item_html`) to ensure plugins we’d created that display stuff via ‘woocommerce_after_shop_loop_item’ still did the same when using those blocks, like products by category.

      I think your case is a bit different but I’m not sure I understand it correctly. Can you provide more details about that use case?

      > Also: “The Compatibility Layer disables when the WooCommerce Single Product, WooCommerce Product Attribute, WooCommerce Product Taxonomy, WooCommerce Product Tag, WooCommerce Product Search Results or WooCommerce Product Grid block is added on the page.”
      > Why is this? Let’s say you’ve got some custom stuff displaying via woocommerce_after_shop_loop_item, a user adds a single product block to the page, then adds the new products by category collection block below or is somewhere else on the page, from the information above it seems like the custom stuff displayed via woocommerce_after_shop_loop_item wouldn’t be there in that block as there is a single product block on the page, why does it disable in this scenario?

      Great question! I think I know where the confusion may come from. We need to distinguish “Single Product” block from “WooCommerce Single Product”.
      – Single Product – this is pretty new block, it will work just fine with Compatibility Layer and the scenario you described can be achieved.
      – WooCommerce Single Product – this is a block that represents a classic template. This and other classic templates (others starting with “WooCommerce…”), along with Compatibility Layer leads to unexpected results and conflicts, hence we disable the Layer. We recommend transforming classic templates to blockified versions of these.

      I’m updating the Compatibility Layer documentation in this PR to avoid such confusion: https://github.com/woocommerce/woocommerce/pull/44924.

      Let me know if that answers your question!

      Reply
  2. Kathy Avatar
    Kathy

    Are the innerblocks going to be available for import into 3rd party plugins? For example, mix and match products shows a list of products which could sorta be considered a product collection. In a new feature I was working on, i ended up having to render all the products via React, but had to create my own components for re-usable things like product title, description, image, quantity input, etc. It would be handy to be able to import those from Woo.

    Reply
    1. karolmanijak Avatar
      karolmanijak

      We should distinguish React components from Blocks.

      There’s @woocommerce/blocks-components that exports some of the React components which can be used as part of the custom blocks (list of them is available in Storybook: https://woocommerce.github.io/woocommerce-blocks/?path=/docs/external-components-button–docs)

      But there are also Blocks that can be reused but in a different way. WooCommerce, while installed, registers set of blocks and they can be referenced in other blocks (including 3rd party). The same goes for Gutenberg’s blocks in general and here’s a good reference explaining that concept: https://developer.wordpress.org/block-editor/how-to-guides/block-tutorial/nested-blocks-inner-blocks/.

      Depending on specific of your use case, the idea we have on how to make Product Collection extendible could be helpful. As our plan is to enable registering custom product collections. Products (set would depend on provided query) would be displayed via Product Collection block with 3rd party developer specific the Product Template with all the Product Elements available.

      Reply
      1. Kathy Avatar
        Kathy

        That’s a good distinction and I’m not sure I was entirely making it. To start, I refactored my display to be entirely a react app… this was my first React app and I just made a first block last week sooo.. let’s say I am late to the transition. 🙂 So thanks for the explanation.

        But now that y’all posted an article about dynamically/frontend rendering blocks (https://developer.woocommerce.com/2021/11/15/how-does-woocommerce-blocks-render-interactive-blocks-in-the-frontend/) I know that’s actually possible and it perhaps opens up using a block template in my case. Mix and Match has always shown a group of products so that seems like it *could* be a Product Collection in a way.

        Reply

Leave a Reply

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

Related Posts