WooCommerce email filters can be changed by themes, mu-plugins, SMTP plugins, custom order status plugins, payment gateways, subscriptions, and email customizers. A rollback kit keeps the team from disabling the wrong plugin or losing proof while orders are still coming in.
Use this when a WooCommerce update, snippet, email customizer, or status plugin causes missing recipients, wrong subjects, blank templates, duplicate emails, or order emails that never reach the inbox.
Quick answer
WooCommerce Email Filter Rollback Kit should be handled with a narrow evidence-first workflow: capture baseline, find email hooks, rollback one layer, then verify the result before making broader changes.
What to check first
- List every hook touching WooCommerce email recipients, subjects, headings, enable flags, templates, and attachments.
- Export the current plugin list, theme version, mu-plugin list, and SMTP provider logs before making changes.
- Create a test order for each affected status, including failed, refunded, completed, canceled, and custom statuses.
- Rollback one layer at a time, starting with the newest snippet, mu-plugin, or email customization.
- Record the before and after evidence for WooCommerce logs, order notes, SMTP event IDs, and inbox receipts.
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 baseline | List every hook touching WooCommerce email recipients, subjects, headings, enable flags, templates, and attachments. | The rollback changes only one email layer at a time. |
| Find email hooks | Export the current plugin list, theme version, mu-plugin list, and SMTP provider logs before making changes. | Each affected email has a test order ID, order note, SMTP event, and inbox receipt. |
| Rollback one layer | Create a test order for each affected status, including failed, refunded, completed, canceled, and custom statuses. | The team can name which hook, plugin, or snippet caused the failure. |
| Retest order states | Rollback one layer at a time, starting with the newest snippet, mu-plugin, or email customization. | Temporary debug logs and disabled test plugins are removed after verification. |
Why this usually happens
- Several plugins can filter the same WooCommerce email object in different priorities.
- A custom order status can use a separate email class that is easy to miss.
- A payment failure can create an order note without producing the customer email.
- SMTP delivery proof does not prove the WooCommerce email payload was correct.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
grep -R "woocommerce_email_" wp-content/themes wp-content/plugins wp-content/mu-plugins -n > /tmp/wc-email-hooks.txt
wp plugin list --fields=name,version,status > /tmp/plugin-list-before-email-rollback.txt
# Keep SMTP event IDs and test order IDs with the rollback notes.
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 baseline
- Find email hooks
- Rollback one layer
- Retest order states
- Document final state
What to tell the client or owner
Give the owner a rollback record with the exact layer changed, the test order used, and the proof that email works again.
Production verification checklist
- The rollback changes only one email layer at a time.
- Each affected email has a test order ID, order note, SMTP event, and inbox receipt.
- The team can name which hook, plugin, or snippet caused the failure.
- Temporary debug logs and disabled test plugins are removed after verification.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix WordPress and WooCommerce email delivery.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references