Upgrade from 6.x-2.x to 6.x-3.x: document necessary steps, possible workarounds needed

I would recommend that you delete the old panels directory entirely, since the directory structure changes between Panels 2 & Panels 3. Other than that, though, I think you should be set. I enabled CTools before I ran update.php, but I don't know if that's necessary.

Btw, you might want to make copies of your panels tables in the DB, just in case you have to rollback to Panels 2.

Other potential things to watch out for:

- Make sure to enable Views Content Panes if you use Views in your panels.
- Make sure that you don't have any other modules enabled that override functions like taxonomy_term_page(). So far, I've found Taxonomy Manager, RDF, and Taxonomy Translation (i18ntaxonomy) do that.

I'll add more items to this list as soon as I manage to get the upgrade fully working myself. Some of my panels aren't working on a site that is a copy of my production site. However, they did work on a stripped-down version of the site which I was using to test the upgrade process itself. So I suspect there are other module conflicts I haven't worked out yet.

My issue #512882: PHP error: 'panels_page_access_handler' is not a valid callback illustrates why it's important to fully remove the old Panels directory before upgrading. If the panels_page module is still lying around, it can cause problems.

Ok, I fixed my panels like /help which weren't showing: it required me to export & reimport them after changing the style settings for the rows so they didn't say 'style' => -1. I'll post a bug report for that.

Now I just have to figure out why one of my panels is not showing up as a regular panel, but is showing up in the "advanced panel" list, where you can have multiple task handlers.

Hope this has been helpful to you in your own upgrade process.

Changed the title to make this a little clearer.

Btw, I just opened the issue relating to my 'style' => -1 bug: #515072: Loading admin/build/pages gives "A script on this page may be busy" JS error multiple types w/large # of panels. Anyway, I'm feeling pretty good about the Panels 3 upgrade now, because I discovered the final issue I mentioned (why the "advanced panel" isn't showing up) was actually because it had the 'style' => -1 in it.

I also heard from merlinofchaos just now that there will be a new beta of Panels 3 released in the next few days, so you might want to wait till then to upgrade, if you haven't already.

You may not encounter all the issues in upgrading that I have, but I wanted to give them here just in case. So, to recap, here are the upgrade steps that were required for me:

1) Delete all old panel module files from the sites/all/modules directory.
2) Unpack the new panels files & CTools files in sites/all/modules.
3) Enable CTools & the delegator.
4) Run update.php.
5) Enable all panels modules (& Views Content Panes if you use views in your panels.)
6) Make sure you don't have any modules enabled that override pages like taxonomy/term/%, as this will cause conflicts with the Delegator (see issue #469124: taxonomy/term/% overwritten by another module).
7) Export, correct errors, & reimport panels if they still aren't showing up properly (as per my issue #515110: Panels with 'style' => -1 in exported code will not display (after upgrade from 6.x-2.0-alpha to 6.x-3.0-beta2)).

If there's anything still missing from this list of steps, please let me know. Possibly something like this (but expanded) should go in the README.txt for Panels 3. I've already added it to the drupal.org online Panels 3 documentation at Upgrading from Panels 2 to Panels 3.

Changed this to a documentation task to focus people's energies on the newly-created Upgrading from Panels 2 to Panels 3 page.

What functions would auto-enable panels and tasks as a post-upgrade process from scripting an update? I want to update a big site with Drush and the only issues I am having is getting Ctools to upgrade through it, and subsequently, Panels to self-enable. Right now when I update, the panels are all disabled. I am writing a script that will run after I do drush, but can't seem to find an appropriate function to enable panels.

    drupal_install_modules(array('panels'));

Yes, but does that also Enable the node_view, node_edit etc overrides? It starts out Disabled after an upgrade.

ahh, hm. You probably need to variable_set() those specifically. There's a 'more correct' way to do it but it requires loading a bunch of data you really don't need just to enable system pages. Look in the plugin/tasks/*.inc files and look at the enable callback to see what variable it sets.

Ok I'll check that out thanks

I was able to upgrade from 6x-2.0-alpha3 to 6.x-3.1 quite easily by doing the following:

1) Download and copy over CTools
2) Enable CTools, Page manager, Views content panes
3) Delete the Panels directory and copy over the new 6.x-3.1 version
4) run update.php

Done!
Thanks for this awesome module!

Okay, so the enabling worked with variable set.

variable_set('page_manager_user_view_disabled', 0);
variable_set('page_manager_node_view_disabled', 0);

The next thing that needed addressing was assigning CSS ID's, classes, and updating the panel panes that use CCK Fields for display.

I have two testing sites, one I configured manually, and one I did the autoupdating on. I figured I could just do a mysqldump of the panel tables and import those, and have all those settings preconfigured.

When I go and edit a panel, the Content information is missing.

--tables page_manager_handlers page_manager_pages page_manager_weights panels_pane

Did I miss one?

You should use the bulk export to export handlers and pages, and stick them in a module.

Okay, I did that. I tried to follow the ctools example module, but couldn't figure out how to import multiple page variants of node_view.

I used:

function site_update_ctools_plugin_api($module, $api) {
  if ($module == 'page_manager' && $api == 'pages_default') {
    return array('version' => 1);
  }
}

and named one of the inc files mymodule.pages_default.inc. Then I went to Pages > node_view edit, and the variant isn't there. I believe I am missing a step.

I wish you hadn't changed the subject of the issue I created, since it was on documentation. Oh well.

Sorry, that wasn't my intent. I tried looking through the issue queue but I am not exactly sure what it is I am looking for. I just want to find out how to import node_view variants. Could you point me to some issues and get me in the right direction?

Taxonomy Translation causes a conflict with the CTools module called Page Manager which handles path overrides for Panels 3. I believe you can't have both enabled at once and expect both to work. You either have to use one or the other to display the term page.

Look at the information below which says something like "Required by" & then disable those modules first.

It would involve a change in how Drupal handles dispatching page requests to particular functions (i.e., it's pretty core). Maybe merlin has some thoughts on it...