I have tested this item ✅ successfully on 4ec63c6

@dgt41 done.

@zero-24 correctly like that?

The default value field must allow to enter "NOW" as a valid value. It would be the most useful default value actually (it will be replaced with current date when the form is shown) ?

So either we leave it as text or we find a way to allow NOW as valid input. The latter would need a plugin specific formfield for the default value.

When the default value is empty then it defaults to now anyway, so it is not needed to have support for the now parameter explicitly.

When the default value is empty then it defaults to now anyway, so it is not needed to have support for the now parameter explicitly.

That's not true (and would be wrong anyway). When the default value is empty it defaults to empty as expected.

Use pattern="Some regex" to customize the validator in client side

@Bakual not the value in the field, but when you open the editor, then it does.

@laoneo fixed with c2e0ea2

@laoneo is it correct that the new field is outside of the fieldset?

@zero-24 yes it is correct, because it overwrites the default field of the normal form and not adding an additional parameter.

? I just want to be sure ;)

not the value in the field, but when you open the editor, then it does.

Yep, when you open the calendar popup, it will start with the current date. But that's not exactly a default value (which would prevent saving an empty value).

So what do you suggest then @Bakual? There is no way to put a string into the datepicker field. What can be done is when the field is required to default it with the current date from the PHP side. Like that we have the "Now" behavior.

I would try an adjusted field where you can toggle between NOW and datepicker mode.

What you guys think, should we go with this PR and don't have support for the "NOW" parameter or should we leave it as a free textarea? I honestly don't have an opinion at all.

I had a look and imho creating a field which allows to enter both is to complex - at least for me.

Personally I wouldn't use the popup to enter the default value and keep the possibility for a NOW value. Which currently means leaving it as freetext. I weight the possibility for a "NOW" value higher since that is a quite useful default value.
However I think it would be great to adjust the tooltip (description) of this field so it is clear that the value needs to be entered in the english format (YYYY-MM-DD HH:MM:SS) and that it allows "NOW" as value.
Overriding the tooltip would be simple. @laoneo already did that in another PR for another custom field ?

@Bakual using a custom element here you could do that in less than 50 lines, but we don't have custom elements...

Reverted the default value and set a better default text.

using a custom element here you could do that in less than 50 lines, but we don't have custom elements...

@dgt41 Actually, we could do what you would do in your custom element just fine with an adjusted plugin specific formfield here. That's not the issue. I just lack the skill to create the JS needed for that and it would take me far more time than it is worth imho. If you know how to do it and make it look pretty, we could do it without any core changes.

@Bakual the js for switching between the 2 values should be exactly the same as #13113

Nah, that wont work because if I understand it right it just deletes the value of another field on submit, but here we need the same field (default_value) to be able to store either "NOW" or a date (with picker).

Ideally the calendar field would just have an added button "NOW" and if enabled it submits "NOW" for the field.
Another thing I would have imagined is a switcher which toggles between two states a "NOW" and the calendar. The tricky part is that both will have to send the same "name" of the field. I assumed if we use two fields with the same name and the inactive is disabled and thus will not be sent it could work. But haven't tested.

Anyway, I lack the skills to do it.

Where are we at with this one?

The proposed solution imho is wrong as it limits the useage. The existing text field isn't "nice" but doesn't limit anything.
Nos other solution coded.

I'v changed the implementation that only the default label and tooltip are changed, not the field type itself. But it needs to wait till #14793 get merged.

This pr is overriding the default strings now correctly, it doesn't change the field type of the default field:

I guess like that we can give it a go for testing.

Merged

I have tested this item ? unsuccessfully on 03fe667

The default value is displayed in the front end but only the date part, the time is not displayed. Thus, for instance the value 2017-08-24 13:45:01 is displayed as 2017-08-24.
Another thing: are the default values set for the field at the article level (Articles:Edit --> Fields tab) override the original field values?(Articled:Edit Field). They don't.

I have tested this item ✅ successfully on 03fe667

Forget my previous test.I had not set the Show Time option to YES