Hi 8theme Support team,
We’re seeing a serious performance issue on one of our WooCommerce stores that we’ve now traced to XStore Core’s own add-to-cart AJAX handler, with help from CheckoutWC’s support team who reproduced it independently. Details and evidence below — hoping you can help us pin down and fix the underlying cause.
Site: washgiant.nl Theme: XStore XStore Core version: 5.7.7 WooCommerce version: 11.0.1 CheckoutWC version: 11.1.4 (premium checkout plugin) WordPress / PHP: latest WP, PHP 8.4
The issue
Every time a customer clicks “Add to cart” on a product page, the theme’s own AJAX request (action=etheme_ajax_add_to_cart, POST to admin-ajax.php) takes 5–9 seconds and returns a response of roughly 700 KB, instead of the small JSON/fragments payload we’d expect.
We asked CheckoutWC’s support team to look into it, since the response body turned out to be the fully rendered checkout page HTML. Their engineer reproduced the issue live (as an anonymous visitor) and gave us this diagnosis:
The etheme_ajax_add_to_cart handler responds with an HTTP 302 redirect (Location: /checkout/) instead of a normal AJAX response — as if it were handling a regular, non-AJAX form submission. Because fetch/XMLHttpRequest follow redirects transparently by default, the browser silently issues a second GET request to /checkout/ and treats that page’s full HTML as the “response” to the add-to-cart call. That’s why the response is large and slow — it’s actually a complete checkout-page load happening invisibly in the background of every add-to-cart click.
They also checked their own code (Redirect::checkout() / Redirect::head(), which is what renders our CheckoutWC checkout page) and confirmed it behaves correctly and only runs for genuine requests to the checkout page — it isn’t what’s issuing the redirect. So this points squarely at the etheme_ajax_add_to_cart handler itself sending a 302 where it should be sending an AJAX response.
Setting they asked us to check, now ruled out
CheckoutWC support suspected XStore Core might be respecting WooCommerce’s native “Redirect to the cart page after successful addition” setting even on AJAX requests. We checked: this setting is unchecked/off on washgiant.nl. The redirect still happens, so it isn’t driven by that particular WooCommerce toggle — it looks like it’s either hardcoded in the handler or tied to some other setting we haven’t found yet.
A useful comparison
We manage a second WooCommerce store on the same stack, craftyponies.nl (also XStore + CheckoutWC). There, “Add to cart” never triggers etheme_ajax_add_to_cart at all — it uses lightweight actions (etheme_svp_cart, cpbfgf_refresh), each roughly 1–1.5 seconds and ~10 KB, with no redirect and no checkout content involved. The one clear difference between the two sites: XStore Core version.
washgiant.nl: XStore Core 5.7.7 (affected)
craftyponies.nl: XStore Core 5.3.13 (not affected)
That suggests something changed in the add-to-cart handling between those two versions — possibly related to an “instant checkout” or prefetch-style feature. We weren’t able to confirm this from your public changelog, which appears not to have been updated since November 2022.
Settings already tested on our end (no effect on the redirect/response)
Cart widget “Content Type” (Off-Canvas / Dropdown / None)
Cart widget “Automatically Open Canvas” toggle
Cart widget “View Checkout Button” (disabled and republished live — no change)
Theme Options → “Ajax add to cart” (generic AJAX-vs-reload toggle, not the cause)
Theme Options → “Buy Now” button (disabled — not related)
WooCommerce → “Redirect to the cart page after successful addition” (confirmed off, per above)
What we’d like help with
Could you help us identify why etheme_ajax_add_to_cart is issuing a 302 redirect to /checkout/ instead of a normal AJAX response, and how to disable that behavior so “Add to cart” returns a lightweight response as expected? Happy to provide site admin access, HAR files, or any further diagnostics you need.
Thanks in advance.
Also, I didn’t receive the purchase offer/discount shown on ThemeForest, so please refund the difference I overpaid.
