Author Topic: VM 3.6 breaking backwards compatibility with payment methods  (Read 1322 times)

ssc3

  • 3rd party VirtueMart Developer
  • Jr. Member
  • *
  • Posts: 148
    • Online Store Plugins
VM 3.6 breaking backwards compatibility with payment methods
« on: September 02, 2019, 20:43:37 pm »
VM 3.6 is breaking backwards compatibility with payment methods which are restricted by countries

causing the error

"No payment method matches the characteristics of your order"

Affects native Authorize.Net, 1-2 Checkout, KlicandPay, Skrill, Realex and possibly others

plus third party checkouts.


When function checkConditions contains the following code. 


protected function checkConditions($cart, $method, $cart_prices)
    {
    $address = (($cart->ST == 0) ? $cart->BT : $cart->ST);



$address is always set to $cart->ST even when it does not contain a valid address.

In VM 3.6 the ST array only contains address_type_name.

There is no valid virtuemart_country_id

Example of an array with billing address only.

[BT] => Array
    (
    [email] => test@test.com
    [company] =>
    [title] => Mr
    [first_name] => John
    [middle_name] =>
    [last_name] => Smith
    [address_1] => 10 Test St
    [address_2] =>
    [zip] => 12345
    [city] => Test Town
    [virtuemart_country_id] => 222
    [virtuemart_state_id] => 0
    [ phone_1] => 0123456789
    [phone_2] =>
    [fax] =>
    [customer_note] =>
    [tos] => 0
    )

[ST] => Array
    (
    [address_type_name] => Address Nickname
    )



The ST array is always selected with the following code.

$address = (($cart->ST == 0) ? $cart->BT : $cart->ST);



Virtuemart Payment Plugins

https://plugins.online-store.co.uk

jjk

  • Global Moderator
  • Sr. Member
  • *
  • Posts: 3524
  • using Matomo instead of Google Analytics
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #1 on: September 02, 2019, 22:25:36 pm »
Maybe this is of relevance to you:  https://docs.virtuemart.net/tutorials/development/236-update-payment-shipment-plugin-using-new-core-restrictions.html
(I'm not a VM developer, so not sure about this)
Non-English Shops: Are your language files up to date?
http://virtuemart.net/community/translations

Jumbo!

  • 3rd party VirtueMart Developer
  • Full Member
  • *
  • Posts: 679
  • Full-stack Web Developer
    • www.virtueplanet.com
  • VirtueMart Version: Always latest
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #2 on: September 03, 2019, 08:18:00 am »
Try the following codes to get the correct shipping address:

Code: [Select]
<?php
$address 
$cart->getST();
?>

ssc3

  • 3rd party VirtueMart Developer
  • Jr. Member
  • *
  • Posts: 148
    • Online Store Plugins
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #3 on: September 03, 2019, 09:57:48 am »
The problem is the backwards compatibility of VM 3.6 when country restrictions are used.

Upgrading to VM 3.6 may stop already installed plugins from working correctly.

In VM 3.4 when the shipping address is not defined the VirtueMartCart Object looks something like

[ST] => 0

In VM 3.6 it looks like

[ST] => Array
    (
    [address_type_name] => Address Nickname
    )


The ST array is always selected with the existing code, which is used by a number of native and third party plugins

$address = (($cart->ST == 0) ? $cart->BT : $cart->ST);


Using something like the following would fix the plugins.

if(isset($cart->ST['virtuemart_country_id']))
    {
    $address = $cart->ST;   
    }
else
    {
    $address = $cart->BT;
    }



but ideally it should be possible to upgrade to VM 3.6 without it effecting already installed plugins.

Unless there is a good reason for changing.

This issue also effects some of the native Virtuemart plugins such as Authorize.Net

Virtuemart Payment Plugins

https://plugins.online-store.co.uk

Jumbo!

  • 3rd party VirtueMart Developer
  • Full Member
  • *
  • Posts: 679
  • Full-stack Web Developer
    • www.virtueplanet.com
  • VirtueMart Version: Always latest
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #4 on: September 03, 2019, 12:39:54 pm »
Use the codes I mentioned in my post above.

Replace

Code: [Select]
$address = (($cart->ST == 0) ? $cart->BT : $cart->ST);
By

Code: [Select]
$address = $cart->getST();
It should also be updated in the core plugins soon.

GJC Web Design

  • 3rd party VirtueMart Developer
  • Super Hero
  • *
  • Posts: 9142
  • Virtuemart, Joomla & php developer
    • GJC Web Design
  • VirtueMart Version: 3.4.2
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #5 on: September 03, 2019, 23:36:39 pm »
the getST() is a function in the cart helper

public function getST($name=0,$FBBT=true){

but I suspect it will still always return the ST as address_type_name is always set?
GJC Web Design
VirtueMart and Joomla Developers - php developers http://www.gjcwebdesign.com
VM3 AusPost Shipping Plugin - e-go Shipping Plugin - VM3 Postcode Shipping Plugin - Radius Shipping Plugin - VM3 NZ Post Shipping Plugin - AusPost Estimator
Samport Payment Plugin - EcomMerchant Payment Plugin - ccBill payment Plugin
VM2 Product Lock Extension - VM2 Preconfig Adresses Extension - TaxCloud USA Taxes Plugin - Virtuemart  Product Review Component
http://extensions.joomla.org/profile/profile/details/67210
Contact for any VirtueMart or Joomla development & customisation

GJC Web Design

  • 3rd party VirtueMart Developer
  • Super Hero
  • *
  • Posts: 9142
  • Virtuemart, Joomla & php developer
    • GJC Web Design
  • VirtueMart Version: 3.4.2
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #6 on: September 06, 2019, 13:26:17 pm »
Tested this and the solution for older plugins with  $address = (($cart->ST == 0) ? $cart->BT : $cart->ST);

is   $address = $cart->getST();

GJC Web Design
VirtueMart and Joomla Developers - php developers http://www.gjcwebdesign.com
VM3 AusPost Shipping Plugin - e-go Shipping Plugin - VM3 Postcode Shipping Plugin - Radius Shipping Plugin - VM3 NZ Post Shipping Plugin - AusPost Estimator
Samport Payment Plugin - EcomMerchant Payment Plugin - ccBill payment Plugin
VM2 Product Lock Extension - VM2 Preconfig Adresses Extension - TaxCloud USA Taxes Plugin - Virtuemart  Product Review Component
http://extensions.joomla.org/profile/profile/details/67210
Contact for any VirtueMart or Joomla development & customisation

Milbo

  • Virtuemart Projectleader
  • Administrator
  • Super Hero
  • *
  • Posts: 9943
  • VM3.2 Cached and Optimized
    • VM3 Extensions
  • VirtueMart Version: VirtueMart 3 on joomla 3
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #7 on: September 06, 2019, 14:30:29 pm »
ah shit. I overlooked this construction.

There is a good reason for this Backward compatibility problem. The old cart just displayed the default values of userfields, but the defaults were not set in the address arrays like $cart->BT. The good thing is, that shipment/payments and other stuff directly correctly works with a set default. But the stupid side effect is, that the prior empty values are now most time filled with some defaults. The set defaults are stored in array (for example byDefaultBT) within the cart, so we even know if we just use a default value or a set value.

I wrote the function getST with the fallback parameter. The function considers the variable STsameAsBT. The ST is only used, when STsameAsBT is empty, else the getST returns the BT.

I updated now the core plugins as far as I can see. Most time it was very simple to solve, I just followed my own tutorial.

http://docs.virtuemart.net/tutorials/development/236-update-payment-shipment-plugin-using-new-core-restrictions.html
I should fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

Milbo

  • Virtuemart Projectleader
  • Administrator
  • Super Hero
  • *
  • Posts: 9943
  • VM3.2 Cached and Optimized
    • VM3 Extensions
  • VirtueMart Version: VirtueMart 3 on joomla 3
I should fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

Milbo

  • Virtuemart Projectleader
  • Administrator
  • Super Hero
  • *
  • Posts: 9943
  • VM3.2 Cached and Optimized
    • VM3 Extensions
  • VirtueMart Version: VirtueMart 3 on joomla 3
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #9 on: September 12, 2019, 19:09:13 pm »
I added a new article to the docs. Would be nice to get some comments, whats missing, etc. Something else to update for vm3.6?

http://docs.virtuemart.net/tutorials/development/240-important-adjustments-for-virtuemart-3-6.html
I should fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

ssc3

  • 3rd party VirtueMart Developer
  • Jr. Member
  • *
  • Posts: 148
    • Online Store Plugins
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #10 on: September 13, 2019, 08:31:01 am »
Would this help?

In vmPSPlugin

the function checkConditions is called in

getSelectables

Code: [Select]
if ($this->checkConditions ($temp, $method, $cart->cartPrices)) {

replace with the following



Code: [Select]
$temp = $cart;

$temp->ST = $cart->getST();
               
if ($this->checkConditions ($temp, $method, $cart->cartPrices)) {


It ensures a valid shipping address is contained in the temp cart that is passed to check conditions

while the value of the orginal cart does not change.

The old plugins will read the value in the ST array while the new one will read getST()

Both should get the correct fields

Tested this and it seems to work with old and new plugins.


the function is also called in

displayListFE
onSelectedCalculatePrice
getSelectable

but

getSelectables

seems to be the problem
Virtuemart Payment Plugins

https://plugins.online-store.co.uk

Milbo

  • Virtuemart Projectleader
  • Administrator
  • Super Hero
  • *
  • Posts: 9943
  • VM3.2 Cached and Optimized
    • VM3 Extensions
  • VirtueMart Version: VirtueMart 3 on joomla 3
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #11 on: September 13, 2019, 23:03:17 pm »
Hmm interesting idea.

http://dev.virtuemart.net/attachments/1181/com_virtuemart.3.6.1.10144_package_or_extract.zip (look last post)

Please read my tutorial. I added to the new core, that already rendered fields are not rendered again. So it is now easy to write backward compatible plugins.

The construction is an idea, but on the other hand it adds "stupid" legacy code (actually very smart). The problem is not to have that for 1-2 years, or 3, the problem is to draw a line. I think about to add it with a deprecated note.
I should fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

EsSa55

  • Jr. Member
  • **
  • Posts: 73
    • 4FootyFans & 4MovieTVmusicFans
  • Skype Name: talk2-4footyfans
  • VirtueMart Version: Live: 3.4.2
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #12 on: September 15, 2019, 11:41:39 am »
Hello

v3.6.1.10144 solves the 'no default currency' issue on my site (ALL payment plugins).

Thanks

Milbo

  • Virtuemart Projectleader
  • Administrator
  • Super Hero
  • *
  • Posts: 9943
  • VM3.2 Cached and Optimized
    • VM3 Extensions
  • VirtueMart Version: VirtueMart 3 on joomla 3
Re: VM 3.6 breaking backwards compatibility with payment methods
« Reply #13 on: September 16, 2019, 08:32:42 am »
Would this help?

In vmPSPlugin

the function checkConditions is called in

getSelectables

Code: [Select]
if ($this->checkConditions ($temp, $method, $cart->cartPrices)) {

replace with the following



Code: [Select]
$temp = $cart;

$temp->ST = $cart->getST();
               
if ($this->checkConditions ($temp, $method, $cart->cartPrices)) {


It ensures a valid shipping address is contained in the temp cart that is passed to check conditions

while the value of the orginal cart does not change.

checkConditions is most time called in the plugin and so it is already to late. But we could do that with the whole trigger. But then payment plugins cannot handle different BT, ST anylonger. But there are plugins working with that.
I should fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

Milbo

  • Virtuemart Projectleader
  • Administrator
  • Super Hero
  • *
  • Posts: 9943
  • VM3.2 Cached and Optimized
    • VM3 Extensions
  • VirtueMart Version: VirtueMart 3 on joomla 3
I should fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/