FAQ: Blocks use custom markup instead of WooCommerce templates / lack of filters

mikejolley commented 5 years ago

Blocks 2.2 introduced new markup for the 'product grid' blocks that is independent of the template files in WooCommerce core.

I've created this issue to summarize the problem and direct reports to a single location to avoid repetition and to keep conversations in one place.

Why?

Blocks need to be consistently rendered in the editor and on the frontend using the same markup and CSS classnames. Using templates removes the ability for Blocks to control this.
Importing templates from core also imports any pre-existing styling. This causes conflicts and prevents Blocks from effectively implementing its own styles, for example, using CSS grids instead of floats.
Templates are evolving. With new blocks come new default designs which may require markup changes. Importing templates would prevent this.

What should themes do to customize blocks? Themes cannot control markup reliably at this point, but themes can style the new blocks using the updated CSS classnames.

So, for example, products in grids use the following CSS classnames:

ul.wc-block-grid__products
li.wc-block-grid__product
.wc-block-grid__product-link
.wc-block-grid__product-image
.wc-block-grid__product-title
.wc-block-grid__product-rating
.wc-block-grid__product-price
.wc-block-grid__product-onsale
.wc-block-grid__product-add-to-cart

Layout and choosing what content gets displayed is left to the user via the block options.

Why doesn't the block markup match shortcodes? Remaking shortcodes as blocks would be underutilizing what is available to use in blocks. With blocks we can add more customization options for users, and redesign how content should appear. Blocks are a new thing and should not be compared to existing shortcodes.

Can I still use shortcodes? Yes, shortcodes still exist in WooCommerce and are still a viable alternative to the blocks, particularly if you need to customise the output. They are documented here.

There is a 'shortcodes' block in Gutenberg if you wish to insert them into the new editor.

Is this a bug? No, the bug was that the editor did not match the content rendered on the frontend, something fundamental to Gutenberg. Controlling the markup in blocks resolves this.

Will markup be filterable? We are discussing whether or not hooks should be introduced short term or left until long term, since some of the blocks being built may be in flux for example rendering may be changed from PHP to JavaScript exclusively in the future.

2 experimental PRs exist which may or may not be merged, but you may add feedback to those or this issue.

A basic filter does exist (woocommerce_blocks_product_grid_item_html) but it lacks usefulness and context and may be dropped. Ref https://github.com/woocommerce/woocommerce-gutenberg-products-block/issues/724 and https://github.com/woocommerce/woocommerce-gutenberg-products-block/issues/845

ValentinGenev commented 5 years ago

Good day, @mikejolley , I'm fairly new to theme development and I would be very thankful if you give me and the other newbies like me a quick tip on how to use thewoocommerce_blocks_product_grid_item_html hook (if you have the spare time, ofcourse).

mikejolley commented 5 years ago

@ValentinGenev It's looking unlikely that this filter will exist once this issue is taken care of; one of the things we are looking at is moving all rendering to React and avoiding PHP completely.

Perhaps you can explain what type of customisations you want to make so we can consider this going forward. Thanks

ValentinGenev commented 5 years ago

@mikejolley, thank you for your fast response!

My main issue at this point (after 3.7.0) is that my content-product.php template is drastically different than the output I'm getting after using your blocks.

EDIT: Removed the long gibberish.

mikejolley commented 5 years ago

Yes the markup is different to the templates. What we'd like to understand is what changes you'd want to make to the markup? What is there is semantic, and styleable, so understanding what you're doing would be helpful.

ValentinGenev commented 5 years ago

I played around with woocommerce_blocks_product_grid_item_html yesterday and I managed to change the output markup (this is a quick look of the hacky way I managed to achieve the change).

Here are my two cents on the matter. The WooCommerce Product Blocks plugin is developing and taking direction towards React which is great, but:

the blocks implementation is duplicated to the core WooCommerce plugin, and a breaking change like the one we're discussing was not a part of the WooCommerce change log for the version that introduced it. I had to find out that the blocks aren't rendering as expected at a meeting with the client since I don't follow WooCommerce Product Blocks' development;
as I said moving away from PHP is fine by me, but dumping hooks like woocommerce_blocks_product_grid_item_html I don't agree with. At this point, using it might not be the finest way to solve my issue, but it doesn't contradict your first arguments either. Here's a quick look of the results and the consistency between the editor and the front-end;
after a theme developer has worked on most of the core templates, it's very intuitive to have the block render as the product list from the archive pages. Your change creates inconsistency in the way a product item looks and functions in different pages of one site which, in my opinion, is way worse then having some differences in the rendering between the editor and the front-end. Having them by default might raise question as "why something looks/functions different" and not having an easy way to deal with it, for me, is a major issue.

My final thoughts are: since you probably wouldn't take back the changes to the core plugin and separate it with the block plugin, I'm suggesting to make the use of the php templates an option (if possible) or keep the hook alive.

I'm sorry for the long post; if something reads negatively, please know that I'm just a bit concern and not trying to be rude.

jespervnielsen commented 5 years ago

I think it can be a good idea to make a new "component" centered product list items, witch should encourage to use a BEM like structure. that way plugin/theme developers can make their css/js for the block extension also load in the admin area.

Theme and plugin developers should be able to add/remove items from the products lists, like we can now. it just a matter of introducing enough hooks'n filters. But my thought is, it also should be possible to extend the block settings.

lets say i have a plugin that creates some simple meta output on the products lists. i want the author of the page, who inserts the block, also to decide whether or not my meta should be output in the product list. just like they can with product list titles, ect. and it should feel smooth, like it a part of the settings for the block.

i would then suggest making "block wrappers" for the shortcodes. and instead of showing the frontend in the admin, then just show some sort of graphic (image) to represent that there is a product lists. it can be done by using dynamic blocks, but where they are decoupled, so that it still only shows the js markup in backend, but is dynamic in the frontend. that would ofcourse create som extra maintance on your side, but it is only the layer between the shortcode and the block editor.

PoeHaH commented 4 years ago

@mikejolley You've asked for examples on why we need filters in blocks so I'll chime in:

A popular WooCommerce plugin is "quick view", which adds a button underneath each product's "add to cart" button. When the button is clicked, a popup appears with product information.

In PHP, it's easy to add this button by using the woocommerce_after_shop_loop_item action.

Currently, there is no way to add this button to the WooCommerce blocks.

I suspect many other plugins are changing the loop items so they are currently unsupported by the Woo blocks.

mikejolley commented 4 years ago

Currently, there is no way to add this button to the WooCommerce blocks.

JavaScript? The popup will need JS anyway. I assume the data would need to be read in a different way rather than spewed into the markup with PHP, but it doesn't seem like an impossible task, just one which isn't compatible with the current method.

PoeHaH commented 4 years ago

@mikejolley The problem isn't with the popup. That's indeed just custom JS. The problem is adding the "quick view" button underneath each product in the Gutenberg block (screenshot: https://i.snipboard.io/NFK7fx.jpg).

Right now, I can do it by using the woocommerce_blocks_product_grid_item_html filter, but I recall reading this filter may not be present in future updates. So I'm just giving you an example where it's crucial that we can edit the output in the Woo block. Whether or not that's via a frontend or backend hook, doesn't matter much I think.

strarsis commented 4 years ago

The woocommerce_blocks_product_grid_item_html filter is very helpful!

function _wc_get_template_part_str($template_name, $part_name=null) {
    ob_start();
    wc_get_template_part($template_name, $part_name);
    $var = ob_get_contents();
    ob_end_clean();
    return $var;
}

function woo_block_product_grid_item_html($html, $block_attr, $_product) {
    global $product, $post;

    $is_woo_block_product_grid_item = true;
    $orig_product = $product;
    $orig_post    = $post;

    $product = $_product;
    $post    = get_post(  $_product->get_id()  );
    $html    = _wc_get_template_part_str( 'content', 'product' );
    $product = $orig_product;
    $post    = $orig_post;

    return $html;
}
add_filter( 'woocommerce_blocks_product_grid_item_html', __NAMESPACE__ . '\\woo_block_product_grid_item_html', 10, 3);

The filter handler above makes the block use the original WooCommerce template, the list element isn't filtered though, styles may have to be adjusted.

One crucial thing that is missing is the block context itself for the filter handler, so it can render different html for different block settings, notably what block style it is for a different template.

Also this block uses the woocommerce_product_query_meta_query and woocommerce_get_catalog_ordering_args filters for the query, hence just using the woocommerce_product_query action doesn't seem to be usable for changing the query.

LauraLeeLee commented 4 years ago

Hello, I'm looking to add product description to the woocommerce blocks-- the blocks provide a cleaner, simpler layout for my needs. I've been inspecting the AbstractProductGrid.php file, (I know I'd need to copy this file to my child theme to edit/add to).
I'm uncertain as to which hooks/filters I need to use-- wordpress or woocommerce-- to grab the product descriptions for each of the products, as well as hook to use to add that info fo the block to render.

I'm figuring I'll need to create a protected function for the product description creating the html needed to render the information.

Any guidance would be appreciated. Thank you. Lee

strarsis commented 4 years ago

@LauraLeeLee: A little bit hacky but quick possibility would be using the woocommerce_blocks_product_grid_item_html filter and append the HTML for description using some parsing/regexp. That filter also receives the instance of the product to be rendered, so you can use that to retrieve the description.

LauraLeeLee commented 4 years ago

starsis thank you. To grab the product description entered in the woocommerce area of the wp dashboard, would I use get_post_meta()? If yes, where do i find the list of keys that woocommerce is using to hold that data? I'm having difficulty finding that information online.

Thank you

strarsis commented 4 years ago

@LauraLeeLee: The product instance passed to the filter got a method for retrieving the description: https://docs.woocommerce.com/wc-apidocs/source-class-WC_Product.html#228-237

smarques commented 4 years ago

@strarsis I think you need to set the $post variable to global (not just $product) in function woo_block_product_grid_item_html in your example here

Thanks for the useful code.

LuigiPulcini commented 4 years ago

As @mikejolley has already pointed out in his original post, the current filter is not ideal as it could create conflicts between plugins that are trying to customize the template markup. In my plugin, for example, my approach was to copy the original markup and include it in the filter, with the adjustments I required for my purposes. The problem with this approach is that, if every plugin uses the same strategy, completely replacing the markup every time the filter is used, only the latest plugin loaded returns the actual markup, obliterating any previous customization.

All that being said, my plugin, like your DynamicBlock, uses the ServerSideRender component because I need my customers to be able to use PHP skins to customize the plugin output. For that reason, if I want to customize the WooCommerce blocks I can only resort to a PHP filter. Ideally, adding actions the way it is done in the regular WooCommerce templates would replicate what I am already doing there. But I wonder what the best approach is right now.

Any input or feedback would be greatly appreciated.

gaelgerard commented 4 years ago

I think Gutenberg blocks are really handfull for post writers. Most of them are appreciating to get a similar view between back and front end.

However, as a theme developper I wonder why WooCommerce blocks aren't using the same filters and action hooks as the core WooCommerce products.

For example, I had to show the Add to cart button on Shop page for Variation products and got 2 major issues:

1- The custom hooks and filter I added to my child theme functions file worked as wanted on default shop and product category pages but not on WC Gut Blocks. The pages where I added Product list blocks don't display the Add to cart button as on the other category pages.

2- After a few search to replicate the functions for WC Gut Block (double work = 3rd issue :/) I faced another major issue with a Fatal Error $product->is_type( 'variable' ) function not recognized!

As said, as a theme developper, I often have to customise the rendering of WooCommerce products (adding custom fields on products for example) and at this point I can't use WC Gutenberg Blocks because they are not efficient for me.

I agree it is good to be able to customize it on backend the Gutenberg way but the blocks should display the Whole WooCommerce product Data to be really efficient.

For now I will keep using Short codes as suggested by @mikejolley in the first post of this thread and waiting/hoping that Woocommerce Gutenberg Blocks will stick to Woocommerce core Datas one day.

iverok commented 4 years ago

About the status of this from the perspective of third-party developers:

It seems that for "All products" the current (aug 2020) way to modify/add stuff is the registerBlockComponent interface (so basically the example plugin at https://github.com/Aljullu/woocommerce-blocks-extension/tree/inner-blocks-extension, but with registerInnerBlock replaced with registerBlockComponent). Is this correct at this time? It does work.

Also, for the "old" blocks like "New products", I take it it still is the php 'woocommerce_blocks_product_grid_item_html' filter, but with care since everybody are going to use this same filter; and with the expectation that this pattern will be superseded by the All Products pattern or something like it?

However, for the first case; to correctly add my inner block, I need to add information to the product model available in the front-end. It seems that there is still no way to add to the schema in the StoreAPI - is this correct? If so, how are we to add the neccessary metainformation to a list of "all products"?

If you could for instance provide a filter at Automattic\WooCommerce\Blocks\StoreApi\Schemas\ProductSchema\ProductSchema::get_item_response then augmenting the product model would be trivial, and then inner blocks would have all the data they need. Eg,

public function get_item_response( $product ) {
                return apply_filters( 'woocommerce_store_api_product_item_response',
                   [
                        'id'                  => $product->get_id(),
                        'name'                => $this->prepare_html_response( $product->get_title() ),
                        'parent'              => $product->get_parent_id(),
                        'type'                => $product->get_type(),
                        'variation'           => $this->prepare_html_response( $product->is_type( 'variation' ) ? wc_get_formatted_variation( $product, true, true, false ) : '' ),
                        'permalink'           => $product->get_permalink(),
                        'sku'                 => $this->prepare_html_response( $product->get_sku() ),
                        'short_description'   => $this->prepare_html_response( wc_format_content( $product->get_short_description() ) ),
                        'description'         => $this->prepare_html_response( wc_format_content( $product->get_description() ) ),
                        'on_sale'             => $product->is_on_sale(),
                        'prices'              => (object) $this->prepare_product_price_response( $product ),
                        'price_html'          => $product->get_price_html(),
                        'average_rating'      => $product->get_average_rating(),
                        'review_count'        => $product->get_review_count(),
                        'images'              => $this->get_images( $product ),
                        'categories'          => $this->get_term_list( $product, 'product_cat' ),
                        'tags'                => $this->get_term_list( $product, 'product_tag' ),
                        'attributes'          => $this->get_attributes( $product ),
                        'variations'          => $this->get_variations( $product ),
                        'has_options'         => $product->has_options(),
                        'is_purchasable'      => $product->is_purchasable(),
                        'is_in_stock'         => $product->is_in_stock(),
                        'is_on_backorder'     => 'onbackorder' === $product->get_stock_status(),
                        'low_stock_remaining' => $this->get_low_stock_remaining( $product ),
                        'sold_individually'   => $product->is_sold_individually(),
                        'quantity_limit'      => $this->get_product_quantity_limit( $product ),
                        'add_to_cart'         => (object) $this->prepare_html_response(
                                [
                                        'text'        => $product->add_to_cart_text(),
                                        'description' => $product->add_to_cart_description(),
                                        'url'         => $product->add_to_cart_url(),
                                ]
                        ),
                ], $product);
        }

Any other suggestions welcome.

iverok commented 4 years ago

In the temporary absence of any other plan for this, the following hack will work for extensions to the All Products block using the store api:

add_action('woocommerce_loaded', function () {
        add_filter('woocommerce_product_get_description', function ($description, $product) {
                if (!did_action('rest_api_init')) return $description;
                if (!is_a($product,'WC_Product')) return $description;
                if (!product_can_be_frobnicated($product)) return $description;

               // Add empty span to signal that this product should be frobnicatable
                return $description . "<span class='_product_metadata' data-product-is-frobnicatable='1'></span>";
                },10,2);
        }
);

with this, the "description" field of the returned product will get an extra empty (and thus invisible) span with enough metadata to determine if a frobnicator element should be added to the product block. It should be easy to rewrite this to use any future solution.

2020-09-03: I'm going to use this as a temporary solution for the All Products block (and the old filter for the other products blocks) for the next version of the Vipps payment gateway plugin, which adds a "buy now"-button to the product listing for certain products. It seems to work well enough.

github-actions[bot] commented 3 years ago

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

Internal: After 10 days with no activity this issue will be automatically be closed.

strarsis commented 3 years ago

Not stale!

ninetyninew commented 3 years ago

We have a website with some custom WooCommerce functionality for a non-standard product type which uses woocommerce_loop_add_to_cart_link to conditionally change the add to cart button to a "Select options" button if the product must have options selected (as the add to cart would mean the product is added without selecting options without this).

Is the equivalent not possible at the moment with blocks? As if so we need to look at either removing these products from blocks or not using WooCommerce blocks throughout the website.

We've also noticed blocks have different styling to the traditional product display in templates - are there any plans to make these the same styling so not inconsistent as you browse through the different parts of the website.

iverok commented 3 years ago

Is the equivalent not possible at the moment with blocks? As if so we need to look at either removing these products from blocks or not using WooCommerce blocks throughout the website.

It is possible, though not convenient. There are currently two types of blocks; the "All products" block and the rest. For the rest, there is a HTML filter woocommerce_blocks_product_grid_item_html which allows you to rewrite the entire html for the block.

For the "All products block" you need to modify the core Woo hooks that provide information about the product, and then use javascript to rewrite the html when apropriate. In my example above, I add a "data"-attribute to the product description, but it is also possible to add a product attribute for instance, which may be cleaner. This block-type also allows you to add sub-blocks to configure it with, so it is more flexible. The modifications must however be done in javascript/react.

ninetyninew commented 3 years ago

@iverok Thanks for the information, so with woocommerce_blocks_product_grid_item_html I guess I could replace {$data->button} conditionally with my changed button in my scenario? That sounds like a way to get this working except for the All products block - which I can recommend is not used or figure out a way to disable it from use (as I know it can't be filtered so it has missing custom functionality)

I appreciate there are probably a number of technical reasons for the following but just a couple of thoughts on this issue/products blocks in general, not really looking for answers but just wanted to throw my thoughts down for future reference:

I find it really odd products in blocks don't use the same styling as non-block based products, so this means you have to add additional CSS for this and keeping block/non-product display consistent is more maintenance
Product blocks without using the non-block filters is very limiting for plugins/extensions/custom development. Example issues from this: customers may order products without all the information they need (e.g. if a plugin/extension adds warning text to the product display that the product is only for a specific use), customers ordering when they shouldn't (e.g. a plugin conditionally removes a product's add to cart button). Right now if a store owner is using the normal product pages from the templates and product blocks in some areas and they have any plugin which is using those filters they are going to have products displaying inconsistently and functionality potentially missing on the block based products

At this moment in time I don't see a way around this other than using the woocommerce_blocks_product_grid_item_html and recommending the All products block is not used or programmatically disable it - neither is ideal.

I think the work on product blocks so far is great but without the extensibility we mostly use WooCommerce for I was actually quite surprised when I uncovered these filters didn't work here.

Happy to add any further feedback that helps move this towards some form of solution.

iverok commented 3 years ago

@ninetyninew

customers ordering when they shouldn't (e.g. a plugin conditionally removes a product's add to cart button).

I don't have a comment on your other arguments which as you see in this issue have been brought up before, but the products "has_options", "is_purchasable" and other properties are mirrored in the javascript object representing the products; so that filters like 'woocommerce_product_has_options', 'woocommerce_is_purchasable' etc will work for some of these scenarios.

For adding elements to the "all products" block you will need to implement an "internal block" which can be added to the configuration. For arbitrary modificatons of the HTML you will probably need to do the same, so that the code will be triggered at the correct times when the page is redrawn. This must all be done in Javascript.

github-actions[bot] commented 3 years ago

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

Internal: After 10 days with no activity this issue will be automatically be closed.

ninetyninew commented 3 years ago

not stale

github-actions[bot] commented 3 years ago

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

Internal: After 10 days with no activity this issue will be automatically be closed.

gaelgerard commented 3 years ago

So, no chance the filters added from template files can be effective on gtb product blocks? This is quite annoying.

github-actions[bot] commented 2 years ago

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

Internal: After 10 days with no activity this issue will be automatically be closed.

rgblab commented 2 years ago

you are not passing string but object to register_block_type function thus we can't use filter in register_block_type_from_metadata to use our functions as render callbacks.

but, it would be really helpful to, at least, add filter to product search block to modify HADRCODED SVG in the submit button. just to remind you, woo blocks are now available in widgets editor, while legacy product search widget is not available out of the box. also, common task in theme development is to have both search and product search widgets with same/similar appearance, hardcoded svg isn't helping at all, and afaik - part of wp develompemnt culture is to leave room for modifications.

github-actions[bot] commented 2 years ago

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

Internal: After 10 days with no activity this issue will be automatically be closed.

davidhealey commented 2 years ago

I'm hitting this issue now too. I have two sites, one using blocks, one not using them. I am making use of the woocommerce_loop_add_to_cart_link filter to change the Select Options button to an Add to cart button for variable products that only have two variations.

ahmu83 commented 2 years ago

The woocommerce_blocks_product_grid_item_html filter is very helpful!
function _wc_get_template_part_str($template_name, $part_name=null) {
    ob_start();
    wc_get_template_part($template_name, $part_name);
    $var = ob_get_contents();
    ob_end_clean();
    return $var;
}

function woo_block_product_grid_item_html($html, $block_attr, $_product) {
    global $product, $post;

    $is_woo_block_product_grid_item = true;
    $orig_product = $product;
    $orig_post    = $post;

    $product = $_product;
    $post    = get_post(  $_product->get_id()  );
    $html    = _wc_get_template_part_str( 'content', 'product' );
    $product = $orig_product;
    $post    = $orig_post;

    return $html;
}
add_filter( 'woocommerce_blocks_product_grid_item_html', __NAMESPACE__ . '\\woo_block_product_grid_item_html', 10, 3);
The filter handler above makes the block use the original WooCommerce template, the list element isn't filtered though, styles may have to be adjusted.

One crucial thing that is missing is the block context itself for the filter handler, so it can render different html for different block settings, notably what block style it is for a different template.

Also this block uses the woocommerce_product_query_meta_query and woocommerce_get_catalog_ordering_args filters for the query, hence just using the woocommerce_product_query action doesn't seem to be usable for changing the query.

This is so helpful. Thank you!

ahmu83 commented 2 years ago

I used @strarsis method and override the template by copying the template templates/content-product.php to my theme and renaming it content-block-product.php and add the class name (wc-block-grid__product) so it doesn't break the formatting (as of woocommerce@6.1.0)

Thanks again @strarsis

github-actions[bot] commented 2 years ago

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

Internal: After 10 days with no activity this issue will be automatically be closed.

ninetyninew commented 2 years ago

Just a note here that the original post states "A basic filter does exist (woocommerce_blocks_product_grid_item_html) but it lacks usefulness and context and may be dropped. Ref https://github.com/woocommerce/woocommerce-gutenberg-products-block/issues/724 and https://github.com/woocommerce/woocommerce-gutenberg-products-block/issues/845"

From our point of view this filter does not lack usefulness! It is currently allowing us to hook into blocks easily and ensure a number of our extensions work correctly with blocks, without this we'd have a much harder job supporting and maintaining functionality our extensions include when a store owner is using these blocks.

jespervnielsen commented 2 years ago

Just a note here that the original post states "A basic filter does exist (woocommerce_blocks_product_grid_item_html) but it lacks usefulness and context and may be dropped. Ref #724 and #845"

From our point of view this filter does not lack usefulness! It is currently allowing us to hook into blocks easily and ensure a number of our extensions work correctly with blocks, without this we'd have a much harder job supporting and maintaining functionality our extensions include when a store owner is using these blocks.

The issue as i see it, is that this filter lets developers very easy re-code the entire output, with their own code in it. So you cant have multiple 3 part plugins extending it. -- unless the developers use DOMDocument or regex, which very easy could become very heavy and non-performant on longer lists. - compared to using hooks and filters to insert the plugins extra info.

So yes. - its better than nothing, but not the best solution :)

ninetyninew commented 2 years ago

Yes we are using a preg_replace via this filter at the moment - I'm getting a bit lost in all the related GitHub tickets to this one, is there yet a means of inserting custom code to Woo blocks (ideally via PHP) without using this filter? I seem to recall seeing some update somewhere on how to apply filters to WooCommerce blocks (although I think this was a JS based solution) - I might be remembering incorrectly?

iverok commented 2 years ago

is there yet a means of inserting custom code to Woo blocks (ideally via PHP) without using this filter? I seem to recall seeing some update somewhere on how to apply filters to WooCommerce blocks (although I think this was a JS based solution) - I might be remembering incorrectly?

Still not. For the All Products block you can add internal blocks using the registerBlockComponent interface; these can add elements to the product block and probably rewrite other elements using Javascript (after rendering). We have done this in our "pay now" plugin.

The javascript wp.hooks.doAction s used in the AbstractProductGrid and ProductSearch, but it is marked "experimental__" in both cases.

The 'woocommerce_blocks_product_grid_item_html' is still the only php filter applied for products block, and it is not used for the All Products block.

ninetyninew commented 2 years ago

Okay - thanks for the info, we'll continue to use woocommerce_blocks_product_grid_item_html for now - we are aware it doesn't get used for the All Products Block, we've included information in our documentation that the functionality our extensions add won't appear on the All Products Block

github-actions[bot] commented 2 years ago

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

Internal: After 10 days with no activity this issue will be automatically be closed.

davidmadon commented 1 year ago

I'm also hitting this issue, in multiple projects. Especially concerning is that theres no way (to my knowledge) to filter the All Products block html. How would one go about making customizations to that block?

It's sad, I want to use the Woo Blocks in multiple projects but this is currently holding me back.

Any progress on this? Or suggestions?

iverok commented 1 year ago

I'm also hitting this issue, in multiple projects. Especially concerning is that theres no way (to my knowledge) to filter the All Products block html. How would one go about making customizations to that block?

It's sad, I want to use the Woo Blocks in multiple projects but this is currently holding me back.

Any progress on this? Or suggestions?

The only way to allow for customization of the All Products is to create an internal sub-block using the registerBlockComponent and let the users add it to the All Products template.

That is, you make a sub-block which can be added to the editable All Products template, which has to be done by the end user.

There is a way to extend the Product schema now (I described a hack further up in this issue thread wrg how to extend the product data available in the front end javascript), but I can't really find good documentation for it yet. Basically you can do this:

if (function_exists('woocommerce_store_api_register_endpoint_data')) {
    woocommerce_store_api_register_endpoint_data([
        'endpoint' => Automattic\WooCommerce\StoreApi\Schemas\V1\ProductSchema::IDENTIFIER,// or 'product',
        'namespace' => 'my-great-plugin',
        'data_callback' => function ($product) {
            $extradata = array('extradata' => ['the_data' => random_int(0, 1)]);
            return $extradata;
        },
        'schema_callback' => function (...$whatever) {
            $schema = array(
                'extradata' => array(
                    'description' => __( 'Some extra data.', 'my-great-plugin' ),
                    'type'        => 'array',
                    'context'     => array( 'view', 'edit' ),
                    'readonly'    => true,
                    'items'       => array(
                        'type'       => 'object',
                        'properties' => array(
                            'the_data'   => array(
                                'description' => __( 'Either one or zero', 'my-great-plugin' ),
                                'type'        => 'int',
                                'context'     => array( 'view', 'edit' ),
                                'readonly'    => true,
                            )
                        )
                    )
                )
            );
            return $schema;
        }]);
}

which will make the StoreAPI produce this, which is available in the front end javascript:

 [extensions] => stdClass Object
        (
            [my-great-plugin] => Array
                (
                    [extradata] => Array
                        (
                            [the_data] => 1
                        )

                )

        )

woocommerce / woocommerce-blocks