Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
My personally experience with this is when filtering content types but bad data or renaming content types during the migrations could also theoretically cause this problem.
Comment | File | Size | Author |
---|---|---|---|
#5 | 2588707-5.patch | 4.38 KB | phenaproxima |
#2 | 2588707-2.patch | 4.43 KB | phenaproxima |
#2 | 2588707-2-FAIL.patch | 1.61 KB | phenaproxima |
Comments
Comment #2
phenaproximaTry these on for size.
Comment #3
neclimdulConcept looks good!
Nit, tests that don't assert anything are "risky." We can assert that a field doesn't exist or something to ensure things ran quietly but the value didn't make it.
Comment #5
phenaproximaAdded a couple of assertions.
Comment #6
neclimdulThanks
Comment #8
webchickI... could not make any heads or tails out of this issue at all. ;)
Adam explained that the problem is if Article node type migration fails, and a field attempts to be migrated later, exceptions ensue. This makes the code more defensive and avoids errors. Makes sense to me.
Since these changes are self-contained against an experimental module, I believe that makes this eligible for commit during RC. Tagging.
Committed and pushed to 8.0.x. Thanks!
Comment #10
neclimdulThat pretty much sums it up. Its also a step toward allowing content types to be skipped, or possibly renamed. Just pulling an example out of thin air that surely doesn't apply to me, if you where migrating node profiles onto user fields and didn't want to pull over the profile nodes.