Single on/off checkbox labels lost when upgrading to D7 with content_migrate

Mikehues:
We have the same issue. By 'changing fields and content to use integer keys' do you mean the database field type?
i.e. Changing the D6 database field to be an int, and the values to be 1 & 0 rather than yes & no?

This results in broken fields, so I'm bumping it the priority to 'major'.

The problem is in content_migrate_extract_allowed_values where it predefines $allowed_values for list_boolean, and then proceeds to add the existing (string) values to the array. It is at this point that the current field is broken.

What should happen is that it should queue up additional tasks to fix the existing content, like what happens with other field types.

Lets see if this works.

It does several things:

1. Fixes content_migrate_extract_allowed_values() to properly update list_boolean values.
2. In content_migrate_text_field_alter() it keeps a copy of the original values in $field_value['settings']['legacy_values'] so it can be used later.
3. In content_migrate_text_data_record_alter() it swaps out the old values for the new ones, based on the legacy_values array stored earlier.

I haven't tested it yet.

Might it be worth adding an update script to fix the settings for existing sites?

I should also mention that because of the fact the new list_boolean field only accepts integers, the converted data is all reset to 0, i.e. this results in dataloss.

Updated, hoping this grabs the correct values. Also, doh.

This fixes my incorrect use of array_pop instead of array_shift. Also, doh.

This patch is completely rewritten to depend upon #1996770: content_migrate's field-module handling is hardcoded, which really needs to be committed.

This'll work better. *cough*

I'd accidentally included some code for this patch in #1996770, this includes all code needed to fix the checkboxes.

FYI I've finally gotten these two patches to work on my local test bed without any problems, hopefully someone out there will be able to test them and give them the RTBC of approval so that 2.5 years after launch we can have a slightly more reliable upgrade for CCK.

This patch doesn't store the legacy values in the field's settings any more as that turned out to be causing problems. Instead text_content_migrate_data_record_alter() loads the settings again when needed.

Fixed #16, had to load the field specs again as content_migrate_extract_allowed_values() is ran again before the data is migrated.

I've been having this same problem - thank you for tackling this! I am having trouble applying the patch (#17) though. It fails in hunk #3... Any thoughts? Do I need to apply all of the patches in order?

@fender177: You need to first apply the patch from #1996770: content_migrate's field-module handling is hardcoded.

Thanks, @DamienMcKenna, that worked for applying the patch. Much appreciated!

I guess I need to put it through its paces again. Time to find a D6 client and test out an upgrade for them :)

So here is an interesting one for you... I've been documenting the process of upgrading from d6 to d7, which involves starting from scratch/a snapshot. It appears that before I apply this patch, the CCK migrate module is able to migrate filefield/image fields. After the patch, they are listed as unavailable... Thoughts on that?

I think I'm going to migrate all of the available fields with the patched CCK module, revert back to the unpatched version and see if I can then migrate the filefield/image fields.

Thanks for your help thus far!

For issues with the file patch please follow up on #1996770: content_migrate's field-module handling is hardcoded.

I have checkbox migration failing.

I Tried applying cck-n1996770-2.patch followed by cck-n1913072-17.patch as described above.

The field definition looked a bit better in D7 but all values were set to 0. Previous values were a mix of 'on' and 'off'

I've sorted this out with manual fix. I used the patches above to migrate the CCK field to D7 core field, edited the field in D7, then ported the lost data and added the bundle manually. If anyone needs more details please contact me.

Thanks! Committed in 6d662c9. Let's fix any related problems in others tickets.

Hi russellb,

I'm a new drupal dev and I'm running into the same issues above. I've applied patch 17 but the data did not migrate. All values are still set ot 0.

Can you provide more detial on what you did?

1) I used the patches above to migrate the CCK field to D7 core field, (Which ones all of them?)

2) edited the field in D7, (What did you edit, what did you change?)

3) then ported the lost data (What did you use to port the data?)

4) and added the bundle manually. (How did you do this? Where?)

Apologies in advance and Thanks!

Hi ssantaana,

It's a while ago now that I did this port, so my experience is a bit out of date but I will try to help.

Looking at this issue queue, I can see that colan has made a commit, so I would recommend that the first thing that you try is using the latest release of the module that includes the commit to fix this. 7.x-3.0-alpha3 has this new code included, so you should not apply the patches as I described.

Hi colan,

Looks in the patch #17 (what is commited to module) there is typo at content_migrate.text.inc line 173. It is:

$field_specs->global_settings = unserialize($results->global_settings);

Need to be:

$field_specs->global_settings = unserialize($field_specs->global_settings);

@myha: Thanks. Can someone else confirm/test? Patches welcome!

Remarks in #30 seem to work for me. One-liner attached.

Going back to Fixed per #27.

The patch in #32 is a duplicate of #2212961: $result should be $field_specs in text migration