How WooCommerce Order Emails Lost Custom Field Data and How I Fixed

The support ticket arrived at 3:47 PM on a Friday: 'The workshop never received the engraving text for Order #1247. The customer is furious.' I pulled up the order in WooCommerce admin, and there it was, 'Forever & Always', plain as day in the order metadata. But when I checked the New Order email the workshop received? Nothing. Not a trace of the custom field. Just the product name, price, and shipping address.

That discrepancy kicked off a week of debugging, plugin conflicts, and eventually, a reliable way to ensure custom checkout fields always appear in WooCommerce order emails, no manual copy-pasting required.

The Problem: Data Exists, But Emails Ignore It

WooCommerce stores custom checkout fields as order metadata, but whether that data appears in emails depends on three things:

1. How the field is saved (underscore-prefixed keys like _engraving_text are hidden by default).
2. Which email template is active (some customizers strip metadata sections entirely).
3. Checkout method (Blocks vs. Classic checkout handle metadata differently).

My first attempt was a custom snippet to force-display meta in emails using woocommerce_email_order_meta_fields. It worked, until a client updated their email template plugin and overwrote the changes. Hardcoding labels broke when field names changed. I needed something self-maintaining.

The Solution: Let WooCommerce Do the Work

After digging into how WooCommerce's core email system decides what to display, I found the answer was simpler than I thought. Fields saved with non-underscored keys and proper labels appear automatically in the 'Additional Information' section of order emails. No hooks. No overrides. Just correct metadata registration.

The catch? Most checkout field plugins don't handle this consistently. Some save data with hidden prefixes. Others rely on filters that break with template customizers. Then I tested NEXU Advanced Checkout Field Editor, it stores fields as display-ready order meta by default. No configuration. No surprises.

Verification Steps for Developers

Before deploying this to a live store, I ran three tests:

1. Blocks vs. Classic Checkout: Placed test orders using both. Fields appeared in emails for both, including per-product metadata (e.g., 'Engraving for Silver Ring').
2. Template Conflicts: Activated a popular email customizer plugin. The metadata section persisted because the plugin uses WooCommerce's native meta display system.
3. Edge Cases: Tested conditional fields (only shown for specific products) and file uploads. Labels matched the checkout form, and file links were clickable in emails.

Why This Matters for Production Workflows

For stores selling personalized products, the New Order email is effectively a production brief. If engraving text, ring sizes, or dietary preferences don't appear there, the team defaults to:

• Manually checking the WooCommerce admin for every order (time sink).
• Emailing customers to confirm specs (delays fulfillment).
• Guessing (risking errors).

With fields auto-populating in emails, the workflow becomes:

1. Customer submits order with custom data.
2. Workshop receives email with all specs labeled clearly.
3. Production starts immediately, no context-switching.

The One Gotcha: Per-Product Fields

Per-product custom fields (e.g., 'Monogram for this shirt') are stored as order item meta, not order meta. Some email templates exclude item meta by default. The fix? Ensure your template's order table includes the {item_meta} placeholder. NEXU's guide covers this in detail, including Blocks checkout compatibility.

Final Takeaway

If you're debugging missing custom fields in WooCommerce emails, start here:

• Check for underscore-prefixed meta keys in the order admin.
• Test with a default email template (disable customizers temporarily).
• Use a field plugin that registers meta for display by default, like NEXU Advanced Checkout Field Editor.

The goal isn't just to show the data, it's to make it actionable for the team and verifiable for the customer. When that happens, the support tickets about 'missing specifications' stop arriving on Fridays at 3:47 PM.