Title: dev's Replies | WordPress.org

---

# dev

  [  ](https://wordpress.org/support/users/devksec/)

 *   [Profile](https://wordpress.org/support/users/devksec/)
 *   [Topics Started](https://wordpress.org/support/users/devksec/topics/)
 *   [Replies Created](https://wordpress.org/support/users/devksec/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/devksec/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/devksec/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/devksec/engagements/)
 *   [Favorites](https://wordpress.org/support/users/devksec/favorites/)

 Search replies:

## Forum Replies Created

Viewing 15 replies - 1 through 15 (of 264 total)

1 [2](https://wordpress.org/support/users/devksec/replies/page/2/?output_format=md)
[3](https://wordpress.org/support/users/devksec/replies/page/3/?output_format=md)…
[16](https://wordpress.org/support/users/devksec/replies/page/16/?output_format=md)
[17](https://wordpress.org/support/users/devksec/replies/page/17/?output_format=md)
[18](https://wordpress.org/support/users/devksec/replies/page/18/?output_format=md)
[→](https://wordpress.org/support/users/devksec/replies/page/2/?output_format=md)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Post SMTP – Complete Email Deliverability and SMTP Solution with Email Logs, Alerts, Backup SMTP & Mobile App] Post SMTP v3.9.1 – Performance Findings](https://wordpress.org/support/topic/post-smtp-v3-9-1-performance-findings/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/post-smtp-v3-9-1-performance-findings/#post-18889681)
 * Hello,
   We have chosen to remove postSMTP from all 16 sites and the performance
   concerns have now been removed from newrelic reports. We can only provide partial
   historical information from new relic but these issues were seen from low traffic
   basic sites, to our most complex and plugin heavy multisite. Given this was seem
   across a wide range, we do not believe its site specific.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Post SMTP – Complete Email Deliverability and SMTP Solution with Email Logs, Alerts, Backup SMTP & Mobile App] Post SMTP v3.9.1 – Performance Findings](https://wordpress.org/support/topic/post-smtp-v3-9-1-performance-findings/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/post-smtp-v3-9-1-performance-findings/#post-18888051)
 * 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 installsWooCommerce-enabled store(s) (
   Site 1 & 2) Object cache enabled via RedisPage caching enabled via LiteSpeedNew
   Relic monitoring in placeVersions/configuration:WordPress: 6.9.4 PHP: 8.3.30WooCommerce:
   10.7.0Post SMTP: Latest Logging enabled: YesWhat 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 sites2. New Relic traces / timings3.
   the specific Post SMTP features currently enabledIf 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[PiWeb Conditional cart fee / Extra charge rule for WooCommerce] Uncaught Error](https://wordpress.org/support/topic/uncaught-error-56/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/uncaught-error-56/#post-18886468)
 * Thanks. To be clear, this was observed on a live production site rather than 
   an isolated test install, so I cannot yet give you a guaranteed single-click 
   sandbox repro.
 * What I can give you is the exact plugin version, the failing code paths, the 
   request endpoints, and the configuration conditions that make the issue reachable.
 * Plugin version:
   `conditional-extra-fees-for-woocommerce 1.1.49.42`
 * We have now seen two separate fatals in your plugin during WooCommerce Store 
   API cart requests.
    1. Payment processing fee path
 * File:
   `public/class-apply-payment-processing-fee.php:28`
 * Code:
 *     ```wp-block-code
       if (isset(WC()->session) && WC()->session->has_session()) {
       ```
   
 * Failing request:
   `POST /wp-json/wc/store/v1/cart/add-item`
 * Fatal:
   `Call to undefined method Automattic\WooCommerce\StoreApi\SessionHandler::
   has_session()`
 * This path becomes reachable when:
    - WooCommerce is recalculating cart fees during a Store API cart request, and
    - the payment processing fee feature is enabled so `apply_gateway_fee()` runs.
 *  2. Country rule path
 * File:
   `admin/selection_rules/rules/country.php:115`
 * Code:
 *     ```wp-block-code
       $user_country = WC()->customer->get_shipping_country();
       ```
   
 * Failing request:
   `GET /wp-json/wc/store/v1/cart?_locale=user`
 * Fatal:
   `Call to a member function get_shipping_country() on null`
 * This path becomes reachable when:
    - cart fees are calculated during a Store API cart/cart refresh request, and
    - at least one fee rule uses the `Country/Continent` condition so `Pi_cefw_selection_rule_country-
      >conditionCheck()` runs.
 * So while I cannot yet provide a clean sandbox repro from our side, the expected
   reproduction setup on your side should be:
 * For the first issue:
    1. Fresh WooCommerce install.
    2. Activate only WooCommerce + Conditional Extra Fees for WooCommerce.
    3. Enable a payment processing fee rule so `Apply_Payment_Processing_Fee->apply_gateway_fee()`
       is active.
    4. Trigger Store API cart add-to-cart flow via `/wp-json/wc/store/v1/cart/add-item`.
    5. Observe whether `WC()->session` is a Store API session handler on that request
       and whether `has_session()` is called.
 * For the second issue:
    1. Fresh WooCommerce install.
    2. Activate only WooCommerce + Conditional Extra Fees for WooCommerce.
    3. Create any fee rule using the `Country/Continent` condition.
    4. Open the cart or trigger `/wp-json/wc/store/v1/cart?_locale=user`.
    5. Observe whether `WC()->customer` is null when `conditionCheck()` runs.
 * Even if you cannot reproduce immediately, both code paths currently assume classic
   WooCommerce objects are always available in Store API requests:
    - `WC()->session->has_session()`
    - `WC()->customer->get_shipping_country()`
 * Those assumptions are what our production traces are failing on.
 * If helpful, I can also send the full stack traces for both errors.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[PiWeb Conditional cart fee / Extra charge rule for WooCommerce] Uncaught Error](https://wordpress.org/support/topic/uncaught-error-56/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [1 month, 3 weeks ago](https://wordpress.org/support/topic/uncaught-error-56/#post-18886013)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WPML Multilingual & Multicurrency for WooCommerce] Performance query — recalculate_totals() on every](https://wordpress.org/support/topic/performance-query-recalculate_totals-on-every/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [1 month, 3 weeks ago](https://wordpress.org/support/topic/performance-query-recalculate_totals-on-every/#post-18882421)
 * Great, thank you. We’ll continue to test it but so far the performance benefit
   has been noticeable which is great.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[PiWeb Conditional cart fee / Extra charge rule for WooCommerce] Uncaught Error](https://wordpress.org/support/topic/uncaught-error-56/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [1 month, 3 weeks ago](https://wordpress.org/support/topic/uncaught-error-56/#post-18882417)
 * Great, thank you !
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Ultimate Gift Cards for WooCommerce] : Performance issue- wps_wgm_wc_shipping_enabled() causes excessive DB queries](https://wordpress.org/support/topic/performance-issue-wps_wgm_wc_shipping_enabled-causes-excessive-db-queries/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [1 month, 3 weeks ago](https://wordpress.org/support/topic/performance-issue-wps_wgm_wc_shipping_enabled-causes-excessive-db-queries/#post-18881017)
 * A more fundamental improvement: when a gift card product’s delivery methods are
   email or downloadable only (no physical shipping option), the plugin should set
   the WooCommerce _virtual meta to ‘yes’ on the product. This lets WooCommerce 
   core handle shipping exclusion natively via needs_shipping() — no filter needed
   at all.
 * The wc_shipping_enabled filter would then only be necessary for the edge case
   where a gift card offers a physical “Shipping” delivery method alongside digital
   options, and even then it should be cached as described above.
 * This could be implemented as:
    - Automatically setting _virtual = ‘yes’ when a gift card product is created
      and only has digital delivery methods configured
    - Updating the flag when delivery method settings change
    - Documenting that store owners should mark digital-only gift cards as Virtual
 * On our end, we’ve marked our digital gift card product as Virtual and removed
   the filter via a code snippet, which resolved the performance issue completely.
   But most store owners won’t have profiling tools to identify this, so the plugin
   should handle it by default.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[PiWeb Conditional cart fee / Extra charge rule for WooCommerce] Uncaught Error](https://wordpress.org/support/topic/uncaught-error-56/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [1 month, 3 weeks ago](https://wordpress.org/support/topic/uncaught-error-56/#post-18879871)
 * 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](https://github.com/woocommerce/woocommerce/issues/63053?utm_source=chatgpt.com))
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[YayMail - WooCommerce Email Customizer] Woocommerce updated, now template don’t apply](https://wordpress.org/support/topic/woocommerce-updated-now-template-dont-apply/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [5 months, 4 weeks ago](https://wordpress.org/support/topic/woocommerce-updated-now-template-dont-apply/#post-18755763)
 * Looks to potentially fix it, just waiting to hear back from customer emails are
   tests show ok. !
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[YayMail - WooCommerce Email Customizer] Woocommerce updated, now template don’t apply](https://wordpress.org/support/topic/woocommerce-updated-now-template-dont-apply/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [5 months, 4 weeks ago](https://wordpress.org/support/topic/woocommerce-updated-now-template-dont-apply/#post-18755010)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[YayMail - WooCommerce Email Customizer] Woocommerce updated, now template don’t apply](https://wordpress.org/support/topic/woocommerce-updated-now-template-dont-apply/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [6 months ago](https://wordpress.org/support/topic/woocommerce-updated-now-template-dont-apply/#post-18753372)
 * Hello,
   Someone else reported it on the last woocommerce update here: [https://wordpress.org/support/topic/templates-get-removed-when-updating-woo/](https://wordpress.org/support/topic/templates-get-removed-when-updating-woo/)
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[YayMail - WooCommerce Email Customizer] Woocommerce updated, now template don’t apply](https://wordpress.org/support/topic/woocommerce-updated-now-template-dont-apply/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [6 months ago](https://wordpress.org/support/topic/woocommerce-updated-now-template-dont-apply/#post-18752673)
 * It seems toggling sorts some of the template but not all. Is there a fix for 
   this ?
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[YayMail - WooCommerce Email Customizer] Woocommerce updated, now template don’t apply](https://wordpress.org/support/topic/woocommerce-updated-now-template-dont-apply/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [6 months ago](https://wordpress.org/support/topic/woocommerce-updated-now-template-dont-apply/#post-18751905)
 * We’ve had to toggle on/off all templates to get them to work again. Seems other
   users have this issue also from other tickets.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Sequential Order Number for WooCommerce] Issue with WC Stripe plugin & refunds](https://wordpress.org/support/topic/issue-with-wc-stripe-plugin-refunds/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [8 months, 1 week ago](https://wordpress.org/support/topic/issue-with-wc-stripe-plugin-refunds/#post-18666560)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WooCommerce Stripe Payment Gateway] Address line1 validation fails since 9.7](https://wordpress.org/support/topic/address-line1-validation-fails-since-9-7/)
 *  Thread Starter [dev](https://wordpress.org/support/users/devksec/)
 * (@devksec)
 * [8 months, 2 weeks ago](https://wordpress.org/support/topic/address-line1-validation-fails-since-9-7/page/2/#post-18658430)
 * Hello,
   Thank you for doing that, much appreciated. We have followed up on the
   github ticket directly and adapted the reference into a workaround for review.

Viewing 15 replies - 1 through 15 (of 264 total)

1 [2](https://wordpress.org/support/users/devksec/replies/page/2/?output_format=md)
[3](https://wordpress.org/support/users/devksec/replies/page/3/?output_format=md)…
[16](https://wordpress.org/support/users/devksec/replies/page/16/?output_format=md)
[17](https://wordpress.org/support/users/devksec/replies/page/17/?output_format=md)
[18](https://wordpress.org/support/users/devksec/replies/page/18/?output_format=md)
[→](https://wordpress.org/support/users/devksec/replies/page/2/?output_format=md)