PW 3.0.171 – Core updates

[ryan]

This week I've had to work on a client project (and that continues for the next week or two), but also have some good progress in the next development branch version of ProcessWire (v3.0.171), which includes the addition to two feature requests: 

The Repeater Fieldtype (and likewise RepeaterMatrix) was updated to improve support for the "depth" option by introducing something called "family friendly mode". This makes the "depth" setting behave in a manner where items with more indent are considered children of items with less indent (parents). So when you click and drag to move a parent item, it brings along the children too. This works whether changing the location or the indent of the parent. In addition, it enforces the parent/child relationship so that there can't be more than one level of indent between parent and child. So you couldn't (for example) have a parent-to-grandchild relationship in the repeater items. A useful case for this is when using repeaters in page builder contexts, like those Jonathan Lahijani demonstrated with RepeaterMatrix. In fact, the settings in this "family friendly" mode were his idea. More to come here too. To enable "family friendly mode", go to your Repeater or RepeaterMatrix field settings and make sure the "depth" setting is greater than 1. When greater than 1, the family-friendly option will appear as a toggle you can enable. 

The other thing added to the core this week was a FieldtypeDecimal module that has been requested for awhile. I was planning on making it a setting of FieldtypeFloat, largely to avoid interfering with the existing 3rd party FieldtypeDecimal module. But a few people indicated they'd prefer it to be separate. After testing on an installation that already had the 3rd party FieldtypeDecimal installed, I found it didn't cause any problems, so that alleviated my concern. To be safe, the new core FieldtypeDecimal module uses the same exact setting names as the 3rd party one, so that hopefully they should remain compatible. In my case, I found that deleting my /site/modules/FieldtypeDecimal directory, and then doing a “Modules > Refresh” enabled the core one to take over with any existing decimal fields. However, until we have reports that the same works well for others, I would suggest backing up and confirming it yourself to be safe. It's not often we intentionally introduce module name collisions, and I don't think we've ever done it in the direction where a new core module overlaps with an established 3rd party one. But in this case, it does seem to facilitate the transition a bit. 

That's all for this week. I've been enjoying and am looking forward to continuing with our roadmap discussions hopefully next week. Have a great weekend! 

[ceberlin]

I can confirm that this method of replacing the decimal field worked on my e-commerce-Project where I tried this. No problems.

[csaggo.com]

Thanks for the addition of Decimal-Field.
Do you think it would be easy to add a setting for using a "," instead of a "." as decimal-seperator. (this is the common notation in the german-speaking countries)

[bernhard]

Yep, that would be great! And it would also be great if it was possible to input 1,23 (using comma), because we have , (comma) and not . (dot) on the numpad:

[LostKobrakai]

Just now, bernhard said:

And it would also be great if it was possible to input 1,23 (using comma), because we have , (comma) and not . (dot) on the numpad:

The HTML5 number input should handle that already. For formatting for output I'd suggest looking at NumberFormatter of php / the intl extension. Having worked with a cldr based library elsewhere extensively I can suggest everyone dealing with locales to use a library for all those differences instead of building one-of solutions.

[Ralf]

On 1/25/2021 at 11:02 AM, LostKobrakai said:

The HTML5 number input should handle that already.

Yes with the HTML5 input type the issue of a comma or dot for the "decimal places" is solved.

However, I then have the issue in the admin area that large values are as good as no longer readable, because I can now no longer capture points.

With the input type text I can enter commas and dots, but as bernhard has already explained in this issue report, PW then stores no value in the DB.
And now?

[LostKobrakai]

Generally I advice to keep formatting/parsing at the edges of any system. Input type number is basically the outermost edge by having the client deal with the normalization, as the client has the most knowledge about the user (locale, system settings, …). The visible input is formatted to the users settings, while the number submitted is normalized cleanly for computers to deal with.

The next outer most layer in processwire would be the Inputfieldfield module. InputfieldText does handle text and doesn't claim to do anything else, while setting it to type number as you asserted might lack features. So the solution would be to create another Inputfield, which is aware of different means of parsing/formatting numbers – maybe even being aware of locales to not just guess the former. This could still render a text input, but handle all the details of locale aware number formatting and parsing.