When you set up a date field to collect an end date in the field settings, you are asked for a default end date, with the options Same as Default date, No default value, Now, and Relative. What I miss here, is the option Same as start date.
Same as start date is similar to Same as Default date, with the important difference that the latter is static; it leaves the end date at the Default date, no matter to what value the start date was changed by an editor. Same as start date in contrast would work dynamically: It would pick up the value of the start date chosen by an editor.
In my opinion, the Same as start date setting makes a lot of sense when you collect an end date and when an event is in the future, which is quite often the case. An example: You add an event node on first of July and choose first of October as the start date. The end date has to be by definition after the first of October. But with the end date setting Same as Default date, it defaults to July. So you first have to adjust the end date widget to jump from July to October (or later) before you can choose the end date. In contrast, with the Same as start date setting, the end date widget would switch to October based on the chosen start date, saving you some widget clicks.
PR by @Graham-72: https://github.com/backdrop/backdrop/pull/1923
Recent comments
@yorkshirepudding thank you for the additional info on improving discoverability and a handy way to keep a list of projects for reuse.
Why not add a Github star?
It is a good point @izmeez and when I was researching repo discoverability I found that GitHub search does prioritise matches with more stars. This is what I was researching for:...
Why not add a Github star?
Do you have a separate development environment and transfer database and config between sites?
Wierd happenings regarding updates...