Problem/Motivation

Steps to reproduce:

  1. Install standard in German
  2. Enable config_translation
  3. Add the english language
  4. Edit the standard profile to not have an standard_install() and add keep_english: true to its .info.yml file
  5. Export the configuration using drush
  6. Re-install the site using drush site-install with the --existing-config flag.

You'll see an error like

 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [21.25 sec, 62.74 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [21.25 sec, 62.75 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [21.25 sec, 62.75 MB]
 [info] Undefined index: field_type FieldConfigStorageBase.php:25 [22.66 sec, 76.9 MB]
 [info] Undefined index: field_type FieldConfigStorageBase.php:28 [22.66 sec, 76.94 MB]

In FieldConfigStorageBase.php line 28:

  [RuntimeException]
  Unable to determine class for field type '' found in the 'field.field.' configuration

Proposed resolution

The problem is caused by container invalidation not causing a reboot. In a non-interactive install container invalidation shouldn't occur because we don't know what the next task is going to do with the container.

Remaining tasks

User interface changes

API changes

Data model changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alexpott created an issue. See original summary.

alexpott’s picture

Status: Active » Needs review
FileSize
747 bytes
webflo’s picture

The patch works great in my installation with three languages and German as default. Thank you!

alexpott’s picture

Here's a patch that has a test and fixes to ensure that language configuration can be imported without unexpected changes during an install from configuration.

Unfortunately the test does not cause the exception to be thrown. I've not managed to work out why yet. If you use the new config in core/tests/fixtures/config_install/multilingual.tar.gz and install from it using Drush is crashes as expected but via the test-runner it does not. So that points us toward either something in Drush or the Test-runner doing something that affects the install. My best guess is there is something in the test environment that cause the container to be rebuilt.

Status: Needs review » Needs work

The last submitted patch, 4: 2999061-4.patch, failed testing. View results

alexpott’s picture

Status: Needs work » Needs review
FileSize
578 bytes
49.4 KB

Status: Needs review » Needs work

The last submitted patch, 6: 2999061-6.patch, failed testing. View results

alexpott’s picture

Status: Needs work » Needs review
FileSize
65.62 KB
56.92 KB

Fixing the tests that are broken by the tarball using a different profile. The patch changes that so we don't have to create a profile in the new test.

alexpott’s picture

So if I hack core's inbuilt install CLI command (core/lib/Drupal/Core/Command/InstallCommand.php) like so

diff --git a/core/lib/Drupal/Core/Command/InstallCommand.php b/core/lib/Drupal/Core/Command/InstallCommand.php
index bff4bc471d..4ed5bde589 100644
--- a/core/lib/Drupal/Core/Command/InstallCommand.php
+++ b/core/lib/Drupal/Core/Command/InstallCommand.php
@@ -74,8 +74,8 @@ protected function execute(InputInterface $input, OutputInterface $output) {
     if ($this->isDrupalInstalled()) {
       // Do not fail if the site is already installed so this command can be
       // chained with ServerCommand.
-      $output->writeln('<info>Drupal is already installed.</info> If you want to reinstall, remove sites/default/files and sites/default/settings.php.');
-      return 0;
+//      $output->writeln('<info>Drupal is already installed.</info> If you want to reinstall, remove sites/default/files and sites/default/settings.php.');
+//      return 0;
     }
 
     $install_profile = $input->getArgument('install-profile');
@@ -135,6 +135,7 @@ protected function install($class_loader, SymfonyStyle $io, $profile, $langcode,
       'parameters' => [
         'profile' => $profile,
         'langcode' => $langcode,
+        'existing_config' => TRUE,
       ],
       'forms' => [
         'install_settings_form' => [

And then use the config provided by this patch to do a re-install I get the same error as Drush. So this points to something special in the test running environment that is making this very hard to test :(

alexpott’s picture

Okay worked out something interesting. Some part of this seems to occur when language config exists in the profiles config/install directory and is in the incoming import.

The attached patch shows an exception against HEAD that no longer occurs with the patch. Hopefully only the new test should fail...

The last submitted patch, 10: 2999061-10.test-only.patch, failed testing. View results

webflo’s picture

#10 works great, but installing Drupal via Drush and providing the Database URL as command line option fails on multiple projects with obscure error messages.

There are error messages in two different projects.

 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: unpublish_on BaseFieldOverride.php:167 [153.84 sec, 116.53 MB]
[23-Oct-2018 09:22:52 UTC] TypeError: Argument 2 passed to Drupal\Core\Entity\ContentEntityStorageBase::onFieldDefinitionUpdate() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given, called in /builds/example/web/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php on line 207 in /builds/example/web/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php on line 424 #0 /builds/example/web/web/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php(207): Drupal\Core\Entity\ContentEntityStorageBase->onFieldDefinitionUpdate(Object(Drupal\Core\Field\Entity\BaseFieldOverride), NULL)
timmillwood’s picture

We're using config in an install profile and getting issue relating to languages on install.

Drupal\Core\Entity\EntityStorageException: 'configurable_language' entity with ID 'en' already exists.

This is the issue I see during drush site-install, and the patch in #10 looked to fix the issue.

However our functional tests don't agree, as they throw:
Undefined index: id core/modules/language/src/ConfigurableLanguageManager.php:317

Which relates to @webflo's errors in #12.

timmillwood’s picture

I was able to resolve my issue by disabling default_content module.

I still need to work out why that was causing Undefined index: id core/modules/language/src/ConfigurableLanguageManager.php:317, as it was not even importing any content, it was just installed.

alexpott’s picture

@timmillwood hmmm are you sure it was doing nothing? I've followed the instructions in the issue summary but also enabled the default_content module and the error you experienced is not happening.

timmillwood’s picture

Here's the diff from my install profile repo between working and not working. So it could've been default_config_extra actually:

diff --git a/config/sync/core.extension.yml b/config/sync/core.extension.yml
index 4c16337..30a4f81 100644
--- a/config/sync/core.extension.yml
+++ b/config/sync/core.extension.yml
@@ -19,8 +19,6 @@ module:
   ctools: 0
   database_sanitize: 0
   datetime: 0
-  default_content: 0
-  default_content_extra: 0
   deploy: 0
   dynamic_page_cache: 0
   editor: 0
diff --git a/config/sync/default_content_extra.settings.yml b/config/sync/default_content_extra.settings.yml
deleted file mode 100644
index e568976..0000000
--- a/config/sync/default_content_extra.settings.yml
+++ /dev/null
@@ -1,4 +0,0 @@
-path_alias: 1
-delete_users: 1
-_core:
-  default_config_hash: aATeapdNwkzWqut8av-LuTfnxmPUoljuN9ymfdH7HY8

Here's the stack trace from when it was failing:

core/modules/language/src/ConfigurableLanguageManager.php:317
core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:1129
core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:465
core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:393
core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:359
core/lib/Drupal/Core/Entity/EntityStorageBase.php:279
core/lib/Drupal/Core/Entity/EntityStorageBase.php:249
modules/contrib/default_content/src/Importer.php:122
modules/contrib/default_content/src/Config/DefaultContentConfigSubscriber.php:41
core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:111
core/lib/Drupal/Core/Config/ConfigImporter.php:652
core/lib/Drupal/Core/Config/ConfigImporter.php:496
core/lib/Drupal/Core/Config/Importer/ConfigImporterBatch.php:30
core/includes/batch.inc:294
core/includes/form.inc:880
core/includes/install.core.inc:666
core/includes/install.core.inc:584
core/includes/install.core.inc:125
core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:286
core/tests/Drupal/Tests/BrowserTestBase.php:564
core/tests/Drupal/Tests/BrowserTestBase.php:394
profiles/my_profile/tests/src/Functional/MyProfileTest.php:37
alexpott’s picture

And I've tried adding default_content to the multilingual config install tarball and running the test - still doesn't fail :(

andypost’s picture

maybe failure depends on drush version?

alexpott’s picture

I'm on Drush Commandline Tool 9.4.0

timmillwood’s picture

After applying the patch in #10 drush site-install worked fine. The only failure I saw was PHPUnit running my functional test.

rpsu’s picture

Applying patch #10 removes drush installation failing to

[Drupal\Core\Entity\EntityStorageException]                  
  'configurable_language' entity with ID 'en' already exists.  

However the same installation stops with the next exception

[Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException]  
  You have requested a non-existent service "content_translation.manager".    

with stacktrace

Exception trace:
 Drupal\Component\DependencyInjection\Container->get() at /var/www/docroot/core/lib/Drupal.php:158
 Drupal::service() at /var/www/docroot/core/modules/content_translation/content_translation.module:198
 content_translation_entity_base_field_info() at n/a:n/a
 call_user_func_array() at /var/www/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php:392
 Drupal\Core\Extension\ModuleHandler->invoke() at /var/www/docroot/core/lib/Drupal/Core/Entity/EntityFieldManager.php:266
 Drupal\Core\Entity\EntityFieldManager->buildBaseFieldDefinitions() at /var/www/docroot/core/lib/Drupal/Core/Entity/EntityFieldManager.php:171
 Drupal\Core\Entity\EntityFieldManager->getBaseFieldDefinitions() at /var/www/docroot/core/lib/Drupal/Core/Entity/EntityFieldManager.php:425
 Drupal\Core\Entity\EntityFieldManager->getFieldStorageDefinitions() at /var/www/docroot/core/lib/Drupal/Core/Entity/EntityManager.php:208
 Drupal\Core\Entity\EntityManager->getFieldStorageDefinitions() at /var/www/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:323
 Drupal\Core\Entity\Sql\SqlContentEntityStorage->getTableMapping() at /var/www/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:188
 Drupal\Core\Entity\Sql\SqlContentEntityStorage->initTableLayout() at /var/www/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:173
 Drupal\Core\Entity\Sql\SqlContentEntityStorage->__construct() at /var/www/docroot/modules/contrib/commerce/src/CommerceContentEntityStorage.php:49
 Drupal\commerce\CommerceContentEntityStorage->__construct() at /var/www/docroot/modules/contrib/commerce/modules/log/src/LogStorage.php:46
 Drupal\commerce_log\LogStorage->__construct() at /var/www/docroot/modules/contrib/commerce/modules/log/src/LogStorage.php:63
 Drupal\commerce_log\LogStorage::createInstance() at /var/www/docroot/core/lib/Drupal/Core/Entity/EntityTypeManager.php:250
 Drupal\Core\Entity\EntityTypeManager->createHandlerInstance() at /var/www/docroot/core/lib/Drupal/Core/Entity/EntityTypeManager.php:239
 Drupal\Core\Entity\EntityTypeManager->getHandler() at /var/www/docroot/core/lib/Drupal/Core/Entity/EntityTypeManager.php:170
 Drupal\Core\Entity\EntityTypeManager->getStorage() at /var/www/docroot/core/lib/Drupal/Core/Entity/EntityManager.php:79
 Drupal\Core\Entity\EntityManager->getStorage() at /var/www/docroot/core/lib/Drupal/Core/Entity/EntityDefinitionUpdateManager.php:356
 Drupal\Core\Entity\EntityDefinitionUpdateManager->requiresEntityStorageSchemaChanges() at /var/www/docroot/core/lib/Drupal/Core/Entity/EntityDefinitionUpdateManager.php:295
 Drupal\Core\Entity\EntityDefinitionUpdateManager->getChangeList() at /var/www/docroot/core/lib/Drupal/Core/Entity/EntityDefinitionUpdateManager.php:53
 Drupal\Core\Entity\EntityDefinitionUpdateManager->needsUpdates() at /var/www/docroot/core/modules/content_translation/src/ContentTranslationUpdatesManager.php:56
 Drupal\content_translation\ContentTranslationUpdatesManager->updateDefinitions() at /var/www/docroot/core/modules/content_translation/src/ContentTranslationUpdatesManager.php:77
 Drupal\content_translation\ContentTranslationUpdatesManager->onConfigImporterImport() at n/a:n/a
 call_user_func() at /var/www/docroot/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:111
 Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() at /var/www/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php:652
 Drupal\Core\Config\ConfigImporter->finish() at /var/www/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php:496
 Drupal\Core\Config\ConfigImporter->doSyncStep() at /var/www/docroot/core/lib/Drupal/Core/Config/Importer/ConfigImporterBatch.php:30
 Drupal\Core\Config\Importer\ConfigImporterBatch::process() at /var/www/docroot/core/includes/batch.inc:294
 _batch_process() at /var/www/docroot/core/includes/form.inc:880
 batch_process() at /var/www/docroot/core/includes/install.core.inc:666
 install_run_task() at /var/www/docroot/core/includes/install.core.inc:584
 install_run_tasks() at /var/www/docroot/core/includes/install.core.inc:125
 install_drupal() at /var/www/vendor/drush/drush/includes/drush.inc:238
 drush_call_user_func_array() at /var/www/vendor/drush/drush/includes/drush.inc:223
 drush_op() at /var/www/vendor/drush/drush/src/Commands/core/SiteInstallCommands.php:141
 Drush\Commands\core\SiteInstallCommands->install() at n/a:n/a
 call_user_func_array() at /var/www/vendor/consolidation/annotated-command/src/CommandProcessor.php:235
 Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback() at /var/www/vendor/consolidation/annotated-command/src/CommandProcessor.php:181
 Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter() at /var/www/vendor/consolidation/annotated-command/src/CommandProcessor.php:150
 Consolidation\AnnotatedCommand\CommandProcessor->process() at /var/www/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:404
 Consolidation\AnnotatedCommand\AnnotatedCommand->execute() at /var/www/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /var/www/vendor/symfony/console/Application.php:964
 Symfony\Component\Console\Application->doRunCommand() at /var/www/vendor/symfony/console/Application.php:248
 Symfony\Component\Console\Application->doRun() at /var/www/vendor/symfony/console/Application.php:148
 Symfony\Component\Console\Application->run() at /var/www/vendor/drush/drush/src/Runtime/Runtime.php:112
 Drush\Runtime\Runtime->doRun() at /var/www/vendor/drush/drush/src/Runtime/Runtime.php:41
 Drush\Runtime\Runtime->run() at /var/www/vendor/drush/drush/drush.php:66
 require() at /var/www/vendor/drush/drush/drush:4

Command used is drush si minimal --debug --uri=a1_test --account-name=admin --account-pass=admin --db-prefix='' --db-url=mysql://user:pass@db:3306/drupal --account-mail=admin@example.com --site-mail=admin@example.com --sites-subdir=a1_test --existing-config -v

Without drush param --existing-congif everything works smoothly.

Drush version : 9.5.2
Drupal Version: 8.6.2

pfrenssen’s picture

Marked #2955457: ConfigFactory static cache gets polluted with data from config overrides as a duplicate of this bug. That issue describes an error message that occurs when a site is being installed from existing config using a non-interactive installer. The bug also occurs when the default language is English, but translated config is present. The rebuilding of the container for non-interactive installation fixes this too.

pfrenssen’s picture

The patch looks good to me. It fixes the bug, and the rebuilding of the container during a non-interactive installation also solves another error message I was having. I have not been able to replicate any of the errors that were mentioned by @webflo and @timmilwood, but I was testing on a minimal site that only had a handful of core modules enabled.

mpp’s picture

Title: Non interactive install not in English with configuration overrides is broken » Non interactive install with configuration overrides is broken

The bug also occurs when the default language is English, but translated config is present.

@pfrenssen, we also encountered this issue when performing non interactive site installation of a site in English with translated config.

Rewording this issue's title accordingly.

pfrenssen’s picture

Update: I have had the same error as reported by @rpsu in comment #2999061-21: Non interactive install with configuration overrides is broken when I tried this patch on one of our distributions. I am going to try to supply a replicable build for this.

webflo’s picture

#2955457: ConfigFactory static cache gets polluted with data from config overrides + that patch from this issue works on my sites. Thanks!

Whats left to get this in?

alexpott’s picture

@webflo I think just an rtbc :)

alexpott’s picture

Rerolled.

alexpott’s picture

Hmmm... :( nope we need a failing test. Which we no longer have for some reason.

alexpott’s picture

Status: Needs review » Needs work

Testing the 23285fb0fe commit shows that the test this issue adds was fixed by #2955457: ConfigFactory static cache gets polluted with data from config overrides - so we need new instructions on what to test to prove this fixes what @webflo et al are experiencing.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mpp’s picture

We're no longer experiencing this error using #2955457 (on 8.7.x-dev).

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

GoZ’s picture

Status: Needs work » Needs review
FileSize
62.15 KB

Patch fail due to multilingual.tar.gz archive on 8.8.x.

Here is a reroll updating this archive.

How i proceed :
I make diff between the last multingual.tar.gz status on 8.7.x and 8.8.x and manually make changes in archive from this issue.

Differences between 8.7.x and 8.8.x are :

--- multilingual-8.7.x/system.file.yml 2017-04-06 13:08:14.000000000 +0100
+++ multilingual-8.8.x/system.file.yml 2019-06-14 08:12:44.000000000 +0100
@@ -1,7 +1,5 @@
 allow_insecure_uploads: false
 default_scheme: public
-path:
-  temporary: /tmp
 temporary_maximum_age: 21600
 _core:
   default_config_hash: t48gCU9DzYfjb3bAOIqHLzhL0ChBlXh6_5B5Pyo9t8g


--- multilingual-8.7.x/core.extension.yml  2017-04-06 13:08:14.000000000 +0100
+++ multilingual-8.8.x/core.extension.yml  2019-10-30 01:06:01.000000000 +0100
@@ -9,6 +9,7 @@
   locale: 0
   node: 0
   page_cache: 0
+  path_alias: 0
   system: 0
   text: 0
   user: 0

This patch is for 8.8.x, i have not test it on 8.9.x

Status: Needs review » Needs work

The last submitted patch, 34: 2999061-34.patch, failed testing. View results

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now 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.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.