• Resolved Diego

    (@daigo75)


    A customer updates the WooCommerce blocks recently, and we spotted an unexpected behaviour. Up until a certain point, changing the billing or shipping address triggered an Ajax/fetch call to refresh the available shipping options and the cart summary. That allowed some of the plugins installed on the client’s site to update the cart totals, setting elements such as prices, currency, VAT and so on.

    The latest blocks seem to work in a different way. Instead of triggering an Ajax call, they simply load all the VAT settings (and, by the look of it, a ton of other settings) on the page. When the address changes, the blocks update the VAT element via JavaScript, leaving the rest of the cart summary as it is. This prevents the cart summary from being updated, and the customer is seeing the wrong values. When the checkout actually goes through, the order is different, and so is the amount sent to the payment processor.

    I’m not sure if this new behaviour is by design, but it’s going to cause a lot of issues. It’s not feasible to re-implement all the existing price calculation logic as pure JavaScript. I wanted to ask if there could be a way to restore the original behaviour, which relied on the cart content being refreshed via a fetch/Ajax call. If not, then I will have to report the checkout block as incompatible, and recommend the customer to use a different solution.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter Diego

    (@daigo75)

    Update
    Please put this on hold. It looks like I have missed something due to the late hour. I will repeat my checks and update this ticket accordingly.

    Hi @daigo75. We’ll await your reply before investigating further. Keep us updated!

    Thread Starter Diego

    (@daigo75)

    @apmwebdev It looks like the block does fetch the data via fetch/ajax, but the logic has changed in a way that broke the code used to “listen” to the call. The block used to call a specific API endpoint, now it calls another, more obscure “batch” endpoint, passing “sub-requests” as the payload (personal opinion: I don’t understand the reasons behind these overcomplications). That was completely unexpected, and it will take some work to fix, but it should be doable.

    Self-pat on the back for reverse-engineering and debugging the logic at 03:33 AM. 👍

    Plugin Support nicw.a11n

    (@nicw)

    Hi @daigo75

    Congratulations on managing to figure it out at 3am – turning coffee into code is more than just a meme.

    It is true that developments in WooCommerce Blocks will be coming fast and furious this year, and the work to make the API more performant and scalable, along with the custom tables planned for orders and order data is going to create some work for developers this year. We’re working hard on areas of WooCommerce which developers tell us need work, and we hope the return will be worth it for all of us involved in open source.

    The blocks Roadmap blog last year still has some relevant links in it. As of 7.1, the Store API is versioned as we ready it for inclusion in WooCommerce core.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Checkout block – Refresh order summary via Ajax/fetch, like before’ is closed to new replies.