The release ZIP for this PR is accessible via:

https://wcblocks.wpcomstaging.com/wp-content/uploads/woocommerce-gutenberg-products-block-6914.zip

Size Change: -107 B (0%)

Total Size: 871 kB

_{compressed-size-action}

@tarhi-saad This is causing problems for me with Mix and Match as now there's no way to distinguish between the meta items at all. There still needs to be a unique identifying class, and ideally have it stay consistent regardless of the site language. See also my comment here

Hello, @helgatheviking! Thank you for reporting this issue!

@alexflorisca's, if you can confirm that the class names aren't translatable, let's revert the changes of this PR! Otherwise, we can open a new issue to add support for unique identifying class.

@helgatheviking I tested this with the product addons plugin and these didn't translate for me. Can you tell us what plugin you're using and how you're seeing the classname strings translated so we can try to replicate?

Hi @alexflorisca thanks for the update. I am working with my plugin WooCommerce Mix and Match Products... so add a Mix and Match product to the cart and then look at the checkout block. I believe the issue also existed with Bundled Products too. What is the specific commit I should test against?

You can test against this commit: 6c68e0c

Hi @alexflorisca I think that is the commit where this change was introduced no? The unique class names aren't present in that commit, so I think I need to go back to the one before it...

Should be the one before it according to github: https://github.com/woocommerce/woocommerce-blocks/commits/trunk?after=22c1f242d856bb6d02d81e0eb20a5d198e11d64b+34&branch=trunk&qualified_name=refs%2Fheads%2Ftrunk

You can try 6286a6f

Thanks, Alex. Maybe it's caching but I can't get the class name to render for anything. 😓 in typical fashion, I can't get the build tools to build.

@helgatheviking We've just reverted this in #7191 so if you get the latest trunk, you should have the classname back. Apologies, I think I deleted that class too soon.

Thanks @alexflorisca I still see the class name is translatable because the key that is displayed must be translatable to support multilingual sites. Here's a test case:

/**
 * Add cart item data to items.
 *
 * @param  array  $data
 * @param  array  $cart_item
 * @return array
 */
function kia_test_cart_item_data( $data, $cart_item ) {

    $data[] = array(
                'key'   => esc_html__( 'Color', 'your-textdomain' ),
                'value' => esc_html__( 'Blue', 'your-textdomain' ),
	);
    return $data;
}
add_filter( 'woocommerce_get_item_data', 'kia_test_cart_item_data', 10, 2 );

/**
 * Change text strings
 *
 * @link http://codex.wordpress.org/Plugin_API/Filter_Reference/gettext
 */
function kia_test_translate_text_strings( $translated_text, $text, $domain ) {
	
	if ( 'your-textdomain' === $domain && 'fr_FR' === get_locale() ) {
		switch ( $translated_text ) {
			case 'Color' :
				$translated_text = __( 'Couleur', 'your-textdomain' );
				break;
			case 'Blue' :
				$translated_text = __( 'Bleu', 'your-textdomain' );
				break;
		}
	}
	return $translated_text;
}
add_filter( 'gettext', 'kia_test_translate_text_strings', 20, 3 );

When I switch my site to the French language, the class changes from wc-block-components-product-details__color to wc-block-components-product-details__couleur. This makes it very tricky to style with CSS.

If I change my above snippet to design key and name:

/**
 * Add cart item data to items.
 *
 * @param  array  $data
 * @param  array  $cart_item
 * @return array
 */
function kia_test_cart_item_data( $data, $cart_item ) {

    $data[] = array(
		'key' => 'color',
                'name'   => esc_html__( 'Color', 'your-textdomain' ),
                'value' => esc_html__( 'Blue', 'your-textdomain' ),
	);
    return $data;
}
add_filter( 'woocommerce_get_item_data', 'kia_test_cart_item_data', 10, 2 );

Then class name is not translated, but neither is the user-facing text:

I am still looking for a way to display the translated text to users but have a static class name. These two things shouldn't be linked in my opinion.

Yeah I get you. So the problem we have is that with the scenario you described above, any item inside the $data[] array can be translated right? That's the only dynamic data that we have to generate unique classnames from, so in theory we can't use any information inside $data[]. We could loop through a for loop and add a number on the end of the classname for each item - but I don't think that's very useful as it's not a sure way of targeting a specific item, only its place in the list. So I'm not really sure how to solve this one. I've reached out to my team to see if anyone else has any ideas

I agree a number would be pretty useless. I would never be able to predict what position the item was in the cart. Can key and name be decoupled so that the class is generated from key and name is the visible label? Can a class param be introduced? Is there a restriction on what data can be in the $data[] array?

Unfortunately we can't decouple key from name as we need to support both to keep compatible with WC Core (more details in this issue). $data[] should ideally be the same as WC core and provide key and display params but it will also work with name and value.

We could potentially introduce a class param here and pass that as a the classname. I'd love to hear if this would work for @jimjasson as well as the product addons plugin does something similar here?

Hey @alexflorisca,

Thank you for investigating this further!

The solution you propose is not 100% clear to me. Would you mind sharing an example of how the code would look like with this change? Moreover, can you please share a screenshot of the DOM structure in the frontend when your changes are active? Which classes will be available at the point where the deprecated class used to exist?

My bad @jimjasson, that wasn't a great explanation. What I mean is that at the moment, we can add extra fields to a product by using the woocommerce_get_item_data filter as mentioned above by @helgatheviking . At the moment, it looks like we only use the key and display props of the item variant. We could include an extra property here classname (or similar) to let users specify a class name to apply to that variant.

The screenshot below shows the class names of the two variant labels, colour and logo. Notice the two <li> elements, with class="wc-block-components-product-details__color" and class="wc-block-components-product-details__logo".

At the moment these are generated on the client from the key or name property of the item data, like so:

const name = item?.key || item.name || '';
const className = name ? `wc-block-components-product-details__${ kebabCase(name) }` : '';

The item here comes from the woocommerce_get_item_data filter, where it's equivalent to $data

function kia_test_cart_item_data( $data, $cart_item ) {

    $data[] = array(
                'key'   => esc_html__( 'Color', 'your-textdomain' ),
                'value' => esc_html__( 'Blue', 'your-textdomain' ),
	);
    return $data;
}
add_filter( 'woocommerce_get_item_data', 'kia_test_cart_item_data', 10, 2 );

What @helgatheviking is proposing is adding an extra class property within the filter where we add the variation data for a product, so that this can be available on the client and used instead of deriving the class from the key or name properties (which may be translated).

function kia_test_cart_item_data( $data, $cart_item ) {

    $data[] = array(
                'key'   => esc_html__( 'Color', 'your-textdomain' ),
                'value' => esc_html__( 'Blue', 'your-textdomain' ),
                'class' => esc_html__( 'wc-block-components-product-details__color', 'your-textdomain' ),

	);
    return $data;
}
add_filter( 'woocommerce_get_item_data', 'kia_test_cart_item_data', 10, 2 );

So in this example, the final DOM will look the same, but the class name is explicitly given rather than derived from the name or key props.

Does that make sense?

I like it! A class name we can specify would give parity to the php cart/order row class filter too.

Gotcha @alexflorisca -- thank you for the detailed explanation! Yes, that would be helpful for us too!

Great, I've created an issue to do this. Bare in mind that once this solution is merged and released, your tests will probably start failing again @jimjasson, until you make the required change on your side.

Thank you @alexflorisca !

your tests will probably start failing again @jimjasson, until you make the required change on your side.

Yes, this makes sense.

I will keep a close eye on the progress of this issue -- I would really appreciate it though, if you could ping me when this is implemented + close to release. Thanks! 🚀

@jimjasson pinging you as this is now complete and merged to trunk in #7328

Thanks @alexflorisca for the ping. I just tested and I see the classes are back

@PanosSynetos you should now be able to add a class that doesn't change via translation.

Awesome :) Thanks for the ping Kathy!