Direct answer
WooCommerce's order-items email template can print the SKU; core customer emails simply do not ask for it. To show it, set the native show_sku argument to true only while WooCommerce renders a verified core customer order email, through the documented email-order-items arguments. Leave admin emails native by default. Write nothing: no SKUs, products, variations, orders, recipients, templates, HTML, or CSS. When the switch is off, the email is an admin or third-party message, or the context is uncertain, return every argument unchanged.
Product Codes in Customer Emails for WooCommerce follows that argument-only boundary. Free turns on SKU display in verified WooCommerce core customer order emails. Pro, at $39 per year for one site with a 14-day trial, selects from a fixed list of core customer email types and can optionally include core admin order emails.
One argument is not an email redesign
| Approach | What changes | Main failure surface |
|---|---|---|
| One native argument at render time | Whether core customer emails show the existing SKU | Correct recipient and email-type detection |
| Theme template overrides | Copies of WooCommerce email markup | Overrides go stale as WooCommerce templates change |
| Drag-and-drop email builder | Templates, HTML, CSS, per-email design | A full design surface for one toggle |
A merchant who only wants the saved SKU under each item name does not need a template builder, an HTML editor, or new email designs.
Public support reports show the recurring pain. One merchant asked how to restore SKU display in the new WooCommerce email templates, and support said it is not included and needs code or a plugin. Another reported SKUs appearing in admin mail but missing from customer order mail and was pointed to custom code. A third asked how to show the SKU in the standard customer thank-you email and was told it needs customization. These reports document individual incidents only. They do not establish that every store or template version behaves the same way.
Let WooCommerce own the email
The SKU lives on the product or variation, and WooCommerce's official product editor documentation describes that native field. The email markup lives in WooCommerce's templates. The current email-order-items.php source shows the template reading the show_sku argument. A focused helper only answers that argument; it owns no content and no markup.
That rule prevents several dangerous shortcuts:
- Do not write products, variations, SKUs, orders, customers, or templates.
- Do not change recipients, addresses, totals, email HTML, or CSS.
- Do not generate SKUs or add custom labels to fill blank lines.
- Do not touch third-party extension emails, including quote emails.
- Do not run cron, queues, remote APIs, telemetry, or frontend assets.
The settings write requires the exact manage_woocommerce capability and a valid nonce. A request that lacks either saves nothing, keeps the prior valid state, and makes no remote call.
Flip one native argument at render time
WooCommerce builds order-item lines through the native woocommerce_email_order_items_args filter. A narrow helper reads its two owned options, confirms the message is not sent to an administrator, sets only show_sku to true, and returns every other argument byte-identical.
Malformed input, an admin message, a third-party email, or an uncertain context returns the incoming arguments unchanged. Pro identifies the core email type during the documented before-order-table hook and applies a fixed allowlist of customer email types. The default remains customer-only.
Turn on the switch and send one test email
- Open WooCommerce > SKU in Customer Emails.
- Turn on Show product codes in customer emails and save.
- Place a test order for a product that has an SKU, or resend a core customer order email.
- Confirm the SKU appears under each item name in the customer email.
- Confirm the admin new-order email stays native unless Pro explicitly includes it.
- Check an item with no SKU and confirm its line renders without added text or errors.
- Turn the switch off and confirm native emails return immediately.
The settings screen uses labeled controls, works by keyboard at desktop and mobile widths, and announces state to screen readers.
The correct pass condition is existing SKUs in core customer emails only. A helper that also rewrites templates or touches extension emails is solving a wider job with a wider support surface.
Diagnose a missing SKU
| Symptom | Check first | Safe expected result |
|---|---|---|
| No SKU in the customer email | Saved switch, whether the product has an SKU, whether the email is core | SKUs appear in verified core customer emails |
| Admin email unchanged | The customer-only default | Admin emails stay native unless Pro includes them |
| One item shows no code | Whether that item has an SKU | Items without SKUs render natively |
| Quote or extension email unchanged | Whether the email is WooCommerce core | Third-party emails stay native by design |
| Switch off but SKU still shows | Another plugin or a template override | This plugin's argument change disappears at once |
| Settings page missing | Whether WooCommerce is active | One dismissible admin notice, no fatal error |
Start with one core customer order email for an item that has an SKU. If the code appears there, the argument works and the remaining surface is a non-core message that is intentionally untouched. Do not override templates before identifying which email owns the line.
Choose bounded email types, not a builder
Pro can apply the change to chosen core customer email types from a fixed allowlist of at most eight, and can optionally include core admin order emails. It adds no labels, layouts, or template edits, and it never touches third-party emails.
If Pro or the license API is unavailable, the valid Free customer-email behavior continues and Pro-only selections are ignored.
Understand compatibility honestly
The order-items arguments are a shared render surface. WooCommerce's core emails pass through them, but a third-party extension that builds its own message does not have to.
A safe product promise is therefore:
- verified core customer order emails show existing SKUs while the switch is on;
- admin and third-party emails stay native unless a valid Pro setting says otherwise;
- missing SKUs, malformed state, and uncertain contexts render natively;
- no product, order, recipient, template, HTML, or CSS is ever written.
This is more useful than claiming SKUs appear in every email a store sends, which cannot be proven across an open plugin ecosystem.
Test failure and rollback
Release acceptance should cover:
- Core customer emails with and without SKUs, switch on and off.
- Admin emails staying native by default.
- Malformed arguments and uncertain contexts returning everything unchanged.
- Third-party extension emails staying untouched.
- WooCommerce missing causing no fatal error.
- Pro or the license API unavailable leaving Free behavior active.
- Update, downgrade, rollback, deactivation, and uninstall.
- Unchanged products, SKUs, orders, customers, templates, and recipients.
When WooCommerce is missing or inactive, the plugin registers no settings page or email filter and shows one dismissible admin notice. There is no fatal error and no email change.
Because nothing is written, rollback is immediate. Turn the switch off or deactivate, and native email output returns with no residue. Uninstall removes only the plugin's own settings.
Resource boundary
One email needs at most two owned option reads and one changed argument. Nothing loads on the storefront: no JavaScript, no CSS, no remote request, no cron event, no custom table, and no background job. Measure the real hosting stack before a high-volume launch.
The plugin stores no personal data and sends no telemetry. Pro contacts the StoreFixKit license and update API only from authenticated admin requests.
Common mistakes
Overriding email templates in the theme
A copied template goes stale as WooCommerce updates its emails. The argument is the stable switch the template already reads.
Buying a drag-and-drop email builder for one toggle
A builder owns templates, HTML, and CSS. Showing an existing SKU needs one argument, not a design tool.
Editing products or orders to label items
A display need is not a data change. Order and product edits corrupt records and reports.
Generating SKUs to fill blank lines
A display helper shows existing codes. Invented SKUs confuse fulfillment and inventory counts.
Expecting third-party plugin emails to follow
Extension emails build their own messages and stay native by design. Covering them needs per-extension adapters.
Market boundary
The official WooCommerce Marketplace lists a current Email Customizer for WooCommerce offer at $99 per year; the listing reports 900+ active installs and documents a Product SKU toggle. A broad WordPress.org SKU plugin reports 2,000+ active installs. That proves an active email-control category. It does not prove demand or revenue for a narrower argument-only tool, and none of these counts is a payer count.
The commercial hypothesis is that some nontechnical merchants prefer one switch over template overrides or a design suite. Measure StoreFixKit installs, setup completion, verified emails, trial starts, paid conversions, refunds, renewals, and support load. A competitor's price or install count is not StoreFixKit traction.
FAQ
How do I add SKUs to WooCommerce customer order emails?
Turn on one switch that sets the native show_sku argument while WooCommerce renders a verified core customer order email. Existing SKUs appear through the native template; nothing is written.
Why does my admin email or quote-plugin email stay unchanged?
Admin emails stay native by default, and third-party plugins build their own messages. Pro can explicitly include core admin order emails; extension emails are out of scope by design.
What happens when the switch is off or the plugin is deactivated?
The argument stops changing and native email output returns immediately. If only Pro or licensing is unavailable, the valid Free customer-email behavior continues.
Focused plugin
Use the one-job implementation.
Show existing product or variation SKU codes through WooCommerce's native order-items template in verified core customer emails, without generating codes or editing products, orders, recipients, templates, HTML, or CSS.