Voting starts in March for the Drupal Association Board election.
Field types need to be able to do some extra massaging on the "default values" when they get in and out of CMI storage.
- config for "default values" of entity_ref / taxo / image fields need to reference UUIDs instead of numeric ids - and this is critical for config deployment: see (there is probably a more specific issue for this, but I couldn't find it)
- date module does strange tricks to handle its own default values - and this is currently broken:
It's currently up to widgets to specify if they support "default field values".
When displaying the "field instance edit form", Field UI checks whether the widget used by the field supports default values, and if yes, displays the widget as an input for "default values".
This comes straight from CCK D6 and was introduced to let date fields provide their own handling of "default values" - because a default value for a date field is typicially "current date", "current date + 1 day"..., and those are not values that can be entered using any date widget, which only let you input a specific date ("12/25/2013").
This is conceptually broken:
- "the widget used by the field" makes no sense now that we have form modes
- the support from default values and how to enter them should be specific to the field type, not widget by widget
Now that field types are finally classes, we can implement a sane flow around default values:
- add defaultValuesForm() / defaultValuesFormSubmit() methods in ConfigFieldInterface, just like there currently is settingsForm() and instanceSettingsForm() in ConfigFieldIItemnterface
The methods are added on the field classes rather than the field item classes, because this is where default value handling occurs, as per and .
- ConfigField::defaultValuesForm() reproduces the current behavior (display a widget to allow input of default values).
Field types than want to opt out or do things differently just override the method. Patch does that for file and image fields.
- defaultValuesFormSubmit() lets them process values before they get saved in CMI (e.g numeric id -> UUID)
- getDefaultValue(), added in , lets them massage back default values before using them in actual "create new" entity forms (e.g UUID -> numeric id)
- this is mostly adding methods to ConfigFieldInterface, but base implementations in ConfigField reproduce the current behavior,
- 'default_value' property in widget plugin annotations is "officially" removed, will just have no effect if it's still there.
PASSED: [[SimpleTest]]: [MySQL] 58,226 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] Setup environment: Test cancelled by admin prior to completion. View
PASSED: [[SimpleTest]]: [MySQL] 58,059 pass(es). View