Failed Orders won’t use Email Builder template

We have now completed a technical investigation of the issue, and the root cause has been identified. This is an **XStore Email Builder bug**, not a hosting, Gmail, SMTP, WooCommerce trigger, or template-configuration issue.

The relevant findings are:

* WooCommerce administrator Failed Order email:

* Class: WC_Email_Failed_Order
* ID: failed_order
* Enabled
* Recipient: sales@choovio.com

* WooCommerce also sends the paired customer notification:

* Class: WC_Email_Customer_Failed_Order
* ID: customer_failed_order

* XStore Failed Order template:

* Post ID: **20204**
* Published
* Stored email type: failed_order
* No duplicate published failed_order template exists

* XStore Default template:

* Post ID: **14545**
* Published

For actual failed order **#40003**, the transactional log shows the notifications were generated consecutively in this order:

1. customer_failed_order
2. failed_order

There is no published XStore customer_failed_order template.

The problem is in XStore Core:

packages/woocommerce-email-template-customizer/includes/email-trigger.php

The singleton:

VIWEC\INC\Email_Trigger

retains Default-template fallback state between the two consecutive WooCommerce emails.

trigger_recipient() resets $template_id, but does not clear the previous $use_default_temp state.

As a result:

1. customer_failed_order has no mapped XStore template and enables the Default fallback.
2. The immediately following failed_order correctly finds template **20204**.
3. The correct XStore Failed Order subject is therefore used.
4. However, the stale Default fallback flag remains set.
5. During rendering, the body is replaced with Default template **14545**.

This exactly matches the real received email: the XStore header/footer and correct Failed Order subject are present, but the specific Failed Order template body is missing and the Default fallback body is used instead.

We also verified:

* XStore preview of template 20204 renders correctly.
* XStore’s own test of a failed order sends the complete rich template correctly.
* No child-theme override or other email-customizer plugin is causing the template selection issue.
* SMTP/mail transport is not involved.
* Developer Mode is off.
* No relevant XStore Patcher fix is currently available.
* XStore 9.7.7 / Core 5.7.7 is available, but its changelog does not identify a fix for this issue.

No production settings or vendor files have been modified.

Please have your development team provide an **official patch** that resets the Default fallback state at the beginning of each email processing cycle — specifically the stale $use_default_temp state in Email_Trigger::trigger_recipient().

At this stage, I do not need additional generic troubleshooting suggestions. The bug has been isolated to the XStore Email Builder implementation and reproduced with technical evidence.

Please either:

1. provide the official patch;
2. confirm that this is fixed in a specific XStore/Core release and identify that fix;
3. or have your developer log in and apply the appropriate correction directly.

Given the 24-hour response cycle, I would appreciate this being escalated directly to the XStore developer responsible for the WooCommerce Email Builder rather than continuing with another round of configuration checks.

The FEX.NET archive you provided is not accessible. It displays “Limited access — for extension of rights, contact the owner,” so I cannot download or test the modified XStore Core package.

In the meantime, we completed the technical investigation ourselves and confirmed the issue is caused by stale Email Builder singleton state between customer_failed_order and the immediately following administrator failed_order.

We implemented a small update-safe workaround using XStore’s existing public API at priority 9, immediately before XStore’s priority-10 handler:

VIWEC\INC\Email_Trigger::init()->reset_template_id( array() );

This successfully restores the complete XStore Failed Order template, and regression testing confirmed that the customer Failed Order notification and unrelated New Order templates continue working correctly.

Please now confirm one of the following:

Does XStore Core 5.7.7 contain an official fix for this specific state-leak issue?
If yes, please identify the exact file/function or changelog item.
If not, please attach your modified XStore Core archive directly to this support ticket/private area rather than using FEX.NET, and provide the exact code change/diff your developer made.

The expected permanent correction is to reset the Email Builder state at the start of each Email_Trigger::trigger_recipient() processing cycle, including $use_default_temp, $template_id, and $unique.

At this stage the issue is technically isolated and reproduced, so I do not need further generic troubleshooting steps. I need confirmation of the official fix and a usable patch/package.

Thanks, Jack.

We now have enough technical evidence to separate **two different XStore issues**:

## 1. Failed Order Email Builder bug

We confirmed the problem is caused by stale state inside:

VIWEC\INC\Email_Trigger

WooCommerce sends the paired failed-order notifications in this order:

1. customer_failed_order
2. failed_order

On our site there is no published XStore template for customer_failed_order, so XStore enables its Default-template fallback. The following administrator failed_order correctly finds our published XStore template, but the previous fallback state remains set and replaces the body with the Default template.

Our published Failed Order template is:

* Post ID: **20204**
* Email type: failed_order
* Subject: Choovio: Order Failed: #{order_number}

The production workaround we implemented is intentionally very small and update-safe:

add_filter(
    'woocommerce_email_recipient_failed_order',
    function ( $recipient, $order, $email ) {
        if ( class_exists( '\VIWEC\INC\Email_Trigger' ) ) {
            \VIWEC\INC\Email_Trigger::init()->reset_template_id( array() );
        }

        return $recipient;
    },
    9,
    3
);

XStore registers its own trigger_recipient() at priority 10, so this clears the singleton state immediately before XStore processes the administrator Failed Order email.

We verified from the installed XStore source that reset_template_id() clears:

$this->use_default_temp = '';
$this->template_id      = '';
$this->unique           = [];

The workaround has been tested successfully in production:

* Failed Order rich template: PASS
* Customer Failed Order notification: PASS
* New Order template regression test: PASS
* Gmail delivery with full imagery/order details: PASS
* No SMTP, recipient, order-data, or vendor-file modifications

We also tested XStore Theme **9.7.7** / Core **5.7.7** and confirmed that the public 5.7.7 release does **not** contain this fix. Its affected email-trigger.php was byte-for-byte identical to the previous 5.7.6 version.

Your newly supplied custom archive does appear to implement the correct broader upstream approach by resetting state at the beginning of the email-processing cycle. That is the correct place for the permanent XStore fix.

Please confirm whether your development team intends to include that state reset in the **next official XStore Core release**, and if possible provide the expected version number.

—

## 2. Separate serious regression in XStore 9.7.7 / Core 5.7.7

Unfortunately, when we updated production to the latest versions, the website frontend became severely corrupted.

The update sequence was performed correctly:

1. XStore Theme **9.7.6 → 9.7.7**
2. XStore Core **5.7.6 → 5.7.7**

Immediately afterward, the site experienced major frontend/theme-layout problems, including:

* Header/navigation layout corruption
* Incorrect/default-looking XStore header elements
* Footer layout collapsing into a narrow column
* Default XStore footer branding appearing
* General theme/layout styling becoming inconsistent
* XStore icon font requests returning errors

We investigated the usual cache/CSS causes:

* WP Rocket Remove Unused CSS was disabled
* Used CSS was cleared
* WP Rocket page cache was cleared
* WP Rocket Preload remained OFF
* Normal XStore 9.7.7 stylesheets were present and loading
* Disabling our custom Failed Order workaround plugin did **not** correct the frontend

We then restored the SiteGround backup from immediately before the XStore update.

After the restore:

* XStore Theme returned to **9.7.6**
* XStore Core returned to **5.7.6**
* The website frontend immediately returned to normal
* Our Choovio XStore Failed Order Email Fix plugin remained ACTIVE

This conclusively shows that our email workaround was **not** responsible for the frontend problem.

The frontend regression was introduced by the XStore **9.7.7 / Core 5.7.7 update sequence**.

We have therefore disabled/avoided automatic XStore updates and are currently keeping production on:

* XStore Theme 9.7.6
* XStore Core 5.7.6
* Choovio XStore Failed Order Email Fix 1.0.0 active

Please have your development team investigate this frontend regression as a separate issue before asking us to update production again.

If you need additional evidence, we can provide:

* Before/after frontend screenshots
* Browser console/network captures
* Installed version screenshots
* Theme/Core update screenshots
* The Failed Order workaround plugin source
* XStore 5.7.6 / 5.7.7 source comparison
* Technical deployment/test report
* SiteGround restore evidence

For the frontend regression, please let us know specifically what your developers need us to provide so they can investigate it directly.

Given the amount of evidence now available, I would appreciate both items being escalated to the relevant XStore developer rather than continuing with general troubleshooting steps.

The two requested outcomes are:

1. **Failed Order Email Builder:** confirm the official XStore Core version that will include the state-reset fix.
2. **XStore 9.7.7 / Core 5.7.7 frontend regression:** identify and correct the update-related theme/layout break before we attempt the update again.