Page MenuHomePhabricator

Date values get lost when editing
Closed, ResolvedPublic

Description

I just updated to the master version (1343d6d) and found that my date values get lost if I edit an existing page (the fields are just empty).

My values are in the format 2020/08/21. If I re-enter them they are saved as 2020-08-21. Maybe that helps debugging the issue?

Event Timeline

This issue still persists in version cfe9a8b (5.0 alpha) from 23.10.2020.

Sorry for not responding before. I can't replicate this issue. Is this happening with only a specific input type?

Thanks for your reply and the good question. Indeed, the dates only vanish with input type=datepicker. If I delete input type=datepicker the date doesn't get lost.

This happens, when there is an ''incomplete'' Date in the field , f.e. 2020 or 04/2019. It just clears the field when page is opened by form even the date flield it is not touched by the user.

It was no problem to hold incomplete dates until 5.0 . Currently we loose data with this.

Testcase:

https://sandbox.semantic-mediawiki.org/wiki/Peter_Parker

Born ist 2020-12 , well supported by SMW.

if opened with form the date disappears.

That's interesting. What did datepicker display before on an incomplete date, do you know? Did "2020" become "January 1, 2020"?

No, I think it just display as the data was - 2020 in your case, because it did not change the values, when the page is opened and saved by form.

@Carchaias - is this for the "datepicker" input type, or "date"? This may be a separate issue from the original one reported here.

This is for datepicker and datetimepicker. I just dubblechecked with V 4.9.5 : 4.9.5. did not touch the incomplete dates when the page is opened by form and it allows entering incomplete dates wich is a precondition.

Oh, okay. I don't know what can be done about that - Page Forms now uses the OOUI datepicker (before version 5.0, it used the now-deprecated jQuery UI datepicker), and it doesn't seem like OOUI's datepicker can handle incomplete dates. (I'm surprised to hear that the jQuery UI one did - I didn't use it that much.) I think the best advice might be to switch to using the "date" input type, which can definitely handle incomplete dates.

Switching to input type= date does not solve the problem as it even does no longer fully handle incomplete dates. Example: https://sandbox.semantic-mediawiki.org/wiki/Peter_Parker . This depends on how the date is saved on the page sth. like January 2020 is OK but not 01.2020 . 01.2020 is the style that datepicker before saved the date on page in my wikis -> so all this dates get lost anyway.

Wow, I don't know what to do about this... "MM.YYYY" seems like a strange format for month/year dates. I should know this, but: was that the standard format for the datepicker input, or did you set that? And if you set it, why did you choose that format?

Well, I at least I'm not shure if datepicker used this format for saving data. I crawled thru my date data today and found that MM.YYYY format for a number individual values. Maybe these have been entered by the editor or text-fields.

This style is typical in Germany and somehow supported by SMW well, but these Input types don't like it.

I checked in this change, so now the "date" and "datetime" input types should be able to handle the MM.YYYY format:

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageForms/+/647941

Didn't see this action before I reported a similar issue here: https://phabricator.wikimedia.org/T271224

Yaron_Koren claimed this task.

I haven't heard for sure whether this fix worked for anyone, but I'm assuming that it has - feel free to re-open if not.