“Can you change my order to a size 32 instead of 30?” is one of the most common messages a fashion e-commerce store gets after checkout — and one WooCommerce genuinely has no built-in answer for.
Two separate obstacles
The first obstacle is that WooCommerce order line items simply don’t have a “change variation” action anywhere in the UI. You can edit quantity and price on an existing line, or delete it and add a different product from scratch — but swapping just the variation while keeping the same product, price and quantity isn’t exposed.
The second, less obvious obstacle is that WooCommerce’s native line-item editing only works while $order->is_editable() returns true — which for a default install means the order status is pending, on-hold, or auto-draft. In practice, most real orders have already moved to Processing by the time a customer asks for a size change, which locks the native editor out entirely.
What we built
We added a Change variant link under each variable-product line item on the order-edit screen — deliberately independent of WooCommerce’s is_editable() check, gated only on admin capability, since correcting a variant after the fact is exactly the situation where the order has already moved on. Clicking it loads every size, colour and length combination for that product as clickable pills, reusing the same picker component built for the Manual Order Creator.
Selecting a new variation calls WooCommerce’s own WC_Order_Item_Product::set_variation() method — the same method WooCommerce’s checkout uses internally when it first builds the line item — so the attribute meta ends up in exactly the shape every other part of WooCommerce expects, rather than a hand-rolled approximation that breaks in order emails or CSV exports.
Every change also writes an order note recording precisely what changed — for example, from Size 56 / Length 43 / Deep Blue to Size 50 / Length 43 / Deep Blue — so there’s a clear audit trail if a customer disputes what they received.
What it deliberately doesn’t do
This feature only swaps the variation identity: size, colour, length, and the item’s name. It doesn’t touch price, quantity, or stock levels automatically. That’s a deliberate boundary — silently changing what a customer was charged, or auto-adjusting inventory counts, are decisions a staff member should make explicitly, not side effects of a size correction.
Key takeaways
- A feature that only works while an order is “editable” in the platform’s narrow sense often solves the wrong case — the real need shows up after that window has closed.
- Reusing a platform’s own setter methods, instead of writing raw meta updates, is what keeps custom changes compatible with everything else that reads that data.
- Drawing an explicit boundary around what a feature does not touch (price, stock) is as important as what it does.
Running into a similar limitation in your own WooCommerce or WordPress admin? Let’s Talk — Artintech Solution builds exactly this kind of custom store tooling.