I configured the 'Unpublished on' field as 'Datetime Timestamp' under 'Manage Form Display'. Whenever I created a new node or updated an existing one, the 'Unpublish on' date would be defaulted to the current date and time, which was not expected. (The instruction under the date/time field says "Leave the date blank for no scheduled unpublishing.")
To avoid the 'Unpublish on' date/time being defaulted to the current value, I had to configure it as 'Datetime timestamp with no default'.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2807081-3.label_for_Timestamp_widget.patch | 760 bytes | jonathan1055 |
| #3 | new_widget_label.png | 71.73 KB | jonathan1055 |
| #3 | existing_widget_label.png | 71.05 KB | jonathan1055 |
Comments
Comment #1
wtchan commentedwtchan created an issue.
Clarification: when updating a node, only if the 'Unpublish on' field was blank, it would be updated with current date and time.
Comment #2
jonathan1055 commentedHi Wingo,
Yes, 'Datetime Timestamp with no default' is an extra choice provided by Scheduler specifically to get round the unwanted default. When you first install Scheduler the date widgets are set to this correctly. Only if you uninstall then re-install Scheduler might you have got this problem in the past - the is more discussion on #2652036: Field widget set incorrectly after Scheduler module re-install.
Core issue #2754477: Unexpected config entity delete due to dependency calculations was fixed on 28 June in core 8.1.x and 8.2.x, so it should only be a problem now if an admin changes the date widget from the initial type which Scheduler sets.
Jonathan
Comment #3
jonathan1055 commentedThe datetime widget that we provide for Scheduler is badly labelled. The 'no default' name is done for internal, programming reasons, because the widget does not default to the current date. But this is mis-leading for admins. and also contradictory, given that we can set a default time in the Scheduler settings.
Existing:
There is no need to change the widget name, but it would be an improvement to give a label which indicates what the widget is for, and which module it is used in. Then if someone decides to alter the form display settings they have clearer information on which to make their choices, and this confusion might be eliminated.
New:
Comment #5
jonathan1055 commentedThanks wtchan for bringing this to my attention.
Committed and fixed.