Problem/Motivation

Now that Views is in core, it behooves migrate_drupal to provide an upgrade path for any views defined in a D6 or D7 site.

Proposed Resolution

Views are complicated, but it still looks reasonably straightforward to pull them from a D6/7 database and migrate them to config entities.

One complicating factor is that views can be stored in the database or in code. If they live in code, they don't live in the database. I talked briefly about this on Slack with @effulgentsia, and he said: "i think migration instructions of "get your Views (and other "features") into the db, then run migrate" is reasonable." I agree with this, but other options are welcome. One thing is certain -- views stored only in code will not be visible to migrate_drupal.

Remaining Tasks

  • Figure out how to handle views in code
  • Write the migration(s) and tests
  • Review and commit

Comments

dawehner’s picture

I remember that chx had some code in the sandbox at some point.

phenaproxima’s picture

mikeryan’s picture

Some initial thoughts on the general case of migrating stuff embodied in code on the source side: #2397849: Export migration configuration via services.

Sree’s picture

'web services' might be a case to consider here in this scenario

phenaproxima’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Active » Postponed

Views migration is something we want to do, but the only code for it is in the IMP sandbox and it needs to be thoroughly updated, tested, and refactored. We're not going to get to it by 8.0, and we shouldn't try. I think this is an appropriate 8.1 target.

iantresman’s picture

I think this is relevant (because six times as many people use Views 6.x-2.x than are using Views 6.x-3.x):

dawehner’s picture

Well, I still think we should fix the one issue for views 6.x-3.x and then provide an upgrade path and don't support an update path for 6.x-2.x,
but well I fear I'll be alone with that opinion.

Vayira’s picture

Hi I'm only a humble user rather than a developer, but the issue of update path for views 6.x-2.x is a game changer for me. If there is no easy way to move my sites from 6 to 8 I will just keep hanging on to the bitter end because to rebuild the views, cck, the theme & everything from nothing would be many weeks' work. If it is not broke I really don't want to spend hours of my life fixing it so I will just stay with 6 which does exactly what I wanted it to do and which took me a long time to develop bit by bit. I imagine there are many others in the same boat as me. Have mercy on us!

dawehner’s picture

I'm pretty convinced that the same problem you have with the 6.x-2.x to 6.x-3.x migration you'll have when you migrate from 6.x-2.x to 8.0.x directly

iantresman’s picture

Not only is Views the top most popular module, six times as many people use Views 6.x-2.x than are using Views 6.x-3.x. If we don't provide an upgrade path from Views 6.x-2.x we'd be preventing most people from migrating.

dawehner’s picture

Well, the update path from 6.2 to 6.3 mostly works (99%), then I don't see a reason why we should support both versions.

iantresman’s picture

Forcing people to upgrade from Views 6.x-2.x to 6.x-3.x first, is an extra hurdle which most users have already decided not to do, because they are running a mature stable web site. Upgrading to Views 6.x-3.x is a one-way option, which may be difficult to remedy if it goes wrong.

Migrating from Views 6.x-2.x or 6.x-3.x to Drupal 8, ensures that people have a reliable stable web site if something goes wrong, and because Drupal 8 is undergoing active development, is more likely to be fixed, and more quickly, than if a Drupal 6 upgrade to Views 6.x-3.x fails.

Issues regarding the upgrade path from Views 6.x-2.x to 6.x-3.x have been noted on the Views home page since May 2012 and has not been resolved since that time. We don't know whether 99% of sites will be OK, or whether 80% will be OK with a one in four chance of breaking a site.

I think that if you want people to jump on board Drupal 8, then you must make it easy for most people to migrate. Most Drupal 6 sites use Views 6.x-2.x.

dawehner’s picture

@iantresman
I recommend you to spend the energy in solving problems, rather than complaining about the status quo. We need to solve the pager migration issue, its how it it.

darol100’s picture

Status: Postponed » Needs work

Drupal 8 already have a stable release. We should start considering on adding a migration path for D8. Moving it to "Needs Work"

geneatwell’s picture

I have a Drupal 6 site with Views 6.x-3.2 installed and working properly. I've duplicated the site and have a freshly installed Drupal 8 multi-site ready to use. How can I volunteer using my current set up to test patches or write documentation for Views? I've previously attempted to migrate the site using the web interface and Drush 8 with two different installations of Drupal 8 and had no luck concerning Views. Please point me in the right direction.
Thanks

quietone’s picture

Issue tags: +migrate-d6-d8, +migrate-d7-d8

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

heddn’s picture

I would question the validity & do-ability of upgrading views. Too often there are field renames when upgrading, merging of content types, over-all site re-architecture, etc. It seems like a fairly reasonable guess that we'd spend a lot of time writing something, but then there would be very few installs that use the views upgrade path. Not to mention the technical impedance of views plugins that are renamed; extensions to views not being necessary or available (views_conditional, bef, etc), views being altered, and much , much more.

Someone will come along and say an upgrade path is terribly important because they have 953 views that have to be upgraded and it is too much work to do manually. My reply would be that of those 953, they could probably do a pretty good job of re-architecting and reducing that number. And they'll be able to do it with all the new wonders of D8 Views. An upgrade path is probably going to only help with the super-simple views, which were only going to take minutes to rebuild anyway. So just accept it, an upgrade from D6/D7 is going to mean work in rebuilding views.

I'm highly tempted to bump this down from a major, for the reason of my arguments above.

mikeryan’s picture

Category: Task » Feature request
Status: Needs work » Active
dawehner’s picture

My hope with a potential views upgrade path was to migrate in a state where we have broken handlers etc, but at least the view itself is renderable and outputs something in some form or another. Just like themes are also not migrated, views are often part of just the output layer of a site.

In general though I agree, migrating a view is a hell lot of a task, especially because things like the d6->d7 image formatter changes.

mikeryan’s picture

Priority: Major » Normal
Status: Active » Postponed

After careful consideration by the migration system maintainers, and consultation with xjm (D8 Release Manager), we've decided that migration of legacy views will not be supported in Drupal 8 core for the initial stable release of the core Migrate suite. heddn's previous comment lays out many of the specific challenges this support would face. Simply put, a fully complete automated migration path for views is not possible, and implementing what is possible would take too much time and effort away from more tractable migration work only to arrive at a situation where we end up saying "views migration is supported, except for views defined in code, and views which use these plugins, and views based on that table, ...". A partial solution is not suitable for core.

That being said, dawehner has started a migrate_views project in contrib - we would encourage those who are motivated to tackle this difficult problem to help out there. A contributed module can more flexibly attack the issue incrementally, for example starting with support for simple node views and enhancing the support from there over time.

Thanks for all your input.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.