This caused #731724-334: Convert comment settings into a field to make them work with CMI and non-node entities code all over comment field
Problem
For field instance that created from Field UI module (means with browser) the default_value is not assigned.
There only hook_ENTITY_TYPE_create()
hook that allows to inject defaults into saving field instance.
Also when field is added to existing entity no default value is populated so field item needs to override __get()
to detect this.
For example comment field implements:
comment_field_instance_config_create()
and \Drupal\comment\Plugin\Field\FieldType\CommentItem::__get()
Proposed solution
Use the Field Defaults project. See #46.
Find sane way to assign default value to field item.
Possible approaches:
1) implement DataDefinition->setDefaultValue()
2) use TypedDataInterface::applyDefaultValue()
Comment | File | Size | Author |
---|---|---|---|
#34 | 1919834-34.patch | 3.9 KB | jofitz |
#21 | 1919834-comment-defauls-21.patch | 2.63 KB | andypost |
Comments
Comment #1
yched CreditAttribution: yched commentedSorry but I don't understand what's expected here
Comment #2
andypostI mean that code needs always check for existence a value in widget and everywhere
but better to populate "default_value" for field instance upon when it got saved first time but I found no way to make it
No ability to alter :(
Comment #3
swentel CreditAttribution: swentel commentedSo there's http://api.drupal.org/api/drupal/core%21modules%21field%21field.api.php/... but that's not ideal, maybe we should have a drupal_alter here ?
Comment #4
andypostquickly discussed with @swentel in IRC
Probably we get this hook with field CMI convertion #1735118: Convert Field API to CMI
Comment #5
yched CreditAttribution: yched commentedHmm, it seems what you'd want is the field type to be able to specify a "default default value" for new fields of this type ?
Comment #6
andypostto specify a default value for field instance
Comment #7
yched CreditAttribution: yched commented@andypost : you're being too cryptic.
This is filed as a bug report. Please explain, with sentences, what the bug is.
Comment #8
andypostnp, I think that code #2 explains that we have no hook_field_instance_presave of drupal_alter() for instance when fiel_ui creates instance
Comment #9
andypostFor example I'm adding a Comments field so the next step I need to configure it's default value (Open,Closed)
But field ui creates a field and instance for me without default value (Open) so widget, formatter needs always check for
isset($values[0])
to not throw notices.Ability to provide default value on field/instance level will help DX to simplify formatters and widgets. Also we get standard way to store defaults for field instance.
Currently core "datetime" implements own constructor and instance settings value to provide a default value via annotations so:
What is a better way to initialize default value for field instance now?
Will CMI conversion help to set "default_value" or "default_value_function" for Instance? (probably presave hook for Instance entity is enough to control this)
Comment #10
andypostDiscussed in IRC. After #1735118: Convert Field API to CMI we could use any of
_presave()
hooks on Instance entity_presave()Comment #11
andypostThis still valid. Tryed after #1777956: Provide a way to define default values for entity fields
No success
Comment #12
swentel CreditAttribution: swentel commentedSo this will work after #2031203: Configurable fields should use applyDefaultValue() gets in.
Comment #12.0
swentel CreditAttribution: swentel commentedUpdated issue summary.
Comment #13
andypostThe bug still there and comment module implements
comment_field_instance_config_create()
hook to init default values.EDIT another hack lives in
\Drupal\comment\Plugin\Field\FieldType\CommentItem::__get()
Comment #14
andypostUpdated summary, at least issue should fix comment field.
Comment #15
andypostSeems field needs item list class for that now
Comment #17
andypostLooks like migrate applies default values diferently
Comment #18
yched CreditAttribution: yched commentedMinor, but looks a bit weird. If it's empty, we might as well assign its value ($default_value = ...), rather than append to it ($default_value[] = ...)
Do we really need to specify all of this ? Wouldn't it be enough to only specify 'status' ?
I mean, when a default value *is* set, it only contains a default value for 'status', and that's what the method returns, right ?
So it seems when no default value is set, we could simply do $default_value = CommentItemIbterface::OPEN ?
Other than that, approach looks correct.
Comment #19
andypost@yched maybe it makes sense to update
FieldOverview::submit()
to set default values for fields(instances) rather then provide a hacks?PS comment should be fixed anyway according #2318605: uuid, created, changed, language default value implementations need to be updated
Comment #20
andypost@yched now default values has consistent API please suggest a solution here.
Also in related #2401497-23: Field UI creates fields that can never be translated issue we find that forms hardcodes default values
Comment #21
andypostThere's first bird of changes to simplify that #2446511: Add a "preconfigured field options" concept in Field UI
Patch just checks how many tests would fail
Comment #23
andypostThat still does not work
Comment #24
andypostComment #25
andypostComment #27
andypostComment #28
andypostproper component
Comment #31
jibranThis is actually postponed on #2346019: Handle initial values when creating a new field storage definition.
Comment #33
andypostThis is no longer postponed, I think this change could be accepted in minor version as bugfix
Comment #34
jofitz CreditAttribution: jofitz at ComputerMinds commentedRe-rolled.
Comment #39
andypostIt still needs work and
comment_field_config_create()
also would be great to have in field classComment #41
dqdIf I understand the issue and the goal correctly (partly too cryptic), I am still not convinced of that a newly created field in a existing bundle with already existing content should write the "default value" (like setup in the field creation process) to all already existing rows without asking yet. Unless this is planned to be optional (checkbox etc.) I think this can become a dangerous approach?
Apart from that, there is a contrib module for that: https://www.drupal.org/project/field_defaults
Comment #46
quietone CreditAttribution: quietone as a volunteer commentedDiscussed in #bugsmash with andypost, catch, berdir and Lendude and it was agreed that this is working as designed.
Anyone wanting this functionality should use the Field Defaults project. If you think what that module does should be in core, open a new Feature Request to discuss why it is needed, the pros and cons etc. Also, add this issue as a related issue.
Thanks!