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

amateescu’s picture

Adding some tags.

yched’s picture

Not 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 ?

amateescu’s picture

@yched, yes, but if you use the entity api to create the field config, you won't run through the form submit handler? :)

amateescu’s picture

Title: ER's ID to UUID default value conversion doesn't work for default configuration » Update ER's ID to UUID default value conversion code to use the new "getTarget()" API
Issue summary: View changes

After 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.

amateescu’s picture

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 ?

@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 :)

xjm’s picture

Status: Postponed » Active

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.