I guess I should specify that the error is in the JS console.
I’m not managing to recreate, to be honest. Is there any way you could check for more detail with that console error? Perhaps check for a provided stack trace?
I do what I can to only load what little JS I need when I need it, including checking what admin screen I’m on, but it is possible it’s managing to affect things for AJAX requests somehow.
Here’s the stack trace:
POST https://example.com/checkout/?wc-ajax=update_order_review 404 (Not Found)
send @ jquery.js?ver=1.11.3:5
m.extend.ajax @ jquery.js?ver=1.11.3:5
wc_checkout_form.update_checkout_action @ checkout.js?ver=2.4.10:241
Just in case this would affect anything, I’m using the Authorize.net CIM credit card gateway.
And here are lines 241-293 of of checkout.js
:
wc_checkout_form.xhr = $.ajax({
type: 'POST',
url: wc_checkout_params.wc_ajax_url.toString().replace( '%%endpoint%%', 'update_order_review' ),
data: data,
success: function( data ) {
// Always update the fragments
if ( data && data.fragments ) {
$.each( data.fragments, function ( key, value ) {
$( key ).replaceWith( value );
$( key ).unblock();
} );
}
// Check for error
if ( 'failure' === data.result ) {
var $form = $( 'form.checkout' );
if ( 'true' === data.reload ) {
window.location.reload();
return;
}
$( '.woocommerce-error, .woocommerce-message' ).remove();
// Add new errors
if ( data.messages ) {
$form.prepend( data.messages );
} else {
$form.prepend( data );
}
// Lose focus for all fields
$form.find( '.input-text, select' ).blur();
// Scroll to top
$( 'html, body' ).animate( {
scrollTop: ( $( 'form.checkout' ).offset().top - 100 )
}, 1000 );
}
// Trigger click e on selected payment method
if ( $( '.woocommerce-checkout' ).find( 'input[name=payment_method]:checked' ).size() === 0 ) {
$( '.woocommerce-checkout' ).find( 'input[name=payment_method]:eq(0)' ).attr( 'checked', 'checked' );
}
$( '.woocommerce-checkout' ).find( 'input[name=payment_method]:checked' ).eq(0).trigger( 'click' );
// Fire updated_checkout e
$( document.body ).trigger( 'updated_checkout' );
}
});
Still not seeing anything specific to CPTUI yet.
That said, try this version out: https://cloudup.com/crRAjPubpyf
I added some “DOING_AJAX” checks and if that’s true, I return before any enqueuing of our scripts.
That still didn’t fix it. I know WooCommerce uses endpoints now instead of dedicated pages for some things… And this AJAX request that’s looking for an endpoint returns a success message but for some reason the code is 404 instead of 200. I’m wondering if it has something to do with permalinks/rewriting and the way CPT UI works with them?
Confirmed that it’s not the gateway’s fault. Tested with Simplify Commerce and still doesn’t work.
Not sure. What are your slugs that you’ve used for your post types? All we do is take in text values and pass them into register_post_type() or register_taxonomy. We don’t do anything special outside of that endgoal.
Wow. I’m a complete idiot. I can’t believe I didn’t think of this. I had a CPT slug “state”. Makes sense why changing the Billing State (passed as “state” in the data) screwed everything up.
Thanks for all your help!
Nah, no complete idiot. It’s an easy mistake to make really.
So just to confirm, if you’ve taken care of it already, once that got changed, everything started to click like expected?
Yep, everything works just fine now. Thanks again! I donated today; I’ll be sure to leave a review. Your plugin rocks.
Awesome, and thanks 🙂
Have a good holiday weekend.
Hi Zack,
May I ask how you resolved this?
I’m having a similar issue with a different CPT plugin (Pods) and WooCommerce.
I also have a few ‘location’ based CPTs, and have now set the slugs to be rewritten as the plural version, ie ‘countries’, ‘states’ and ‘cities’ – but this did not solve the ‘POST https://example.com/checkout/?wc-ajax=update_order_review 404 (Not Found)’ error.
Is there something that you did which I am not seeing? Thanks in advance!
Hi there, seems I resolved this too, thank you.
I also had a custom taxonomy ‘currency’, which I now changed to ‘currencies’ and that seemed to fix the problem.
Nice! Kinda begs the question: why doesn’t WooCommerce prefix all this data with wc_
?
Created an issue here: https://github.com/woothemes/woocommerce/issues/9703