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.
As of now, all major migration regarding the content i,e the content type and the respective nodes are being imported from Drupal 6 to Drupal 8. Also, all the taxonomies available in the Drupal 6 instance are ported successfully to Drupal 8 instance.
However, after a successful upgrade, when the content is analysed the Taxonomy term reference that a node holds in Drupal 6 instance is no more maintained in the Drupal 8 instance.
Comment | File | Size | Author |
---|---|---|---|
#20 | migrate_plus.migration.upgrade_d6_term_node_2.yml | 1.41 KB | niccottrell |
Comments
Comment #2
dipali.dhole CreditAttribution: dipali.dhole commentedComment #3
mikeryanMoved to the core issue queue - anything to do with the results of the migration (as opposed to what happens in the browser during the process) is 99% sure to be in the underlying framework which actually performs the migration.
I did a test migration of my own D6 site to D8 just last week and the term-node relationships came over just fine, so I don't there's a universal problem with migrating term references. Is there anything unusual about your environment (especially the D6 side) related to taxonomy (such as contrib modules affecting taxonomy)? On the D8 side, when you say "when the content is analysed", how did you analyze it? Did you edit nodes with known term references to see if the relationships were there? If not, one possibility would be that the data itself was migrated but perhaps the proper display settings weren't...
Comment #4
quietone CreditAttribution: quietone commentedComment #6
akleinwaechter CreditAttribution: akleinwaechter commentedHi,
I have the same problem. All the migrate map tables for term node relations are filled but have no destination Id. The migration says they are processed but ignored. This would normally happen if the referenced node wouldn't exist but they are all migrated. What I don't understand: Does Drupal 8 Migration generate taxonomy reference fields in the content types for Drupal 6 vocabulary while migration like the old Drupal 6 to 7 way?
Best regards
Alex
Comment #7
mikeryan@akleinwaechter - the Drupal 6->Drupal 8 upgrade process does generate term reference fields for Drupal 6 term_node relationships, yes, via the d6_vocabulary_field and d6_vocabulary_field_instance migrations.
I've just run a migration from my D6 site to D8 using the tip of 8.1.x and my term-node references are successfully migrated. So, this is still not a universal problem with the term_node migrations - there's some element that's different in your case to trigger what you're seeing. Could you look at the questions in #3 above and see if there's anything that might apply in your case?
Comment #8
Marc Angles CreditAttribution: Marc Angles commentedHi,
In my case (which seems to look like the description of the issue) the vocabulary on the drupal 6 was set to be french and localized. Some of the nodes have one of these terms set. On the end side of the migration the terms are not created in the vocabulary (the vocabulary IS created though).
I tried to change the vocabulary i18n config in the source (Changed to no language, to english and french) but I don't get the terms created in the drupal 8 either way.
Comment #9
bkeller CreditAttribution: bkeller commentedRunning an upgrade from D6 to D8.1.3. While the migration is being processed, I get this error:
After the migration, I see this with drush ms:
Now when I look at the taxonomy term vocabs, they are present but there are only terms present for one of the vocabularies. The others are blank. When I look at the database, they are there, and if I go to edit them (/taxonomy/term/35/edit) and Save, it then shows up in the listing. Viewing the tables in the DB, I see nothing that is changed. And yes I have rebuilt Drupal cache.
The next problem of course is that since they are there but hidden from Drupal, they are not referenced in their respective nodes.
I would assume that this is an issue with the configuration of the D6 site, but I'm not sure where to start looking or where to fix this. Also, I don't understand the first error of the missing bundle, but it seems like that would be a good place to start.
Help?
Comment #10
Marc Angles CreditAttribution: Marc Angles commentedI tried with a patch from https://www.drupal.org/node/2225775#comment-11324551, with drupal 8.2.x-dev and all the migrate tools updated to dev version.
I have those messages when running drush migrate-upgrade:
Upgrading d6_term_node:1
InvalidArgumentException: Field project_type is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 471 of /drupal_root/core/lib/Drupal/Core/Entity/ContentEntityBase.php).
Field project_type is unknown. (/drupal_root/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:756)
... and again
At the end I can find the terms in the DB but still not in the drupal UI.
Comment #11
Marc Angles CreditAttribution: Marc Angles commentedAfter adding an entry for each tid in the 'taxonomy_term_hierarchy' table, the terms are now showing in the UI
Comment #12
mikeryan@Marc Angles: If the problem you're seeing is taxonomy_term_hierarchy not being populated, that would be #2744639: Taxonomy term hierarchy migration incomplete.
Comment #13
viirak CreditAttribution: viirak commentedMy case, taxonomy terms also have its translation. Migration does not combine terms into one entity with translation, which mean terms translations are not properly migrated. Hence, the connection between translation nodes to taxonomy terms are broken.
Comment #14
mikeryanI walked through this kind of scenario with someone on IRC yesterday, and was able to replicate the problem when running the migrations as generated through drush migrate-upgrade --configure-only, although the references worked fine when running a direct upgrade. d6_node_term maps the nid thusly:
And in the custom case it could be made to work by replacing
migration: d6_node
withI.e., expanding out the specific node migrations. Seeing that, I'm not quite sure why it works at all, but it seems to me it would be less fragile if D6TermNodeDeriver would expand those node migrations.
Comment #15
nrambeck CreditAttribution: nrambeck commentedI was running into this same issue. Ran a
drush migrate-upgrade --configure-only
migration, then generated a custom module to store the migration configuration in. The Vocabs and Terms would migrate, but not the term/node references. Changing the*term_node_[ID].yml
files as suggested by @mikeryan above resolved the problem. However, in my case using 2 underscores was not appropriate. I believe the appropriate value is whatever the ID is in the migration config for each node type. Also, I am migrating node revisions so I had to reference each individual node revision migration in*term_node_revision_[ID].yml
.Here are 2 example files after making the changes:
migrate_plus.migration.d6_term_node_1.yml
migrate_plus.migration.d6_term_node_revision_1.yml
Comment #16
chx CreditAttribution: chx at Smartsheet, Migrate Rocks commentedUntil a reproduction case arises this doesn't belong in the core queue. I have no idea whatsoever what migrate plus does which might or might not break the migration process plugin or whatever else.
Comment #17
mikeryanThe problem is D6TermNodeDeriver as described in #14. It generates a migration process plugin referencing "d6_node", which is not a real migration and should be expanded to the actual migrations that D6NodeDeriver generates. The core upgrade UI works anyway because it's preserving nids, which just fall through here, but attempting to use the derived migrations in a custom migration scenario where IDs are not preserved will fail as described.
Comment #18
mikeryanAh, I see now - the core plugin manager expands that d6_node at runtime (expandPluginIds()), so in the scenario here we need migrate-upgrade --configure-only to do the equivalent expansion when generating configuration entities...
Comment #19
Matt B#15 @nrambeck - could you share your custom module code please? It may help me understand this better.
Comment #20
niccottrell CreditAttribution: niccottrell at Transmachina commentedI get the same
Missing bundle for entity type taxonomy_term (/XXX/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php:83) [error]
but my --configure-only generatedmigrate_plus.migration.upgrade_d6_term_node_2.yml
looks a little different (see attachment) specifically:that it says "upgrade_d6_node" rather than just "d6_node" like mentioned in #14.
Furthermore, the output claims that this term is migrated correctly:
Processed 5877 items (0 created, 0 updated, 0 failed, 5877 ignored) - done with 'upgrade_d6_term_node_2' [status]
But later migrations fail like:
Do I still need to edit the
migration:
entry? If so, to what?Comment #21
mikeryan@niccottrell: See comment #14 above. Edit the migration entry replacing upgrade_d6_node with a list of your specific upgrade_d6_node_* migrations.
Comment #22
niccottrell CreditAttribution: niccottrell at Transmachina commentedThanks @mikeryan. Oh, dear. So I have 34 migrate_plus.migration.d6_term_node_XXX.yml files. Not all terms are used by all content types, will it hurt if I just list ALL content types in ALL these config files?
Comment #23
mikeryanNo, just a minor performance impact as it will be searching more map tables than it really needs to.
Comment #26
mikeryanDone - migrations derived from d6_term_node and d6_term_node_revision now expand the references to d6_node migrations.
Comment #27
Matt BSorry to report, but I've tried this with Drupal 8.2.0, migrate_upgrade-8.x-3.0-rc1 and whilst all the vocabularies and terms are imported and available for selection on the node edit form, they have not been assigned to the nodes as they were in Drupal 6. Is this a separate issue?
Snippet from Drush below.
Comment #28
mikeryanThis is the issue reported at #2797057: Migration upgrade_d6_term_node_revision_18 did not meet the requirements. Missing migrations upgrade_d6_term_node_2.
Comment #29
Matt BIt looks like the node terms are correctly expanded, here's my migrate_plus.migration.upgrade_d6_term_node_1.yml
The error message is
but there is a upgrade_d6_node_recording_file.yml ?
Comment #30
niccottrell CreditAttribution: niccottrell at Transmachina commentedShouldn't the filename be
migrate_plus.migration. upgrade_d6_node_recording_file.yml
?Comment #31
mikeryanYes, it should. Looking at your migration .yml files, all of them should have the migrate_plus.migration. prefix, how many are missing it?
Comment #32
Matt BI ran drush cex --destination=/tmp/export and have the following files:
Comment #33
mikeryanI guess I'm confused by your comment #30 - there is a migrate_plus.migration. upgrade_d6_node_recording_file.yml, as expected?
Comment #34
Matt BThe full output of migrate-all --import if it may be of help. Please let me know if there is any other info that would help!
Comment #35
mikeryanAh, that wasn't your comment, never mind...
Comment #36
Matt BI've tried with Drupal 8.2.1, Migrate Plus 8.x-3.0-beta1 and Migrate Tools 8.x-3.0-beta1 - still having the same problem.
Comment #37
Matt BI've followed the instructions here: https://www.drupal.org/project/migrate_upgrade/releases/8.x-3.0-rc1 to create a custom module, and commented out the references to upgrade_d6_node_recording_file in the term_node and term_node_revision yml files, nd it now works. Some warnings and errors, but I believe this is something to do with the recording_file or recording_data content type on my D6 system (possible use of node references), which I can work around if needs be.
Comment #39
drzraf CreditAttribution: drzraf commentedIt was pushed into migrate_upgrade 8.x-3.x
But for people still experiencing the issue (especially the one described by @Marc Angles in comment 10): see #2827867: InvalidArgumentException: Field <taxonomy-slug> is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 472 core/lib/Drupal/Core/Entity/ContentEntityBase.php)
@mikeryan: About the different behaviours between
configure --only
andmigrate-upgrade
(#2653984-14: Drupal 6 term references not migrated #2823414-15: User Profile field values not migrated from Drupal 6) andmigrate_drupal_ui
, is there a centralized issue about this?Comment #40
kubrt CreditAttribution: kubrt commentedI'm experiencing the exact same issue. Nodes are being migrated correctly, vocabularies as well but the term references are not updated.
Any further migration is happy with Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored).
Migration status is happy withy unprocesssed items
No error messages at all.
I've originaly created the migrations using migrate-upgrade --configure-only and then moved them over to my custom module.
Any hints greatly appreciated.
My config migrate_plus.migration.d6_term_node_1.yml looks like this
Comment #41
kubrt CreditAttribution: kubrt commentedQuoting from this article
Why ? Why ?
Is there really no usable way to find out why something is being ignored by the migration process?