Orders processed with blank or improper shipping

[info@.....com]

Hi Stan,
Immediately after upgrading a VM store from OPC v2.0.244 to v2.0.273 orders are sporadically coming in without shipping being applied (and in one case an international order having domestic shipping method applied). The store is in the US and all of these cases are international orders. We have tried everything to recreate the issue using same cart details and are not able to find a problem.

Digging into the http logs it seems at least several of the orders are from iPad devices using Safari browser so my theory is something is preventing the shipping from being updated on cart address changes/etc and an invalid shipping option is submitted back to the web server by the customer. To test this scenario we modified the selected shipping method on the web browser to a method number that is invalid based on cart details. When the order is submitted it is processed (gets past the COM_VIRTUEMART_CART_NO_SHIPPINGRATE check in cart_override.php->checkoutData) but the shipping is later set to shipment_id = 0.

I then reinstalled OPC v2.0.244 and did the same test but the order is properly stopped and redirected back to the cart with the COM_VIRTUEMART_CART_NO_SHIPPINGRATE message.

I then did some tracking of the code and found the potential problem. The update I made to fix the problem was to comment out @line 588 in components\com_onepage\helpers\loader.php:

Code: Select all

//$cart->virtuemart_shipmentmethod_id = $saved_id; 

This line is resetting the shipment method id back to the $saved_id. I believe VM is checking if the shipment method is valid for the order in getCheckoutPrices and if it is not the shipping is set to 0. However this gets reset by this line which then does not trigger the COM_VIRTUEMART_CART_NO_SHIPPINGRATE check in cart_override.php->checkoutData

Stan, can you please look at this to see if this issue can be fixed in a future release or let me know if I am off-base with this analysis.

Chuck

[admin]

hello Chuck, this also depends on your VM version. In general it's important to disable VM's "automatic shipment" which sometimes overrides already selected shipipng method. i just released 277 version and i haven't had this problem for a longer time, let me know if you would still get the missing shipping info even on the latest version.

also, some payment methods (or calculation plugins) sometimes change the selected shipping method. for this reason i strongly recommend to disable all payment/shipping plugins in joomla plugin manager which are not used in your virtuemart.

best regards, stan

[info@.....com]

Hi Stan, We installed that latest version 2.0.279 and tested out our issue again. The same problem is occurring in this version. We have VM's automatic shipment off and only shipping and payment plugins that we use are enabled. The problem still seems that if an invalid shipping method is posted from a browser to OPC it does not stop the checkout and report back a shipping method problem like it did in v2.0.244 and prior.

[admin]

hello, let me know at email as i did many tests and i cannot replicate this on my demos. if possible, i'd like to debug opc's controller and opc's cart_override.php for:

$x = JRequest::getVar('virtuemart_shipmentmethod_id');
var_dump($x);

put this many times at various places at opc.php and cart_override until the order is saved. My suspicion is that some other plugin incorrectly changes the ID, or just the returned html (that should be saved upon orderConfirmed event) called at:
\components\com_onepage\overrides\cart_override.php

Code: Select all

// pairs the cookie with the database
         $returnValues = $dispatcher->trigger('plgOpcOrderCreated', array($cart, $order ));
         
         if (class_exists('OPCPluginLoaded'))
         {
         // runs shipping confirm as first and payment as last
         $returnValues = $dispatcher->trigger('plgVmConfirmedOrderOPC', array('shipment', $cart, $order));
         
         $returnValues = $dispatcher->trigger('plgVmConfirmedOrderOPC', array('calculation', $cart, $order));
         
         $returnValues = $dispatcher->trigger('plgVmConfirmedOrderOPC', array('custom', $cart, $order));
         
         
         // we used detach event above, so we can now freely call the function again:
         $returnValues = $dispatcher->trigger('plgVmConfirmedOrder', array($cart, $order));
         // re-attach events:
         
         if (!empty(vmPlugin::$detached))
         foreach (vmPlugin::$detached as &$instance)
         {
          $dispatcher->attach($instance);
         }
         
         }
         else
         {
            $returnValues = $dispatcher->trigger('plgVmConfirmedOrder', array($cart, $order));
         }



the code above does this:
- regarless of the order of:
JPluginHelper::importPlugin('vmpayment');
JPluginHelper::importPlugin('vmshipment');
...

which as shown above normally causes exactly the problem that you are describing, the code (with overrided opc's vmplugin.php) is capable of triggering the shipment before the payment code and thus not causing redirect before the shipment is stored.

i would really like to help you, but i will need to check this on your site directly via ftp ideally.

best regards, stan

[info@.....com]

Hi Stan. I did many hours of that type of debugging a couple weeks ago to locate the fix that I implemented. It showed that the "virtuemart_shipmentmethod_id" was the same value submitted from the web client as it went through the OPC controller validation. But when an invalid "virtuemart_shipmentmethod_id" is forced into the OPC controller it is not identified as an invalid shipping method like it used to in previous versions. I don't think anything is changing the "virtuemart_shipmentmethod_id" but rather it is being reset to the invalid "virtuemart_shipmentmethod_id" after VM correctly sets it to 0 due to being invalid.

I really think the problem is in the components\com_onepage\helpers\loader.php which is resetting the virtuemart_shipmentmethod_id to the invalid id number after VM has done the logic to identify the virtuemart_shipmentmethod_id as invalid based on the address/cart details. This causes the COM_VIRTUEMART_CART_NO_SHIPPINGRATE message not to trigger as it should.

Perhaps the best thing would be for me to try to recreate the problem using one of your demo sites similar to how I described it in my email. If I can recreate the issue there I can walk you through how I create the problem. Basically I force the "virtuemart_shipmentmethod_id" on the web client to a number which is invalid for the shipping address. This should then trigger the COM_VIRTUEMART_CART_NO_SHIPPINGRATE message once submitted.

[admin]

hello chuck, i finally solved this and also reported a bug to VM core team.

for weight_countries which is used by most 3rd party developers as the scaffolding of the new plugins, it indeed is missing an internal validation upon checkout. virtuemart's core team says the validation should have been done at plgVmOnCheckoutCheckDataShipment which is triggered just before the order is stored in the datables. This function should have called both "onSelectCheck" within the core master vmpsplugin class and also it's own checkConditions function.

but none of the core shipping plugins (especially weight countries) do a check for this upon these events. It seems that plgVmOnSelectCheckShipment function is called upon every impression of the virtuemart which would make it not suitable to call the checkConditions function.

we had solved this problem by adding a wrapper function into our override class which checks (only at the checkout) for both
plgVmOnSelectCheckShipment
checkConditions
and thus can return false in case the selected shipping is out of it's own conditions.

My guess is that this behavior was different on older VM2 versions and that it used to run checkConditions from onSelectCheck, but this is no longer true.

Besides this, we also added a check for non-existend shipping ID as far as it's numeric and not empty (to support shiping methods within non-numeric IDs like 2_3 and empty if OPC allows no shipping)

I've sent you the latest DEV for this, let me know if this meets your goals. It will be soon released.

Best Regards, Stan