Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
http://screensnapr.com/v/fcWwOG.png
that is the table migrate creates. the settings are:
http://screensnapr.com/v/Rhkvf9.png
as the keys are saved, here 0 and 1 this will not work. it can be easily fixed manually but wanted to put this infos somewhere.
Comment | File | Size | Author |
---|---|---|---|
#8 | fix-text-list-migration-1351880-8.patch | 904 bytes | yched |
#7 | 1351880-fix-text-list-migration.patch | 624 bytes | bdragon |
Comments
Comment #1
jenlamptonThe images you posted are broken or missing. Can you describe the bug in words? Without an explanation of what you are experiencing, no one will be able to help.
Comment #2
marcoka CreditAttribution: marcoka commentedif you migrate list fields, they key in the table is wrong, and so nothing is set to the list widget. to see that you can take a look at the fields tables after the migration
Comment #3
jenlamptonAre you sure the key was correct in your D6 database tables?
Comment #4
marcoka CreditAttribution: marcoka commentedthe key was wrong. thats what i said.
Comment #5
bigjim CreditAttribution: bigjim commentedI can expand on this, and confirm it. I have to say if you don't have DB/SQL chops this is a total show stopper for content migration for D6->D7.
The issue is the content_migrate_extract_allowed_values() function is adding numeric keys to fields the allow values list (despite the fact that the instructions in D6 & D7 say it is not necessary to add a key to the allowed value list). This all seems well and good and well intended.
So a list like:
Joe
John
Andy
Karen
Dries
Angie
becomes:
0|Joe
1|John
2|Andy
3|Karen
4|Dries
5|Angie
The problem is the data in the *_value fields of respective field_data_* and field_revision_* tables is not being updated to reflect the new keys, do the *_value fild remains Joe, John, etc.... While the input field is expecting a numeric key.
Comment #6
gregglesRe-stating title and updated status.
Thanks for the debugging and clear description of the problem, jalama.
Comment #7
bdragon CreditAttribution: bdragon commentedLooks like core avoids numerically indexing the allowed values array when working with text. So content_migrate is required to do the same.
Comment #8
yched CreditAttribution: yched commentedCommitted the attached patch :
- in D6 we never autogenerated numeric positions, the value is always the string itself
- fixes an additional problem with '0' being discarded as an allowed value
Comment #10
giorgio79 CreditAttribution: giorgio79 commentedI hope you don't mind if I set this back to active as I tested migration with this patch, but still having an issue with this. The node display shows the key instead of the label, while during node edit the label is shown fine.
Here is a commenter with a similar experience:
http://drupal.org/node/1285486#comment-5867294
Comment #11
giorgio79 CreditAttribution: giorgio79 commentedHiting save on the "Manage Display" screen of each content type after the upgrade fixed this issue for me.
Comment #12
Summit CreditAttribution: Summit commentedHi,
Setting this to active while I think this is still active right?
For me not solved using latest CCK migrate. Still the values of the term reference fields are shown on Viewing a node, but not shown while editing the node.
Setting this to active again:
I think something like this has to be done by a SQL statement:
This is also valuable info:
#11 is referring to: http://drupal.org/node/1285486#comment-5477518
I cannot manually modify the Blob, I am on a commercial server...
Does somebody have the MYSQL statement to get this working?
Greetings, Martijn
Comment #13
Summit CreditAttribution: Summit commentedHi,
May be this patch: http://drupal.org/files/content_taxonomy-migration-fails-1208164-16.patch from http://drupal.org/node/1208164#comment-6572690
works...but how do I deal with already migrated content?
greetings, Martijn
Comment #14
Summit CreditAttribution: Summit commentedHi,
I think this patch worked! And I could easily rollback the content using content_taxonomy_migrate.module.
Greetings, Martijn
Comment #15
drummSetting this back to fixed since #1208164: migration from D6 fails for Content Taxonomy fields is tracking the fix.