wc_update_variation: update a variation
Updates one variation of a variable product.
Arguments
| Argument | Required | Meaning |
|---|---|---|
id |
Yes | The variation |
sku |
No | Stock keeping unit |
regular_price |
No | Normal price |
sale_price |
No | Sale price |
description |
No | Variation description |
stock_quantity |
No | Stock level |
attributes |
No | The attribute combination |
dry_run |
No | Report without writing |
Only the fields you pass are changed.
Permissions
Allow WooCommerce catalog writes open, plus manage_woocommerce or edit_products.
Use the dry run, and read the before
It returns a genuine before and after:
Use a dry run to set the regular price on variation 2204 and show me the before and after.
The before tells you whether a sale price is currently active on this variation — which decides whether your change affects what customers pay. Variations are frequently on sale individually, so this varies within a single product.
The price fields behave as they do on products
regular_price is the normal price, sale_price is the discount, and price in the response is WooCommerce's computed result and cannot be written.
To end a sale on a variation, set sale_price to an empty value. Omitting it leaves the discount running.
See wc_update_product, where the same three fields are described in full.
Changing attributes re-identifies the variation
This is the field unique to variations, and the most dangerous one here.
attributes defines which combination the variation represents. Changing it does not move a price between combinations — it redefines what this variation is.
Two failure modes:
- A combination that no longer matches the parent's attributes makes the variation unselectable. It still exists, and no customer can reach it.
- A combination that duplicates another variation leaves two variations competing for the same selection, and WooCommerce picks one.
Read the parent's attributes and the sibling variations before touching this field. Most price and stock work should not touch it at all:
Update only the regular price. Do not change the attributes.
Stock
stock_quantity sets a number; whether WooCommerce uses it depends on stock management being enabled on the parent product, which is not a variation field.
Check the parent with wc_get_product before assuming a stock write will have an effect.
No revision history
Variations keep no history of price or stock. The values you read before writing are the only record.
Show me variation 2204's current price and stock, then apply the change.
Read it back and check the storefront
The response reflects what was saved, but other plugins hook variation saves — dynamic pricing, feeds, inventory sync.
After writing:
- Read the variation back.
- Open the product page.
- Select that specific combination and confirm the price and availability shown.
- Check the product's price range on listing pages.
- Purge the cache, then the CDN.
Step 3 is the proof. Stored data being correct does not guarantee the selector behaves.
Before a batch
Update one variation with a dry run, apply it, check the storefront, and only then use wc_batch_update_variations.
Common problems
| Symptom | Cause |
|---|---|
| The write is refused | Catalog write gate closed |
pom_ai_mcp_wc_variation_not_found |
Wrong ID, or the ID is a product |
pom_ai_mcp_wc_forbidden |
Missing shop capability |
| The customer price did not change | A sale price is still active |
| The variation vanished from the selector | Its attributes no longer match the parent |
| Stock is ignored | Stock management is off on the parent |
| The price range is stale | Cache not purged |