WC REST API fixes for product variation attributes with special characters in WooCommerce 10.5

In the upcoming WooCommerce 10.5 release, two fixes have been implemented in the WooCommerce REST API for product variations:

  1. Attribute names with special characters: Previously, when creating product variations via the REST API, attribute names containing special or non-ASCII characters (like Persian, Arabic, or other Unicode characters) were not properly handled.
  2. Attribute option values with special characters: Previously, attribute option values were not being properly decoded when creating variations via the REST API.

Why These Changes Were Made

These fixes address issues reported by developers who were unable to create product variations programmatically when using:

  • Attributes names with non-ASCII character names (e.g., Persian/Farsi, Arabic, Chinese, etc.)
  • Attribute option values with non-ASCII character names (e.g., Persian/Farsi, Arabic, Chinese, etc.)

Impact

These fixes primarily affect the following REST API endpoints when creating or updating variations:

  • POST /wp-json/wc/v3/products/{id}/variations
  • POST /wp-json/wc/v2/products/{id}/variations
  • PUT /wp-json/wc/v3/products/{id}/variations/{variation_id}
  • PUT /wp-json/wc/v2/products/{id}/variations/{variation_id}

Note: While GET endpoints (GET /wp-json/wc/v3/products/{id}/variations/{variation_id}) already properly decode attribute values when returning responses, these fixes ensure that variations are created correctly in the first place, so GET endpoints will return accurate data for variations created after these fixes are applied.

How can developers tell if they are affected?

You are affected by these issues if you:

  1. Create or update product variations programmatically via the WooCommerce REST API (v2 or v3)
  2. Use attributes with non-ASCII character names (e.g., Persian/Farsi, Arabic, Chinese, Japanese, Korean, or any Unicode characters)
  3. Use attribute option values with non-ASCII character names (e.g., Persian/Farsi, Arabic, Chinese, Japanese, Korean, or any Unicode characters)
  4. Experience issues where variations are created but attributes are not properly saved, or attribute options fail to match existing terms

What action do developers need to take if affected?

No action is required: these fixes are backward compatible and will automatically improve the handling of special characters in your existing code.

However, if you were previously working around these issues with hardcoded encoding/decoding logic or custom workarounds, you may want to review your code to ensure it still works as expected with the improved handling. If you use attributes with special characters or non-ASCII names, we recommend testing variation creation via the REST API to ensure everything works as expected.


Leave a Reply

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