If you try to import into the D6 version a field export created in D5, it will totally fail because the field structure has changed. I did some playing around with this and found a way to get a D5 to D6 import to at least partly work -- you still need to visit the field afterward to be sure all the settings got picked up correctly, but it gets most things right and it's better than creating everything from scratch.

I made a patch that allows this. This is similar to what we ended up with for Views1 to Views2 imports -- the import saves time and gets you partly there but you still need to edit the imported view to be sure everything is set up correctly.

@yched, what do you think about including this?

CommentFileSizeAuthor
content_copy.module.patch2.31 KBkarens

Comments

yched’s picture

yched commented

I'm not sure I see the exact scenario where export from D5 / import to D6 would be needed, and would have had no problem in calling this 'unsupported'. But if the code works, well, why not.
I'd feel safer if there was a way to make definitely and explicitly sure that this branch of code will be run on D5 exports only, thus not messing with the regular (and more frequent) D6->D6 workflow we currently have. Reading through the patch, I can't convince myself this is the case. Maybe it's just that messing with $field arrays makes me nervous (although you're more familiar with this than I am) :-)

Perhaps also there's no 100% sure and obvious way to tell a D5 export from a D6 export. In this case, we could append a "$content['export_version'] => 6" string in D6 exports and wrap the code in the patch around a if (!isset($content['export_version'])) { check. What do you think ?

karens’s picture

karens commented

I originally saw no reason for this, and then ended up needing it as a quick way to set up some test sites. So it's not critical and I can leave the code in my own copy.

It's true that you can't be 100% sure that it's coming from an older version, I just make the assumption that if you're missing a couple fields that would be in a D6 export it's coming from D5. This is not bullet-proof by any means, even if we do add a way to be sure it's an import from another version.

Let's just leave it sitting here for now. If no one else chimes in that they need this capability, we can leave it out.

BTW, I ran into something that might be a bug in the current code but haven't had a chance to investigate more. The 'active' flag doesn't get set when you import the D5 fields and we need to be sure that gets set. I wanted to confirm that a D6 to D6 import gets that field set, so a TODO is to confirm that that happens correctly in a D6 import.

yched’s picture

yched commented

Well, the last export / import attempts I made resulted in fields that seemed to work pretty normally, so I'd expect the 'active' flag gets set OK. Is there any specific edge-case you have in mind ?

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

Thanks for this! I've been Googling around trying to figure out how I was going to avoid redoing a content type that has like 30 fields on it and I'm hoping this will give me a good start. :)

Michelle

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

Well, the patch applied but I keep getting this error:

"The following modules must be enabled for this import to work: text, optionwidgets."

They are both enabled and I've tried re-installing a couple times and even tried the dev and no luck. I just get the same error. Did the module name change internally or something that it's not finding it?

Michelle

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

FWIW, I just commented out the error check here and the import worked just fine:

  if ($not_enabled) {
    form_set_error('macro', t('The following modules must be enabled for this import to work: %modules.', array(
        '%modules' => implode(', ', array_unique($not_enabled))
        )));
  }

So something in there is incorrectly thinking the modules are not enabled when they are.

Michelle

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

Is this patch still relevant?

sarjeet.singh’s picture

sarjeet.singh commented

thanks "KarenS".

karens’s picture

karens commented
Status: Needs review » Closed (won't fix)

Too old now. I don't have a good D5 installation any more to test something like this.

bzsim’s picture

bzsim commented

Was having the same problem bringing in content types from 5 to 6. Wouldn't let us because of missing modules like field_image, etc. that we created. So we installed the patch and that helped a little, although now we are getting the same error Michelle received: The following modules must be enabled for this import to work: text, optionwidgets. Yet they are enabled. Guess we'll try commenting that line out too.

I may be naive, but I can't help but wonder why version 6 was developed to be so incompatible with version 5, making it very difficult on us non-programmers to upgrade. I hope going from 6 to 7 is a lot easier.