I don't intend to work on this myself right now :-/, just letting this be trackable somewhere.

Coming from #721890: Update non-fieldapi -> fieldapi.
Views D7 exposes Field API fields using table aliases that are different from the ones exposed by CCK D6 ('node_data_*', didn't make any sense in D7). --> D6 views will lose their fields in D7.
Views D7 provides a mechanism to dynamically translate old table aliases into new ones ('moved to' property in hook_views_data()).

Exposing those 'moved to' information probably belongs to content_migrate rather than Views module. Cannot be part of content_migrate itself, since the module intended to be uninstalled once D6 fields are migrated.

Possible approach :
- content_migrate sets a $field['d6'] = TRUE property on migrated fields (Field API will preserve this through field_update_field() calls)
- a small dedicated content_views_compatibility (or something) side module just implements hook_views_data() and exposes the 'moved to' data for the old aliases, for each field having $field['d6'] set.

Granted, we won't be able to magically make every D6 views work perfectly in D7 (field formatters, settings for some handlers might have changed...), but at least people wouldn't be obliged to remove old fields, filters, args, re-add new ones, just adjust existing ones.

Comments

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented

Something like this would be very big for the upgrade path.

I would like to add that it should come with an analyze hook; any view still using a 'moved' field can be flagged as a warning, and that would make it easy (using a drush views analyze command that either exists now or exists as a patch) to tell us if the compatibility module can be disabled.

sahuni’s picture

sahuni CreditAttribution: sahuni commented

If I understand well, it's "normal" that actually, after a a successful migration of cck fields and Views, all my old cck fields are missing in my views? It's what this post is about?

Do we have to wait? When are we supposed to upgrade from D6 to D7? It's too early after 1 year of D7?

Or do you think it will never be done? So we must add all that missing things manually inside the view?
How do people manage with a lot of views including a lot of fields, filters etc etc etc. ??

sahuni’s picture

sahuni CreditAttribution: sahuni commented

You don't intend to manage upgrade of d6 cck fields in views?
It's on purpose that we have to re-do all views displays?

giorgio79’s picture

giorgio79 CreditAttribution: giorgio79 commented

Marked #971668: Update views from cck to fieldapi as a dupe of this, there is some nice code example from dereine in that issue, so worth checking out

MM10’s picture

MM10 CreditAttribution: MM10 commented

Just so I understand this correctly- if I upgrade from D6 to D7, and migrate my CCK fields appropriately, I will need to remake all of my views? Or manually rename my fields during views import?

ayalon’s picture

ayalon CreditAttribution: ayalon commented

It's a nightmare, but it's true.

You have to redo all views after migrating your fields.

And I had to go through this nightmare several times...

axle_foley00’s picture

axle_foley00 CreditAttribution: axle_foley00 commented

This is a bit disheartening. We have about 40 websites to convert and some of those could have 4+ views with a variety of displays, some pretty complex that we'd have to convert manually.

Surely there must be an automated way?

drzraf’s picture

drzraf CreditAttribution: drzraf commented
Category: feature » task
Priority: Normal » Major

unbelievable... how did CCK module authors managed to upgrade their own views ?
some custom scripting ? manually ?
If it's not a bug-report then this is a critical task because this makes Drupal update ... painful, to say the least.

sahuni’s picture

sahuni CreditAttribution: sahuni commented

as you said : unbelievable!

Kattia’s picture

Kattia CreditAttribution: Kattia commented

I have the same issue, with my views and fields i think first is to use content_migrate module, migrate all the fields that we need. I found this module helpfull since explain which content type is using the field. I use customphp and this field is not part of cck or the core so I need to install the module as well notice this module is in dev for d7

I export from d6 the views, before import into d7 examples:

node_data_xxxx will be: field_data_xxxx
xxxx_text_value will be: xxxx_text
image_fid will be image
link_url will be link

table for body field:
[node_revisions] -> [field_data_body]

I will keep updating, probably we should create an script to convert views from d6 to d7

subhojit777’s picture

subhojit777
he/him
Primary language Bengali
CreditAttribution: subhojit777 commented

@Kattia thank you

More updates for code conversion

For custom text field:
'field' will be nothing
'table' will be views
Make sure that field content comes under ['alter']['text']
If you have multiple custom fields then make sure their ids are always unique. nothing, nothing_1, nothing_2,... like this.

For custom php fields obtained from views_php module:
'field' will be php
'table' will be views
Make sure that field content output comes under 'php_output' array key and field content value comes under 'php_value' array key.
If you have multiple custom php fields then make sure their ids are always unique. php, php_1, php_2,... like this

drzraf’s picture

drzraf CreditAttribution: drzraf commented
Issue summary: View changes

@Kattia did you scripted that in some way?