Contrib.social

Installing site from existing config fails when message_digest_ui module is part of the install

Open on Drupal.org →
Created on 18 July 2023, 11 months ago
Updated 7 March 2024, 4 months ago

Problem/Motivation

When installing a site from existing configuration (we do this for platform applications), and message_digest_ui is installed as part of that, the installation fails with the following error (both installing through Drush and through the browser UI):

 You are about to:
 * DROP all tables in your 'db' database.

 // Do you want to continue?: yes.                                                                                      

 [notice] Starting Drupal installation. This takes a while.
 [notice] Performed install task: install_select_language
 [notice] Performed install task: install_select_profile
 [notice] Performed install task: install_load_profile
 [notice] Performed install task: install_verify_requirements
 [notice] Performed install task: install_verify_database_ready
 [notice] Performed install task: install_base_system
 [notice] Performed install task: install_bootstrap_full

In EntityType.php line 885:
                                                                  
  Missing bundle entity, entity type flag, entity id email_node.

Steps to reproduce

  1. Setup a Drupal Composer project.
  2. Add a config sync directory and set the absolute path to this as the value for $settings['config_sync_directory'] in settings.php.
  3. composer require drupal/message_digest
  4. drush si minimal -y --no-interaction
  5. drush en taxonomy
  6. drush en message_digest_ui -y --no-interaction
  7. drush cex -y
  8. drush si --existing-config -y --no-interaction
  9. Confirm the error above.

The error stems from the message_digest_ui_install(), lines 27-41:

  // Add the `message_digest` field to flagging types.
  $prefix = \Drupal::config('message_subscribe_email.settings')->get('flag_prefix');
  foreach (['node', 'term', 'user'] as $name) {
    $display = \Drupal::service('entity_display.repository')->getFormDisplay('flagging', $prefix . '_' . $name, 'default');
    if (!$display->getComponent('message_digest')) {
      $settings = [
        'type' => 'options_select',
        'weight' => 0,
        'region' => 'content',
        'settings' => [],
        'third_party_settings' => [],
      ];
      $display->setComponent('message_digest', $settings);
      $display->save();
    }
  }

Assuming that $prefix = 'email';, the issue here is the flagging bundles email_node, email_taxonomy, and email_user do not exist yet during a fresh install from configuration, and so it blows up when you try to save a new form display configuration for a bundle that does not exist.

Proposed resolution

1. The install hook should check if the process is syncing, and if so then bail and assume the sync process will handle properly synchronizing configuration.
2. Add configuration dependencies to the derived action plugins for: the entity type email flag, and the digest interval.
3. Add an update hook which re-saves all actions that might have been installed in hook_install so dependencies are re-calculated and added to each action configuration entity.

🐛 Bug report
Status

Needs review

Version

1.0

Component

Code

Created by

🇺🇸United States lpeabody

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @lpeabody
  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 8
    last update 11 months ago
    Not currently mergeable.
  • @lpeabody opened merge request.
  • Open in Jenkins → Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 8
    last update 11 months ago
    37 pass
  • First commit to issue fork.
  • Open in Jenkins → Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 8
    last update 11 months ago
    37 pass
  • @capysara opened merge request.
  • Status changed to Needs review 11 months ago
  • Comment 11 months ago →
    🇺🇸United States capysara

    I hit the same issue today, and I'm also not sure what would be the best way forward. I moved the problematic field addition into a hook_update instead of the hook_install. It worked on my set up, but I haven't tested it on a clean install yet.

    I didn't test out the MR 11 because the description said it produce more errors.

  • Comment 11 months ago →
    🇺🇸United States lpeabody

    The additional errors are coming from when the configuration sync process kicks in (after modules are installed) system action configuration is being synchronized but the plugin the action references does not have a definition as yet. So, really the only solution to this is making sure the definition exists before the sync process attempts to add the action configuration. I'm not sure at this point what it would take to ensure that.

  • Open in Jenkins → Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 8
    last update 11 months ago
    37 pass
  • Open in Jenkins → Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 8
    last update 11 months ago
    37 pass
  • Open in Jenkins → Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 8
    last update 11 months ago
    37 pass
  • Comment 11 months ago →
    🇺🇸United States lpeabody

    I think MR11 is actually ready for review now. In a nutshell, it:

    1. Checks the install hook to see if a sync operation is happening, and if it is then it does not bother with modifying configuration (since it is expected this will be taken care of when configuration synchronizes, after modules have been installed).
    2. Adds configuration dependencies to the derived action plugins, including dependencies on the related digest interval and email flag.
    3. Adds an update hook which re-saves all previously installed action configuration entities, which will ensure that dependencies are recalculated for each.

    With that in place if someone updates the module and then subsequently exports configuration, the exported action config entities which were previously causing a problem will have their dependencies updated and exported correctly. When installing from config again, the added dependencies will result in the action entities being synchronized in an order that will not generate any errors (because the dependencies have already been synchronized and generated the plugin that the action is dependent on).

  • Comment 11 months ago →
    🇺🇸United States lpeabody
  • Comment 10 months ago →
    🇺🇸United States lpeabody
  • Comment 9 months ago →
    🇺🇸United States lpeabody

    Bump for review from maintainers.

  • First commit to issue fork.
  • Open in Jenkins → Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 8
    last update 8 months ago
    37 pass
  • Open in Jenkins → Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 8
    last update 8 months ago
    37 pass
  • Open in Jenkins → Open on Drupal.org →
    Core: 10.2.x + Environment: PHP 8.1 & MySQL 8
    last update 4 months ago
    37 pass
  • Comment 4 months ago →
    🇪🇸Spain Aaron Gil Martinez Zaragoza

    Adding static patch for composer.
    Created from: MR 12

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024