dev

Thanks for the reply.

I appreciate you passing this to your development team.

For context, the concern on our side is not only the time taken when wp_mail() is actually called, but the broader runtime overhead we are seeing on a busy WooCommerce multisite environment and less busy standalone wp sites with minimal plugins. We found Post SMTP being worse in terms of performance the woocommerce itself. This includes plugin-related hooks, option access, logging/history features, and any work performed during normal frontend or AJAX requests.

Our environment is:

WordPress multisite & standalone WP installs
WooCommerce-enabled store(s) (Site 1 & 2)
Object cache enabled via Redis
Page caching enabled via LiteSpeed
New Relic monitoring in place

Versions/configuration:

WordPress: 6.9.4
PHP: 8.3.30
WooCommerce: 10.7.0
Post SMTP: Latest
Logging enabled: Yes

What we are trying to determine is whether any Post SMTP functionality is contributing measurable overhead outside of actual wp_mail() execution, particularly on frontend/admin-ajax requests in a plugin-heavy WooCommerce setup.

If helpful, I can provide (Via email or offline):

1. a list of active plugins on the affected sites
2. New Relic traces / timings
3. the specific Post SMTP features currently enabled

If there are any recommended settings for reducing runtime overhead in a high-traffic WooCommerce multisite setup (our primary concern), please let us know.

We have however now moved 16 sites of post SMTP so only have historical data only.

We’ve now identified a second fatal in the same plugin during WooCommerce Store API cart requests.

This one occurs on:

GET /wp-json/wc/store/v1/cart?_locale=user

Fatal:
Call to a member function get_shipping_country() on null

File:
admin/selection_rules/rules/country.php:115

From the plugin code, the country rule does:

$user_country = WC()->customer->get_shipping_country();

with no null check on WC()->customer.

Combined with the earlier fatal on:

WC()->session->has_session()

during:

POST /wp-json/wc/store/v1/cart/add-item

this suggests the plugin is assuming classic WooCommerce customer/session objects are always present during Store API requests.

WooCommerce’s Cart and Checkout blocks use the Store API for normal frontend cart activity, so these requests are part of expected customer browsing, not necessarily bot traffic. The issue appears to be that the plugin is not handling Store API contexts defensively.

At this point we have two separate Store API fatals in the plugin:

1. StoreApi\SessionHandler::has_session()
2. WC()->customer being null in the country rule

That looks like a broader Store API compatibility issue rather than an isolated edge case.

Great, thank you !

Thanks for checking.

I’ve gone back through the stack trace and there are two points that may help narrow this down.

The fatal is not occurring on the classic checkout flow. It is occurring during a Store API cart request on:

/wp-json/wc/store/v1/cart/add-item

In our case, the call stack shows WooCommerce recalculating cart totals during that request, which then triggers your fee callback:

WC_Cart->calculate_fees()
→ Apply_Payment_Processing_Fee->apply_gateway_fee()

At that point, WC()->session is an instance of Automattic\WooCommerce\StoreApi\SessionHandler, not the classic WC_Session_Handler. The fatal is specifically:

Call to undefined method Automattic\WooCommerce\StoreApi\SessionHandler::has_session()

So the immediate issue is not whether the endpoint exists, but whether the plugin assumes that WC()->session always exposes the classic handler methods during Store API / Blocks requests.

For reference, WooCommerce currently has an open core bug describing the same problem in isolation, including the same has_session() fatal when a Store API cart request is made and code calls WC()->session->has_session(). That report notes that the Store API session handler is not interface-compatible with the default session handler in this scenario. (GitHub)

A few details that may explain why you are not seeing it consistently:

1. It only appears when the plugin’s fee logic actually runs during cart recalculation on a Store API request.
2. A traditional add-to-cart flow may not reproduce it, even if the product page uses modern WooCommerce components elsewhere.
3. Reproduction is more reliable when testing against the real Blocks / Store API cart flow rather than just calling the endpoint in a way that does not reach the same fee path.

A minimal reproduction path on our side is:

1. Activate WooCommerce and Conditional Extra Fees for WooCommerce.
2. Ensure the fee logic is enabled in a way that causes apply_gateway_fee() to run during cart totals calculation.
3. Add a product to cart through the Store API / Blocks flow so WooCommerce recalculates fees on /wc/store/v1/cart/add-item.
4. The request reaches apply_gateway_fee(), where WC()->session->has_session() is called on Automattic\WooCommerce\StoreApi\SessionHandler, producing the fatal above.

Based on the trace, the safe fix seems to be to avoid assuming WC()->session always supports has_session() in Store API contexts, for example by adding a guard such as method_exists( WC()->session, 'has_session' ) before calling it, or by using a Store API-safe approach that does not depend on that classic session handler method being present.

If helpful, I can provide the exact stack trace and environment details from the site where this occurs via email/offline.

Hello,

All of our templates have the modern block configured. After the WC update, all emails being sent for orders etc were using the WC default templates?

Toggling enable/disabled yaymail has fixed the issue for all but the new order dev/admin emails.

It seems toggling sorts some of the template but not all. Is there a fix for this ?

Ok, so if this plugin breaks woocommerce stripe refunds (which is an official plugin) can you make clear its not compatible and therefor it should not be used?

We’ll have to remove this plugin because of this issue.