Upgrading your Drupal installation to the latest version
Upgrading your site isn't quite as simple as reading UPGRADE.txt that comes with the default Drupal installation profile and going off to the races. Depending on the complexity of a site, upgrading can be an involved process. However, with sufficient planning and patience even the most complex sites can be upgraded in a series of steps that on their own are quite simple.
In this talk, Andre Molnar will walk everyone through his upgrade planning process and highlight some tools that he uses to help get the job done.
Topics covered include:
- Updates vs upgrades
- Backing up your site
- Update status module
- Preparing a site for upgrade
- Development, staging and production servers
- Upgrading
- Testing your upgraded site
About Andre Molnar:
Andre operates Be Circle: a web application development and consulting company that has specialized in Drupal for the past 5 years. Andre's first "web page" was online in 1994, but he started working professionally in web application development in 2000.
Other random highlights: Andre helped organize Drupalcamp Toronto 2008, made a Druplicon Munny (toy), and recently won a Nissan cube that he is decorating to help promote Drupal.
Come to the talk and you will get to the see the car!
Should be an interesting talk ...
I think that the Nissan Cube with the Druplicon eyes on it is reason enough to show up at the meeting.
However, the talk is informative too: upgrading sites built with core only is pretty straightforward. However, who builds sites that use only core modules? We all indulge in the 4,000 + contrib modules that are available for free on drupal.org. Then we realize how much more work we have caused for ourselves when it is time to upgrade ...
Come and hear what Andre Molnar has to say, ask questions, exchange ideas ...
See you all there on Thursday 19:00.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Slides
Thank you to everyone that came out to the presentation. I had a great time.
As promised I have uploaded the slides to my site. You can download them from: http://becircle.com/Waterloo%20DUG%20November%2018%202009.pdf
You can also find the articles I wrote by following this link: http://becircle.com/how_upgrade_drupal_5_drupal_6
If you've got any questions, feel free to use the contact form here or on drupal.org to get in touch with me.
andre
Thanks Andre
Thanks Andre,
This was very informative ...
We had a new contingent from U of Guelph attending, Martin from London, and even one lady who came from Toronto.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Thanks -
Thanks for a great presentation Andre - both in content and delivery, as well as knowledge, insight and expertise.
Thanks to Waterloo DUG for being great hosts - we, the group from UofG, felt very warmly welcomed, and thoroughly enjoyed the company of all and the discussions.
We are a web development group at UofG and have embraced Drupal platform about 1 1/2 years ago. We realize the benefits of community like Waterloo DUG and have plans to set up a formal Web Developer Community on campus. I sincerely think that our groups can mutually benefit from each other, and we look forward to more participation in the community and some day we may host a community presentation like that of yesterday - remember we are [almost] midway from Toronto :o)
Enjoy.
lalit
phpMyAdmin vs Backup and Migrate
Just thought I should add a couple of points about backing up your database, to expand on the discussion last night.
By default Backup and Migrate will exclude the data from cache and session tables but include the table structures, which you can do within phpMyAdmin, but it's a more time consuming, manual process.
On the other hand, phpMyAdmin can (depending on how it was installed) duplicate an entire database in a single operation, which is particularly handy if you're going to be testing on the same server. Give it the new name to dupe to do, click submit and you're done. As was mentioned last night, don't forget the critical step of of pointing your test site to the new database. ;-)
One annoyance I had when
One annoyance I had when doing database dumps with mysqldump was manually adding the ignore table statements, while preserving the table schemas (otherwise all cache writes will fail on your duplicate site).
I ended up creating a small script which I modify for each site I want to back up. Not only does it ensure that cache tables are dealt with properly, but that all database dumps have a consistent name (which is a problem with multiple developers).
Apparently the code filter is messing up backticks (`), which are used to surround the date command.
#!/usr/bin/env bash
DATE=
date "+%Y%m%d"USER=database-user-name
PASS=database-password
HOST=localhost-or-your-db-host
DATABASE=database-name
SITE=www.example.com
OUT=$SITE-$DATABASE-$DATE.sql
# Insert the tables to skip here. These tables will have only their schemas saved.
SKIPTABLES="cache cache_block cache_content cache_filter cache_form cache_menu cache_page cache_update cache_views"
# This builds the ignore parameters for us.
for i in $SKIPTABLES; do IGNORE="$IGNORE --ignore-table=$DATABASE.$i"; done;
# Save all of the data tables
mysqldump --add-drop-table $IGNORE -u $USER --password=$PASS -h $HOST $DATABASE > $OUT
# Append the schema of ignored tables.
mysqldump --add-drop-table --no-data -u $USER --password=$PASS -h $HOST $DATABASE $SKIPTABLES >> $OUT
bzip2 $OUT
Drush and backup workflow
Using a module or phpmyadmin for backing up my sites is something I'd rather avoid but that's just my personal opinion. I have a preference for the command line and cron jobs which ensure I don't forget to back them up. I'd recommend to look into drush and the
sql dumpcommand in particular which will save you a lot of this hardcoded lines above. Not only will it detect which site you want to backup (-r) and pick the right db credentials, but it'll also simplify your script since it has the right mysqldump parameters and you can specify which tables you want to ignore by placing a drushrc.php file in the Drupal root directory or sites/example.com/ (see the all the options of drushrc). There is more goodness on the way: I've created an issue/patch for improving the dump output and making it easy to integrate it with your favorite VCS (svn, bzr, git).Drush does a lot more and many modules have started to integrate with it (coder, features, testing, etc.). Check out the main documentation it's worth starting it use it (As a matter of fact, Drush was recently added to the official debian unstable and testing packages!).
Best of both worlds?
drush is a fantastic tool and it's great to see how support for it is growing.
I should mention that those less technically inclined don't necessarily need to set up drush and a custom cron job. Backup and Migrate can also do scheduled backups, and also has the advantage that you can give client access to backup (and yes, ONLY backup) the site data to a local file, which gives them the ability to keep an offsite archive.
That said, they're also working on drush support in Backup and Migrate, so you could have the best of both.
That's pretty awesome. In my
That's pretty awesome. In my case, I have to deal with some 4.7 and WordPress sites as well, so we're still stuck with the above. But once we get more sites updated, I look forward to using Drush on all of them.
This was the largest turnout
This was the largest turnout I think we've had, and what a great presentation to go along with it! Thanks Andre!