Problem/Motivation

We have a Drupal 11.2 codebase that used external_entities successfully. ( It is a recent upgrade from Drupal 10 ).

The external entity module has an entity defined names "mycustom_external_files", and we also have view that uses this. The site uses configuration management for almost everything.

When updating it to Drupal 11.3, I find that doing a "drush site-install" fails with the following error, when the configuration is imported:

I

n EntityTypeManager.php line 139:
                                                               
  [Drupal\Component\Plugin\Exception\PluginNotFoundException]  
  The "mycustom_external_files" entity type does not exist.       
                                                               

Exception trace:
  at /var/www/html/docroot/core/lib/Drupal/Core/Entity/EntityTypeManager.php:139
 Drupal\Core\Entity\EntityTypeManager->getDefinition() at /var/www/html/docroot/core/lib/Drupal/Core/Entity/EntityRepository.php:58
 Drupal\Core\Entity\EntityRepository->loadEntityByUuid() at /var/www/html/docroot/core/lib/Drupal/Core/Config/ConfigManager.php:515
 Drupal\Core\Config\ConfigManager->findMissingContentDependencies() at /var/www/html/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php:713
 Drupal\Core\Config\ConfigImporter->processMissingContent() at /var/www/html/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php:570
 Drupal\Core\Config\ConfigImporter->doSyncStep() at /var/www/html/docroot/core/lib/Drupal/Core/Config/Importer/ConfigImporterBatch.php:31
 Drupal\Core\Config\Importer\ConfigImporterBatch::process() at /var/www/html/docroot/core/includes/batch.inc:300
 _batch_process() at /var/www/html/docroot/core/includes/form.inc:834
 batch_process() at /var/www/html/docroot/core/includes/install.core.inc:648
 install_run_task() at /var/www/html/docroot/core/includes/install.core.inc:566
 install_run_tasks() at /var/www/html/docroot/core/includes/install.core.inc:122
 install_drupal() at /var/www/html/vendor/drush/drush/includes/drush.inc:69
 drush_call_user_func_array() at /var/www/html/vendor/drush/drush/includes/drush.inc:53
 drush_op() at /var/www/html/vendor/drush/drush/src/Commands/core/SiteInstallCommands.php:174
 Drush\Commands\core\SiteInstallCommands->install() at n/a:n/a
 call_user_func_array() at /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php:276
 Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback() at /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php:212
 Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter() at /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php:175
 Consolidation\AnnotatedCommand\CommandProcessor->process() at /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:389
 Consolidation\AnnotatedCommand\AnnotatedCommand->execute() at /var/www/html/vendor/symfony/console/Command/Command.php:341
 Symfony\Component\Console\Command\Command->run() at /var/www/html/vendor/symfony/console/Application.php:1102
 Symfony\Component\Console\Application->doRunCommand() at /var/www/html/vendor/symfony/console/Application.php:356
 Symfony\Component\Console\Application->doRun() at /var/www/html/vendor/symfony/console/Application.php:195
 Symfony\Component\Console\Application->run() at /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php:110
 Drush\Runtime\Runtime->doRun() at /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php:40
 Drush\Runtime\Runtime->run() at /var/www/html/vendor/drush/drush/drush.php:140

If I remove the .yml file that is the view configuration from the codebase, the site-install works.

If I run "drush cim" directly after the failed "drush site-install", it appears to work and import everything.

Steps to reproduce

I don't have a clean way to reproduce this outside of our codebase yet.

Proposed resolution

I'm not sure what the resolution is, but I think it's possible that some change done in Drupal 11.3 requires the exported configuration of the view have an additional dependency. This is guess and I haven't confirmed anything.

Has anyone else run into something similar ?

Comments

rgristroph created an issue. See original summary.

guignonv’s picture

guignonv
Primary language French
Location Montpellier
commented

I had this problem as well in similar context with different xntt types. I investigated but was not able to understand what was missing. I'm quite sure, it is like you say, a missing dependency somewhere. But the problem is hard to reproduce.
Usually, when it happens to me, I'm working on something else and don't have much time to investigate, so I use a quick manual fix: I recreate the missing external entities using drush, update/upgrade, clear the cache and then, remove them from the UI (sometimes I need to recreate and/or remove some fields before I think I remember...).
I also tried an automated fix with the external entity manager (/admin/structure/external-entity-types/integrity). It works in some cases but not in some others.

My next steps are to complete tests. I hope I'll be able to reproduce the problem with a test and figure out what is going on.

Thanks for reporting!

guignonv’s picture

guignonv
Primary language French
Location Montpellier
commented
Related issues: +#3474663: Drupal\Component\Plugin\Exception\PluginNotFoundException The "<some_xntt_type>" entity type does not exist.
guignonv’s picture

guignonv
Primary language French
Location Montpellier
commented

Note: this issue is different from #3571248: D10 compatibility - The "xnttfile" entity type does not exist and is not related even if the error message is quite similar. One is related to a previously existing external entity type that Drupal could not find and the other is related to Drupal 10 plugin annotation that has been turned into plugin attributes in D11 (backward compatibility issue).

guignonv’s picture

guignonv
Primary language French
Location Montpellier
commented

I still did not find a way to reproduce the error but I suspect there is a dependency missing issue in the field config:
if the config dependency "external_entities.external_entity_type.{XNTT_TYPE_ID}" is missing, the corresponding fields and their view and form configs are not linked to their external entity type and if they are used while the external entity type is not available (removed or not created yet), I think it leads to such issue.
I leave this here as a note for future further investigations...

  • guignonv committed 6058cd61 on 3.0.x 
    Fixes field missing dependencies (related to issue #3567528)
guignonv’s picture

guignonv
Primary language French
Location Montpellier
commented

There was a missing dependency implementation for field storage. I fixed that in commit #6058cd615c2277525a5eeb191d65b2041636cf1b. That should solved issues I reported above.

Also, EntityField::calculateDependencies is not implemented at the moment in the views support. That why you got that error with views. I'll implement it to fix your issue...
...well, it will not fix it since the invalid config files were already created but it should prevent the problem to occur in future config exports.

  • guignonv committed 49ad8f28 on 3.0.x 
    Implemented views support dependency calculation for config (issue #...
guignonv’s picture

guignonv
Primary language French
Location Montpellier
commented
Status: Active » Needs review

Commit #49ad8f28 adds the missing ::calculateDependencies implementations for RenderedExternalEntity and ExternalEntityField (also inherited by ExternalEntityFieldLanguage).

I think now, when external entity views configs are exported (and loaded), it should be fine because it will check first if the corresponding external entity type is there. Could someone test that?