that is the table migrate creates. the settings are:

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.


jenlampton’s picture

Status:Active» Postponed (maintainer needs more info)

The 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.

marcoka’s picture

if 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

jenlampton’s picture

Are you sure the key was correct in your D6 database tables?

marcoka’s picture

the key was wrong. thats what i said.

bigjim’s picture

Priority:Normal» Critical

I 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:




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.

greggles’s picture

Title:Bug with List widgets» List widgets without keys not reflected in field_data_* and field_revision_* tables
Status:Postponed (maintainer needs more info)» Active

Re-stating title and updated status.

Thanks for the debugging and clear description of the problem, jalama.

bdragon’s picture

Status:Active» Needs review
Issue D7
new624 bytes

Looks like core avoids numerically indexing the allowed values array when working with text. So content_migrate is required to do the same.

yched’s picture

Status:Needs review» Fixed
new904 bytes

Committed 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

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

giorgio79’s picture

Status:Closed (fixed)» Active

I 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:

I've got several custom content types in Drupal 6 with type "Text" and "Check boxes/radio buttons" for the widget type. This allows you to create a radio button list of options, and the user selects the appropriate option.

Upon upgrading to Drupal 7, these fields were converted to type "List (text)". This seems to have worked fine for all the existing content, but I tried creating some new content that uses the new "List (text)" fields, and on the node display page, instead of the label for the option selected, I get the numeric value. My "List (text)" options are setup something like this:


The number is the value, and the word after the pipe is the label. What is supposed to happen (and happens for all previous content) is that the selected label appears.

But what is happening for all new content is that the value, the number 0, 1, or 2, is displayed.

giorgio79’s picture

Status:Active» Closed (fixed)

Hiting save on the "Manage Display" screen of each content type after the upgrade fixed this issue for me.

Summit’s picture

Priority:Critical» Normal
Status:Closed (fixed)» Active

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:

I manually modified this blob and replaced each value of "text" with "list", and each value of "text_default" with "list_default". I then cleared the cache, and reloaded a content node page that uses this field. It worked! I now got the list_text label, instead of the list_text value.

This is also valuable info:
The only remaining issue at this point is that when you edit an old piece of content, it will not have the list_text value preselected to what it was previously. You are forced to make a selection. I believe this is because of the issue described in comment #11. Namely, the migrated data has the list_text label, not the list_text value. This could presumably be cleared up by a few database updates, but I haven't gone down that road yet.

#11 is referring to:

I cannot manually modify the Blob, I am on a commercial server...
Does somebody have the MYSQL statement to get this working?

Greetings, Martijn

Summit’s picture


May be this patch: from
works...but how do I deal with already migrated content?

greetings, Martijn

Summit’s picture


I think this patch worked! And I could easily rollback the content using content_taxonomy_migrate.module.
Greetings, Martijn

drumm’s picture

Status:Active» Closed (fixed)

Setting this back to fixed since #1208164: migration from D6 fails for Content Taxonomy fields is tracking the fix.