Customer Name in Order Email Subjects for WooCommerce: safe setup, failure cases, and rollback

Direct answer

Filter the subject for the exact native WooCommerce email you intend to change. Read the billing first and last name from the order, normalize whitespace, reject line breaks and control characters, limit the result, and return the incoming subject unchanged when any value is unsafe. Do not change recipients, headers, bodies, SMTP, or order data. For more email types, use separate bounded templates with a small allowlist of tokens instead of evaluating arbitrary placeholders or order metadata.

Customer Name in Order Email Subjects for WooCommerce follows that model. Free appends the valid billing name only to the native administrator New Order subject. Pro adds bounded templates for eight native order email IDs and five fixed tokens for $39 per year on one site after a 14-day no-card trial.

Choose the smallest suitable approach

Merchants ask for this exact detail

One merchant wanted the customer name in the administrator New Order subject so messages were easier to track and search.

Another asked for customer-name or email placeholders in WooCommerce subjects and was told core did not provide those placeholders.

A third wanted order-specific booking detail in an email subject and was directed toward custom code or another plugin.

These are individual support cases. They establish a real task, not broad market demand, paid conversion, or StoreFixKit sales.

Change the subject, not the email system

WooCommerce documents native messages and recipients in its email settings guide. Each native email class owns a subject path and a delivery path.

A subject helper should touch only the subject filter. It should not claim ownership of:

• whether an email is enabled;
• who receives it;
• the From or Reply-To headers;
• HTML or plain-text body templates;
• attachments;
• SMTP authentication;
• queues or retries;
• provider delivery or spam placement.

This separation makes rollback immediate: remove the filter and the incoming WooCommerce subject returns.

Set up the Free behavior

1. Confirm WooCommerce is active.
2. Use a staging store or safe mail-testing environment.
3. Install and activate Free 0.1.9.
4. Open WooCommerce > Order Email Subjects.
5. Enable Add the billing name to administrator New Order subjects.
6. Save the setting.
7. Create an order with a billing first and last name.
8. Trigger the native administrator New Order email.
9. Confirm the subject contains the normalized name once.
10. Confirm the recipient and body are unchanged.
11. Disable the setting and confirm the native subject returns.

The release fixture exercised the real subject filter and produced a subject containing Avery Stone. That proves the tested hook path, not delivery through every SMTP provider.

Validate the name before using it

Free combines the billing first and last name only after validation.

• The normalized name is limited to 80 characters.
• Repeated whitespace is collapsed.
• Carriage return, line feed, and NUL are rejected.
• Unsafe control characters are rejected.
• Unicode line separator U+2028 is rejected.
• Unicode paragraph separator U+2029 is rejected.
• If either name part is unsafe, the complete incoming subject is returned unchanged.
• A name already present in the subject is not appended again.

Rejecting the whole name is safer than keeping one fragment from an unsafe input.

Use Pro templates within an allowlist

Pro accepts optional plain-text templates up to 180 characters for eight native email IDs:

• New order;
• Cancelled order;
• Failed order;
• Order on hold;
• Processing order;
• Completed order;
• Refunded order;
• Customer invoice.

Only five tokens are allowed:

• {customer_name}
• {order_number}
• {order_total}
• {payment_method}
• {shipping_method}

Leave a template empty to keep Free or native behavior. Unknown, malformed, or unsafe input falls back instead of being evaluated.

Free continues locally if Pro, Stripe, the network, or the license service is unavailable.

Know the support boundary

The product supports those eight native WooCommerce subject filters. Custom email IDs, newsletter messages, CRM notifications, booking-plugin emails, marketplace vendor emails, and email customizers can use different paths.

The plugin does not send or resend email. A missing message still requires checks for WooCommerce enablement, recipient settings, SMTP logs, DNS authentication, provider suppression, and spam filtering.

Troubleshoot by symptom

Use redacted test data. Do not troubleshoot with a real customer's private details when a staging order can reproduce the issue.

Roll back without touching orders

1. Deactivate Pro and test the administrator New Order subject.
2. Turn off the Free switch.
3. Trigger a safe test order email.
4. Confirm the native subject returns.
5. Confirm the recipient, body, order, and customer record are unchanged.
6. Deactivate Free if further isolation is needed.
7. Install a previous deterministic ZIP only for a version rollback.

Rollback does not edit or resend past email. Default uninstall preserves settings. Defining STOREFIXKIT_DELETE_DATA as true removes only this product's owned settings and license/update options.

Safety, privacy, and measured resource use

• Setting writes require manage_woocommerce and a valid WordPress nonce.
• Names are limited to 80 characters and final subjects to 180.
• Header-breaking characters and unsafe controls are rejected.
• Pro accepts only eight email IDs and five tokens.
• Recipients, bodies, headers, SMTP settings, orders, and customers are never written.
• Email generation makes no StoreFixKit or third-party request.
• There is no custom table, cron, queue, telemetry, frontend asset, email log, or customer-data store.

In one Batch 19 demo-server benchmark, 25 inactive and 25 active requests all returned HTTP 200. All six Batch 19 plugin trees together added zero database queries, zero database writes, and zero plugin HTTP calls. Median duration changed by +3.18ms and median peak memory by +2 MB. That benchmark measured ordinary site requests in one environment, not every mail stack.

Common mistakes

1. Editing the email body template to change only the subject.
2. Concatenating raw customer input into a mail header.
3. Allowing arbitrary metadata or executable placeholders.
4. Assuming a customizer plugin uses native subject filters.
5. Treating a subject plugin as an SMTP or deliverability tool.
6. Sending private order data in a support request.

Market evidence boundary

The captured WooCommerce Marketplace page listed Email Customizer for WooCommerce at $99 per year. That proves a broad paid email-customization category exists. It does not prove sales for this narrow subject-line function.

The exact captured customer-name subject phrases were unreported. The broader woocommerce email customizer phrase reported about 140 US searches per month and a $41.61 CPC. A broad phrase cannot be converted into demand for this exact feature.

Captured WordPress.org data reported 50,000 active installs for YayMail and 100,000 for Kadence WooCommerce Email Designer. Those are broad design products. Their adoption cannot be attributed to customer names in subjects.

The parent WooCommerce snapshot reported 7,000,000 active installs. That is ecosystem size, not a buyer forecast.

This product remains a conditional launch hypothesis. It needs verified payment and improving conversion evidence within 90 days. The $10,000 monthly revenue target is a selection gate, not a likely or guaranteed result.

Frequently asked questions

Does this change who receives an email?

No. It filters only the subject string.

Does it send or resend messages?

No. WooCommerce and the configured mail system remain responsible for delivery.

Can Pro use arbitrary order metadata?

No. It uses five fixed tokens to avoid exposing or guessing private data.

What happens when a billing name is unsafe?

The incoming WooCommerce subject is returned unchanged.

What should I send support?

Use StoreFixKit Support and include the email type, redacted expected and actual subject, relevant customizer plugins, plugin versions, WooCommerce version, and delivery status without credentials. Never send passwords, SMTP secrets, API keys, full customer details, order exports, full headers, or a complete license key.