Disable AJAX on checkout for WooCommerce

Question

I'd like to ask how I could disable AJAX at the checkout page (where you enter shipping and billing information) and that instead of using AJAX to update the cart summary based on your location, it would update by doing a natural refresh.

Currently the cart summary would update itself without reloading the page whenever the user switches their location via shipping location. I'd like to remove that AJAX and just have the page reload with the updated information.

I'm not too sure what sort of codes or direction I should be pointing at but I'm ready to provide whatever details necessary. Just let me know! Thank you!!

Solution 1

All WooCommerce strings are properly localized with wp_localize_script so I would think you could correctly translate them by creating the appropriate .po/.mo file, but I confess to not having a lot of experience with translations. For reference: all available language packs are at Github and you might also want to read the documentation.

Anyway, the checkout scripts are all in checkout.js. Like any script you can dequeue it via wp_dequeue_script() as long as you know the handle.

function so_27023433_disable_checkout_script(){
    wp_dequeue_script( 'wc-checkout' );
}
add_action( 'wp_enqueue_scripts', 'so_27023433_disable_checkout_script' );

Solution 2

I had a similar issue, and instead of remove the entire script, i went to see when the event is created, and i found this.

$( document.body ).bind( 'update_checkout', this.update_checkout );

After reading a little, i found that I will not be able to unbind because of the namespace, so i hooked up on the on event and since i can't prevent default i stoped the propagation of the event.

and these solved my problem.

jQuery(document.body).on('update_checkout', function(e){
    //e.preventDefault();
    //e.stopPropagation();
    e.stopImmediatePropagation();
    //console.log(e);
});

Comments

[chdltest]

What happens exactly when you denqueue a script?

[helgatheviking]

It doesn't get loaded on the front-end. Refer to the codex article.

[Eugen Mihailescu]

That's a good idea. Hopefully your event is triggered before the WC default one otherwise I think the e.stopImmediatePropagation will stop the remaining hooked functions but not the one already executed. Obviously you can check the moment the WC hooks its function and you can hook your function just earlier. So yes, I think it would work.

[Eugen Mihailescu]

One more thing about this approach: make sure that you revert the default class on body.checkout_error otherwise you might encounter an JS error because the submit_error function of checkout.js will evaluate the $( 'form.checkout' ).offset() which would trigger a ReferenceError exception.

[Andrew Dinmore]

I don't know if this would work or not, but it's poor practice to edit the code in third-party libraries, such as plugins. It can have unexpected results, often adds considerably to maintenance time and will be lost during standard update procedures.