The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
When doing a site clean install for some reason there's several of tens files that can't be imported in that time and I receiving the following messages (this is just few of them):
[warning] The "block_content:3e9e5e58-6407-41b9-92ac-c67246f11478" was not found
[notice] Missing required data for configuration: purge.logger_channels
[notice] Missing required data for configuration: purge.plugins
[notice] Missing required data for configuration: core.entity_form_mode.paragraph.date
[notice] Missing required data for configuration: facets.facet.content_type
[notice] Missing required data for configuration: field.field.user.user.field_picture
[notice] Missing required data for configuration: flag.flag.follow
[notice] Missing required data for configuration: language.entity.bg
[notice] Missing required data for configuration: pathauto.pattern.group_content
[notice] Missing required data for configuration: views.view.watchdog
[notice] Missing required data for configuration: views.view.who_s_new
[notice] Missing required data for configuration: views.view.who_s_online
While debugging I found that it comes from here the message: core/lib/Drupal/Core/Config/StorageCopyTrait.php from the replaceStorageContents function. Further checking this I've found that in the core/lib/Drupal/Core/Config/CachedStorage.php file the following code segment
public function read($name) {
$cache_key = $this->getCacheKey($name);
if ($cache = $this->cache->get($cache_key)) {
// The cache contains either the cached configuration data or FALSE
// if the configuration file does not exist.
return $cache->data;
}
// Read from the storage on a cache miss and cache the data. Also cache
// information about missing configuration objects.
$data = $this->storage->read($name);
$this->cache->set($cache_key, $data);
return $data;
}is being executed, where the cache returns an object, but the data in the object is empty. While if I run in that time the $this->storage->read($name); I get back the file contents actually.
My current best guess is that the warning has the solution. The only problem is that the contents are created in the hook_site_install_finished when the site should have all the config in place. But it doesn't. Still doesn't explain that a drush cr why does not fix this, why I have to enable any module to be able to import the missing configs.
Steps to reproduce
Unsure if it's reproducible on other installations, yet. But it should be something like this:
1. Have an already working site.
2. Try to do a clean install from config.
3. While it does the install from config I receive these messages and the configs are not installed or imported, and sometimes I can't do it even after the install as its shows like everything is imported. While enabling another module suddenly changes something and I can import the rest of the configs without an issue.
drush cr does not solve the issue, drush en and some module does...
Proposed resolution
On clean install, it should read the files instead of some cached values.
Remaining tasks
n/a
User interface changes
n/a
API changes
n/a
Data model changes
n/a
Release notes snippet
n/a
| Comment | File | Size | Author |
|---|---|---|---|
| #25 | interdiff_21-25.txt | 1.63 KB | sahil.goyal |
| #25 | 3304778-25.patch | 2.1 KB | sahil.goyal |
| #21 | interdiff_20-21.txt | 416 bytes | nitin shrivastava |
| #21 | 3304778-21.patch | 1.74 KB | nitin shrivastava |
| #20 | 3304778-20.patch | 1.76 KB | gaurav-mathur |
Comments
Comment #2
cilefen commentedI don’t totally understand how this is a “clean” install because those notices mention configurations from contributed modules. Or, is that the point of this issue?
Comment #3
golddragon007 commented"clean" install as it does not use database dump.
"those notices mention configurations from contributed modules" - views is not a contrib module as well as fields and form mode and language nor the file where the notice coming from, it's part of the core and it's not capable of importing it on drush site install from existing config. WHY? Why is the $this->cache->get($cache_key) returning a cached object which has an empty data property? While the $this->storage->read($name) is returning the correct file contents from the sync directory?
And I can even ask better, let's say ok, it's incapable of doing it, but then after the drush site install command if I would give a drush cr and drush cim it should, but it doesn't. It says everything is completely fine. While half of the site config is not in database...
But if I enable a module, then it can import them... *facepalm*
Comment #4
golddragon007 commentedI have a feeling that this happens because I receive this:
[warning] The "block_content:3e9e5e58-6407-41b9-92ac-c67246f11478" was not found
This can't be an existing thing at install time, as that's a default content which is added after the install is finished from configs.
This wasn't a problem in the past, as I received several of these warnings but the configs were imported, and the rest which wasn't the next cim imported without an issue. But in the 9.3.x core this does not work like that, so probably if you generate some default content when you install your site from config, with clean DB, then this can happen. And I can't do anything against this, as I can't create this content before importing the configs as this is a custom block type. And I have several other default content, it's interesting that those can be created regardless that the config failed. But I don't see how this can be resolved without using a config-based content import...
Comment #5
golddragon007 commentedComment #6
agentrickardI am seeing the same messages, including the missing block, but that does not seem to be the cause of this issue.
Here's a part of the install from config message:
The missing blocks are simply ignored -- which is fine.
Editing the StorageCopyTrait::replaceStorageContents method to show the $collection variable indicates that it is looking for
langcode: esversions of the config.A few interesting notes here:
Post-install, I have a partial config collection for langcode:es in the config table:
This list almost exactly matches the notices -- though there are 101 notices via drush and 124 of these rows in the config table.
The imported config does have 3 config entities that are marked as langcode:es, but those do not appear in the "spanish" collection.
For instance, the file system.menu.spanish-main-menu.yml contains this:
And this query
select collection, name from config where name="system.menu.spanish-main-menu";returns:So I'm not sure what is going on here.
Comment #7
golddragon007 commentedAs you see I had this issue not only for core but for contrib configurations too.
We have 24 languages, where English is the default, but sometimes some contents may have a different source language.
We do use config translation.
When I checked the configs the default language config was empty from the cache but when I loaded with the other line it loaded the config correctly. Also, the same config was reported 24 times.
Comment #8
agentrickardOdd. I do suspect that multi-lingual plays a role here.
Comment #9
grimreaperHi,
I am also facing this issue and I have not found the origin of the problem.
The problem occurs when installing a website from existing configuration. If the configuration is placed inside an install profile, then it is ok...
Here my investigations on my case if this can help.
At the beginning I had:
Then I removed the french language and all config translations and it reduced to:
First I imagined this was because those files did not have a "langcode" and a "_core/default_config_hash" entries. So I tried to manually put that in ui_patterns_settings.settings.yml file.
Same result.
I disabled Redis cache and any dev mode to ensure it was not the cause of that. Same result.
I tried to do the install using the web UI to test if the problem was present in this case too and I found #3313656: Fatal error when installing website from existing config and dblog is not enabled.
So I duplicated the minimal install profile to put only the 3 problematic config in it, removing as much stuff from the minimal profile to focus on the problematic config.
And then when installing with Drush, without the existing config option, it was ok.
Nothing between "install_bootstrap_full" and "install_config_import_batch".
As on my current project we will have to make an install profile, I will not have problem, but for other projects and my own knowledge I would really like to know what causes that.
Comment #10
robin.houtevelts commentedEdit: I was wrong. My site install was caught in an endless loop due to bad config dependencies. I no longer have any issues.
----
I'm also seeing this now when I do a site install from existing config.
However I don't have a multilingual site.
enis the langcode.It runs fine at first, but then hangs at
Missing required data for configuration: user.role.anonymous.drush site-install -vv --existing-config --no-interactionFull logs are included as attachment.
Comment #11
mikeryanThe "Missing required data for configuration" notices on site install are easily reproducible (at least on 9.4.8):
rm -Rf config/language config/*.yml # In case you're repeatedly testingdrush si minimal -v --account-name=admin --site-name='Test config error' -ydrush en -y config_translationdrush cex -ydrush si minimal -v --account-name=admin --site-name='Test config error' -y --existing-configResult:
Comment #12
mikeryanFYI, #3002457 appears relevant, but that patch does not fix these notices.
Comment #13
mikeryanActually, I think #3063687: ConfigFactory static cache is not updated when cache tags are invalidated has the diagnosis for the problem.
Comment #15
mikeryanWell, I created a patch for #3063687: ConfigFactory static cache is not updated when cache tags are invalidated, but it doesn't seem to have impacted the issue here. I think the next step is to write a test for the failure.
Comment #16
mikeryanI should note - this is reproducible in D10 as well, so that's where it should be fixed first.
Comment #17
plachThis helped me get rid of the notices, but I'm not sure it's the right approach.
Comment #18
plachComment #19
gaurav-mathur commentedComment #20
gaurav-mathur commentedAdded patch against #17 in 10.1.x
Kindly review patch
Thank you.
Comment #21
nitin shrivastava commentedtry to fix #20
Comment #22
smustgrave commentedThis 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.
Did not replicate but if a bug it will need a test case to show the issue.
Comment #23
joachim commentedThis is just repeating the class name.
The docs should say why we need a dedicated version of this for the install process.
Comment #24
sahil.goyal commentedaddressed the #23, it is correct that InstallStorageComparer just repeating classnames, so i updated the docblock.
Comment #25
sahil.goyal commentedFixing CFF empty space error. addressed the #23
Comment #26
sahil.goyal commentedComment #27
smustgrave commentedStill needs tests
Comment #29
alexpottThis looks like a duplicate of #3294293: The target storage in the StorageComparer can get out-of-sync with the container during installation from config - I think the solution there is better.
Comment #30
alexpottAlso see #3406929: Configuration being imported by the ConfigImporter sometimes has stale original data which has resulted in fixing this for me.
Comment #31
dcam commentedI am not able to reproduce this issue using the steps given in #11. The other related issues have also been closed as being outdated because the issue is considered to be fixed. So I'm doing the same here.