The Problem
A client pinged me on Friday afternoon: orders were flowing through the store, payments were captured in Stripe, but no one was getting an email. Not the customer, not the admin, not the warehouse address that picks up shipping notifications. The store had upgraded WordPress to 7.0 the night before and WooCommerce had quietly bumped from 10.7 to 10.8 with the auto-update.
The "New order" email looked fine in the WooCommerce settings preview. The send-test button delivered. Real checkouts? Silent.
Here is what the log showed when I turned on email debugging with WP Mail Logging:
[2026-05-30 16:42:11] Email queued: WC_Email_New_Order
[2026-05-30 16:42:11] PHP Warning: Undefined array key "block_template"
in wp-content/plugins/woocommerce/src/Internal/EmailEditor/BlockEmailRenderer.php on line 184
[2026-05-30 16:42:11] Email body: (empty)
[2026-05-30 16:42:11] wp_mail() returned true
wp_mail was returning true because the call itself succeeded, but the body was empty. Some MTAs drop empty messages on the floor, others deliver them to spam. Either way, nobody saw them.
Why It Happens
WordPress 7.0 promoted the block-based email editor out of experimental status and WooCommerce 10.8 switched the default rendering pipeline to use it for all transactional emails. The classic HTML templates in templates/emails/ still exist, but they are now opt-in fallbacks rather than the primary renderer.
The new pipeline expects every email template to have a registered block template stored in the database, keyed by the email ID (new_order, customer_processing_order, etc.). On a fresh WooCommerce install those entries are seeded by the activation hook. On an upgrade from 10.7, the seeder never runs because WooCommerce considers the email already configured: it only checks for the existence of the email class, not the template.
So the renderer asks the database for the block_template key, finds nothing, throws an undefined-key warning, and returns an empty string. The email object then hands that empty string to wp_mail, which dutifully sends a blank message.
The classic fallback would catch this except WooCommerce 10.8 also flipped the woocommerce_email_use_block_editor option to yes during upgrade, which disables the classic path entirely. That is documented in passing in the WooCommerce 10.8 release notes, but the upgrade notice does not warn you that your existing emails will go silent until the seeder runs.
The Fix
Three options depending on how much downtime you can tolerate.
Option 1: Force the seeder to run. This is the fastest path and what I shipped on the client site. Drop this into a must-use plugin file at wp-content/mu-plugins/woo-email-seed-fix.php:
<?php
/**
* Re-seed WooCommerce block email templates after 10.8 upgrade.
*/
add_action( 'admin_init', function () {
if ( get_option( 'woo_emails_reseeded_10_8' ) === 'yes' ) {
return;
}
if ( ! class_exists( '\Automattic\WooCommerce\Internal\EmailEditor\TemplateSeeder' ) ) {
return;
}
$seeder = wc_get_container()->get(
\Automattic\WooCommerce\Internal\EmailEditor\TemplateSeeder::class
);
$seeder->seed_default_templates( true );
update_option( 'woo_emails_reseeded_10_8', 'yes' );
} );
Hit /wp-admin/ once as an admin. The seeder runs, populates every missing block_template entry with the default markup, and sets the flag so it never runs again. Place a test order and the email body fills in correctly.
Option 2: Roll back to classic emails. If you have customised the HTML templates in your theme's woocommerce/emails/ directory and do not want to migrate them yet, flip the option back:
add_action( 'init', function () {
update_option( 'woocommerce_email_use_block_editor', 'no' );
} );
This restores the classic renderer and your theme overrides start working again immediately. The trade-off is you will need to migrate eventually because WooCommerce 11.0 removes the classic path entirely.
Option 3: Migrate template by template. For sites where the classic templates have heavy customisation, the cleanest long-term move is to open each email in WooCommerce → Settings → Emails and click "Edit in block editor". The first time you do, WooCommerce reads your existing HTML override, converts it to blocks, and writes the result to block_template. Save, and that email is migrated. Repeat for each one. The conversion is lossy on inline styles, so review carefully before going live.
Verify the fix before walking away. Place a real test order using a card-on-file Stripe test, watch the inbox, and confirm the rendered HTML is the expected template — not the blank shell or the default WooCommerce template if you had customisations:
wp eval 'WC()->mailer()->emails["WC_Email_New_Order"]->trigger( 12345 );'
Replace 12345 with a real order ID. The email should arrive within seconds and contain product line items, customer details, and your branding.
The Lesson
Block-based emails in WooCommerce 10.8 silently break on upgrade because the template seeder skips already-installed stores. Either re-run the seeder via a one-line mu-plugin, flip back to classic emails until you can migrate properly, or migrate template by template through the editor. Whichever path you take, send a real test order before declaring the upgrade complete. wp_mail returning true is not the same as the customer receiving an email.
If your WooCommerce upgrade left transactional emails broken and the store is losing trust with every silent order, that is a project I get paid to fix fast. See my services. For another upgrade-related WooCommerce issue from this cycle, read WooCommerce 10.7 short description missing in admin.
Order emails going silent after a WooCommerce upgrade? Get it fixed.