An error appears while importing configuration.

How to reproduce

  1. Install site using standard profile.
  2. Export configuration using a single file.
  3. Import configuration.
Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization. in Drupal\Core\Config\ConfigImporter->validate() (line 730 of /var/www/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php).

The import failed due for the following reasons:
Entities exist of type Shortcut link and Default. These entities need to be deleted before importing.


danylevskyi created an issue. See original summary.

mtift’s picture

I am not able to reproduce this issue.

@danylevskyi, what did you mean by "export configuration using a single file"? Did you import and export a "Full archive"?

roynilanjan’s picture

Same problem as abobe I have got once try to run /usr/local/drush8/drush config-import staging -y

roynilanjan’s picture

Status: Active » Needs review
roynilanjan’s picture

tstoeckler’s picture

Status: Needs review » Postponed (maintainer needs more info)

So it seems that the UUID of the default shortcut set does not match in your exported configuration and in your active configuration.

I was able to reproduce this with the following steps:

  1. drush cex -y
  2. Manually change the UUID in the shortcut.set.default.yml file of the exported configuration
  3. drush cim -y

The question is how you got to the point of having different UUIDs in your configuration? Can someone post detailed steps starting from 0 how to reproduce this issue (without manually editing a config file, like above)?

roynilanjan’s picture

@tstoeckler: YES your steps are fine to work-on but question is why *UUID* needs to change only for *short-cut* & ** component, not for others?

roynilanjan’s picture

Version: 8.0.0-rc1 » 8.0.0
roynilanjan’s picture

Is it possible to import block_content to import? This is found that after full import the block content unable to import in the db, the import block is missing/showing broken in the original region see

roynilanjan’s picture

Status: Postponed (maintainer needs more info) » Needs review
mtift’s picture

Status: Needs review » Active

"Needs review" status is for a patch has been created and needs review and testing: There is no patch here.

jonathanshaw’s picture

I'm hitting this trying to import config into travis.
Some steps to reproduce:
1) Export all config
2) Create a new site with drush site-install
3) Find the site UUID of the original site, and set the site UUID of the new site to be the same with drush config-set "" uuid
4) drush config-import

Problem is discussed here The solution suggested there:
drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'
works for me

ressa’s picture

I was experimenting with the Dcycle workflow combined with drush make.

I can confirm that this is still a problem in Drupal 8.1.3, and that drush command mentioned in #12 breaks my site, unless I un-install and re-install the Shortcut module.

So run these three commands to make config-import possible:

drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();';
drush pmu shortcut -y;
drush en shortcut -y;

EDIT: Still a problem in Drupal 8.3.5 (August 2017), and only one command is actually needed:
drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'

roynilanjan’s picture

Good idea if we can sync the configuration of e.g. short-cut & system-site programmatic way in hook_update

      // Here will be configuration structure & values.

then run the drush cim

ressa’s picture

Version: 8.0.0 » 8.1.3
Priority: Normal » Major

Updating Priority to Major, since this breaks the config-export > config-import workflow.

jonathanshaw’s picture

According to and linked discussions, this can be fixed in many cases by either:
- specifying the minimal install profile (shortcuts come from standard); or
- using

youfei.sun’s picture

I'm getting a similar error at same location:
Drupal\Core\Config\ConfigImporter->validate() (line 730 of
The import failed due for the following reasons:
Unable to install the standard module since
it does not exist.

Looks like it is still some install profile related issue.

-enzo-’s picture

You could fix using Drupal Console, using 1.0.0-RC1 or superior

$ drupal entity:delete shortcut_set default
marcelovani’s picture

I cannot run the drush command because the error happens during drush site-install when I specify the folder to sync

drush si -y standard --config-dir=../config/sync

alex.stanciu’s picture

Assigned: Unassigned » alex.stanciu
alex.stanciu’s picture

Assigned: alex.stanciu » Unassigned

drush si -y standard

The standard installation profile automatically creates two shortcuts in standard.install
A workaround would be to create a custom installation profile where you don't create these two entities on install.

The actual issue comes from the configuration import mechanism which tries to purge and recreate fields if the UUID is different. See for more details.

macherif’s picture

Try to checkout what configuration yml files are displayed as will be deleted then edit every one and remove UUID line in the begin of each file. That works for me !

geerlingguy’s picture

For my own purposes, I just replaced the UUID in the uuid: line of shortcut.set.default.yml with null (so the line reads uuid: null), and then everything worked fine, even with drush site-install --config-dir=../config/default (I'm using a project built with Acquia's BLT, alongside the Configuration Split module).

Sarah10’s picture

#6 worked for me. Thanks!!

ruloweb’s picture

#23 worked for me, thanks!

geerlingguy’s picture

Version: 8.1.3 » 8.3.x-dev
mpotter’s picture

#23 no longer seems to work for me. Using drush 8.1.11 on latest drupal 8.3.x

Also, the downside of #23 is that even though you might successfully use "drush site-install standard --config-dir=config/sync" to install the site, once the site is up and you do a "drush config-export", it will update the shortcut.set.default config because now it has a non-null uuid in the site. If you commit this and push your config/sync to your repo, then another developer trying to pull this and run config-import will have trouble cause their uuid won't match.

Makes me wonder if the uuid stuff is causing more harm than good at this point.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

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

mikeohara’s picture

Yeah, this is a pretty frustrating problem. I've decided to roll my own install profile to ship with our internal starter kit projects that does not include the shortcut module since we invariably never use it in projects.

nerdstein’s picture

This continues to be problematic for me on multiple sites. Is there any momentum toward at least defining a solution?

This pretty much blocks a "standard" site config from being re-installed (critical for building a site locally or working across a team).

jibran’s picture

nerdstein’s picture

First, let me state my opinion that I think the default shortcuts should probably be outside of config altogether. This issue may be just an incremental fix to support previous installs that have already made use of shortcuts being in config. Maybe a separate issue can be created to remove offender(s) from core on new installs (it may exist, even). But, such discretional flexibility in Drupal's framework means this scenario will keep coming up because the Drupal framework does not prohibit items like shortcut.default from being in config (and there could be many other cases outside of the Shortcut example).

UUIDs should be able to be exported into a configuration target from an existing install and subsequently installed in a new site from a defined config directory.

The issue seems to suggest that a completely fresh "standard" install is created first, followed up by a subsequent config import of the defined directory is broken. This approach will fail repeatedly, due to this mismatch of UUIDs after the initial install re-creates configuration with it's own unique UUIDs in conflict to those stored in the existing config directory.

I see two possible problems here: 1. install, 2. after install. Install itself seems to be the primary blocker, as an initial install would at least respect the set of UUIDs imported initially (and, optionally, through the "--config-dir" directive as part of the site install command). After install would only break if, later, the UUIDs become mismatched (which I would hope would only be a result of a manual config change representing a discouraged practice in general).

Should this issue be morphed into fixing an initial site install to respect existing UUIDs? I think thats reasonable.

jibran’s picture

nerdstein’s picture

@jibran, as I understand the problem, this is not a duplicate of #2922417.

I think it is closer to #2914213 but it's hard to tell if they are solving the same problems or just related ones. I think they may be different. Both seem to refer to the issue of UUIDs and "content", e.g. the "shortcut.default" config. If content is installed after a site install using a new hook, does this actually solve the issue of the collision? I would suggest it would create the exact same error with the UUIDs colliding since the existing config will collide with the loading of content regardless of when it happens.

The more relevant issue seems to be that a site install seems to load the requested install profile configuration even if a configuration directory is supplied. Some solutions I see are:

1. turning off the UUID collision validation upon site install.
2. exploring conditional logic that checks if a "config-dir" is passed during site install, it overrides what is provided by the install profile (this makes the install profile selection basically invalid, to be honest).
3. core ships with a "load from configuration" profile that operates just like config_installer does. I sense that option 3 is the cleanest but this should be explored much further. I'm unclear on how "config-dir" would maintain support with profiles other than config_installer.

One related issue is around the "config_installer" based approach. By default, core seems to define the initial installed profile in settings.php. This breaks subsequent site installs with config_installer, because it throws an error for differing install profiles due to this hardcoded setting. My sense is that the installation profile config should not be written to settings.php by default (I am unclear on why this is desirable when it seems to be defined in the system settings config).

BR0kEN’s picture

Version: 8.4.x-dev » 8.5.x-dev

Valid for 8.5.x but drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'; helps.

KarimBou’s picture

We got the same issue when exporting using drush config export and import, between developers or environments, any idea how to fix this because a part from running drush ev, or editing the yaml to change the uuid to null. And we might forget or someone might waste time finding how to do this.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

balsama’s picture

I think the only way to reproduce this issue is to use the --config-dir option with Drush 8 and the Standard profile. Now that Drush 9 is out (which doesn't allow you to use the --config-dir option with Standard) I don't think it can be reproduced.

You can use the config_installer profile to basically achieve the same thing as using --config-dir, and it works around problems like these automatically.

@nerdstein re the problem with config_installer changing the install profile - the best way around this I've found is to remove the install_profile key from settings.php entirely and then revoke write access. Drupal > 8.2.x doesn't need that value in settings and won't complain if it doesn't have write access.

Berdir’s picture

I think this is basically by-design, caused by the fact that installing creates new UUID's. It might fail on shortcut having entities but that's a detail, the real issue is that such an import would delete and re-create every single config entity in the system.

If you want to do installs and then share the config, use something like config_installer. Maybe core in the future will change the installer to instead always install based on default config, which then might have uuid's by default, so that the default config is the same on all sites. But that might also have weird side effects.

Berdir’s picture

In other words, duplicate of #2788777: Allow a profile to be installed from existing config, you're trying to solve the wrong problem IMHO.