Proposal for Improving Variable Product API for Adding to Cart

[wavvves]

Hi everyone,

Currently, when we try to add a variable product to the cart using the API, there's a bit of confusion around how we name attributes. The API expects the "user-friendly" attribute name (what we see on the <label>), but sometimes this doesn't match up with the internal naming system we use in the product markup. This disconnect can cause some problems, especially when we throw special characters into the mix, when building a request to the StoreAPI on the browser (specially if we have to parse HTML to build our request).

I'm proposing the following:

1. Support for multiple naming formats: Let's make the API more flexible by allowing it to accept attribute names in various formats, like unencoded, encoded, and encoded with dashes (URL safe). This way, developers can work with the naming conventions that suit their stores best. This is what we already do for attribute values.

So we would be supporting in this case, for variation[0][attribute]:

• Color %f0%9f%96%8d%ef%b8%8f
• color-%f0%9f%96%8d%ef%b8%8f
• Color 🖍️

Instead of just Color 🖍️. This is what we already do for attribute values data.

2. Priority on encoded with dashes: To keep things simple and error-free, we can prioritize the encoded with dashes format when the API processes attribute names. It's easy to retrieve from DOM parsing and safer to pass along.
3. Maintain backward compatibility: Of course, we'll make sure that any changes we make won't disrupt existing stores. It's essential to keep everything running smoothly for our users.

I believe these tweaks will make life easier for developers working with variable products through the Store API.

Looking forward to your input!

[frosso]

WooCommerce Core uses the attribute_ prefix to name the attribute in product pages (e.g.: the "hoodie" product from the WC templates uses attribute_logo as the name attribute of the select element on the PDP)

This is generated here:

woocommerce/plugins/woocommerce/includes/wc-template-functions.php

Line 3215 in f2d828f

$html = '<select id="' . esc_attr( $id ) . '" class="' . esc_attr( $class ) . '" name="' . esc_attr( $name ) . '" data-attribute_name="attribute_' . esc_attr( sanitize_title( $attribute ) ) . '" data-show_option_none="' . ( $show_option_none ? 'yes' : 'no' ) . '"' . ( $required ? ' required' : '' ) . '>';

Would it make sense to keep the attribute_ prefix compatibility/consistency also on the Store API side?
In the example above, the value for attribute's name would be attribute_color-%f0%9f%96%8d%ef%b8%8f.

[opr]

@wavvves thanks for starting the discussion. I hope I've understood your proposal correctly!

1. Allow attribute names to be passed in three different formats:

• Plain (e.g. unencoded), the value is passed exactly as it's seen in the editor
• Encoded
• Encoded but in kebab-case

2. When receiving them, assume they will be passed as encoded kebab-case first
3. Try matching against the other formats if no matches are found for the encoded kebab-case one?

If I've got anything wrong please let me know.

You mention we already do this for the value of the attribute, so it makes sense to apply the same process to the name. The process should be as similar as possible for both.

I like @frosso's suggestion above, supplying attribute_ for alignment and consistency with core. Would this only be present when passing the value as encoded kebab case?

[wavvves]

Related issue #45846

[wavvves]

Exactly @opr, the kebab-case or, utf8 encoded with dashes (url friendly) should be a safer option for all future usecases. Trying that first would only be a performance choice to encourage and benefit whoever chooses to adopt that.
Supporting the attribute_ would be an extra use case, but I'm on board with that. I believe this is just an example on how in WP we end up carrying multiple scenarios going forward to keeps things working.

[wavvves]

Issue created #47792
Closing this discussion now, thank you all for your input 🙏