There should be a way for a field to set a default value in its own way, i.e. not as a pre-determined, hard-coded value. For instance, Date has to set a default value at the time the entity is created, because it's usually a relative value. In D6 we had a way for a module to create a 'default_value' function that would get called. That got lost in D7 and there is currently no way that I have been able to find for a field to set a default value normally. I found a work-around in D7 that used hook_widget_properties_alter(). That also worked in D8 until the latest round of changes that removed that hook, and I'm back to having no way to set a default value.
There may be some way to do this that I'm missing, but so far I'm coming up empty and help would be appreciated. I suspect it is a bug, but maybe it's a support question.
Comments
Comment #1
arlinsandbulte CreditAttribution: arlinsandbulte commentedSlightly better title, I think.
I don't think this is or should be unique to date fields, but I cannot think of another use case either.
In short, a date field needs to be able to dynamically set its default value to now() or some value relative to now().
IMO, this might even qualify as major, but I will let some one else make that call.
Comment #2
KarenS CreditAttribution: KarenS commentedHere is the problem, both in D7 and D8:
The field code is set up to look for $instance['default_value_function'], and if that exists, use that function to create the default value.
If you create a field using CRUD and manually add that value to the $instance, it works.
However, there is no way for a module like Date to get that value into the instance. We have hook_field_info() and hook_widget_info(). Neither of them set values on the $instance. You can put a value into $field['settings'], $field, $widget, or $widget['settings'], but there is no way to put a value into $instance using the info hooks.
That leaves hook_field_widget_properties_alter() as the only recourse. And it turns out that that fires after the default value has been evaluated.
Hence there is no way for a module to define a default value function for its widget.
I actually wasn't using the hook to set a default function, I was using it to check the entity to see if it was new and set a flag for my post-processing. I was wrong about the hook being removed. It's still there. But it used to have the $entity passed in and that is no longer true, which broke my hacky work-around.
The real fix that is needed is to make it possible to add the default value function to the $instance. Now that we have the new OO handling, maybe I can find some way to get it in there. But really the code should not make this so hard to do :(
Comment #3
HnLn CreditAttribution: HnLn commentedI had a need for this as well. My use case was an entity reference field where the default value needed to be populated by a nodequeue. I ended up using _field_attach_form and jump through multiple hoops to reset the field_state (with field_form_get_state) and got something working.
In general I can imagine a lot of use cases where you want the default value to be depending on a certain context.
Comment #6
ziodave CreditAttribution: ziodave as a volunteer commentedI resorted to creating widgets (extending the base widgets), whose only concern is to set the default value dynamically according to contextual values, e.g. I have a widget that presets a default value to an entity name referenced by the logged in user, something like this:
Comment #10
noktorn CreditAttribution: noktorn commentedIn D7, this can work as follows:
hook_form_alter
But this does not work in D8:
hook_form_alter
And this, too, does not lead to any result:
Comment #12
akalata CreditAttribution: akalata at Tag1 Consulting commentedThis issue may no longer be valid, as there are ways to set default value callbacks on field instances:
BaseFieldDefinition->setDefaultValueCallback()
field.field.my_entity.my_bundle.my_field
to includedefault_value_callback: 'my_default_field_callback'
Comment #13
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented#12 is spot on! Also, field types now have a way to provide default values globally in their item list's
applyDefaultValue()
method.