Upgrade path for D6 CCK fields

It is no longer too early to be thinking about this, in fact it is probably one of the highest priority items at this point.

Some initial thoughts:

The CCK to Field API upgrade process will run in D7. We will therefore need D7 code that understands at least the D6 CCK content_* tables. This includes at least the D6 CCK CRUD functions to identify which fields and instances exist.

We will have a loop that iterates through the D6 CCK fields and instances and creates D7 fields and instances. We'll have to assume that all node types have been upgraded already.

We will have D7 field modules but not D6 field modules. Not all field types will map 1:1. For example, a D6 text field with allowed values will be converted to a D7 list field. This suggests that each D7 field module will need to register itself as being able to import certain kinds of D6 fields, and it will have to embed whatever info about the D6 CCK layout is necessary to do the upgrade. In fact this will probably look a lot like the "Field Conversion" logic for field_update_field(). So when we loop through all the D6 CCK fields, we'll call hook_field_upgrade_from_d6_to_d7($d6_field). In the allowed values case, perhaps list.module will implement that hook and handle any text or number fields with allowed values.

I guess hook_field_upgrade() can both create the D7 field and migrate the data into it. Or perhaps those should be separate passes/separate loops.

I do not think this can be a normal hook_upgrade_N() function because it is unlikely that all field modules a site is using will be available to upgrade all at once, so the upgrade process will require multiple passes. Thus, it should be a module with a UI, perhaps showing all the D6 fields & modules, the D7 fields and modules they map to, and the status of each (upgraded/not upgraded). As Karen points out, we have the luxury of being able to keep the D6 data tables forever, so the upgrade can be re-run multiple times until it is right. This also means that any errors during upgrade can be handled by just deleting the D7 field(s) and running the upgrade again.

subscribing

Karen had started a list of items for the upgrades, that she left in cck.install (HEAD).
I took them out while rolling #516138: Move CCK HEAD in core and posted them as a wiki page on g.d.o

subcribing.

This issue is about all upgrade path D6->D7 or only about the upgrade path of cck/field?

We need better title or a different component.

Better title.
Thing is, we now know this will need a process separate from update.php and possibly a UI (see #3), and thus will need to be provided in a contrib module.
As such, this does not fully belong to the core queue.

This seems like a duplicate of #394720: Migrate profile module data to field API

Please set as duplicated if that is so.

Nope, this issue is for D6 CCK fields, not user profile.

The reason for posting this in the core issue queue is because we may need the assistance of core in making things work even if the upgrade path is handled by the contrib module. Plus as a reminder to everyone that even tho fields are in core in D7, the fields you had in D6 will only be migrated to their D7 versions by CCK contrib, core will NOT be doing any field migration. I suspect that will be a point of confusion for a lot of people.

As I mentioned in the original post:

I realize CCK is contrib but the last time we moved part of CCK into core we found there were core implications for getting the upgrade working right and I assume the same will be true this time.

So this issue is to discuss what needs to happen and whether or not we need any changes to core to make that work. You could certainly make the case that it does not belong in the core queue unless we find we need core fixes, so I'll defer to whatever seems best about that, but I also think it is good to keep this in a place where it will get lots of attention. And I would make the case that anytime core takes over all or part of a contrib module that core has some responsibility to make sure the transition goes smoothly, and you can't tell if it will until the upgrade path has been written and tested.

@Karen: Right, agreed.

It should also be a release blocker IMO.

If a CCK_to_D7 contrib module isn't ready the day D7 ships, it means people cannot upgrade D6 sites on day 1, but can start fresh D7 sites. I'm not sure this qualifies as 'release blocker' (or that drieschick will delay a release for this reason when the day comes)

My 2 cents:

1. I think this does definitely qualify as a release blocker, and is in fact the very definition of one.
2. I think anyone who thinks this upgrade path shouldn't be part of core itself is smoking a particularly string variation of crack. Can someone explain why this makes sense?

Tricky and difficult code is exactly where you want to leverage the advantages of the Drupal core queue with multiple eyeballs on it. I've no idea why it would be desirable to push this code to a dark corner in contrib.

"2. I think anyone who thinks this upgrade path shouldn't be part of core itself is smoking a particularly string variation of crack. Can someone explain why this makes sense?"

I don't see why we want to teach D7 core the intricacies upgrading the D6 Date contrib module to the D7 Date contrib module which isn't even written yet and may not be before D7 ships. Sure, core will provide some mechanisms for an upgrade path, and we need to validate that it is sufficient before release. But we can't expect a single magical CCK to Field API upgrade path to exist separate from all the contrib modules that provide CCK/Field API functionality.

The "more hands and eyeballs" argument is IMO the only one towards CCK_to_D7 in core. Other than that, I really don't see why core should burden with this.

- CCK D6 is contrib, core D6 has no fields to migrate. It's perfectly fine if you need a contrib module to get your contrib D6 fields after switching to D7
- as Barry outlined in #3 and #16, the upgrade cannot be a regular, one-off process running 'silently' along with other update.php updates (because core or even one single contrib module can't predict how to migrate date fields or wicked_contrib_field_type fields). The upgrade process needs to be iterative, provided by a cck_upgrade module that exposes a page with the list of D6 fields that it's able to migrate given the current state of enabled modules. Press 'submit', eligible fields are batch-migrated.
Until date.module D7 (or a submodule) is enabled and implements hook_cck_upgrade() or whatever, stating that it knows how to migrate date fields, your D6 date fields are not visible in D7. Come back to the 'migrate fields' page when you have the module.

tag

tagging :)

s.u.b.s.c.r.i.b.e. m.e.

tag