Forum Replies Created

Viewing 30 posts - 1 through 30 (of 138 total)
1 2 3 4 5
  • Avatar: luc
    luc
    Participant

    Thanks for the support! My topic “etheme_ajax_add_to_cart returns an HTTP 302 redirect to /checkout/ instead of a normal AJAX response” has been successfully resolved.

    #475821 Copied In reply to: etheme_ajax_add_to_cart returns an HTTP 302 redirect to /checkout/ instead of a normal AJAX response
    Avatar: luc
    luc
    Participant

    Hi,

    Thanks for the quick turnaround and the clear explanation!

    I’ve tested the fix live on washgiant.nl and can confirm it’s working.
    Everything looks resolved. Good to hear this will also be part of the next public theme release so we don’t need to track a custom patch.

    Thanks again for digging into this, Luc.

    #475820 Copied In reply to: etheme_ajax_add_to_cart returns an HTTP 302 redirect to /checkout/ instead of a normal AJAX response
    Avatar: luc
    luc
    Participant

    I’ve now traced the exact mechanism and can reproduce it reliably outside of the normal button click, so I’m sharing this in case it saves your team time.
    The add-to-cart request your theme’s JS sends to admin-ajax.php is built by serializing the existing

    element. That form includes WooCommerce’s own classic (non-AJAX) fallback field add-to-cart= (the field WooCommerce uses when JavaScript is disabled and the page is simply reloaded). Your theme’s JS adds action=etheme_ajax_add_to_cart on top and posts the combined body. For example, the real request body captured from the “Lavender fields” product (ID 5800) is:

    quantity=1&add-to-cart=5800&action=etheme_ajax_add_to_cart

    admin-ajax.php boots WordPress fully, including firing the wp_loaded hook. WooCommerce core registers WC_Form_Handler::add_to_cart_action() on wp_loaded unconditionally — it doesn’t check whether the request is an AJAX call or a normal page load, it only checks whether $_REQUEST[‘add-to-cart’] is set. Because that field is present in every request your JS sends, WooCommerce core’s own handler fires first (before admin-ajax.php ever reaches its own action dispatch, which is where etheme_ajax_add_to_cart() is hooked via wp_ajax_etheme_ajax_add_to_cart), adds the product to the cart itself, queues the session notice, and issues wp_safe_redirect() + exit() to the checkout page. Your theme’s own etheme_ajax_add_to_cart() handler (in framework/woo.php) is correctly written and returns a proper small JSON response — but it never actually runs, because the request already exited earlier in the request lifecycle.

    The browser then transparently follows that 302, and the full checkout-page HTML comes back as the “response” to the add-to-cart click — that’s the 4.5–9s delay and 216–724 KB payload.

    Reproduced in isolation, without clicking the button

    Directly in the browser console, on a live product page:

    POST to admin-ajax.php with body action=etheme_ajax_add_to_cart&product_id=5800&quantity=1 (using the field name product_id instead of add-to-cart) → normal 200 response, ~12.5 KB JSON, no redirect.
    The exact same call but with the real field name your JS uses, add-to-cart=5800 instead of product_id=5800 → with fetch(…, {redirect:’manual’}) this returns {status: 0, type: “opaqueredirect”} (i.e. the server sent a 3xx); with a plain XHR (which follows redirects) the request ends at responseURL: https://www.washgiant.nl/checkout/, 723,104 bytes.

    So the presence of the add-to-cart= field name in the AJAX body is the entire trigger — nothing else needs to change to reproduce or fix this.

    Why our other site (craftyponies.nl, older XStore Core 5.3.13) isn’t affected

    There, add-to-cart uses different, lighter AJAX actions (etheme_svp_cart / cpbfgf_refresh) that apparently don’t include the add-to-cart field in their POST body, so WooCommerce core’s classic handler never triggers. This suggests something changed in how the add-to-cart form is serialized between that version and 5.7.7.

    Suggested fix

    Either stop including the add-to-cart field name when building the AJAX POST body (rename it or strip it before sending, keeping only product_id/quantity/action), or explicitly unhook WC_Form_Handler::add_to_cart_action for requests carrying action=etheme_ajax_add_to_cart. Either change should let your existing etheme_ajax_add_to_cart() handler run as intended, without touching anything else in the add-to-cart flow.

    Happy to provide anything else that helps

    #475803 Copied In reply to: etheme_ajax_add_to_cart returns an HTTP 302 redirect to /checkout/ instead of a normal AJAX response
    Avatar: luc
    luc
    Participant

    Thanks for checking. I’ve updated the theme to the latest version (9.7.7).

    Unfortunately the issue is still present. I just re-tested live, logged out (as a real anonymous visitor), on this product page:

    https://www.washgiant.nl/shop/wasstrips/lavender-fields/

    Clicking “Add to cart” still triggers a POST to admin-ajax.php that takes about 4.5 seconds and returns a ~216 KB response. I inspected the response body again and it’s still not a normal AJAX response, it starts with and contains a fully rendered page (head, CSS, etc.), the same signature as before the update. So the redirect-to-checkout behavior in the etheme_ajax_add_to_cart handler does not appear to be fixed by the 9.7.7 update.

    To summarize where things stand:

    Theme/Core/plugins updated to the latest versions (9.7.7) — confirmed via your own check.
    Bug still reproduces exactly as described in my previous message: etheme_ajax_add_to_cart issues an HTTP 302 to /checkout/ instead of a normal AJAX response, the browser auto-follows it, and the full checkout-page HTML comes back as the “response” (+/-216 KB / 4.5s logged out; up to 724 KB logged in).
    WooCommerce’s “Redirect to the cart page after successful addition” setting is off, so that’s not the trigger.
    CheckoutWC support independently reproduced this and confirmed their own code isn’t causing it, it’s on the theme/plugin side.

    Could you take another look

    #475787 Copied In reply to: etheme_ajax_add_to_cart returns an HTTP 302 redirect to /checkout/ instead of a normal AJAX response
    Avatar: luc
    luc
    Participant

    Thanks for the reply.

    Please contact administrator
    for this information.
    #475736 Copied In reply to: etheme_ajax_add_to_cart returns an HTTP 302 redirect to /checkout/ instead of a normal AJAX response
    Avatar: luc
    luc
    Participant

    Thanks for the support! My topic “Header animation on loading page (frosted effect)” has been successfully resolved.

    #462179 Copied In reply to: Header animation on loading page (frosted effect)
    Avatar: luc
    luc
    Participant

    Thank you very much! This is excellent.

    #462178 Copied In reply to: Header animation on loading page (frosted effect)
    Avatar: luc
    luc
    Participant

    See private area

    Please contact administrator
    for this information.
    #462134 Copied In reply to: Header animation on loading page (frosted effect)
    Avatar: luc
    luc
    Participant

    Sure here is a video. This was always the issue. It is an xstore template I used.
    BTW, sometimes the website is very slow as you can see. We are running on a serious VPS.

    Please contact administrator
    for this information.
    #462056 Copied In reply to: Header animation on loading page (frosted effect)
    Avatar: luc
    luc
    Participant

    Hi Jack,

    Excuse me for the late reply.
    I still see the frosted effect on page loading. After I scroll a bit to the top this goes away.
    I like it to start like it is not frosted. Then after scrolling it gets frosted.

    Luc

    #462044 Copied In reply to: Header animation on loading page (frosted effect)
    Avatar: luc
    luc
    Participant

    Hi Jack,
    Sorry for the late reply. As long as it looks and functions the same, it’s okay.

    #460449 Copied In reply to: Header animation on loading page (frosted effect)
    Avatar: luc
    luc
    Participant

    Hi Jack,

    Thanks for the quick reply!
    I still see the frosted sticky effect on loading on mobile.

    #460083 Copied In reply to: Header animation on loading page (frosted effect)
    Avatar: luc
    luc
    Participant

    Tested in Chrome on mobile. Same issue and one new sticky issue.

    Files is visible for topic creator and
    support staff only.
    #460064 Copied In reply to: Header animation on loading page (frosted effect)
    Avatar: luc
    luc
    Participant

    Thanks for the support! My topic “Hidden woocommerce products not visible in carousel” has been successfully resolved.

    #459807 Copied In reply to: Hidden woocommerce products not visible in carousel
    Avatar: luc
    luc
    Participant

    Sure, see private content

    Please contact administrator
    for this information.
    #457610 Copied In reply to: Hidden woocommerce products not visible in carousel
    Avatar: luc
    luc
    Participant

    Hi,

    We are not using any custom snippets.
    I have the products published. But the visibility settings from woocommerce “hidden”. See my screenshot.

    Files is visible for topic creator and
    support staff only.
    #457606 Copied In reply to: Hidden woocommerce products not visible in carousel
    Avatar: luc
    luc
    Participant

    Hi,

    The hidden products are supposed to be on this page: washgiant.nl/welkom

    All hidden products are in this category: Bundel met Gratis drogerballen

    #457573 Copied In reply to: Hidden woocommerce products not visible in carousel
    Avatar: luc
    luc
    Participant

    Thanks for the support! My topic “English → Dutch translations are of very poor quality” has been successfully resolved.

    #457563 Copied In reply to: English → Dutch translations are of very poor quality
    Avatar: luc
    luc
    Participant

    Thanks for the support! My topic “Simple question: How can i disable the “+2 more” at the categories” has been successfully resolved.

    #457562 Copied In reply to: Simple question: How can i disable the “+2 more” at the categories
    Avatar: luc
    luc
    Participant

    Hi Luca,

    The login should work now.

    #456717 Copied In reply to: Simple question: How can i disable the “+2 more” at the categories
    Avatar: luc
    luc
    Participant

    How can I share the translations?

    #456707 Copied In reply to: English → Dutch translations are of very poor quality
    Avatar: luc
    luc
    Participant

    Thanks for the support! My topic “Stock status not correct on variable products” has been successfully resolved.

    #455308 Copied In reply to: Stock status not correct on variable products
    Avatar: luc
    luc
    Participant

    Thanks jack, I think this is the best solution.

    #455307 Copied In reply to: Stock status not correct on variable products
    Avatar: luc
    luc
    Participant

    It is strange that the regular stock status widget from Elementor works, but that one is not displaying the on stock status…
    There must be something wrong, I think.
    Video: https://streamable.com/q67jcr

    #455123 Copied In reply to: Stock status not correct on variable products
    Avatar: luc
    luc
    Participant

    So I have to enable stock? But we don’t use stock.
    We just want to use In Stock, Out of Stock, and On Backorder.
    When I set a product to Out of Stock, the buy button is disabled, but the notification still says it is in stock.

    #455105 Copied In reply to: Stock status not correct on variable products
    Avatar: luc
    luc
    Participant

    Hi Andrew, I hope you’re doing well. Could you please provide me with an update at your earliest convenience?

    #455012 Copied In reply to: Stock status not correct on variable products
    Avatar: luc
    luc
    Participant

    Sure, see the private content area.

    Please contact administrator
    for this information.
    #454451 Copied In reply to: Stock status not correct on variable products
    Avatar: luc
    luc
    Participant

    Thanks for the support! My topic “Website width suddenly restricted despite correct container settings” has been successfully resolved.

    #454434 Copied In reply to: Website width suddenly restricted despite correct container settings
    Avatar: luc
    luc
    Participant

    Thanks for the support! My topic “Product images, thumbnails, and gallery not visible on product page” has been successfully resolved.

    #453775 Copied In reply to: Product images, thumbnails, and gallery not visible on product page
    Avatar: luc
    luc
    Participant

    Found it!
    Checked so much… I thought it must be a setting… And it was.

    Files is visible for topic creator and
    support staff only.
    #453774 Copied In reply to: Product images, thumbnails, and gallery not visible on product page
  • 1 2 3 4 5
    1–30 of 138 posts
Viewing 30 posts - 1 through 30 (of 138 total)
1 2 3 4 5