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);
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)
Try the following codes to get the correct shipping address:
<?php
$address = $cart->getST();
?>
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
Use the codes I mentioned in my post above.
Replace
$address = (($cart->ST == 0) ? $cart->BT : $cart->ST);
By
$address = $cart->getST();
It should also be updated in the core plugins soon.
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?
Tested this and the solution for older plugins with $address = (($cart->ST == 0) ? $cart->BT : $cart->ST);
is $address = $cart->getST();
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
Forgot to post the link, please test http://dev.virtuemart.net/attachments/1178/com_virtuemart.3.6.1.10129_package_or_extract.zip
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
Would this help?
In vmPSPlugin
the function checkConditions is called in
getSelectables
if ($this->checkConditions ($temp, $method, $cart->cartPrices)) {
replace with the following
$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
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.
Hello
v3.6.1.10144 solves the 'no default currency' issue on my site (ALL payment plugins).
Thanks
Quote from: ssc3 on September 13, 2019, 08:31:01 AM
Would this help?
In vmPSPlugin
the function checkConditions is called in
getSelectables
if ($this->checkConditions ($temp, $method, $cart->cartPrices)) {
replace with the following
$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.
http://dev.virtuemart.net/attachments/1183/com_virtuemart.3.6.1.10150_package_or_extract.zip
This doesn't help the DIBS payment system.
It is just not showing up on the front page as an alternative.
Have tried reinstalling etc, but no luck.
(Everything updated here... J3.9.11 - VM 3.6.1 10150 - PHP 7.2.22, Apache)
Quote from: Nilsy on September 20, 2019, 09:39:20 AM
This doesn't help the DIBS payment system.
Collect the links to doc.vm.net in this thread and inform your plugin developer.
Hello,
Coming in a little late, but following...
Spoke with the developer, Alatak, about this issue and a similar issue for shipping plugin and wanted to know if there is a temp code fix or it's more complicated and would require a release update...?
Thank you for your time! Jim
the fix for older plugins is in this thread .. http://forum.virtuemart.net/index.php?topic=143564
I think next release will be the official fix
Thanks GJC!
Without sounding worried, can I install the release "com_virtuemart.3.6.3.10163_extract.zip" over my current 3.6.2.10159 and get plugin functionality while maintaining updating VM within Joomla's "Update" feature...?
My apologies if this is not the correct forum for this type of discussion...
Thank you for your time!
Jim
I know Max wants to release 3.6.4 as soon as possible so personally I would wait...
The fix to any old plugins plgVmOnCheckAutomaticSelectedPayment() or plgVmOnCheckAutomaticSelectedShipment() function will work and wont affect anything else.
the idea is to return something .. not 0
I'm not sure what Max wants to finally do but the change that caused the problem in the cart helper has been reverted in 3.6.3.10163
I may be wrong, but I think the checkconditions problem is still an active bug.
There is no fix in the latest revisions that I can see.
If you upgrade your site and have an old style plugin, you may still lose the ability to take orders.
You should NEVER update directly into live
At worst - you should try an update into your test site and see if your payment or shipment plugins are still functioning as expected
Quote from: AH on October 10, 2019, 15:15:06 PM
You should NEVER update directly into live
At worst - you should try an update into your test site and see if your payment or shipment plugins are still functioning as expected
The majority of Virtuemart users are not experienced web designers. They are shop owners first and second.
They do not read these forums and they do not have test sites.
I should know from the emails I have been answering.
They trust the lastest recommended stable release from Virtuemart not to break their shops.
I understand the problems with updating and the issues it can bring.
QuoteThey trust the lastest recommended stable release from Virtuemart not to break their shops.
And that is normally the case. But they should have a plan for if it does.
This is an unfortunate plugin compatibility issue that - no doubt - will get resolved.