Date Field: Validation broken + values overwritten
A bug in 2.2, submitted by michael-e on 14 February 2011
Announcement
Symphony's issue tracker has been moved to Github.
Issues are displayed here for reference only and cannot be created or edited.
Browse
Closed#564: Date Field: Validation broken + values overwritten
The first things makes sense as we rely of strtotime() to handle relative dates (e. g. “today + 1 week”), so we cannot simple check for matching date formats. How should Symphony behave in your opinion?
A string like “hello” should be invalid. Invalid values should not be changed. The field should be marked as invalid, still containing the original value.
(strtotime('hello')
returns FALSE
, so it’s invalid, isn’t it?)
I agree. If strtotime
returns FALSE, which it should if it fails to parse into a date, the field should return the original value as invalid.
Ah, right you are. I thought for a moment strtotime()
returns 1970-01-01 01:00
on error, but it does indeed return false
in this case.
So this should be fixed. :-)
Could wait for after 2.2 as I don’t think it’s a showstopper.
I’ve fixed the bug (Returning invalid for a bad date), but I’d like to spend lunch today looking over how to return ‘Hello’, instead of just blank.
There will be a commit within 4 hours :)
Confirmed. It works really great now!
Nice one mate, thanks! I tried making this change but ended up hacking away. The communication between the different functions (checking post, processing data, display publish panel) wasn’t clear to me, so I’m glad it was pretty simple in the end.
This issue is closed.
There seem to be some severe problems with the date field in Symphony.
Typing pure nonsense like “hello” in a date field bypasses validation, but is turned into a valid date (like 1970-01-01 01:00, depending on Symphony’s date format setting).
If you make the
__isValidDateString
function return false by hardcoding the return value, Symphony will show an error upon saving the entry, but still any original “bullshit” value will be turned into a valid date string (in this case: current date/time).A similar issue can also be seen in Symphony 2.1.2 — the only difference I noticed is that in 2.1.2 case 1 returns the current date/time as well (which might be caused by different server setups — I didn’t test this on the same machine).