Double shopper fields after VM update

[peter@.....com]

Hi, I updated to VM 3.0.6 on my development server.

Now the shopper fields 'first_name', 'middle_name' and 'last_name' are showing twice in my shopping cart (see screendump).

In the shopper field config, the 'show in cart form' boxes for these fields are unchecked.
However, the fields now show a 'locked' sign on the VM shopper fields page, that is different from my production site (which still has VM 3.0.4).

When I look in the database of the updated site, all the field settings are exactly the same as on the old site (which displays correctly).

Any idea what's causing this and how to fix it?


My config:
Joomla 3.3.6
VM 3.0.6
OPC 2.0.281.070215

[admin]

hello peter, pls make sure that the fields are not marked as "Cart" fields within VM's shopper fields (there is a column for this). This will render them twice (once for the BT address and secondly for just the order), we will fix this from within opc in later releases, but the current logic in VM is not that good for the "cart fields". We used to call them "order fields" within opc on vm2.x.

the idea of VM's cart fields (or opc's order fields) is that some fields like "delivery date" or "order note" are not BT or ST fields, but should purely be stored with the order associated with the cart. Right now opc loads them twice without checkout if they are already in BT or vice versa. In future, if they are marked as "cart fields" they will always load blank at the cart/checkout and will not get displayed in BT address.

best regards, stan

[peter@.....com]

Hi Stan, thanks for explaining, but that's not it.

I already made sure the 'show in cart form' option is not checked.

When I look in the database, I see that the field settings are exactly the same as before the VM update (from 3.0.4 to 3.0.6).

I guessing they must have changed something in the logic, but I can't figure out what.

I'm sort of hoping that you can make it go away with the way OPC handles these fields

[blackcomm.1@.....com]

There must be some additional problem. Using the bandbox template, name and last name fields now appear before creating an account. Also, if you order as a guest, these fields do not appear.

See attached pics

[admin]

hello, we fixed all the vm3.0.6 problems in version 282, we apologize for this, but we really cannot know what the next VM features will be...

pls update to opc 2.0.282.

the BT fields should not be marked as cart fields even in 282 until the logic in VM3 is fully understood.

best regards, stan

[peter@.....com]

Wow, that is really great service ... and fast too!

Installed and tested it OK with:
Joomla 3.3.6
VM 3.0.6
OPC 2.0.282.210215

Thanks for this update, much appreciated.

[blackcomm.1@.....com]

Hi all,

Stan, you have one of the very best supports in Joomla/VM scene.

Great service.

Thanks a lot.

[admin]

hello, the new VM3.0.6 brought a few serious cross compatiblity issues with opc which i had fixed at 282 version of OPC. all of the problems were reported to the VM team, and hopefully the modifications that were done will be removed from the VM and new VM3.0.6.2 will be released soon.

we detected these issues:
- when there is a situation which needs no shipping and no payment to be selected (such as an API method being used like USPS,UPS or similar) or when you configure opc to give "-- select --" as an default shipping/payment option, Virtuemart regardless of it's configuration still forces a selection of at least one shipping/payment methods. There is no way in 3.0.6 to remove this fucntionality with a configuration and thus if all of your shipping/payment methods have a fee assigned, you cannot really find out the totals calculation without these fees. In OPC 282 we fixed this problem by installation of a new plugin which forces VM to think that no shipping must be auto selected.
- another issue in 3.0.6 is that VM's function (getCoreFields) which we considered as registration only, now returns also first_name, last_name and middle_name and thus opc prior 282 thinks that these fields are registration fields. the fix in VM3 was done to prevent deletion of these fields because some other hard written queries required them to be able to delete orders or other information. This behavrior will hopefully change in next VM3.0.6 release and thus OPC prior 282 would still work on VM3

- we also reported a few minor notices caused by deserialization or missing variables within the order emails, but these should not cause any harm in the logic

Under the current developement we are now testing a reported issue with Paypal IPN (which we cannot reproduce now) and also the "shipment" text and ST address changes within the very latest 3.0.6 build.

best regards, stan