Is it possible to import a Drupal 6 view into Drupal 7?

There aren't any real problems that we know of. It's a good idea to export copies of your views and save them in case something does go wrong. There may be some tweaks you'll have to make and you should doublecheck all of your views after upgrading.

This is bullshit. Stop sticking your head in the ground: the issue is not fixed. I have the exact same problem: views that work fine in 6-2, got exported there and imported to 7-3, and I get just "field handler tab.xyz is not available" for every single field.

Manually deleting the field in 6 and recreating it in 7 is no option because I'd have to manually recreate every single field in my view.

Can somebody at least give me a clue to the cause of the error message? Google didn't help in the least. I saw some mention of column aliasing but there are no aliases in the view export.

This is bullshit. Stop sticking your head in the ground: the issue is not fixed.

No comment is the best comment here.

If you want to have a proper update you should export your views to code, see advanced help, which is part of views.
Then you should use content migration to migrate the cck fields. But as it seems to be content migration doesn't update there views definition, see #1229192: Implement Views compatibility layer in a side module ? but as it's written there this is somehow out of scope of views itself.

There are no CKK fields to export.

The view is generated with Table Wizard, in Drupal 6 of course (because there are far fewer working tools for Drupal 7 than there were for Drupal 6) and works perfectly fine in Drupal 6 + Views 2.

But export there and import in Drupal 7 + Views 3 imports nothing. I can start again from scratch. And it's way harder than it was for Views 2. That's progress.

edit: bonus: Views 3 has no documentation (yet?).

@bartl
As i explained the cck fields still have to be converted, as long there nothing happens (and you can help there) nothing can be done in the views.module. Please don't expect that any software you use has any feature you need.

Of course not! But in most cases of serious use of Drupal this difficulty implies:
- Rework a site practically from scratch
- Test each detail of the site
- or worse... Take the decision of freezing the site in drupal 6.
Drupal is the best generic CMS, I think that this problems of migration should be considered as a priority.
Is my opinion.
Obviously the problem is the change in the cck fields name, but I think the solution is very easy from the views module point of view: asking and proposing a change in the names of the fields when a migration is detected!!!! This will save a lot of time for administrators.
Best regards.

Yeah right very easy. Just for example table names are changing totally different from d6 to d7, man this has to be very easy to convert. All this lazy views contributors. What do they even think?

Well, the table names change in a predictable way. content_field_widget becomes field_data_field_widget, with the added complication that the content_type_something tables are gone.

Many D6 sites have dozens of Views with many CCK fields in them. Without some upgrade path for converting these Views, rebuilding all these views could well be by far the most time-consuming aspect of a D7 upgrade if you don't have a lot of custom code. I'm not saying that it is trivial. But if CCK has an upgrade path to Fields, it seems that it should be possible for Views a well. I'm not saying that it is trivial or that you maintainers have nothing to do. But if I had a client with a site with a heavy dependence on Views, I would recommend not upgrading as the cost and difficulty of exactly duplicating the Views would be prohibitive.

One thing I haven't even delved into yet: what about Views templates: how much has their internal content changed?

It's though still a problem of cck, see #1229192: Implement Views compatibility layer in a side module ?

@drm and jparets - Please post your "easy" patch that will upgrade my site for me. Much appreciated.

I have the same issue with my views and fields, what i did is use content_migrate module, migrated all the fields. I found this module helpfull since explain which content types are using the field.

I export view from d6, before import into d7 replace

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 but cases will vary it will depend of the field

fields are one thing, but I have a lot of broken handlers in my views that aren't just cck->fields naming conversions.

when you export the view into drupal 7 what are the errors that you see? As far as i know handlers didn't change

I was using workflow module, and that broke in a few places. Had to apply a patch to get that working.

VBO also has a different format in D7 as it is no longer a display type.

The way that taxonomy terms are implemented is a little different in some respects which broke some handlers.

Views OR no longer exists as it is being handled natively.

The hooks for defining custom handlers are slightly different - one of them is no longer required.

Can no longer format images to just display the URL as that imagecache formatter was not ported to image styles in core, so those need to be reworked.

That's all I have so far, but I'm sure there's more... I've only been looking into it for about a half day.

Oh, Views Bonus for exporting things in XML format no longer exists and has been superceeded with Views Data Export, so my views that were using bonus pack to do xml exports need to be rebuilt and my tpl.php files updated accordingly.

Just thought I'd add my comments/experience to this issue.

I have a couple of views on a D6 site which need to be exported across to a D7 site. Normally an upgrade would be the solution but for whatever reason this instance its an export/import - which can happen.

First thing you need to ensure is that all of the content types, fields + views plugins are correctly named on both sites.

Then when I went to export the view from D6 to D7 I was met with the same errors everybody else was receiving. xxxx field is missing etc.

It was strange because the fields I manually added on the D7 site was named exactly the same but its just that views throws in different naming for each of the fields.

An example for a field:

'field_referral_callback_datetime_value' => array(
    'label' => 'Call Back Date Time',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'html' => 0,
      'strip_tags' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 0,
    'label_type' => 'widget',
    'format' => 'medium',
    'multiple' => array(
      'multiple_number' => '',
      'multiple_from' => '',
      'multiple_to' => '',
      'group' => TRUE,
    ),
    'repeat' => array(
      'show_repeat_rule' => '',
    ),
    'fromto' => array(
      'fromto' => 'both',
    ),
    'exclude' => 0,
    'id' => 'field_referral_callback_datetime_value',
    'table' => 'node_data_field_referral_callback_datetime',
    'field' => 'field_referral_callback_datetime_value',
    'relationship' => 'none',
  ),

Example for Sorts:

$handler->override_option('sorts', array(
  'field_referral_serial_value' => array(
    'order' => 'DESC',
    'delta' => -1,
    'id' => 'field_referral_serial_value',
    'table' => 'node_data_field_referral_serial',
    'field' => 'field_referral_serial_value',
    'relationship' => 'none',
    'override' => array(
      'button' => 'Use default',
    ),
  ),
));

What I then did was exported a D7 view with similar fields and just compared the two to find that you need to remove the "_value" at the end of the field names and replace "node_data" for "field_data".

My import then looked like:

Fields:

 'field_referral_callback_datetime' => array(
    'label' => 'Call Back Date Time',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'html' => 0,
      'strip_tags' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 0,
    'label_type' => 'widget',
    'format' => 'medium',
    'multiple' => array(
      'multiple_number' => '',
      'multiple_from' => '',
      'multiple_to' => '',
      'group' => TRUE,
    ),
    'repeat' => array(
      'show_repeat_rule' => '',
    ),
    'fromto' => array(
      'fromto' => 'both',
    ),
    'exclude' => 0,
    'id' => 'field_referral_callback_datetime',
    'table' => 'field_data_field_referral_callback_datetime',
    'field' => 'field_referral_callback_datetime',
    'relationship' => 'none',
  ),

Sorts:

$handler->override_option('sorts', array(
  'field_referral_serial_value' => array(
    'order' => 'DESC',
    'delta' => -1,
    'id' => 'field_referral_serial_value',
    'table' => 'field_data_field_referral_serial',
    'field' => 'field_referral_serial_value',
    'relationship' => 'none',
    'override' => array(
      'button' => 'Use default',
    ),
  ),
));

Essentially this probably isnt the best method but its worked for me in this small instance and could be helpful to others. Ideally look at a test D7 view export to see what the syntax should look like.

EDIT:

I've noticed that not all values have been imported but the fields themselves have been. You may need to do some manual reconfiguring.