Took the Drupal 7 plunge -- finally -- Looking good
In January 2010 I attended a launch party for Drupal 7, and was real excited at the new features etc. But I started to look into upgrading my sites, and found a bunch of modules had not been ported to Drupal 7 yet. Eleven months ago, eleven months after that launch party, I posted an inventory of module readiness for upgrading my sites to Drupal 7, and still found a number were not ready, though in most cases I was feeling shy of modules marked "beta". (hint: "beta" means "not ready for prime time, we are still testing") There's also been an issue of my time availability as I am working hard at writing news articles for other sites, and haven't spent much time here. So.. the project slipped and I just decided to take care of my first Drupal 7 upgrade last night. Upgrading from Drupal 6 to Drupal 7 wasn't too hard but was harder than maybe it should have been.
The overall process is as it's always been for a major version upgrade (details are on drupal.org -- but this is my version of what to do)
- Back up your database of the D6 site
- Make a subdomain within which to build the upgraded D7 site
- Copy the contents of the production D6 to that area
- Make a new database to store tables for the D6-D7 conversion
- Clone the database from the existing production database to that one
- Edit the settings.php to point to the new database
- Log into the new subdomain
- Go into Site Information and make the Site Name clear that you are in the conversion site
- Put the site offline
- Double check with the production site that the changes you've made have not been to the production site
- Switch the site to the Garland theme
- Start disabling all modules other than the core modules
- You can also uninstall any modules that you won't be needing in D7
- Build a drush make file that creates a D7 site with the modules you need
- Run that drush make file to generate the new site
- mv the directory for the subdomain out of the way
- mv the directory for the D7 site you just built in its place
- Edit its settings.php to have the correct database
- Connect with the update.php script for the subdomain
- Run the upgrade
Of course there were problems. This site began life as a Drupal 4.6 site and has been upgraded every step since. I'm sure there's some cruft in the database some of which tripped me up in this upgrade.
First was that I left out a step above. In the D7 site you need to copy the sites/default/files directory structure from your production site to the new site. After doing that remove all content from the css and js subdirectories. I spent a long time with the theme not working and wondering why it wasn't working. As soon as I copied the files directory over it started to work, I had to also go into the Garland theme settings, make a change, then click save, and the theme began working fine.
Next was a real bad kerflump when I enabled the RDF module. It tripped over some old tables from something I'd installed during D6 testing, and there were majorly scary messages being printed. I had to delete all entries from the system table that referred to the RDF module, and the site began working again.
Next was the administration toolbar that was simply missing in action. If you install D7 from scratch it asks if you want a fancy D7 install, but doing the D6-D7 upgrade you don't get such a question. You get the toolbar by going into the modules and enabling the necessary module.
That was fine but most of the entries were missing from the toolbar. That was puzzling but I eventually found a discussion on drupal.org detailing this and a curious fix at http://drupal.org/node/865702#comment-4015758
Next was - how to replace the cachebrowser? I was using cachebrowser to cause the cache to be on the disk rather than in the database, to reduce database load. The correct module for this in D7 is the filecache module.
I also use boost on this site, and while boost is available for D7 there was an error message that came up that confused me for a few minutes. In the Performance area I'd enabled caching and didn't think much of it, but upon enabling the boost module it started complaining about the caching already enabled would prevent boost from working. Turns out that the caching option I enabled is new for D7, and is for caching page renderings for anonymous users. Obviously that's the same function that boost does, and if it detects a page in the cache it won't generate a boost page for that page. Just do as boost says, turn off the caching of page renderings for anonymous users.
Another odd misbehavior was when I went to create this blog post. The site told me that I hadn't configured any content types, and that I was unable to create content. Specifically: "You have not created any content types yet. Go to the content type creation page to add a new content type." Huh? There's 20 content types, how can that be.
Turns out that I had disabled the Create Content choice under the Navigation menu because I thought - hey, I'll be clicking that Add Content thing in the administrator toolbar, why do I need to have this Navigation menu entry enabled? Turns out that Drupal is checking that menu for the kinds of menu types that can be added, irregardless of what the user permissions settings say. Re-enabling those Navigation menu choices is enough. By the way, this site isn't displaying the Navigation menu, and I've now decided to treat the Navigation menu as a kind of vestigial artifact kind of like the Appendix.