Content copy destroys field settings

For nodereference, at least, the problem is that the exported array of referenceable types looks like:

array(
  'page' => TRUE,
  'story' => FALSE,
);

instead of

array(
  'page' => 1,
  'story' => 0,
);

I dug back through the code to see where those values are getting skewed, and got all the way back to content_field_instance_read(). When serialized arrays are pulled out of the database they are coming out with the boolean rather than numeric structure. That then fails to import correctly.

This affects $field arrays wherever they are used, and undoubtedly could be having some detrimental effect on allowed values lists and optionwidgets checkboxes, too.

We have to force those serialized arrays to be numeric, but I have no idea how to do that.

I'm bumping this to critical because I think this problem is more far-reaching than breaking some fields in Content Copy

OK, here's what I found so far. This is *not* a general problem of data in the $field array getting garbled, it is specific to Content Copy (whew!)

However, the current way that Content Copy works has a critical problem because when drupal_execute() is run on a nodereference field, it garbles the values as noted above, and then saves that result, so not only is the export wrong, the original field settings have been destroyed. You have to go back and edit the settings manually to reset them.

As an example, create a content type with a nodereference field that references a couple other content types. Save it. Then export that field. Go back and check the settings on the field after your export and all the referenceable types selections will be missing.

I tried following this through to figure out exactly where it was getting garbled, but couldn't find it and gave up. However I found I can make it work right by force-feeding the current field values to drupal_execute() instead of allowing it to create its own.

I want to do a bit more testing to be sure it's working right, but I'll commit this shortly.

And this is another reason why we need to get rid of drupal_execute on the export (we already got rid of it on the import). I think we'll still need it to create the content type, but we could use our API from that point on.

I don't have the time or energy to fix this now, though, so I'll focus on the quick fix above.

Renaming.

I committed this fix.