Problem/Motivation

Uncovered while working on #3165990: UX bug with the duration widget for date-only ranges. That issue is trying to fix a FieldWidget for datetime_range fields to deal with weirdness when the widget is used on a date-only daterange field. The date-only aspect is a property of the field storage definition. Ideally, the widget would advertise / use different default settings depending on if the field it's attached to is datetime or date-only.

Sadly, PluginSettingsBase::defaultSettings() is public static (without a class instance), and gets no context passed in. So it's currently impossible to do this in a clean way.

Steps to reproduce

Try to have different values for defaultSettings() based on the field definition or field storage definition the widget or formatter is attached to.

Proposed resolution

The B/C implications of changing defaultSettings() itself would be monstrous. Every implementation calls parent::defaultSettings(), this is implemented dozens of times in core and perhaps 1000s of times in contrib.

Instead, let's add a parallel version that gets passed the fieldDefinition.

Sadly, PluginSettingsBase doesn't have the fieldDefinition. That currently lives directly in FormatterBase and WidgetBase. But those two seem to be the only things extending PluginSettingsBase, so I think we can just move those two protected members up in the class hierarchy. ;)

Remaining tasks

  1. Upload the initial patch.
  2. Discuss naming, structure, etc.
  3. Add some tests to prove this works as intended.
  4. Reviews / refinements.
  5. RTBC.
  6. Commit.
  7. Fix contrib modules like datetime_extras that wish this exists.

User interface changes

Nothing directly. Field plugins might present different default settings based on field definitions.

API changes

TBD.

Data model changes

N/A

Release notes snippet

TBD.

CommentFileSizeAuthor
#2 3166481-2.patch3.73 KBdww

Comments

dww created an issue. See original summary.

dww’s picture

Status: Active » Needs review
StatusFileSize
new3.73 KB

Definitely NW, but to get us started, here's a totally untested version. Curious if the bot blows up at all with this. Would love feedback on the approach before spending much more time on this.

Thanks!
-Derek

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs review » Needs work

First thanks for the super details issue summary helped out a lot!

Just queued #2 for 10.1.x tests also.

Moving to NW for the additional discussion and path forward.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.