Upgrading from Drupal 5 to 6 is giving me too much pain

vvanaparthy - October 11, 2008 - 04:02

Dearest Colleagues,

I am currently running Drupal 5.10. I want to upgrade it to Drupal 6.4. Here are my observations. I would appreciate if some one could shed some light on my plight.

So here is the Procedure I follow:

1) Upgrade the Contrib Modules to the latest versions available.
All success until this point

content module
Update #1009
    * ALTER TABLE {content_field_hardware_appliance_types} ADD INDEX (nid)
    * ALTER TABLE {content_field_virtualization_product} ADD INDEX (nid)
    * ALTER TABLE {content_field_interests} ADD INDEX (nid)
    * ALTER TABLE {content_field_potential_purchase} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_audience_tax} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_dev_status_tax} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_solarea_tax} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_website_url} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_compress_size} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_alloc_mem} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_vmw_tools} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_os} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_short_desc} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_username} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_password} ADD INDEX (nid)
    * ALTER TABLE {content_field_vmware_va_applications} ADD INDEX (nid)
    * ALTER TABLE {content_type_company} ADD INDEX (nid)
    * ALTER TABLE {content_type_optional_questions} ADD INDEX (nid)
    * ALTER TABLE {content_type_page} ADD INDEX (nid)
    * ALTER TABLE {content_type_story} ADD INDEX (nid)
    * ALTER TABLE {content_type_tou} ADD INDEX (nid)
    * ALTER TABLE {content_type_vmware_community_va} ADD INDEX (nid)
    * ALTER TABLE {content_type_vmware_partner_va} ADD INDEX (nid)

Update #1010

    * No queries

panels module
Update #5215

    * ALTER TABLE {panels_object_cache} CHANGE COLUMN data data longtext
    * ALTER TABLE {panels_page} DROP INDEX name_2
    * ALTER TABLE {panels_object_cache} DROP INDEX {panels_object_cache}_idx
    * ALTER TABLE {panels_pane} ADD PRIMARY KEY (pid)

Update #5216

    * ALTER TABLE {panels_pane} ADD COLUMN shown int(1) DEFAULT 1 AFTER subtype
    * ALTER TABLE {panels_display} ADD COLUMN title varchar(128) AFTER cache
    * ALTER TABLE {panels_display} ADD COLUMN hide_title int(1) AFTER title
    * ALTER TABLE {panels_display} DROP COLUMN name
    * ALTER TABLE {panels_pane} ADD COLUMN visibility text AFTER access

Update #5217

    * ALTER TABLE {panels_page} ADD COLUMN switcher_type varchar(128) AFTER no_blocks
    * ALTER TABLE {panels_page} ADD COLUMN switcher_name varchar(128) AFTER no_blocks
    * ALTER TABLE {panels_page} ADD COLUMN switcher_options longtext AFTER switcher_type

Update #5218

    * Update #5218 only has changes for PostgreSQL. There are no updates for MySQL databases - since you're running MySQL, you should consider this update successful.

2) Disable all the custom , contrib modules and custom themes.
3) Take a fresh copy of Drupal 6.4.
4) upgrade the core modules first with the all the custom modules , contrib and themes removed from the location.
5) Then install latest Drupal 6 versions of Contrib modules. Run update.php almost 7 times to finish successful completion. I had problems with filefield and imagefield modules if I included them. Fatal Error (so had to remove them). 15 pages full of Red query errors while updating. All kinds of red errors here some are warnings, some are notices, array_megre errors . People would hate me if I put that logfile in this post.
6) After CCK upgrade upgrading filefield and imagefield was done fine. I am trying to understand the dependency during upgrade.
7) Finally Install custom modules, custom theme.
8) Include info file in theme it shows up but many errors. Especially headers already sent and aryay_merge. Had to remove menu_local_task from the template.php.
9) All my custom modules become obsolete. Because of multistep forms and menu changes. Well understood
10) I download deadwood project and run it on my custom modules. Code changed diffs are good.
11) Enable the custom modules. None of my menu_hooks work. I dont know why

Guys I am using standard drupal upgrade procedure defined in manual. What is going wrong? One final thing I will post my contrib modules in Drupal 5 that is good to see to diagnose :

Actions
Administration menu
content
ccck taxonomy
content copy
Fieldgroup
File Field
Image Filed
Link
Node Reference
Number
Option Widgets
Text
user Reference
Views
Views RSS
Ciews theme wizard
Views UI
Five Star
Voting API
Date
Date API
Date Popup
Date Timer Zone
Image API
Image API GD2
Image Cache
Image Cache UI
Usernoode
NodeQueue
Active Select
Flag Content
JS Character Count
MimeDetect
Path Auto
evsision Moderation
Token
Panel pages
Panels
View panes

Too much time spent to get it working. I cant automate it because I can never guess how many times drupal update.php has to run.

One main question I have is: Is there any way I could export all the data from my Drupal 5 and install fresh copy of drupal 6 and get it imported there. (CCK, Nodes, Users, menus, path aliases)

Please Help!!!

This may be

cog.rusty - October 11, 2008 - 06:08

This may be useful:

Upgrading your menu system from 5.x to 6.x
http://drupal.org/node/103114

Also, running update.php one more time, just to rebuild the menus, wouldn't hurt.

Generally I run update on all the contributed modules at once, first on a test site. Failing that, I update views and CCK first, and then the rest. Some dependencies are obvious (such as CCK field modules dependencies on CCK). The rest are mentioned in each module's modulename.info file.

Interesting Error !!!

vvanaparthy - October 11, 2008 - 06:28

After Enabling my custom modules converted from D5 to D6 with Deadwood Project. I run update.php and then I see the the blank page of death of PHP.

Very Wierd!!! Some how cant get the hang of it.

No httpd error logs , no watch dogs . I dont even understand how to debug this.

May be the deadwood conversion is going bad.

Sample Code conversion

D5

function mymodule_menu($may_cache) {
  $items = array();
  global $user;
  if ($may_cache) {
    $items[] = array(
      'path' => 'register',
      'title' => t('Register'),
      'callback' => 'drupal_get_form',
      'callback arguments' => array('mymodule_registration'),
      'type' => MENU_NORMAL_ITEM,
      'access' => TRUE, //$user->uid == 0, // Only anonymous users can register.
    );}

D6

function mymodule_menu() {
  $items = array();
  global $user;
/* TODO
   Non menu code that was placed in hook_menu under the '!$may_cache' block
   so that it could be run during initialization, should now be moved to hook_init.
   Previously we called hook_init twice, once early in the bootstrap process, second
   just after the bootstrap has finished. The first instance is now called boot
   instead of init.

   In Drupal 6, there are now two hooks that can be used by modules to execute code
   at the beginning of a page request. hook_boot() replaces hook_boot() in Drupal 5
   and runs on each page request, even for cached pages. hook_boot() now only runs
   for non-cached pages and thus can be used for code that was previously placed in
   hook_menu() with $may_cache = FALSE:

   Dynamic menu items under a '!$may_cache' block can often be simplified
   to remove references to arg(n) and use of '%<function-name>' to check
   conditions. See http://drupal.org/node/103114.
   The title and description arguments should not have strings wrapped in t(),
   because translation of these happen in a later stage in the menu system.
*/
  if ($may_cache) {
    $items['register'] = array(
      'title' => 'Register',
      'page callback' => 'drupal_get_form',
      'page arguments' => array('mymodule_registration'),
      'type' => MENU_NORMAL_ITEM,
      'access arguments' => TRUE, //$user->uid == 0, // Only anonymous users can register.
    );

The white screen may be a

cog.rusty - October 12, 2008 - 02:23

The white screen may be a result of the increased php memory requirements of Drupal 6 (plus installed modules). It may have run out of memory in the middle of some operation.

Check your php memory_limit (http://drupal.org/node/59680) and try to increase it (http://drupal.org/node/207036).

Then run update.php again (just to rebuild the menus) and see if it completes.

Drupal 6 does not run menu

darren.ferguson - October 11, 2008 - 22:30

Drupal 6 does not run menu every time only when menu is rebuild or when modules are listed.

In the example you have above for the menu the global $user means that user will always be the administrator in your case for these pieces.

Also there were a lot of changes between d5 and d6 including forms and the l and url functions.

Just changing the menu function in the module is not sufficient.

Check your httpd logs or php logs there should be issues in there hence the white screen of death.

If not try installing xdebug as a zend_extension that will produce the information for you.
Darren Ferguson
OpenBand / M.C.Dean

Video tutorials, and docs

juan_g - October 11, 2008 - 22:22

A simple procedure is described in the video:

Upgrading from Drupal 5.x to Drupal 6.x

And another, also simple, to update module code (if you need it) in the video:

Porting Drupal Modules

Of course, there is also the documentation on upgrading Drupal, and -for developers- on updating your modules.

As we explicitly state in

sdboyer - October 15, 2008 - 15:36

As we explicitly state in big bold letters on the Panels project page, we have not yet written the D5->D6 upgrade path, and are unlikely to do so until we get it out of Alpha.

As far as I know, there is

andrus_k - October 15, 2008 - 18:46

As far as I know, there is no upgrade path from D5 to D6 for Imagefield yet.
======================
http://www.westki.info
http://www.vilniusblogs.com

 
 

Drupal is a registered trademark of Dries Buytaert.