Ensure that migrations of entities which have file or image fields depend on private/public files migration

New edge case discovered when using https://www.drupal.org/project/file_entity → . This updated patch adds protection for it.

Next patch can we change the name of it, unless it's not meant to be tested?

addFileMigrationDependencies
Can this be typehinted since it's a new function?

file.migration.dependency.manager:
As a new service believe this will need a change record.

The edge case you mentioned in #16 could that be added to the issue summary too please.

Thanks!

Trivial conflicts when applying #16 to 10.2.0:

• 📌 Enable more service autowiring by adding interface aliases to core modules Fixed
• 📌 Move file upload validation from file.module to constraint validators Fixed

Changing patch to MR to allow easier review.

@smustgrave - What you you mean by "...addFileMigrationDependencies... Can this be typehinted since it's a new function?"

The latest patch introduces a hard dependency on migrate module inside file.module. That is not really acceptable, as it can cause errors in install from config.

Fatal error: During class fetch: Uncaught ReflectionException: Class "Drupal\migrate\Plugin\MigrationDeriverTrait" not found while loading "Drupal\file\FileMigrationDependencyManager". in /var/www/html/vendor/composer/ClassLoader.php:576 Stack trace: #0 [internal function]: Composer\Autoload\ClassLoader->loadClass('Drupal\\file\\Fil...') #1 /var/www/html/vendor/symfony/config/Resource/ClassExistenceResource.php(76): class_exists('Drupal\\file\\Fil...') #2 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(361): Symfony\Component\Config\Resource\ClassExistenceResource->isFresh(0) #3 /var/www/html/vendor/symfony/dependency-injection/Compiler/RegisterAutoconfigureAttributesPass.php(32): Symfony\Component\DependencyInjection\ContainerBuilder->getReflectionClass('Drupal\\file\\Fil...', false) #4 /var/www/html/vendor/symfony/dependency-injection/Compiler/Compiler.php(80): Symfony\Component\DependencyInjection\Compiler\RegisterAutoconfigureAttributesPass->process(Object(Drupal\Core\DependencyInjection\ContainerBuilder)) #5 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(767): Symfony\Component\DependencyInjection\Compiler\Compiler->compile(Object(Drupal\Core\DependencyInjection\ContainerBuilder)) #6 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(1447): Symfony\Component\DependencyInjection\ContainerBuilder->compile() #7 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(971): Drupal\Core\DrupalKernel->compileContainer() #8 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(515): Drupal\Core\DrupalKernel->initializeContainer() #9 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(739): Drupal\Core\DrupalKernel->boot() #10 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #11 {main} in /var/www/html/web/core/modules/file/src/FileMigrationDependencyManager.php on line 18

The MigrationDeriverTrait only has one method.

Removing the Trait call and moving that method into FileMigrationDependencyManager.php fixes the issue, but I suspect this may affect all uses of the Trait.

It seems to be a race condition regarding how the plugin alter hook gets called.