decimal field ignores comma input

[BernhardBaumrock]

Short description of the issue

If a user enters a german decimal value using "comma" instead of "dot" the value is completely (and silently!) ignored.

Expected behavior

The comma should be converted to a dot or at least the field should throw an error message to indicate that the value was not saved.

Actual behavior

Input:

After save:

The input is just ignored - without any helpful or warning information...

Discussion

I think the easiest solution would be to add a setting to the fieldtype (or maybe also to fieldtypefloat?) that defines the comma separator and if it is set to "comma" the field will save a value of 1,23 as 1.23

[ryancramerdesign]

@BernhardBaumrock I had thought that the HTML5 number input took care of this case. Can you check that your field settings "Input" tab has "HTML5 number" selected for the "Numeric input type"? If it doesn't, please test to see if that resolves it. If so, then we probably just drop the "Text" option for this field, as it's only there for legacy reasons, so hardly necessary on this relatively new fieldtype. If it doesn't fix it, then we'll probably have to get into checking locale settings for decimal and thousands separators, etc. Thanks.

[BernhardBaumrock]

Hey @ryancramerdesign sorry for the late response, I had a filter catching all mails from github :)

You are right that it works when using the HTML5 number input type! But please don't remove the text input option - that's a necessity for my calculator module: https://github.com/baumrock/RockCalculator

The number input on the other hand converts this:

1.500,50

To that:

Number inputs are a pain - so I don't expect you to solve all these troubles :) But I think at least possibly critical things should be fixed, so maybe just show a warning if the field had some input but nothing was saved to the database?

Not sure if the field should also take care of formatting different inputs and trying to save that intelligently to the database as we have several different formats around the world and even here in austria I find differently used numbers on invoices every day... Ideally I could just copy and paste the following input into the field and it would store a correct value:

1.000,50€ --> 1000.00
1.000  --> 1000.00
1,500 --> 1.50
1 000,50 --> 1000.50

Maybe we could have some algorithm?

If there are both dot and comma, the last one is the decimal
If there is only one (dot/comma), use the field settings to determine if it is a thousands separator or a comma (or better decide on the number of digits behind the separator?)
...

Thx for your thoughts.

PS: Maybe a little JS (similar to rockcalculator) could help that parses the input instantly and shows the result to the user. This would make it obvious what happened. RockCalculator for example does this and converts numbers to decimal point format (even though this is not common here, but it works best...)

[skeltern]

Hi all, following my conclusion after different checks.

FieldtypeDecimal ist not usable in the backend if the language locale setting is different from the default English dot '.' decimal separator. For example with German language Pack and locale 'de_DE.UTF-8'.

As German editor you can't see an existent decimal field value. And you can't add anyone decimal number in English ('55.44') or German ('55,44') format. Only full integers are stored without digits ('55.00'). So this great fieldtype is not usable in many language contexts.

FieldtypeFloat, on the other hand, works correct with such different locale separators. I guess this issue could be fixed by updating the FieldtypeDecimal module through the context locale separator involvement. Fallback option, each decimal field in all languages accepts just English format regardless from locale setting ('55.44').

Hope there is a chance to fix this behaviour. Because decimal fieldtype is such helpful!

.

[matjazpotocnik]

Maybe we need something like http://autonumeric.org/ ?

[BernhardBaumrock]

Autonumeric looks interesting. Though I'fe found 2 issues when playing around with it:

1. For my CRM I'm often copy and pasting invoice amounts. Depending on the origin of the invoice the amount can be something like 1.000,00 or 1,000.00 - ideally both inputs should end up as onethousand, but depending on the comma separator one input of both will be ignored
2. On mobile the inputfield is a regular text inputfield. It would be nice to have a number inputfield to get only the numpad instead of the whole keyboard

[skeltern]

FieldtypeDecimal ist not usable in the backend if the language locale setting is different from the default English dot '.' decimal separator...

I spend more time to test the decimal fieldtype on different sites with different language setups. It's a little bit confusing. In some cases it works like a charm in multilang setups trought all languages (backend editor languages). With field input setting "Number (HTML5)" even with correct separator by language. In other similar setups I can only edit and see decimals as english backend editor as described before.

A possible explanation might be the switch from installed third party "classic" decimal fieldtype to the new core fieldtype. I'm not sure but I guess this decimal separator issue is connected with old to new fieldtype switch. On "fresh" installs with decimal fieldtype as core field it works, on older installs with switch older third party to core field I see described issue. Maybe anyone simple detail in the background after field switching. It's a mystery. :)

Can anyone confirm this?

[matjazpotocnik]

Perhaps <input type="text" inputmode="decimal" /> ? And perhaps we need dedicated money fieldtype/inputfield?

[skeltern]

Perhaps <input type="text" inputmode="decimal" /> ? And perhaps we need dedicated money fieldtype/inputfield?

I don't think there is an extra fieldtype needed for money. FieldtypeDecimal covers all types of money values. If it works.

[skeltern]

FieldtypeDecimal works as espected with PHP 8, but not 7.4

Another update... It seems surprisingly connected with the running PHP version. In PHP 7.4 the field has issues as long described above. In PHP 8 is works as expected even with different digits separator by language. Tested on two sites which switched from 7.4 to 8. That explains my guess older sites have issues and newer are fine.

Nevertheless it would be nice that FieldtypeDecimal works correct even with older PHP 7.4. Not every site could be easy peacy updated and FieldtypeDecimal is not usable in many contextes.

[ryancramerdesign]

@matjazpotocnik That's a good idea. I don't know how that would affect the issue mentioned here specifically but it seems like a good addition for mobile device input either way. I have added it. @skeltern I pushed some updates for #1594 that might also help with this one. Glad to hear that it seems to be working as expected in PHP 8 though. It must be due to some difference in the locale conversion supported in the PHP versions.

[matjazpotocnik]

@skeltern what's the status of this issue? I guess the PHP differences still play a role?

[poljpocket]

This just happened to us too. We were building a site locally with a decimal input set to text mode.

Locally on Docker, the output used a . (dot) as a decimal point which worked flawlessly. After deploying to the staging server, our numbers got mangled after simply saving a page with decimal inputs in it. It took us some time to realise that all of a sudden - probably because of server locale differences - there was a , (comma) used as a decimal point. Upon saving, this got ignored and so the digits after the dp would be promoted to digits in front of the dp converting 1000s to 1000000000s.

We are on PW version 3.0.227, Browser is Edge 124

We fixed the problem by using the HTML5 number input option in the field settings.

[matjazpotocnik]

Thanks for the report. What's the PHP version and locale?

[poljpocket]

Thanks for the report. What's the PHP version and locale?

Thanks for looking into it!

The local Docker install uses PHP 8.2.18 and locale variable LC_ALL is set to C.

The remote dev environment uses PHP 8.2.16 and the locale variable LC_ALL is set to C.

So actually only a very minor difference. I used Tracy's PHP console to get the locale variable.