Thank you Christian for the explanation!
Shall I go ahead and create a separate ticket for the order update issue?
Copied from parent ticket:
Also, following the latest updates to Toolset plugins on May 28, our CRED forms "Revert Order" and "Update Order" — which are suppose to change WooCommerce order status to wc-processing and wc-completed respectively — have stopped working. Pressing the buttons do nothing to update their status.
Okay I'm having a bit of trouble testing this. WooCommerce is quite out-of-date, as is the parent X theme. When I update everything locally, I'm running into too many PHP and JavaScript errors and warnings to be able to effectively debug. The cred_save_data callbacks are not firing at all, and I'm seeing an alert that says "there was an error while submitting the form", so it makes sense that the order statuses are not being updated. If I turn on error logs, I see notices about scripts and styles being enqueued incorrectly.
If I place the Update Order form on a test page somewhere and pass in an Order ID using a shortcode attribute, the form submits as expected and the order is marked as Completed. So something is going in the main search page that is obstructing form submission. I'm not really familiar with how your application is set up, but it seems like there are quite a few Forms on this page, and lots of content in general. I would try to narrow down the problem by forcing these Views to include fewer results. During testing, you could do this by adding a post ID filter and hard-coding the ID of an Order. If the callbacks still aren't fired, then I would check to see if you're doing any DOM manipulation that might break JavaScript handlers that are set on these forms during pageload. For example, detaching and reattaching Forms, or moving them around in the DOM after page load.
Any ideas?
Can you provide me with the shortcode for the Update Order form for testing? Sorry, I'm not sure how to specify the post to edit from the shortcode generator. I'll test on the live site and come back with the results.
For Views, we always wanted to limit the filter to only output orders 30 days before and after today. We will see about implementing this today to reduce the amount of content and errors in general. We'll also check the JS per your suggestion.
You can add the "post" shortcode attribute and set it to the post ID you want to edit:
[cred_form form='update-order' post='4615']
When I put [cred_form form='update-order' post='4377'] on a test page and try it, the form gives me an "An error has occurred while submitting the form" but when I check the order, its status was changed to Completed. Very odd, but at least we know the update is somewhat working. [cred_form form='revert-order' post='4377'] doesn't work.
We're going to try rolling-back the Toolset plugins to their previous versions since the update issue began after the latest updates. I'll do this on pantrytest.site and let you know how it goes.
Thanks, I'll stand by for an update.
Hello Christian,
Doesn't seem like rolling back the plugins on pantrytest did anything unfortunately.
Our Toolset contractor Fernando has written codes to update/revert order status via AJAX directly. This also seem to not be working on the live site.
The JS codes are as follow:
<script type="text/javascript">
$(".classrevertbuttonalternative").click(function () {
var order_id = $(this).attr('order_id');
alert(order_id);
$.ajax({
type: 'POST',
url: '<em><u>hidden link</u></em>',
data: {
'order_id': order_id,
'action': 'revertOrderAJAX' //this is the name of the AJAX method called in WordPress
}, success: function (result) {
alert(result);
},
error: function () {
alert("error");
}
});
});
</script>
And the PHP to go in the website's Snippet:
// update alternative begin
function revertOrderAJAX() {
// retrieve post_id, and sanitize it to enhance security
$order_id = intval($_POST['order_id'] );
// Check if the input was a valid integer
if ( $order_id == 0 ) {
echo "Invalid Input";
die();
}
$order = new WC_Order($order_id);
if (!empty($order)) {
$order->update_status( 'processing' );
echo 'revert completed';
die();
}
echo 'Invalid order';
die();
}
add_action( 'wp_ajax_nopriv_revertOrderAJAX', 'revertOrderAJAX' );
// update alternative end
I'll test this on pantrytest to see if it'll work there.
Okay it looks like this is a custom application that doesn't use standard form submissions. There is no CRED JavaScript API, so I'm not able to give any advice about setting up custom calls to admin-ajax.php, or triggering events in CRED by external means, and I'm not able to provide technical details about the requirements for simulating a CRED form submission. The PHP code doesn't touch any Toolset APIs either, so there isn't much I can offer here. If you put together a basic implementation that doesn't use custom AJAX calls, and uses the CRED API instead of AJAX callbacks, then I can help you troubleshoot it. Extrapolating that to a non-standard form submission is outside the scope of support we provide here in the forums.
Okay, we'll separately work on updating without CRED ourselves.
As for the CRED forms, I don't think pressing the CRED form's submit button works at all. I ended up making a secondary button to trigger the form's button; it worked and updated the status.
The simple jQuery code is:
$('.test-revert').click(function() {
$('.revert-btn').trigger('click');
});
.test-revert is a simple <input> button and .revert-btn is a class applied to Revert Order's submit button. I'll see if the same can be applied to Complete Order.
Hello Christian,
I tested above using Completed, got "There was an error while submitting a form" but the Order was completed. However, I couldn't get both to work again after — very frustrating.
Edited: The AJAX calls seem to work at random, but I noticed they have more luck to work specifically on Order #4377 on the live site. I will include the information gleaned from the Network console of DevTools.
I know you have a site clone, but have you had the chance to inspect the live website itself?
Another test, this time on Order 4881. As you can see the form seem to be targeting 4377 for some reason?
I think I know why the forms don't work now. The All Modals view output multiple Orders just like the Kitchen Orders view. When either form is used, they naturally target the very first order in the view — thus why 4377 is being targeted when I limited the views to 3 test orders; it's the first one.
We either need to correct the forms to target the correct corresponding order or limit the All Modals view to output just one Order. Any advice on either solutions will be appreciated.
What if you add the CRED form shortcode in the View results loop, and specify the post ID in the shortcode attribute? There will be more than one CRED form in the DOM, but your code already shows and hides Orders so only one form will be displayed at a time.
Do you mean adding [cred_form form='update-order' post='[wpv-post-id]'] to the Loop Item in Kitchen Orders All Modals? I tried it before and did it again; still no effect.
We have the PHP hooks for the CRED in a Snippet on the website, you'll see them here:
add_action('cred_save_data', 'saveOrderComplete',10,2);
function saveOrderComplete($order_id, $form_data)
{
if ($form_data['id']==4323)
{
$order = new WC_Order($order_id);
if (!empty($order)) {
$order->update_status( 'completed' );
}
}
}
add_action('cred_save_data', 'saveRevertOrder',10,2);
function saveRevertOrder($order_id, $form_data)
{
if ($form_data['id']==4325)
{
$order = new WC_Order($order_id);
if (!empty($order)) {
$order->update_status( 'processing' );
}
}
}
