Can't save number with leading zero to DC_File

[christian-kolb]

I have a DCA File which uses "File" as DataContainer.

// Config
'config' => array
(
    'dataContainer'               => 'File',
    'closed'                      => true
)

One of the fields is there to save the postal which can be a number with a leading zero.

'postal' => array
(
    'label'                   => &$GLOBALS['TL_LANG']['settings']['postal'],
    'inputType'               => 'text',
    'exclude'                 => true,
    'eval'                    => array('mandatory'=>true, 'maxlength'=>32, 'tl_class'=>'w50'),
),

Unfortunately it doesn't work. Whenever I insert a number with a leadings zero, the value gets changed.

For example: "01129" is transformed to "74".
When I insert a letter at the end like "01129A" everything works like a charm. But there shouldn't be a letter at the end of a postal.

This works fine when I save the values to a table.

[discordier]

This issue is already known for some time now.
I have the same problem with the Catalog.

The problem resides in DataContainer Handling and Input handling in Contao in general.
See #1250 and #2148 which shows exact the same problem for other DC. In the end, it is all the same. ;)

[christian-kolb]

But I don't really get why the problem was never solved. If you save the values without an rgxp=>'digit" as text and don't test them with is_numeric then there shouldn't be a problem, should there?
I think this is a bug which just have to be fixed in any way. You can't expect a customer to understand that he just is not able to insert a postal (or any number) without a leading zero, because the system just doesn't support it.

[discordier]

I totally agree that we need a fix. Therefore you might want to give it a try and create a patch. Please focus on backwards compatibility. i.o.w. rather force string handling instead of defaulting to it or you might break existing functionality. We need to elaborate this some more.

[fjacobi]

In my opinion the problem is not in DC_File but in the Config class, in the escape method...

Old:

!preg_match('/e|^00+/', $varValue)

This will also match every postal or phone number you'll try to enter, starting with a zero OR a +xx... So I tried this:

New:

!preg_match('/e|^0+|^\++/', $varValue)

Which seems to work quite well... Except that you can't save any octal numbers...

[leofeyer]

There is another problem with this: Even if you could save octal numbers, they were converted to their decimal equivalent in the back end settings.

[dmolineus]

I've struggled with the same issue. I have to store an postal code in the config as well, starting with a leading zero.

Please provide an optional parameter to the Config class where the escaped format can be forced. A field in the DC_Config should be configurable to set this format as well.

[leofeyer]

We have discussed this in Mumble on January 26th and we have agreed that this is a known limitation. The localconfig.php is to be deprecated in Contao 4 anyways, therefore we do not want to put time and energy into this issue.

[ausi]

Sorry to bring this up again. The localconfig is still used in Contao 4 and the issue can be reproduced with the core fields (e.g. entering 0123 in “Exclude folders from synchronization”).

I think this can be easily fixed by changing the regex in Config.php:475 to !preg_match('/e|^[+-]?0[^.]/', $varValue).

[discordier]

Won't this then change existing behaviour in an incompatible way?
I mean, existing values will then get resaved differently (see comments above)?

IMO the only safe way would be to "type hint" within the field eval, as pointed out above by @dmolineus, yet this would be a new feature.

[ausi]

Won't this then change existing behaviour in an incompatible way?

I don’t think so.

I mean, existing values will then get resaved differently (see comments above)?

Why? Can you give an example?

[discordier]

You are right, it will still safe every fractional number as string. My concerns proved invalid.

[leofeyer]

Fixed in f690d69 then. Thank you @ausi.