Allow config import with empty system.site UUID

Drupal 8.7.9 → was released on November 6 and is the final full bugfix release for the Drupal 8.7.x series. Drupal 8.7.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.8.0 on December 4, 2019. ( Drupal 8.8.0-beta1 → is available for testing.)

Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule → and the Allowed changes during the Drupal 8 and 9 release cycles → .

Works for me

works as intended, and IMHO helps in development process, too.

So I think there might be some mileage in allowing this but we need test coverage and also we need to ensure that the site UUID is not updated to be empty. Which is what I think the patch would result in.

Also this is not a bug fix. The system is working as designed.

Also now that you can install a site from configuration via the installer I'm not entirely convinced that this is actually that useful.

People are doing this because of the issue regarding default entities existing on a BLT build, causing BLT to fail out because it can't over-write them. There needs to be some logic that allows configuration to totally over-ride any existing default entities without throwing a failure to Pipelines. Until then, this patch is necessary.

This is what we get when we try to import an existing configuration into a blank BLT setup.

[error]  Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Site UUID in source storage does not match the target storage.
Entities exist of type <em class="placeholder">Shortcut link</em> and <em class="placeholder">Shortcut set</em> <em class="placeholder">Default</em>. These entities need to be deleted before importing. in Drupal\Core\Config\ConfigImporter->validate() (line 755 of /var/www/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php). 

In ConfigImportCommands.php line 261:
                                                                                                                                                                                                             
  The import failed due to the following reasons:                                                                                                                                                            
  Site UUID in source storage does not match the target storage.                                                                                                                                             
  Entities exist of type <em class="placeholder">Shortcut link</em> and <em class="placeholder">Shortcut set</em> <em class="placeholder">Default</em>. These entities need to be deleted before importing.  
                                                                                                                                                                                                             

config:import [--preview [PREVIEW]] [--source SOURCE] [--partial] [--diff] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-d|--debug] [-y|--yes] [--no] [--remote-host REMOTE-HOST] [--remote-user REMOTE-USER] [-r|--root ROOT] [-l|--uri URI] [--simulate] [--pipe] [-D|--define DEFINE] [--notify [NOTIFY]] [--druplicon] [--xh-link XH-LINK] [--] <command> [<label>]

[Acquia\Blt\Robo\Tasks\DrushTask]  Exit code 1  Time 03:09
[error]  Failed to import configuration! 
[error]  Command `drupal:config:import ` exited with code 1. 
[error]  Command `drupal:install ` exited with code 1. 

The only solution I'm aware of is to remove the UUID from both the system.site.yml and the shortcut.set.default.yml prior to import. If you know of any other way to do this, I'm all ears.

I'll try to have a go with this for 8.8.4

  /**
   * {@inheritdoc}
   */
  public function validateSiteUuid() {
    $source = $this->sourceStorage->read('system.site');
    $target = $this->targetStorage->read('system.site');
    // It is possible that the storage does not contain system.site
    // configuration. In such cases the site UUID cannot be valid.
    return empty($source['uuid']) || ($source && $target && $source['uuid'] === $target['uuid']);  
  }

Patch for 9.0.x

Patch for 8.9.x

Drupal 8.8.7 → was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 → or Drupal 9.0.0 → for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule → and the Allowed changes during the Drupal 8 and 9 release cycles → .

Works great, I can import config on new site without a problem.

The patch works great for the BLT config-import scenario described above: installing from configuration without all the limitations, caveats and inconsistencies of a profile's config install scenario (read: no core.extension support). In our case, we wrote a BLT Task Hook to run on new sites install only, thus, when deploying updates we avoid existing sites configuration from being overwritten by the drush cex/cim cycle.

3047392-17 - Patch is skipping -

Drupal 8 is end-of-life as of November 17, 2021 → . There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Patch still applies on Drupal 9.1.9. and removes the error message.

Drupal 9.4.9 → was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Drupal 9.3.15 → was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Patch still applies on Drupal 9.3.7. and removes the error message.

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.

This was previously tagged for tests in #11 that will still need to happen.

Did not test

Patch applies cleanly to 9.5.9 and resolved this particular issue for me.

let's try with latest and create a MR.

new MR created against latest Drupal 11.x

+ Added a test for empty Site UUID.

Verified the tests fail as expected with error Undefined array key "uuid"

Can the issue summary be updated a little, seems bare. Least have a proposed resolution section.

Summary updated ... so Back to "Needs review".

Thanks issue summary looks good to me!

I am doing triage on the core RTBC queue → .

Issue summary is complete and easy to follow. I skimmed through the comments and the overview on the MR and I don't see any comments referring to a code review. :-(

This is changing the behavior of \Drupal\Core\Config\StorageComparerInterface::validateSiteUuid() as described in the doc block. The BC implications of that should be considered before proceeding.

I have commented in the MR. Setting back to NW.

some updates for MR threads. Back to review

Appears all threads have been addressed.

I'm triaging RTBC issues → . I read from my last comment and read the MR again. The only thing I can find is that I think the title can be improved. Doing that now.

Leaving at RTBC.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

alexismmd → changed the visibility of the branch 3047392-site-uuid-in-from-10 to hidden.

alexismmd → changed the visibility of the branch 3047392-site-uuid-in-from-10 to active.

alexismmd → closed merge request !5688

alexismmd → changed the visibility of the branch 3047392-site-uuid-in-from-10 to active.

alexismmd → changed the visibility of the branch 3047392-site-uuid-in-from-10 to hidden.

@akexismmd what is wrong with older MR against 11.x? I'm guessing you've made the MR for a patch against 10.1.x? But that's a guess as you've not documented what you are doing on the issue.

I;ve updated the old MR https://git.drupalcode.org/project/drupal/-/merge_requests/4133

I think the new MR 5690 should be hidden because it is against the wrong branch and does not contain tests.

FWIW the plain diff of MR 4133 can be applied to 10.1.x and up.

@alexpott, the update of MR 4133 was need it. I see you already have done, then yes I going to hidden MR 5690, sorry about that. Thanks!

alexismmd → changed the visibility of the branch 3047392-site-uuid-in-from-10 to hidden.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

MR rebased. status updated.

Hi @vasike

I don't know why but now MR doesn't apply in 10.1.7

@alexismmd you could try the hidden MR for 10.1.x
https://git.drupalcode.org/project/drupal/-/merge_requests/5690

As i said in my previous comment the "current" MR https://git.drupalcode.org/project/drupal/-/merge_requests/4133 was rebased ... as it had conflicts with the latest changes on 11.x.

alexismmd → changed the visibility of the branch 3047392-site-uuid-in-from-10 to active.

Actually appears this was previously RTBC before sent back to turn to MR.

I still have the same reservations as I raised in #11. Given you can install a site from configuration what is the use-case? So far the old case is to install configuration on a BLT site - but shouldn't BLT by updated to use the ability to install from configuration. Additionally, if you are scripting things as in #20 then you can write the site's uuid to the config you're going to import before you run the import.

So I think the change looks complete but I'm not sure about why we need to make this change.

I agree with @alexpott, I think that this is a bug in BLT, if that does not allow to just use the --existing-config?

Is anyone using this patch in a scenario that is not related to BLT?

I've seen it before in regular drush commands before, but haven't checked that code we use in a while.

Given #59 and #60 I'm going postpone this and say we need more info as to why it is necessary.