Allow configuring of datelist year range date_year_range via UI

giddyup

This works for me

This is an experimental module so no need for the upgrade path and upgrade path tests.

A few questions/comments here.

Why is this only specific to the daterange field? Both normal datetime and date range fields support select list entry. Also, this is currently applied as a setting regardless of the form widget selected. It is only applicable to select list entry I think (unless it is meant to validate/constrain dates between those years, in which case it needs work since that bit isn't working...).

Also, we already have a Datelist form element, which that widget is using. Can't we just expose the setting and then stuff it into #date_year_range key in DateRangeDatelistWidget::formElement() and DateTimeDatelistWidget::formElement().

 /*
   *   - #date_year_range: A description of the range of years to allow, like
   *     '1900:2050', '-3:+3' or '2000:+3', where the first value describes the
   *     earliest year and the second the latest year in the range. A year
   *     in either position means that specific year. A +/- value describes a
   *     dynamic value that is that many years earlier or later than the current
   *     year at the time the form is displayed. Defaults to '1900:2050'.
   */

Since PluginSettingsBase::getSetting() merges in defaults, I don't think either would need an upgrade path and upgrade path tests, just a cache clear.

Also, we already have a Datelist form element, which that widget is using. Can't we just expose the setting and then stuff it into #date_year_range key in DateRangeDatelistWidget::formElement()

That's what the patch does, the YearRange form element is just for the settings form, borrowed from the approach in date_api in D7.

I agree, this can go up one layer further to the single date field, but that'd be in the non-experimental module.

> I agree, this can go up one layer further to the single date field, but that'd be in the non-experimental module.
Let's do that. I believe we can add new features to any module in a minor release.

I just re-read this. Haven't played with it applied, but I like the better UX of the form element approach rather than a simple text field.

And yeah, this can go into the datetime version, too. As long as the datetime version doesn't depend on the daterange one, they this is a valid new feature for 8.4.x: it adds a new admin feature to an existing form in a non-disruptive way. A select with 150 things in it is a UX WTF anyway.

1. +++ b/core/modules/datetime_range/src/Element/YearRange.php
   @@ -0,0 +1,104 @@
   +    if (!self::rangeIsValid($year_range)) {
   +      $form_state->setError($element['years_back'], t('Starting year must be in the format -9, or an absolute year such as 1980.'));
   

   static

2. +++ b/core/modules/datetime_range/src/Plugin/Field/FieldWidget/DateRangeWidgetBase.php
   @@ -164,4 +165,34 @@ protected function createDefaultValue($date, $timezone) {
   +  public static function defaultSettings() {
   +    return parent::defaultSettings() + [
   +        'year_range' => '1900:2050',
   +      ];
   +  }
   +
   

   I don't think the setting should be on the base class, just the list widget.

3. +++ b/core/modules/datetime_range/src/Plugin/Field/FieldWidget/DateRangeWidgetBase.php
   @@ -164,4 +165,34 @@ protected function createDefaultValue($date, $timezone) {
   +    return parent::defaultSettings() + [
   +        'year_range' => '1900:2050',
   +      ];
   +  }
   

   Extra indent.

4. +++ b/core/modules/datetime_range/tests/src/Functional/DateRangeYearRangeTest.php
   @@ -0,0 +1,123 @@
   +    $storage = FieldStorageConfig::create([
   +      'entity_type' => 'entity_test',
   +      'field_name' => 'range',
   +      'id' => 'entity_test.range',
   +      'type' => 'daterange',
   +      'settings' => [
   +        'target_type' => 'entity_test',
   +      ],
   +    ]);
   +    $storage->save();
   +    $config = FieldConfig::create([
   +      'field_name' => 'range',
   +      'entity_type' => 'entity_test',
   +      'bundle' => 'entity_test',
   +      'id' => 'entity_test.entity_test.range',
   +      'label' => 'Range',
   +    ]);
   +    $config->save();
   

   We can just use the ->save() w/o an intermediate local variable.

5. +++ b/core/modules/datetime_range/tests/src/Functional/DateRangeYearRangeTest.php
   @@ -0,0 +1,123 @@
   +      ->setComponent('range', array(
   +        'type' => 'daterange_datelist',
   +        'weight' => 10,
   +      ))
   

   Can use [].

Looks like there is no coverage of the new form element on the manage display or did I miss something?

Rerolled the patch.

Fixed minor coding standards issues.
Removed Needs Reroll tag.

Doesn't look like #10 has been addressed.

Sorry, my mistake. I didn't read properly and assumed they had all been address in #13.

1. Changed self:: to static::
2. Moved defaultSettings() to DateRangeDatelistWidget
3. Resolved as part of 2.
4. Removed intermediate variables
5. Corrected as part of the re-roll in #13

Add defaultSettings() to DateRangeDefaultWidget too.

Did some manual testing.

Currently doesn't work on datetime fields. Let's make it work there, too.

Like the way this works on daterange. Big UX win.

Patch in #19 no longer applies cleanly. Re-rolled.

Added to datetime fields in the same way it is on daterange fields.

1. +++ b/core/modules/datetime/src/Plugin/Field/FieldWidget/DateTimeDatelistWidget.php
   @@ -26,7 +26,9 @@ public static function defaultSettings() {
   -    ] + parent::defaultSettings();
   +    ] + parent::defaultSettings() + [
   +      'year_range' => '1900:2050',
   +    ];
   

   I think we need to move this to DateTimeWidgetBase.

2. +++ b/core/modules/datetime/src/Plugin/Field/FieldWidget/DateTimeDatelistWidget.php
   @@ -138,7 +140,7 @@ public function settingsForm(array $form, FormStateInterface $form_state) {
   -    $summary = [];
   +    $summary = parent::settingsSummary();
   

   Need to look at this applied, but this looks like it could be out of scope? But if we do the #1 bit, then this is probably needed.

3. +++ b/core/modules/datetime/src/Plugin/Field/FieldWidget/DateTimeDefaultWidget.php
   @@ -98,4 +98,13 @@ public function formElement(FieldItemListInterface $items, $delta, array $elemen
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public static function defaultSettings() {
   +    return parent::defaultSettings() + [
   +      'year_range' => '1900:2050',
   +    ];
   +  }
   +
   

   This def needs to move to DateTimeWidgetBase() so it is available in all of the Datetime widgets.

4. +++ b/core/modules/datetime_range/config/schema/datetime_range.schema.yml
   @@ -71,3 +71,7 @@ field.widget.settings.daterange_datelist:
   diff --git a/core/modules/datetime_range/src/Element/YearRange.php b/core/modules/datetime_range/src/Element/YearRange.php
   
   diff --git a/core/modules/datetime_range/src/Element/YearRange.php b/core/modules/datetime_range/src/Element/YearRange.php
   new file mode 100644
   
   new file mode 100644
   index 0000000..e39a262
   
   index 0000000..e39a262
   --- /dev/null
   
   --- /dev/null
   +++ b/core/modules/datetime_range/src/Element/YearRange.php
   
   +++ b/core/modules/datetime_range/src/Element/YearRange.php
   +++ b/core/modules/datetime_range/src/Element/YearRange.php
   @@ -0,0 +1,104 @@
   

   This can't be in datetime_range. At a min, it needs to be in datetime, but possibly in with the core Elements since there could be value outside these modules.

   ?

5. +++ b/core/modules/datetime_range/src/Plugin/Field/FieldWidget/DateRangeDatelistWidget.php
   @@ -27,7 +27,9 @@ public static function defaultSettings() {
   -    ] + parent::defaultSettings();
   +    ] + parent::defaultSettings() + [
   +      'year_range' => '1900:2050',
   +    ];
      }
   

   See above bit about moving to the base class.

6. +++ b/core/modules/datetime_range/src/Plugin/Field/FieldWidget/DateRangeDefaultWidget.php
   index 0000000..308751d
   --- /dev/null
   
   --- /dev/null
   +++ b/core/modules/datetime_range/tests/src/Functional/DateRangeYearRangeTest.php
   
   +++ b/core/modules/datetime_range/tests/src/Functional/DateRangeYearRangeTest.php
   +++ b/core/modules/datetime_range/tests/src/Functional/DateRangeYearRangeTest.php
   @@ -0,0 +1,121 @@
   
   @@ -0,0 +1,121 @@
   +<?php
   +
   +namespace Drupal\Tests\datetime_range\Functional;
   +
   

   Need to add coverage for the datetime widgets and mirror the test in datetime module for these settings.

1. Done
2. After the change in 1. this is now needed.
3. Done
4. Moved into core elements.
5. Done
6. Added equivalent test coverage for datetime widgets.

Also fixed test failure and coding standards error.

Corrected error in new test.
Removed unused use statement.

1. +++ b/core/lib/Drupal/Core/Render/Element/YearRange.php
   @@ -0,0 +1,103 @@
   +class YearRange extends FormElement {
   

   Should we add a kernel or unit test specific to this new render element? I was trying to find a specific one for the existing data render element, but could not find one, however many render elements have dedicated unit tests. These public methods seem pretty easy to unit test.

2. +++ b/core/modules/datetime_range/tests/src/Functional/DateRangeYearRangeTest.php
   @@ -0,0 +1,121 @@
   +    // Test the new 1978:2017 range.
   

   Let's add at least one test that deals with relative dates to ensure those are working (eg, -3:+3).

Agree with needing a little more test coverage.

#2 should test 1978:2017, -3:2017, 1978:+3, -3:+3, ie all of the possibilities.

Not working if you don't give the field default value.

1. Added unit test for this render element.
2. Added more tests to the functional test.
3. Added condition to handle case when default value is not provided.

Hello is it possible to make this work if we use 'now' date for example?
Also try to enter start day +1 and the end date +10 for example, this is not working.

@Anas_maw Rather than 'now' you can use '+0' (or perhaps open a follow-up issue).

What is not working with '+1:+10'?

1. Correct form validation that is preventing the starting year being a positive relative value (e.g. +1).
2. Update the error messages to agree with the form element descriptions.
3. Correct indentation.

Tested in 8.6.x. Works.

We need to add a check so that the start year <= the end year, and test coverage for that.

+++ b/core/modules/datetime/config/schema/datetime.schema.yml
@@ -65,7 +65,7 @@ field.formatter.settings.datetime_time_ago:
 field.widget.settings.datetime_datelist:

@@ -81,3 +81,7 @@ field.widget.settings.datetime_datelist:
 field.widget.settings.datetime_default:

+++ b/core/modules/datetime_range/config/schema/datetime_range.schema.yml
@@ -55,7 +55,7 @@ field.formatter.settings.daterange_custom:
 field.widget.settings.daterange_datelist:

@@ -71,3 +71,7 @@ field.widget.settings.daterange_datelist:
 field.widget.settings.daterange_default:

Now that datetime and datetime_range are not experimental anymore we need an upgrade path and upgrade path test as well.

Since these are just widget settings with default values, don’t we just need an empty post update to trigger a rebuild?

+++ b/core/modules/datetime/config/schema/datetime.schema.yml
@@ -81,3 +81,7 @@ field.widget.settings.datetime_datelist:
+    year_range:

+++ b/core/modules/datetime_range/config/schema/datetime_range.schema.yml
@@ -71,3 +71,7 @@ field.widget.settings.daterange_datelist:
+    year_range:

As we are adding a new key to the datelist and default formatters we need to update the config for the existing field formatters with the new key and default values.

Hi Team,

I love this post. I have same issue, I just used the form_alter to restrict the date range. So my date range is 1990 to current year. It works fine but I need the descending date sort order, means 2018, 2017, ...1990. Is this possible via form alter? It would be great if we implement the sort order in UI if it is not in date form api.

Thank you.

Would love this feature as well. It's not very useful for example to have a date of birth field where you can choose 2050 as the year.

Just 8.8/8.9 re-roll with no additional changes.

The patch in #47 has an issue with the namespace for t()

MachineNameTest.php also defines Drupal\Core\Render\Element\t, not t() so function_exists will return false (see https://www.php.net/manual/en/function.function-exists.php#117916) but will trigger this error:

PHP Fatal error:  Cannot redeclare Drupal\Core\Render\Element\t() (previously declared in /web/core/tests/Drupal/Tests/Core/Render/Element/MachineNameTest.php:119) in /web/core/tests/Drupal/Tests/Core/Render/Element/YearRangeTest.php on line 70

Updating Functional tests & addressing #49

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Rerolled, applies cleanly against 9.5.x and 10.1.x.

Am working on the fixes.

This will hopefully fix the problems; I accidentally lost the t() function change in YearRange.php.

I don't understand why the t() change is required in the first place? But it's causing the test to fail.

Rerolled the patch in #61 against 10.3.x

Converted the patch from #65 to an MR. Lets see how the pipeline looks

Passing pipeline, now with update path & tests

Can the IS be updated to use the standard template please.

Thanks

This is not only to broad for certain cases, it's also to limited for others, e.g. if using Drupal for historical data.

See my comment in #2942828: Remove hard-coded #date_year_range making it impossible to enter dates < 1900, > 2050. Instead make them optional and configurable in the UI. I'm unsure if we should better proceed here and postpone the other issue or start from scratch over there. The issue summary here was focused on "datelist" (List!) where such a limit at least makes some sense, but currently the limit also applies to HTML5 datepicker, which is a bug. That's what the other issue is about.

However, we should get this finished.