Given two environments dev & live, how do you properly transfer field default values for entity reference fields when deploying with Drush (cex & cim)? The default value is a UUID, which is database- / environment-specific and basically leads to an incorrect deplyoment.

E.g. I am importing categories (taxonomy terms) from a remote API, but only the name (term label) is imported. The default category for nodes is not imported, but selected on our own (dev) system. Later when running migrate import on the live system, the same term has a differnet UUID, and the deployed default value is incorrect.

What I am doing right now is awkward:

  • Create a boolean field field_is_default_value_for_other_entity on the taxonomy terms.
  • Manually edit the terms/select the custom default value on both environments.
  • Create a hook_form_alter. Using entity query I select the fake default taxonomy terms and set the default value.

This somehow works, but IMHO this also is absolutely horrible. It is a hidden logic contradicting the settings in field UI, it is duplicating existing functionality, and the code for setting the default value is depending on the field widget too (...and breaks when switching from e.g. checkboxes to auto-complete)

Is there a better way to set environment-save default values for ER fields?

  • So the problem is migration doesn't import UUIDs?
    – 4uk4
    Commented Sep 6, 2022 at 9:53
  • Config sync uses the UUID generated by Drupal, this has nothing to do with the primary key of the terms on the remote API providing the categories (the remote API is a third party outside our scope, not one of our Drupal env's).
    – Hudri
    Commented Sep 6, 2022 at 9:58
  • Still you should try to use UUIDs to your advantage, not fighting against it. If you are not migrating, but importing from the third party source independently you should derive the UUID from the imported data.
    – 4uk4
    Commented Sep 6, 2022 at 11:12

1 Answer 1


Sometimes, Drupal's separation of configuration and content gets really messy-- an entity reference default value is configuration, but it points to content.

I was very frustrated by this too so here is what I did. It is a lot of work to set up, but it is robust.

Basically, use Feeds to make all taxonomy terms content.

  1. Create a feed for each vocabulary.
  2. Set up the field mappings for each feed.
  3. Use CSV Excel files (or whatever else Feeds supports) to store your taxonomy in code.
  4. Use drush to import the feeds content as part of your build.
  5. Add a drush script that uses an entity query to find the entities that are used as default values and set the uuid to a predetermined uuid.

This gives me everything in code-- the taxonomy terms are stored in a CSV file, and the uuids that need to be fixed are stored in a drush script.

As a less extreme step, you could try setting the uuids with an entity query and drush.

Here's the script I use:

function set_uuid(string $entity_type, int $entity_drupal_id, string $uuid): void {
  $entity = \Drupal::entityTypeManager()->getStorage($entity_type)->load($entity_drupal_id);
  if ($entity instanceof TaxonomyTermBundle) {
    $entity->set('uuid', $uuid);
  else {
    throw new MyDrushScriptException("Failed to load entity of type $entity_type with uuid $uuid!");

set_uuid('taxonomy_term', $term_id_apple, 'abcd-efgh-ijkl-mnop');
set_uuid('taxonomy_term', $term_id_orange, '1234-5678-9012-3456');

$term_id_apple and $term_id_orange are pulled from the db via a query.

  • Is it safe to manipulate UUIDs of content entities in a production database? I once tried to manipulate nids in a live system, and that went terribly wrong.
    – Hudri
    Commented Sep 6, 2022 at 10:07
  • @Hudri AFAIK, it's safe to manipulate UUIDs because the chance of them colliding is nearly impossible (reference: the number of random version-4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71 quintillion (Wikipedia UUID) and they are random, so there is no chance of them getting out of order. Node ids, on the other hand, must be sequential according to the database, so if the nid counter gets out of sync with the nids on the site, disaster will result. Commented Sep 6, 2022 at 10:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.