WooCommerce email preview is useful for layout and style review, but its documented dummy data is not an actual database order. A preview can look correct while live emails use a different recipient, locale, status transition, payment link, tax display, coupon, custom field, template override, extension hook, mail transport, or asynchronous sending path.
Use this for WooCommerce store owners, agencies, designers, support teams, extension developers, and release managers changing email templates, branding, order statuses, gateways, localization, SMTP, or email customizer plugins.
Quick answer
Treat preview as the visual baseline, then create sanitized real orders for every important status and data shape. Trigger emails through the same status transitions and code paths used in production. Capture the generated subject, recipient, headers, HTML, plain text, hooks, template source, locale, send log, provider event, and inbox rendering. Diff structure and business data separately.
What to check first
- Record WooCommerce version, email settings, sender identity, enabled emails, recipients, template overrides, customizer, SMTP plugin, provider, queue mode, locale, tax display, gateway, and extension hooks.
- Save preview HTML and plain-text output, screenshot desktop and mobile rendering, and mark every dummy value that cannot validate order-specific behavior.
- Create sanitized fixtures for guest and account orders, paid and unpaid status, failed payment, refund, coupon, tax, shipping, virtual item, backorder, download, payment link, custom metadata, and translated locale.
- Trigger each email through the actual order transition, then capture subject, recipient, reply-to, headers, HTML, plain text, template path, hook log, queue job, provider acceptance, bounce event, and inbox result.
- Diff preview versus live output by layout, conditional sections, monetary values, links, escaping, accessibility, mobile width, clipping, localization, and extension-added content, then fix the owning layer.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Capture the preview baseline | Record WooCommerce version, email settings, sender identity, enabled emails, recipients, template overrides, customizer, SMTP plugin, provider, queue mode, locale, tax display, gateway, and extension hooks. | Each enabled transactional email has at least one real-order fixture and expected recipient. |
| Build real order fixtures | Save preview HTML and plain-text output, screenshot desktop and mobile rendering, and mark every dummy value that cannot validate order-specific behavior. | Subjects, monetary values, status wording, payment and download links, custom fields, locale, and conditional sections match the fixture. |
| Trigger production-equivalent transitions | Create sanitized fixtures for guest and account orders, paid and unpaid status, failed payment, refund, coupon, tax, shipping, virtual item, backorder, download, payment link, custom metadata, and translated locale. | WooCommerce logs, queue state, SMTP provider event, and inbox receipt agree on one message identity. |
| Trace generation through delivery | Trigger each email through the actual order transition, then capture subject, recipient, reply-to, headers, HTML, plain text, template path, hook log, queue job, provider acceptance, bounce event, and inbox result. | Desktop, mobile, dark mode where relevant, image blocking, and plain-text views remain readable and actionable. |
Why this usually happens
- Preview data is intentionally synthetic and cannot reproduce every order state or extension field.
- Some email tags and payment actions only exist after a real order is created or changes status.
- A theme or child-theme override can be stale while the preview tool renders a newer path.
- Provider delivery, suppression, bounce, and inbox rendering occur after WooCommerce generates the message.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture: failed_guest_coupon_tax
order_status_before: pending
order_status_after: failed
preview_render: pass
live_recipient: verified
template_source: child-theme/woocommerce/emails/customer-failed-order.php
provider_accepted: true
inbox_render_mobile: pass
business_data_diff: none
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Capture the preview baseline
- Build real order fixtures
- Trigger production-equivalent transitions
- Trace generation through delivery
- Diff layout and business data
Decision rule
Approve an email change only when preview and real-order fixtures are visually acceptable, all order-dependent values and recipients are correct, both HTML and plain text pass, provider delivery is proven, and no stale override or extension hook remains unexplained.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Each enabled transactional email has at least one real-order fixture and expected recipient.
- Subjects, monetary values, status wording, payment and download links, custom fields, locale, and conditional sections match the fixture.
- WooCommerce logs, queue state, SMTP provider event, and inbox receipt agree on one message identity.
- Desktop, mobile, dark mode where relevant, image blocking, and plain-text views remain readable and actionable.
Mistakes to avoid
- Do not change several plugins, cache rules, firewall settings, or integrations before preserving a baseline.
- Do not treat one successful browser test as proof for APIs, retries, alternate clients, background jobs, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer records into tickets, screenshots, or long-lived logs.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Why does preview show an order that does not exist?
WooCommerce documents that the preview uses dummy data rather than an actual database order.
Does provider acceptance prove the customer received the email?
No. Reconcile acceptance with delivery, suppression, bounce, complaint, and inbox evidence where available.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, security gate, performance incident, or attribution workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, test WooCommerce transactional emails.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Expand the email test across locales and overrides
Use the WooCommerce email locale and template override matrix to test guest and account orders, taxes, coupons, refunds, RTL, plain text, provider delivery, dark mode, and mobile inboxes.
Test video embeds in delivered email
Extend preview testing with the WooCommerce 11.1 email editor embed delivery parity test for supported providers, unsupported URLs, plain text, blocked images, and real inbox clients.
Helpful references