Bug #91731
closedCannot empty a date field in TCEforms if MySQL is in strict mode
0%
Description
Steps to reproduce:
1. Have MySQL in strict mode (i.e., the default configuration without any changes): STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION (this is MariaDB's default)
1. Have an extension with a date or datetime field that uses the config 'eval' => 'date' or 'eval' => 'datetime'
1. Fill in a date and save.
1. Empty the date (by using the "clear" icon) and save again.
Expected result:
The date field is emptied, and there is no error message.
Actual result:
The date field still has the date value (that should have been removed), and an error flash message is displayed:
SQL error: 'Incorrect integer value: " for column `…'
Additional information:
Bug report in the seminars extension:
https://github.com/oliverklee/ext-seminars/issues/548
Workaround in the seminars extension:
Add an int eval: https://github.com/oliverklee/ext-seminars/pull/549/files
So empty date and datetime fields need to be cast to an integer before saving so that an empty value gets converted to 0.
Updated by Xavier Perseguers almost 3 years ago
- Related to Bug #95513: SQL error: 'Incorrect integer value: '' for column 'grade' at row 1' added
Updated by Georg Ringer about 2 years ago
- Status changed from New to Needs Feedback
IMO this is fixed by using additional eval:int
and with latest version a config like
'config' => [ 'type' => 'datetime', 'default' => 0, ],
can you confirm?
Updated by Oliver Klee about 2 years ago
With this configuration in the TCA, the problem still is there in V11 and V10:
'config' => [
'type' => 'input',
'renderType' => 'inputDateTime',
'eval' => 'datetime'
]
I consider adding the int eval or the 0 default as a workaround, not as a fix to the problem. IMHO the core should do the correct casts by default for date/datetime fields.
Updated by Garvin Hicking 2 months ago
- Status changed from Needs Feedback to Closed
Closing due to https://forge.typo3.org/issues/95513 - I think that the 'default=0' notation is a de-facto standard as of now, also documented with a note. This issue didn't get real traction and for the sake of cleaning up I hope it's ok to leave this be for now.
Since TCA streamlining is a process already, I'd rather think this will get addressed at the time where this is refactored and lead to better "default" casting.