Checking out Drupal 6: Update upsets!
For the benefit and amusement of others, here's a rundown of some of the troubles adventures I had upgrading this site from Drupal 5 to Drupal 6. I worked on an exported copy of my Drupal Ace database, imported to a new empty database, all using a different temporary domain; the goal was to get that working, and then have drupalace.com start pointing to that new setup. (See previous Checking out Drupal 6 installments for more on preparations leading to the upgrade.)
Trial 1: The forgotten
Although I properly disabled non-core modules before upgrading, the result was more error messages than I even wanted to bother recording. Specifics are lost to the sands of thyme.
(Yes, thyme. Can't help it; I'm feeling a bit peckish.)
Trial 2: The daring
Nuke the failed database. Start again with a fresh copy of the D5 database. And this time... double-dog dare the Fates.
That's right, a double-dog dare – the alleged apogee of childhood dare escalation (though one suspects that the feared triple-d features far more prominently in "Stand By Me"-style tales of youthful innocence than it ever did among actual children). In my case, the red cape I waved before the Fates was an upgrade with all modules left enabled.
Why? I dunno; because the instructions say not to, and I was curious. Also, it was worth it just to see shocked Drupal ladies overcome with the vapors, and Drupal gentlemen drop monocles into champagne glasses.
Errors ensued. Stuff like this:
* user warning: Table 'database.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('sitemap') ORDER BY fit DESC LIMIT 0, 1 in <my site path>/includes/menu.inc on line 315.
* user warning: Table 'database.views_view' doesn't exist query: SELECT DISTINCT v.* FROM views_view v in <my site path>/sites/all/modules/views/includes/view.inc on line 1217.
* user warning: Table 'database.cache_views' doesn't exist query: UPDATE cache_views SET data = ... <followed by really long mess>
Try that update again. More errors – some the same as before, some new. Update again. More errors old and new.
Among the errors, it was clear that D6 was choking while updating certain modules, especially CCK, Views, Image, Nodereference, and Paging. My leaving these modules enabled may or may not have been a problem, but actually reading the update directions carefully reveals that upgrading D5 modules to the latest version is a key step in updating to D6.
It's not required for all modules, but definitely for some. Which ones? Well, if there's a master list, I haven't seen it; I checked all key modules' pages on Drupal.org to look for notes and download latest versions. The CCK and Image modules, to be sure, specify recent versions of the 5.x modules as requirements for updating to D6. So if you're making the update, check those modules' pages, and any other modules you suspect as causing update troubles.
Trial 3: The getting serious
All right. Revert to fresh copy of D5 database. Update lots of outdated 5.x modules. Then disable them anyway. Everything by the book (or the scattered bits of documentation, as it is). Run update.
Well, that sure didn't prevent errors. Lots of 'em like these:
* user warning: Table 'database.faq_questions' doesn't exist query: ALTER TABLE faq_questions ADD `detailed_question` TEXT DEFAULT NULL in <my site path>/includes/database.mysql-common.inc on line 298.
* warning: array_merge() [function.array-merge]: Argument #2 is not an array in <my site path>/update.php on line 174.
* user warning: Duplicate column name 'show_citation' query: ALTER TABLE quotes_blocks ADD `show_citation` SMALLINT DEFAULT 0 in<my site path>/includes/database.mysql-common.inc on line 298.
* warning: Invalid argument supplied for foreach() in <my site path>update.php on line 339.
On to the user page, which bleated the below:
* warning: array_map() [function.array-map]: Argument #2 should be an array in <my site path>/modules/system/system.module on line 966.
* warning: array_keys() [function.array-keys]: The first argument should be an array in <my site path>/includes/theme.inc on line 1760.
* warning: Invalid argument supplied for foreach() in<my site path>/includes/theme.inc on line 1760.
All righty. Next, per some of the warnings/notices, I enabled CCK modules and ran update again, a required step to complete the process.
And... hey! No error messages following the update, or on the Admin page! Drupal 6, you just became my bestest friend.
Troubles did remain. Some of these and their status:
The old Drupalace theme doesn't work; it just results in a mess with menus missing. That's fine; I'm going to create a new one.
Editing and previewing old nodes was tossing up taxonomy-related errors, like this:
warning: Illegal offset type in isset or empty in <my site path>/modules/taxonomy/taxonomy.module on line 1088.
This one wasn't inexplicable, though. It turned out that I'd done something dumb in the original database even before starting the update: somehow, I'd disabled a Vocabulary for several of the node types that made use of it. Heading to admin/content/taxonomy/edit/vocabulary/<number> in the new D6 site, and enabling the Vocabulary for the content types in question, fixed things right up.
All Views that I had set up are gone, at least in that they don't show up in the list of available Views. Also missing are all menu items that point to those Views; the menu items aren't disabled, they're gone.
This one is pure mystery to me. In the interest of forging ahead, I'll likely just re-create the Views.
I don't recall whether I noticed and fixed this before or after "flipping the switch" (below), but a number of recent posts weren't showing up on the front page, even though they appeared on admin/content/node and were properly set up to appear.
Heading to admin/content/node-settings and cicking "Rebuild Permissions" worked its magic and fixed this problem. (Curiously, the "Rebuild Permissions" no longer appears for me on that page! The issue is discussed in this thread.)
Images I'd input into nodes via IMCE were fine. But anything I had attached to nodes via the Image and Image Attach modules wasn't showing up, despite key troubleshooting steps: re-editing nodes, making sure the image was selected in the Attached images field, making sure the file system settings were right, confirming via FTP that the images were where they should be, checking image file permissions, etc.
Things did work fine if I uploaded and attached a new image, even though old images were selectable as attachments, and both old images and new were sitting in the site directory right where they should be. Hmm...
At a loss for clues, I headed to phpMyAdmin, and searched for some of the known image file names. This revealed the problem: although I'd set the file system to reflect the temporary domain I was using, paths to the images appearing in database tables still reflected the drupalace.com file system.
This suggested to me that the problem would resolve itself when I switched the site back to drupalace.com. And so:
Flipping the switch
I set things up so that drupalace.com would point to the new D6 site directory, and made sure that its settings.php file was also configured for drupalace.com. Thusly was the switch flipped.
And... still no attached images. I don't recall what made me decide to try this again, but toggling back and forth between Public and Private file system settings – something that hadn't worked initially – kicked images into working. Problem resolved!
Okay. There's a partially-remembered overview of the hoodoo and slapdash troubleshooting behind my update. There are still problems to fix. But there are already great benefits – the fantastic interface improvements of D6 (drag'n'drop list ordering!) to start with – and little surprises too (no more bizarre cursor position fluctuations in my TinyMCE windows).
Updates, upsets... and then upward!