Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
EntityReferenceFieldItemList has some code in defaultValuesFormSubmit() that converts the default value set by the user in the UI from an ID to an UUID. #2341357: Views entity area config is not deployable and missing dependencies will introduce some generic logic for "getting an ID/UUID/whatever for storing a reference to an entity in config" so we have to wait for that issue to be fixed before writing a patch here.
Proposed resolution
In order to fix it we need to move that code to a preSave() method.
Remaining tasks
Patience.
User interface changes
Nope.
API changes
Nope.
Comments
Comment #1
amateescu CreditAttribution: amateescu commentedAdding some tags.
Comment #2
yched CreditAttribution: yched commentedNot sure I get this - defaultValuesFormSubmit() ensures what is written in yaml for the 'default_value' when submitting the "Field edit" form is a uuid.
Then, default config shipped in a module's config/install/*.yml should be composed based on real-life yaml files, so they're supposed to contain uuids for default values too ?
Comment #3
amateescu CreditAttribution: amateescu commented@yched, yes, but if you use the entity api to create the field config, you won't run through the form submit handler? :)
Comment #4
amateescu CreditAttribution: amateescu commentedAfter further discussion with @alexpott, it's ok for the code to stay in the form submit handler but we just need to use the new API that will be introduced in #2341357: Views entity area config is not deployable and missing dependencies.
Comment #5
amateescu CreditAttribution: amateescu commented@yched, that's partly true. The problem with targeting uuids in config files is that it only work in the "config sync" scenario, which is always done as a full package of your config files, so we know that the UUID of a config entity will match the one used as a default value.
But, in the default config shipped by a module or install profile, we are supposed to strip the UUID of the config entity, so even though that config entity will be created before the field config storage thanks to the dependency system, it will have a new UUID, not the one that was set as the default value.
We can discuss this more tomorrow if it's still not clear :)
Comment #6
xjmComment #18
LendudeThis came up during a Bug Smash Initiative triage session.
This is still valid, the custom code could probably just use
getConfigTarget, but feels like a task and not a bug since we are just moving to using existing API under the hood.