Change record status: 
Project: 
Introduced in branch: 
8.9.x
Introduced in version: 
8.9.0-alpha1
Description: 

Prior to 8.9.0, module authors needed to check the config installer to see if config was being synced when their hook_install, hook_uninstall, hook_modules_installed and hook_modules_uninstalled was being called.

To make it easier to check the config installer syncing status, an $is_syncing parameter is now passed to these hooks.

The value of $is_syncing will be TRUE when a module is being installed/uninstalled as part of a configuration import. In these cases, your hook implementation needs to carefully consider what changes, if any, it should make. For example, it should not make any changes to configuration objects or entities.

e.g. from demo_umami_content module

Before

/**
 * Implements hook_install().
 */
function demo_umami_content_install() {
  if (!\Drupal::service('config.installer')->isSyncing()) {
    \Drupal::classResolver(InstallHelper::class)->importContent();
  }
}

After

/**
 * Implements hook_install().
 */
function demo_umami_content_install($is_syncing) {
  if (!$is_syncing) {
    \Drupal::classResolver(InstallHelper::class)->importContent();
  }
}
Impacts: 
Module developers
Site templates, recipes and distribution developers

Comments

pingwin4eg’s picture

For example, it should not make any changes to configuration objects or entities.

Are there alternative ways to change configs and entities? For example, if there's a need to add fields to an entity type and fill them with values during a module install.

In a website development it's a usual thing that new custom modules are installed in all envs except local through the configuration import.

apotek’s picture

I am also confused by this. If hook_install/uninstall are documented as being the way by which we can install custom entities or custom fields on entities (and remove them), but we are being told *not* to make such changes in these hooks during a config:import (which is the way most sites these days install and uninstall modules, not via explicity drush commands or the web gui), then it seems we are unable to have our custom fields or entities installed as part of a site deployment.

Or are hook_uninstall() and hook_install() run twice? Once during config:import and once during some other part of the deployment process?

Very confused here as this requirement to not make changes to entities in hook_install seems to run counter to the whole point of the hook.

mah ham