After updating to 3.2.14 order numbers skipping seemingly at random.

[WebStuff]

I have updated to 3.2.14 and my order numbers seem to be jumping by 2 instead of 1 every now and again.
I have the order numbers synced so they match the order_id via an order number plugin.
It doesn't seem to be related to a particular payment/shipment plugin as it is happening with the three payment and three shipment plugins I use.

I understand these are really hard to debug as it seems to be random but I'm wondering where to look in the code for what might have changed on the upgrade to 3.2.14 that might be affecting this.

Any help greatly apppreciated.

[Milbo]

This should not happen. Which ordernumber plugin do you use?

[WebStuff]

Hi Milbo,
It's the Opentools one.
It did adapt it from the VM2 one and it has been working fine right up to the 3.2.14 update.
I just can't get why it's doing it now.
It seems to be completely random so I've not been able to catch it happening to see if it is assigning one number for pending then being called again and adding another one to it.
At the moment I get number sequences like:
XXXXX_257 where order_id= xxx257
XXXXX_258 where order_id= xxx258
XXXXX_260 where order_id= xxx259
XXXXX_260-1 where order_id= xxx260
XXXXX_261 where order_id= xxx261
XXXXX_262 where order_id= xxx262

I'm going to do a full test server run and see if I can catch it happening.
Any help greatly appreciated.

[WebStuff]

Snippet from PayPal log where the error seems to have occured:

Code Select Expand

2018-04-23 10:09:18 DEBUG plgVmConfirmedOrder: order number: XXXXX553
2018-04-23 10:09:18 MESSAGE plgVmConfirmedOrder: Amount/Currency stored 80.82 paymentcurrency 52 orderusercurrency52
2018-04-23 10:11:30 DEBUG plgVmConfirmedOrder: order number: XXXXX554
2018-04-23 10:11:30 MESSAGE plgVmConfirmedOrder: Amount/Currency stored 80.82 paymentcurrency 52 orderusercurrency52
2018-04-23 10:14:35 DEBUG PaymentNotification, paypal_data:: Array
(
    [mc_gross] => 80.82
    [invoice] => 27554

etc....
It seems that plgVmConfirmedOrder has been called twice for the same virtuemart_order_id. I have no idea if this is the user or VM that has called it twice.
I found the same type of thing in a WorldPay log:

Code Select Expand

2018-04-24 14:49:11 MESSAGE plgVmConfirmedOrder order number: XXXXX565
2018-04-24 14:49:59 MESSAGE plgVmConfirmedOrder order number: XXXXX566
2018-04-24 14:51:23 MESSAGE checkWorldPayIPN - IP MATCHES WORLDPAY.COM : 195.35.91.68 pxy201.outbound.worldpay.com

I think what is happening is that the user is pressing the back button in the browser and it's assigning the next order_number to the previous order_id that they've gone back to, which it didn't used to do.

[WebStuff]

It seems it's something going on in this code from [VM_ADMIN]/components/com_virtuemart/models/orders.php
Line 1318  to 1330:

Code Select Expand

$i = 0;
while($oldOrderNumber==$_orderData->order_number) {
if($i>5) {
$msg = 'Could not generate new unique ordernumber';
vmError($msg.', an ordernumber should contain at least one random char', $msg);
break;
}
$_orderData->order_number = $this->genStdOrderNumber( $_orderData->virtuemart_vendor_id );
if(!empty($oldOrderNumber)){
vmdebug('Generated new ordernumber ',$oldOrderNumber,$_orderData->order_number);
}
$i++;
}

Error Log reports:
$oldOrderNumber=XXXXX590 $_orderData->order_number=XXXXX591
So it seems it's this part of the code that isn't behaving as it should. Unless this is intentional as part of the French compliance changes.

[WebStuff]

Sorted it by just adding :

Code Select Expand

if ($oldOrderNumber) {
$_orderData->order_number = $oldOrderNumber;
}
.... after the while loop. Should be a setting soon hopefully. Unless this is what ReUsePendingOrders is for?

[AH]

"Unless this is what ReUsePendingOrders is for?"

Looks like it to me.

Works where the same customer and order status is p and within the last hour

function reUsePendingOrder(