Monetary usage lang transition

[tgtje]

Long story in short ( i hope): Systems runs quite smooth using new lan version, best on BANK. External gateways throws error(s) Tested (i supply Alex tested, as a api key is for business only) on Mollie as being largest gateway. The new version seems functioning well on English based LANG files. (eg : Eng en Dutch using same defines!!)

Problem : switching to Dutch results in click>Buy Now! > white page (no error etc..). After deeper digging in error logs Alex found :

Got error 'PHP message: PHP Fatal error: Uncaught InvalidArgumentException: Invalid integer part 7,2. Invalid digit , found in /xxxx/e107_plugins/vstore/vendor/moneyphp/money/src/Number.php:256\nStack trace:\n#0 /xxxxxxxxxx/domains/xxxxxxxxxxxl/e107_plugins/vstore/vendor/moneyphp/money/src/Number.php(37): Money\Number::parseIntegerPart()\n#1 /xxxxxxx/domains/xxxxxxxx/e107_plugins/vstore/vendor/moneyphp/money/src/Number.php(50): Money\Number->__construct()\n#2 /xxxxx/domains/xxxxx/e107_plugins/vstore/vendor/omnipay/common/src/Common/Message/AbstractRequest.php(282): Money\Number::fromString()\n#3 /xxxxxxxt/domains/xxxxx/e107_plugins/vstore/vendor/omnipay/common/src/Common/Message/AbstractRequest.php(315): Omnipay\Common\Message\AbstractRequest->getMoney()\n#4 /xxxxxxxx/domains/xxxxxxx/e107_plugins/vstore/vendor/omnipay/mollie/src/Message/Request/PurchaseRequest.php(77): Omnipay\Comm...', referer: https://xxxxxx/vstore/checkout/.

Searching reveals (iff i understand correctly) Invalid integer part 7,2. Invalid digit points to numberformat eg : system does not 'convert' the Numberformat Dutch uses > 12,00 vs 12.00 ( comma vs point ). FF in Eng points ( . . . ) fine NOw for testing purposes after a lot of reading in forum Moneyphp (2020) a similar case happened when setlocale is in use. This assumption made me to comment the setlocale ( lan/Dutch/Dutch php) to not being 'seen'. System reacts to change al dutch curruncy numbers , , to points... (hoped and getting). Applying this in a live setting now Dutch shop functions too. (of course nice, but we (dutch etc.. do not use . in number buildup, and so will be the all others langs))

So have to conclude : ?? the moneyphp files (interacts with omnipay???) do something wrong with numberformation/conversion.

Small peeks into files : some present files look older (in coding changes) than presently on MP site..

so basically : functioning shop afaics, but numberformatting is the barrier. How to go on?, as this is going out of my league/knowledge.

edit : >working php 7.4.x 8.x.xx latest git's)

just notice #103 Alex already posted it also ;-)

[CaMer0n]

@tgtje @Alex-e107nl Thank you for your research on this.

I've been running some tests locally. My session data still uses the format 0.00 even with the the locale set to NL. (it does display the price with the 0,00 format though). Perhaps you can test on your side? Just enable debug ?[debug=paths+] then add an item to the cart and proceed to "Checkout". Scroll to the bottom of the page until you see Session Data for 'vstore' and then check the 'price' values.

I have also added this line to vstore.class.php (line 1848) which you can uncomment to log the data before it is sent to OmniPay.

// file_put_contents(DIR."/checkoutData.log", var_export($_data,true));

I have added some extra casting of (float) to the price values. That could help, but you will want to run tests with a decimal price. eg. $19.95 to make sure it didn't round the price up or down.

[Alex-e107nl]

Thx Cameron for looking in to it, i have tested on e107 github of today, downloaded git vstore with changes of today and activated the logging with checkoutData.log

With the admin language set to EN i get:

array (
  'cancelUrl' => 'https://e107.nl/vstore/checkout/cancel/',
  'returnUrl' => 'https://e107.nl/vstore/checkout/return/',
  'amount' => 7.2,
  'shippingAmount' => 0.0,
  'currency' => 'EUR',
  'items' => 
  array (
    0 => 
    array (
      'id' => '1',
      'name' => '00021',
      'price' => 5.95,
      'description' => 'Test product',
      'quantity' => 1,
      'tax_rate' => 0.21,
      'file' => '',
      'vars' => '',
      'item_vars' => '',
    ),
  ),
  'transactionId' => 'babc9b0900336be58ccfd5bc4b4e03ba',
  'clientIp' => '0000:0000:0000:0000:0000:ffff:5457:8588',
  'description' => 'Order date: Saturday, 17 Dec, 2022',
  'paymentMethod' => 'ideal',
)

And this one works, i get the test and can choose what i want to do, complete etc... The next is the logging with the admin language set to NL, see the Saturday - changed to Zaterdag and 17 Dec is 17 dec., with an extra . ? Rest seems okay?

array (
  'cancelUrl' => 'https://e107.nl/vstore/checkout/cancel/',
  'returnUrl' => 'https://e107.nl/vstore/checkout/return/',
  'amount' => 7.2,
  'shippingAmount' => 0.0,
  'currency' => 'EUR',
  'items' => 
  array (
    0 => 
    array (
      'id' => '1',
      'name' => '00021',
      'price' => 5.95,
      'description' => 'Test product',
      'quantity' => 1,
      'tax_rate' => 0.21,
      'file' => '',
      'vars' => '',
      'item_vars' => '',
    ),
  ),
  'transactionId' => 'babc9b0900336be58ccfd5bc4b4e03ba',
  'clientIp' => '0000:0000:0000:0000:0000:ffff:5457:8588',
  'description' => 'Order date: zaterdag, 17 dec., 2022',
  '
```paymentMethod' => 'ideal',
)

This last one gives a blank screen ... with an server error:

[Sat Dec 17 21:00:31.101011 2022] [proxy_fcgi:error] [pid 3891332:tid 140343576073984] [client 84.87.133.136:64508] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught InvalidArgumentException: Invalid integer part 7,2. Invalid digit , found in /home/******/domains/e107.nl/private_html/e107_plugins/vstore/vendor/moneyphp/money/src/Number.php:256\nStack trace:\n#0 /home/******/domains/e107.nl/private_html/e107_plugins/vstore/vendor/moneyphp/money/src/Number.php(37): Money\\Number::parseIntegerPart()\n#1 /home/******/domains/e107.nl/private_html/e107_plugins/vstore/vendor/moneyphp/money/src/Number.php(50): Money\\Number->__construct()\n#2 /home/******/domains/e107.nl/private_html/e107_plugins/vstore/vendor/omnipay/common/src/Common/Message/AbstractRequest.php(282): Money\\Number::fromString()\n#3 /home/******/domains/e107.nl/private_html/e107_plugins/vstore/vendor/omnipay/common/src/Common/Message/AbstractRequest.php(315): Omnipay\\Common\\Message\\AbstractRequest->getMoney()\n#4 /home/******/domains/e107.nl/private_html/e107_plugins/vstore/vendor/omnipay/mollie/src/Message/Request/PurchaseRequest.php(77): Omnipay\\Comm...', referer: https://e107.nl/vstore/checkout/

e107 - Version 2.3.3 (git) 
Server - Apache/2 - (host: e107.nl)
PHP Version - 7.4.33
MySQL - 10.5.18-MariaDB

[Alex-e107nl]

Maybe this https://github.com/moneyphp/money/issues/593 helps?

[CaMer0n]

Thanks @Alex-e107nl .

After seeing your data dump, it's clear that the issue is in the vendor's code, and not vstore. The link you shared confirms this and the workaround I had also seen elsewhere. Could you please add the following code right before that logging code (ie. ... checkoutData.log) and test again?

setlocale(LC_NUMERIC, 'en_US');

[Alex-e107nl]

Yesss that's solved it, i can do a test payment with Mollie now in the NL language!

Logged:

array (
  'cancelUrl' => 'https://e107.nl/vstore/checkout/cancel/',
  'returnUrl' => 'https://e107.nl/vstore/checkout/return/',
  'amount' => 7.2,
  'shippingAmount' => 0.0,
  'currency' => 'EUR',
  'items' => 
  array (
    0 => 
    array (
      'id' => '1',
      'name' => '00021',
      'price' => 5.95,
      'description' => 'Test product',
      'quantity' => 1,
      'tax_rate' => 0.21,
      'file' => '',
      'vars' => '',
      'item_vars' => '',
    ),
  ),
  'transactionId' => '637244459d7a96d94175d47bdc626865',
  'clientIp' => '0000:0000:0000:0000:0000:ffff:5457:8588',
  'description' => 'Order date: maandag, 19 dec., 2022',
  'paymentMethod' => 'ideal',
)

Only thing is that the green alert gives a generic error?

Succes Generic error Your order #ALVA000041 is complete and you will receive a order confirmation with all details within the next few minutes by email.

and now hopefully on to the translated version of the vstore that tgtje has been working on!

THX!

[tgtje]

@Alex-e107nl point at 17 dec. is likely the date format (dutch : Factuur datum formaat) the chooseable state is with a . (eg 17 dec. , < in field)

[Alex-e107nl]

Thx tgtje, https://e107.nl/e107_admin/prefs.php#nav-core-prefs-date there's the dec. brrrrr that . is should not really be there i think...

[tgtje]

[Wed Jan 11 20:05:18.483407 2023] [lsapi:error] [pid 28458:tid 140522127582976] [client 2a02:a44e:70e6:1:784f:a0a1:8711:a7cb:2657] [host xxxxx] Backend fatal error: PHP Fatal error: Uncaught Omnipay\Common\Exception\InvalidRequestException: Amount precision is too high for currency. in /home/xxxxx/domains/xxxxx/e107_plugins/vstore/vendor/omnipay/common/src/Common/Message/AbstractRequest.php:288\nStack trace:\n#0 /home/xxxxx/domains/xxxxx/e107_plugins/vstore/vendor/omnipay/common/src/Common/Message/AbstractRequest.php(315): Omnipay\Common\Message\AbstractRequest->getMoney()\n#1 /home/xxxxx/domains/xxxxx/e107_plugins/vstore/vendor/omnipay/mollie/src/Message/Request/PurchaseRequest.php(77): Omnipay\Common\Message\AbstractRequest->getAmount()\n#2 /home/xxxxx/domains/xxxxx/e107_plugins/vstore/vendor/omnipay/common/src/Common/Message/AbstractRequest.php(686): Omnipay\Mollie\Message\Request\PurchaseRequest->getData()\n#3 /home/xxxxx/domains/xxxxx/e107_plugins/vstore/vstore.class.php(1877): Omnipay\Common\Message\AbstractRequest->send()\n#4 /home/xxxxx/domains/xxxxx/e107_plugins/vstore/vstore.class.php(716): vstore->processGateway()\n#5 /home/xxxxx/domains/xxxxx/e107_plugins/vstore/vstore.class.php(322): vstore->process()\n#6 /home/xxxxx/domains/xxxxx/e107_plugins/vstore/vstore.php(41): vstore->init()\n#7 /home/xxxxx/domains/xxxxx/index.php(69): include_once('/home/u2004d311...')\n#8 {main}\n thrown in /home/xxxxx/domains/xxxxx/e107_plugins/vstore/vendor/omnipay/common/src/Common/Message/AbstractRequest.php on line 288\n, referer: https://xxxxx/vstore/checkout/

testing on live server ( new domain; fresh files) 2.3.3 latest git php 8.1.1
throws on checkout>> page 500 >>log >>Amount precision is too high for currency according to github.com/thephpleague/omnipay-common/issues/143 added floats throw issues. now it seems ALSO related to php versions ( interpretation of files) when i revert the added float code lines (class php) and even do NOT use the locale US > it functions see images

image 1 > order in EURO Dutch with , no point ( internal admin uses a point on list, while product itself amount is entered with a , (comma). So > i use dutch method... see blue list all is with comma

image 2 after reverted the float code (eg removed; rest unchanged and NO locale US) i receive this (bare in mind i use a fake mollie test key so the outcome is expected (OK) . (because of this message / system servers communications a further handling of the handling does not take place (mails,confirmation etc..). > for me it points to working (without errors so far). I just post it because any further testing (if willing) to do by Alex (but helas ill).

a sample log array ( 'cancelUrl' => 'https x/vstore/checkout/cancel/', 'returnUrl' => 'https x/vstore/checkout/return/', 'amount' => 9.98, 'shippingAmount' => 3.95, 'currency' => 'EUR', 'items' => array ( 0 => array ( 'id' => '2', 'name' => 'VIDEO556', 'price' => '9.25', 'description' => 'Hindsight dvd', 'quantity' => '1', 'tax_rate' => 0.21, 'file' => '', 'vars' => '', 'item_vars' => '', ), ), 'transactionId' => '57cf5a90c88c7a72d112eac12de0253d', 'clientIp' => '2a02:a44e:xxxxxxxxxxxx 'description' => 'Besteldatumwoensdag, 11 jan., 2023', 'paymentMethod' => 'ideal', )

[tgtje]

edit : site is dutch installed and running dutch, Voux in use ( no issues (identical behavior) when switching to BS5 or BS3)

[tgtje]

Done more testing on 3 different php versions : 7.4.2 8.0.4 8.1.1 scenario using a vstore setup BEFORE latest changes (float etc.) were made 7.2.4 fails (error 500) 8.0.4 success 8.1.1 success

need to mention when i use 8.1.1 (assuming now 8.0.4 will react same) float throws above mentioned error..Amount precision.... so it SEEMS that the latest additions were not necessary (iff case : sorry) knowing NOW that a change in php versions has a greater impact than expected. Since i do not know too much of the interaction of a lot of one would likely assume here that (Float to string casting will now always behave locale-independently. as of 8.0.x) has influence ????? ( do not know if correct) and as a second since the overall issues COULD have been influenced by the system language locales (main setlocale). Again assumption : these all almost for every lang pack the same PER country (in cont.mang. lang), which means that a locale is written: example : 'nl_NL.utf8', 'nld_nld.utf8', 'nld.utf8', 'nl.utf8', 'nl' > identical construction for most present languages. All newer speak only of the country and language in the xx_XX format specified by ISO 15897 > nl_NL (ISO 15897: uses an underscore). (each country has own)

example of float to string casting : `Float to string casting will now always behave locale-independently. as of 8.0.x

php setlocale(LC_ALL, "de_DE"); $f = 3.14; echo $f, "\n"; // Previously: 3,14 < comma // Now: 3.14 < point `

Done some more research esp. in Mollie api they do mention :

Mollie : our hosted payment pages currently only support the following languages: en_US en_GB nl_NL nl_BE fr_FR fr_BE de_DE de_AT de_CH es_ES ca_ES pt_PT it_IT nb_NO sv_SE fi_FI da_DK is_IS hu_HU pl_PL lv_LV lt_LT. An ISO 4217 currency code. > Iso 4217 : EUR = correct country of the address in ISO 3166-1 alpha-2 format : NL a date in YYYY-MM-DD format phone numbers must passed as strings in the E.164 format. For example, +31208202070.

Although i do not see very much happening when nl_NL is used in 7.2.4. and php 8.x, it is possible that Mollie literally sees nl_NL and not any of the nl_NL.utf8', 'nld_nld.utf8', 'nld.utf8', 'nl.utf8', 'nl' ?? Due to php changes it is harder to make a statement. Anyway i would ssuggest for further use to add the ISO 15897 > nl_NL structure for ALL languages (each country its own) (yes would be a translator information)

English ( en ) seems to not be affected overall as a general code when no specific country is needed.

ps whilel searching and reading : IntlDateFormatter ; new class IntlDatePatternGenerator >php 8.1

Anybody any insight in this ??