Problem/Motivation
Right now, entities which have file or image fields can be migrated without the corresponding file migration, that ends in incomplete entity migrations (with stubbed files..).
Proposed resolution
Make these kind of content entity migrations depend on private/public files migration.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3123775
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
huzookaComment #3
huzookaFixing coding standard and updating failing tests by adding the required file migrations to the executed migrations.
Comment #4
huzookaComment #5
wim leers🤔 Shouldn't this be
\Drupal\Component\Plugin\Exception\PluginNotFoundException?🤓 s/is/are/
🤓 Mismatch.
This is a super long method. It would benefit a lot from splitting up into helper methods that are more easily understood.
Nit: we could add typehints to the anonymous function.
🤓 Usually we format this as
Interesting — what are examples of when this edge case occurs?
This is
node-specific.What would it take to make this support bundles of other entity types? (It does already support arbitrary entity types that are bundleless 👍)
😍 Very elegant!
What would be a reason for somebody to want to provide an alternative implementation of this service?
Comment #7
quietone commentedIt is more reliable to get the source version number from the source database. As in migrate_drupal.module.
I guess I am missing something, why not just add the file migrations as optional dependencies ?
Comment #10
wim leersBack in early 2020 I would've said that is not possible, but now I agree it is!
This logic (and related logic) should be updated to add these as optional instead of required dependencies.
Comment #12
narendrarRerolled #4 for 9.3.x
Unable to provide complete interdiff file due to below error:
Comment #13
wim leers#12 looks identical to #4 — except for different whitespace in
file.services.yml👍Comment #16
wim leersNew edge case discovered when using https://www.drupal.org/project/file_entity. This updated patch adds protection for it.
Comment #17
smustgrave commentedNext patch can we change the name of it, unless it's not meant to be tested?
addFileMigrationDependenciesCan 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!
Comment #19
wim leersTrivial conflicts when applying #16 to 10.2.0:
Comment #22
fjgarlin commentedChanging patch to MR to allow easier review.
Comment #23
fjgarlin commented@smustgrave - What you you mean by "...addFileMigrationDependencies... Can this be typehinted since it's a new function?"
Comment #24
agentrickardThe 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.
Comment #25
agentrickardThe 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.
UPDATE: I was testing an older patch version against Drupal 10.3. The newest patch no longer applies, so it is unclear whether the install problem is fixed.