The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To store a different custom value for each variation in WooCommerce, render an input with the woocommerce_variation_options_inventory action, then save it on the variation with the woocommerce_save_product_variation action. Match each posted value to its variation using the loop index, and store it as metadata on that variation’s product object. Before writing any code, decide whether the data really belongs in a variation attribute, in internal metadata, or in a shopper-facing option, because each one is handled differently.
Decide what kind of field you need
Most requests to “add a custom field to variations” fall into one of three categories. Picking the right one first saves a lot of rework.
- A variation-defining choice. If the value is what the shopper selects, such as size, color, or material, it should be a product attribute used by the variable product. WooCommerce uses attributes to organize products around shared characteristics, so this is the native mechanism for choices.
- Internal item-specific metadata. If the value is extra information that does not change the choice itself, such as a supplier SKU, a bin location, or a certification number for one variation, a custom metadata field is the usual fit. WooCommerce’s custom fields documentation describes custom fields as a way to add specific information to a product listing.
- A shopper-entered option. If the customer must type or pick something on the product page, such as an engraving text or a gift message, you are building a product option, not admin metadata. This needs a frontend field, validation at add-to-cart, and usually an extension or custom cart logic. Later in this article we cover when an extension is the sensible choice.
The rest of this guide covers the second case, which is the one the WooCommerce developer tutorial addresses directly.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11How the variation save cycle works
WooCommerce renders variation fields in the product editor’s Variations panel, one block per variation. Each block is numbered by a loop index. When the product is saved, WooCommerce passes each variation’s ID and its loop index to your save callback. Your code uses that index to find the matching posted value, which is why the form field name must carry the loop index.
#1 Best Overall
- In the WordPress admin, open Products > All Products, edit a variable product, and open the Variations tab in the Product data panel.
- Expand a variation. Your rendered field appears in its block, next to the built-in variation fields such as price and inventory.
- Enter a value for one variation and click Save changes (or Update on the product, which saves variations too).
- WooCommerce calls
woocommerce_save_product_variationfor each variation. Your callback reads$_POSTusing the loop index, sanitizes the value, and writes it to that variation. - Reopen the variation. The field should show the stored value, because your render callback reads it back from the variation ID.
Code example
The following is a minimal pattern that follows the hook names and functions in WooCommerce’s official tutorial, “How to add a custom field to simple and variable products.” It is a starting point, not a drop-in plugin. Place it in a custom plugin or a child theme’s functions.php, and replace _custom_value and the text domain with your own values.
Render the field
add_action( 'woocommerce_variation_options_inventory', 'ym_render_variation_field', 10, 3 );
function ym_render_variation_field( $loop, $variation_data, $variation ) {
woocommerce_wp_text_input( array(
'id' => '_custom_value[' . $loop . ']',
'label' => __( 'Custom value', 'your-textdomain' ),
'value' => get_post_meta( $variation->ID, '_custom_value', true ),
'wrapper_class' => 'form-row form-row-full',
) );
}Save the value
add_action( 'woocommerce_save_product_variation', 'ym_save_variation_field', 10, 2 );
function ym_save_variation_field( $variation_id, $loop ) {
if ( ! isset( $_POST['_custom_value'][ $loop ] ) ) {
return;
}
$value = sanitize_text_field( wp_unslash( $_POST['_custom_value'][ $loop ] ) );
$variation = wc_get_product( $variation_id );
if ( ! $variation ) {
return;
}
$variation->update_meta_data( '_custom_value', $value );
$variation->save_meta_data();
}Three details matter here. The field name uses [ $loop ] so each variation sends its own value. The save callback uses the variation ID, not the parent product ID, so the value lands on the correct child. The metadata key, _custom_value, must be identical in the render, save, and read-back code. A typo in any one of the three produces a field that looks saved but reads back empty.
Sanitize according to the field type
The official example sanitizes a text value with sanitize_text_field(). That is correct for plain text, but it is not sufficient for every field. Use validation that matches what the value is supposed to be.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #2
| Field type | Suggested handling before saving | Notes |
|---|---|---|
| Single-line text | sanitize_text_field( wp_unslash( ... ) ) |
The approach used in the official example. |
| Multi-line text | sanitize_textarea_field() |
Keeps line breaks, which the single-line function removes. |
| Whole number | absint(), or check with ctype_digit() and reject other input |
Decide whether zero or empty is a valid stored value. |
| Decimal number | floatval() plus a range check |
Store a consistent format, such as a period as the decimal separator. |
| URL | esc_url_raw() |
Escape for output later with esc_url(). |
| Checkbox | Store a fixed value such as yes, and treat a missing key as unchecked |
Unchecked boxes are not posted, so the save callback must handle absence. |
Escape values again when you output them on a page. The official display snippet uses esc_html() for this purpose.
Parent product field versus variation field
Hook choice determines where the data lives. A field saved on the parent variable product is shared by every variation. A field saved on each child variation can hold a different value per variation. The developer tutorial presents the parent-product hooks separately from the variation hooks, and its variation save callback works with the variation ID.
| Question | Parent product field | Variation field |
|---|---|---|
| Where the value is stored | On the variable product | On each variation product |
| Can each variation differ? | No, all variations share one value | Yes, each variation holds its own value |
| Typical hook for saving | The parent product save action | woocommerce_save_product_variation |
| Typical example | A product-wide warranty note | A per-variation supplier code |
If the value must be different for each size or color, use the variation field. If one value applies to the whole product, store it on the parent and avoid repeating it on every variation.
Showing the value on the storefront
Saving variation metadata does not create a customer-facing display. The developer tutorial notes that on a variable product page, WooCommerce updates only some content when the shopper changes the selected variation, and it points to the variation script, add-to-cart-variation.js, as an example of that behavior. The official display snippet for custom metadata reads a value from the product and escapes it, but it is written for product-level data and does not update when the variation changes.
Free tools Windows power users keep installed
One-click scans. No signup required.
Product-level display
If the value should appear the same way for every variation, a product-level template snippet is enough. Read the parent product’s metadata, escape it with esc_html(), and output it where you need it.
Variation-aware display
If the value must change when the shopper selects a variation, you need more than the save code. One route is to add the value to the variation data that WooCommerce sends to the page, using the woocommerce_available_variation filter, and then update the page with JavaScript when the variation changes. Confirm how that filter and the variation script behave on your WooCommerce version before relying on them, and test the change with several variations selected in sequence.
Reading and writing through the REST API
WooCommerce’s REST API documentation covers variation resources. The v2 documentation describes endpoints to create, retrieve, update, delete, and batch-manage variations. The v3 variation documentation covers retrieving a variation, and a separate v3 product custom-fields endpoint lists custom-field names that have been recorded.
These pages do not establish that arbitrary custom metadata is automatically writable or returned for every variation. If an external system needs the value, confirm the exact API version your site uses, confirm that the metadata key is registered and exposed, and test a read and a write on a staging variation before depending on it.
Recommended Free Tools
Customer-facing options and extensions
If the real requirement is to let shoppers choose or enter something, a frontend option extension is usually a better match than the admin metadata approach above. WooCommerce’s custom fields documentation points to its Marketplace for extensions and to Woo Agency Partners for custom development.
- Dynamic Product Options adds product-page fields, choices, and display rules. Variation is among the documented rule conditions, though some rule types are part of its premium feature set.
- Product Options and Fields documents options attached to a specific variation that appear when the shopper selects that variation.
These extensions create shopper-facing inputs. They are not automatic substitutes for developer-managed variation metadata, so they do not replace the admin field in the code above. Check each extension’s current feature list, supported WooCommerce version, and pricing on its own product page, because those details change.
Troubleshooting common problems
- The field appears but the value is not saved. Confirm the input name matches the key you read in
$_POST, including the brackets and the loop index. Confirm the save callback is registered with two accepted arguments. - Each variation shows the same value. The render code is probably reading the parent product ID rather than
$variation->ID, or the save code is using the parent product. - The field is empty after saving. The metadata key differs between render and save. Use one constant for the key across both functions.
- Unchecked checkboxes clear unexpectedly. Treat a missing posted key as unchecked, and store an explicit value for the unchecked state if you need to distinguish it from never set.
- Metadata saves but the storefront does not change. That is expected for admin metadata. Add a variation-aware display step as described above.
Version notes
WooCommerce’s developer tutorial states that its complete example was written for WordPress 6.2 and WooCommerce 7.6.0. Treat those versions as the documented baseline, not a guarantee for current installations. Admin markup, hook behavior, and the variation script have changed across WooCommerce releases, so confirm the hooks and the rendered admin layout on the exact WordPress and WooCommerce versions your site runs.
Wherever this article describes a specific product option or extension, its feature set and compatibility are those stated in the vendor’s own documentation at the time of writing in October 2026, and they can change.
Before deploying, test with at least three variations, change one value at a time, and confirm that each variation keeps its own value after a save, a reload, and a variation reorder.
Quick Recap
The Bottom Line
“”
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
