Product Block Editor: Add the fundamental support and map Text and Integer attribute inputs to currently available generic blocks

[eason9487]

Changes proposed in this Pull Request:

To be compatible with Product Block Editor, this PR adds fundamental support:

• Extract the processing of getting the visible and hidden product types in AttributesForm as a method.
• Convert the init_input method in AttributesForm to a static method.
• Add methods to Admin\Input\Input for getting block config.
• Add a new class AttributesBlock to register blocks to Product Block Editor for product attributes.

Also, it turns a few attribute inputs to support Product Block Editor first:

• Map Text and Integer inputs to currently available generic blocks.
• Add the block attribute 'min' to the multipack input.

Last, it adds some PHP tests and removes a few unused PHP classes or method:

• Remove the unused method is_custom_value from SelectWithTextInput.
• Add PHP unit tests for
  • the Admin\Input\Input class and its inheritance classes.
  • the attribute input classes under Admin\Product\Attributes\Input.
  • the AttributesForm class.
  • the AttributesBlock class.

Screenshots:

📷 Simple product

📷 Variation product

📷 The min attribute of the multipack input

Detailed test instructions:

📌 Prepare test environment

1. Set up WooCommerce 8.3.0
2. Install WooCommerce Beta Tester
3. Go to WooCommerce > Settings > Advanced > Features. Enable the New product editor
   
4. Go to Tools > WCA Test Helper > Features. Make sure the product-block-editor and product-variation-management options are enabled.
   
5. Deactivate WooCommerce Beta Tester as it's incompatible with GLA for now. See GLA inaccessible when WooCommerce Beta Tester plugin is active #2147

📌 Test the simple product type

1. Go to edit a simple product, e.g. the Beanie with Logo imported from WC's sample products
2. Switch to the Organization tab and find the Attributes section.
3. Check if there is the Google Listings & Ads section under the Attributes section.
4. Within the Google Listings & Ads section, operate the text and number fields and change their values.
5. Click on the Update button at the top-right of the page.
6. Refresh the page or switch back to the classical product editor to see if the changed values are saved.

📌 Test the variable and variation product type

1. Go to edit a variable product, e.g. the Hoodie imported from WC's sample products
2. Switch to the Organization tab and find the Attributes section.
3. Check if there is the Google Listings & Ads section under the Attributes section.
4. Within the Google Listings & Ads section, there should be only a brand field for now. Operate the brand field and change its value.
5. Click on the Update button at the top-right of the page.
6. Refresh the page or switch back to the classical product editor to see if the changed value is saved.
7. Back to edit the same variable product with Product Block Editor.
8. Switch to the Variations tab and find the Variations section.
9. Click on one of the Edit links within the Variations section to go to edit a variation product.
10. With the General tab, find the Image section.
11. Check if there is the Google Listings & Ads section under the Image section.
12. Repeat the similar test to verify the fields for this variation product.

📌 Test the related filters

1. Continue to use the above variation product editing page.
2. Filters the list of applicable product types for each attribute - "woocommerce_gla_attribute_applicable_product_types_{$attribute_id}"
   1. Confirm there is no Brand field.
   2. Add a filter to the google-listings-and-ads.php file:

      add_filter(
      	"woocommerce_gla_attribute_applicable_product_types_brand",
      	function ( array $applicable_types ) {
      		$applicable_types[] = 'variation';
      
      		return $applicable_types;
      	}
      );

   3. Refresh the page.
   4. Check if the Brand field appears.
3. Filters the list of product types to hide for each attribute - "woocommerce_gla_attribute_hidden_product_types_{$attribute_id}"
   1. Confirm there is the Size field.
   2. Add a filter to the google-listings-and-ads.php file:

      add_filter(
      	"woocommerce_gla_attribute_hidden_product_types_size",
      	function ( array $applicable_types ) {
      		$applicable_types[] = 'variation';
      
      		return $applicable_types;
      	}
      );

   3. Refresh the page.
   4. Check if the Size field disappears.

Additional details:

The generic number block ('woocommerce/product-number-field') doesn't support verifying/limiting for entering an integer. If it's not supported afterward, then we may have to convert it to a custom block.

Changelog entry

[codecov]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (abb5fcb) 58.2% compared to head (9ff6a97) 60.6%.

Additional details and impacted files

@@                           Coverage Diff                            @@
##             feature/support-product-block-editor   #2151     +/-   ##
========================================================================
+ Coverage                                    58.2%   60.6%   +2.4%     
- Complexity                                   4127    4144     +17     
========================================================================
  Files                                         453     453             
  Lines                                       17691   17785     +94     
========================================================================
+ Hits                                        10300   10777    +477     
+ Misses                                       7391    7008    -383     

Flag	Coverage Δ
php-unit-tests	60.6% <97.5%> (+2.4%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
src/Admin/Input/Input.php	100.0% <100.0%> (+100.0%)	⬆️
src/Admin/Input/InputInterface.php	100.0% <ø> (+100.0%)	⬆️
src/Admin/Input/Integer.php	100.0% <100.0%> (+100.0%)	⬆️
src/Admin/Input/SelectWithTextInput.php	100.0% <ø> (+100.0%)	⬆️
src/Admin/Input/Text.php	100.0% <100.0%> (+100.0%)	⬆️
src/Admin/Product/Attributes/AttributesForm.php	97.2% <100.0%> (+97.2%)	⬆️
src/Admin/Product/Attributes/AttributesTab.php	0.0% <ø> (ø)
src/Admin/Product/Attributes/AttributesTrait.php	100.0% <100.0%> (ø)
.../Admin/Product/Attributes/Input/MultipackInput.php	100.0% <100.0%> (+100.0%)	⬆️
...ernal/DependencyManagement/CoreServiceProvider.php	0.0% <0.0%> (ø)
... and 1 more

... and 36 files with indirect coverage changes

[jorgemd24]

Thanks @eason9487 for working on this, I ran some tests with simple products, and things went smoothly, except for the issue I mentioned in the comment about encountering an error with the filter.

Regarding the variation you mentioned:

Within the Google Listings & Ads section, there should be only a brand field for now. Operate the brand field and change its value.

All I'm seeing is a blank section.

The filters didn't seem to affect anything when I tested them with the variations.

I ran out of time today, but I am happy to debug this issue deeper if you are not able to replicate it.

[jorgemd24]

Would be nice to have the type reference here: /** @var Automattic\WooCommerce\Internal\Admin\Features\ProductBlockEditor\ProductTemplates\Group */

[eason9487]

This line will be removed by PR #2179. I added related type references to that PR in ac4abe9.

[jorgemd24]

The return type should be: SectionInterface

https://github.com/woocommerce/woocommerce/blob/633bf40f13263cd80c6d803b44c2b0d40422b7e1/plugins/woocommerce/src/Internal/Features/ProductBlockEditor/ProductTemplates/Group.php#L48

[eason9487]

Thanks! This method will be removed by this commit in PR #2179. To avoid future code conflicts, I would skip this adjustment.

[jorgemd24]

Initially this part confused me, as it seems that the method add_section would add the $attributes_section. However, it turns out the 'add' method retrieves the group from this attribute section and subsequently adds a new section. I'm thinking, perhaps renaming this function to something like 'add_section_to_group' could better clarify its purpose.

[eason9487]

Thanks for the suggestion.

This method call will be inlined by this commit in PR #2179. Instead of using $this to indirectly add group and section to template, the changed code fragment now calls to the literal callee, which I believe should not cause similar confusion as here.

[jorgemd24]

Thanks, yes that will remove the ambiguity!

[jorgemd24]

Similar to my earlier comment, this could be add_blocks_to_section

[eason9487]

In this commit of PR #2179, this line will be changed to $this->add_product_attribute_blocks( $product_attributes_section );, which should be able to clarify the purpose that it adds product attribute blocks to a section.

[jorgemd24]

Do we want to keep the type generic using BlockInterface ? Or can we use Automattic\WooCommerce\Internal\Admin\Features\ProductBlockEditor\ProductTemplates\Section?

[eason9487]

In the definition of this hook, there are several possible incoming instances, and each of them is a class that implements BlockInterface.

Although in runtime it passes in a Section instance, I think it also makes sense to use the more generic type BlockInterface here. Like when I adjusted their insertion position in #2179, the type reference here didn't need to be changed.

[jorgemd24]

Maybe An attribute classname ....

[eason9487]

Sorry, I don't understand this comment. Could you explain a bit more?

[jorgemd24]

My bad, I should have clarified this better 😅. What I meant was in the PHP doc, when we mention 'An attribute class,' strictly speaking, it refers to the actual name of that class. So, my suggestion was more along the lines of asking whether we should update this to: 'The name of the Attribute class extending AttributeInterface.'

[eason9487]

Thanks for the suggestion! Updated all related PHP docs for the AttributesForm class by 9ff6a97.

[jorgemd24]

If I use the filter in the following way I get an error:

add_filter(
	'woocommerce_gla_attribute_hidden_product_types_gtin',
	function ( array $applicable_types ) {
		return [ 'simple', 'variation' ];
	}
);

[eason9487]

Thanks for catching this! Fixed in https://github.com/woocommerce/google-listings-and-ads/pull/2151/files/0408038b4607fb9e4779f33b38848cf2920398ef..466d83e5d874c1b7cd1daeba45aedaadbca5f8fa.

[eason9487]

Hi @jorgemd24, thanks for the review.

Regarding the variation you mentioned:

Within the Google Listings & Ads section, there should be only a brand field for now. Operate the brand field and change its value.

All I'm seeing is a blank section.
[...]
The filters didn't seem to affect anything when I tested them with the variations.

Could you check if WooCommerce Brands is activated? If it is, the Brand attribute input will be dynamically converted to use SelectWithTextInput, which is not yet converted in this PR. Attribute inputs that are not yet converted will be skipped, so the GL&A section in a variable product will be blank.

google-listings-and-ads/src/Admin/Product/Attributes/AttributesBlock.php

Lines 130 to 133 in 46830dc

	// TODO: Remove this check after all attribute inputs have specified a block name
	if ( '' === $input->get_block_config()['blockName'] ) {
	continue;
	}

If this is not the cause, then I can't reproduce it, so I may need your help to find the cause.

[jorgemd24]

Thanks @eason9487, for fixing the issue and your comments. The reason why the brands field is not displayed was because the SelectInput doesn't have a block name, therefore the code is skipping this field. For this test, I added the blockname 'woocommerce/product-text-field' and I could test the behaviour. I see that you already work on this here https://github.com/woocommerce/google-listings-and-ads/pull/2178/files#diff-eb72915300551a54c7e5237203c3878b9c0bcedb253bb0d0624e45890e7b so I am approving this PR as everything works nos smoothly.

Thanks again!