I am introducing new configuration to an entity in Drupal that adds a few new boolean fields. The problem is, even though I set the default value as TRUE in the UI, this is only for new entities. Existing entities will have no value, or false, when evaluated in code.

I would like to script a change in that will default all existing entities to TRUE when the configuration is introduced for backwards compatibility, and only run it that one time.

Typical deployment scripts advise running updb first before cim with Drush. This creates a conflict when trying to attempt this.

Pantheon deployment script example:

  $status = 0;
  $config_directory = dirname(__FILE__) . '/config/default';

  passthru("drush updb --yes", $status);
  passthru("drush cim --yes", $status);
  passthru("drush cim --yes", $status);
  passthru("drush cim --yes", $status);
  passthru("drush updb --yes", $status);
  passthru("drush cr", $status);

  if ($status == 0) {
    echo('Configuration imported and database updated.' . "\n");
  } else {
    echo('Configuration not imported / database not updated. Drush command returned an error.' . "\n");

Is there a better way to do changes like this that only run once without causing script like the one above to fail?

  • 1
    The only option I've come across in these cases is to add the fields programatically in the update hook, before you set the data. The config import for those fields will then essentially become a no-op, but it means you don't need to change your deployment
    – Clive
    Commented Dec 6, 2021 at 16:28
  • Incidentally, Pantheon seem to run updb and cim an...interesting number of times. Typically you would only do both once like drush does
    – Clive
    Commented Dec 6, 2021 at 16:31
  • That is patterned off what folks advised for deployments in the past - CIM is exhausted, updb is run first before cim, then at the end ' in case' other updates are required. I never found any additional update around that process either, but its been pretty bulletproof on Pantheon and Acquia to date.
    – Kevin
    Commented Dec 6, 2021 at 16:33
  • Not sure that really makes sense - either all the updates run first time, or the build should fail. The only way to introduce new updates following updb is a code change, at which point it's a new deployment and you're back on the first updb again. But that's not really what you're asking about so I'll shush now
    – Clive
    Commented Dec 6, 2021 at 16:36
  • Is it a case for this, maybe? api.drupal.org/api/drupal/…
    – Kevin
    Commented Dec 6, 2021 at 16:46

1 Answer 1


You can use drush deploy, which performs updates in this order:

  1. Update hooks from module.install
  2. cim
  3. cr
  4. Deploy hooks from module.deploy.php

So converting your update hook to a deploy hook means it will run after the config import.

  • This has the same problem as the OP’s original deploy code - the new config won’t be imported before the update hook tries to use it
    – Clive
    Commented Dec 6, 2021 at 17:27
  • Moving the update hook to a deploy hook means it runs after import
    – Lambic
    Commented Dec 6, 2021 at 20:21
  • 1
    Ah yes, I didn't get that first time round. May be worth mentioning the need to add (e.g.) passthru('drush deploy:hook', $status); if OP wants to run their own script instead of drush deploy directly
    – Clive
    Commented Dec 6, 2021 at 20:28

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.