Summary of Drupal 11.3.6/11.3.7 potential data loss and update steps for 11.3.8

If you are confused about the following release notes snippet for Drupal 11.3.8, which is now a security release, then you are not alone.

Drupal 11.3.6 introduced a critical regression for importing configuration that could result in data loss under certain circumstances: #3584812: ConfigInstaller isSyncing does not persist to hook_modules_installed() when multiple modules are installed. This release hotfixes that regression.

Sites that attempted to import configuration on Drupal 11.3.6 or 11.3.7 should re-import their configuration using the site's recommended method (for example, drush deploy). Make note of any differences in configuration, and ensure that data associated with that configuration has not been deleted.

Thank you to @catch56 for the detail explanation in Drupal Slack after I asked, which I quote below:

catch : This only goes wrong if you installed more than one module at once in a config sync.

catch : The problem is that it's possible to do that by accident - e.g. if you deploy to staging installing one module, then deploy to staging installing a second module, then deploy the code to production, then only production will have two modules installed at once, so you didn't get a chance to QA it.

catch : This is why so far we didn't give details on exactly what the data loss is in the release notes because we'd rather people update core than try to figure it out and lose some data while they're making a decision.

catch : If you export active configuration, and you get a field removed compared to the code base, that would tell you something went wrong.

catch : If export is the same as the code base that's deployed on production, no problem.

I came up with the following work flow:

1. Analyse your current web site:
   1. If there is data missing (such as a field), then restore from a backup.
   2. Inspect the configuration status (either via the UI or CLI)
      1. If there is configuration removal i.e. your active configuration would remove from your staged configuration such as a field , then your site is affected. You should not export your configuration to overwrite your staged configuration.
         1. NOTE : If you do not manage configuration or if your configuration is wildly out-of-date, then this will be a false negative! If this is the case, you really want to make sure your staged configuration matches the expectations of your site first.
      2. Otherwise you can simply update to 11.3.8.
2. Update to 11.3.8 running database updates and cache rebuild processes as normal.
3. Run configuration import if 1.2.1 applies unless 1.2.1.1 applies.

For instance, on my blog here, I had no deployments that did things such as adding a field while I was on 11.3.7, so I only had to run composer require drupal/core-recommended:11.3.8 core/composer-scaffold:11.3.8 -W , commit my composer.* files, push, and run my CI deployment, which runs drush updb and drush cr (and optionally drush config:import).