Taking your site from Drupal 6 to Drupal 7


Published on

Presented at CapitalCam

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • ----- Meeting Notes (7/21/11 22:05) ----- Here's a quick overview of what I plan to cover. The topics I plan to discuss will be from a high-level view of what's needed to take your site from Drupal 6 to Drupal 7; whether that's upgrading your site, or building something completely new in D7 and migrating your users and content to it. I won't get into great detail, but I certainly hope to push you in the right direction.
  • While you can keep the site’s look and feel to the average user, drastic shifts in modules and site administration will possibly require retraining (for site editors, content producers, etc)
  • Don’t get left behind: As module development shifts to D7, D6 support will dwindle – module maintainers only have so much time. New versions or features will be introduced in 7.x versions, as well as bug fixes – typical behavior is to fix in the latest version (HEAD) and backport to 6.x if warranted and as time allows. Site cruft: Sometimes, as a site gets on in years, cruft (either development or content) keeps a site from being maintainable in its current state. Then, a redesign or site refresh is in order.
  • Determine how much of your site can easily be upgraded. Drupal Core, most popular contrib modules, and themes have upgrade paths that will update site content for you.
  • Converting themes from Drupal 6 to Drupal 7 -- has 60+ changes to Drupal 7 theming. Template file changes (like html.tpl.php), block changes – helpful names rather than numeric IDs (CSS selector wrangling); region changes like right and left sidebar became first and second sidebar; primary and secondary links became main_menu and secondary_menu. Render arrays! Render arrays are the building blocks of content; structured content not rendered into HTML until the last possible moment. Think about Forms API arrays. When we went from 4.5 to 4.6, you no longer built your forms in HTML; this allows for hook_form_alter – preprocess and postprocess hooks in theme now.
  • This is kind of a non-sequeter, but it’s useful to get this out of the way now, to talk about the tools that you need in your arsenal
  • Show-stoppers – required functionality Next round upgrades – What’s used, but not required for immediate use (reporting, newsletters). Identifying these can make upgrading your site faster and can keep the budget down for things that can be handled later. Better ways? – Perhaps there’s now a better way to do what your site did. Context and Features are all vast improvements to development and maintenance workflow that weren’t likely available when your site was first built. Nice-to-haves – What features to users occasionally use, but perhaps aren’t worth the effort. Alternative replacements -- What can be replaced with third-party plugins? There are more widgets available now than when the site was first build (Disqus, Wibya) Cut list – identify site cruft and what things can be left on the cutting room floor.
  • Compare this inventory with what has 7.x versions. Modules may require fewer dependencies now that some contrib modules are in code. Dependencies may have changed if a previous dependency module was deprecated. Might have new dependencies. You may not need to keep some modules if they’re no longer required. This allows you to establish a level of effort (LOE) for upgrading your existing site vs. building a new version of your site and migrating content. Determine if you can live with beta versions. Sometimes, beta means it’s got bugs. Some developers use “beta” to signify level of maturity, *not* the level of quality. May go through 10 betas before releasing a 1.0; many times, these beta versions are fine. But sometimes beta isn’t production ready (not all functionality is complete, etc). Read the issue queues
  • Some modules have migration or upgrade documentation right on their project page (or they link to documentation from their main project page). Issue queues aren’t just for bugs. Look in module’s issue queues to determine upgrade issues and tips. When you get stuck, you should realize that you probably aren’t the first one, so check the issue queues. Check the forums also, for tips on upgrading particular modules. Drupal search is your friend, and Google is your BFF.
  • Chances are, you’re going to have to replace some outdated, deprecated, or abandoned modules. It happens. It even happens when working within the same version of Drupal. Maintainer of Nodewords is a co-maintainer of Metatags, and *is* working on a migration path.
  • Don’t do this in your main development environment. You want to use a new, fresh development environment (another vhost is fine, shared hosting is fine, just use a different database and code base). You’ll want to refer back to your main dev site for comparison as a control. You’ll also want to take snapshots of code and database along the way. Think of it as save points in your game.
  • There’s some really thorough documentation on Drupal.org to walk you through step-by-step in upgrading core. It’s very detailed and will basically hold your hand through the whole process. Distilled down, these are the main steps of upgrading Drupal core.
  • There’s some great documentation linked from the main CCK project page that walks you through upgrading your custom content types to Fields API. The D7 version of CCK does *not* do any custom-content, that’s what Field API is. CCK in D7 is primarily a bridge between old CCK and Fields API.
  • It’s important to do this one at a time. Start with dependencies, then work your way up through the highest priority modules. Views?
  • Module builder doesn’t help upgrade much; but in the event you need to throw together a custom module to help, Module Builder will help with a module’s skeleton quickly. Advanced Help will have information about upgrading Views from 6 to 7.
  • If your scripts can access your data, most likely, so can anyone else. Be particularly careful to avoid exposing your user data. Depending on your privacy policy, depending on your local or state laws, if you expose your user data, you may be in hot water. Even if no one finds it, just the *exposure itself* can cause you some headaches.
  • Might want to check out table wizard and Data modules; not sure the status, but they both do well to expose data that you might want to import using Feeds module in your new site.
  • Migrate module has a very robust API to migrate content. Uses Batch API to keep the process running without timeouts. Can save progress; can stop and restart migration. Also allows for incremental migration – you can migrate everything you have now, but while you’re working on the new site, users are adding new content. This allows you to migrate only the new stuff.
  • Backup and Migrate lets you backup your database and lets you cherry-pick tables. It does some automation of database table backups to potentially help with incremental migrations. Doesn’t *do* anything to your database tables; it just backs them up and you can import those into your new site. Doesn’t handle relational data integrity or anything. It’s perfect for just moving over custom tables to your new site.
  • Table Wizard, Data, Views RSS – all let you access data in ways that you can spit out any feed type that you want: RSS, Atom, Custom XML, CSV, whatever. You can use Views with arguments to handle different types of data that you want to port to the new site. Feeds replaced FeedsAPI module. Feeds will let you define your own parser if you need to, and define what happens with the date from your feed – how it gets inserted into the new site.
  • Direct database connections bypass the need to have exposed data and data parsing, and cuts right to the chase. Might be preferable for smaller jobs, and when using shared environments. Will need to do a schema load prior to switching the active database to prevent a chicken-or-egg scenario.
  • There are few things in this world more frustrating than watching a custom migration script run for 5 minutes, and then just timeout. Passing values by reference instead of by value helps reduce your migration script’s memory footprint.
  • Taking your site from Drupal 6 to Drupal 7

    1. 1. Taking your site from Drupal 6 to Drupal 7 <ul><li>Tobby Hagler, Phase2 Technology </li></ul>
    2. 2. Overview <ul><li>Modules incorporated into Drupal Core </li></ul><ul><li>How does this affect your work as a site maintainer </li></ul><ul><li>Why not just stay in Drupal 6? </li></ul><ul><li>How do I know when to upgrade </li></ul><ul><li>Migration vs. Upgrading </li></ul><ul><li>Tools to upgrade or migrate </li></ul>
    3. 3. Biggest changes between D6 and D7 <ul><li>Theme changes </li></ul><ul><li>New templates such as html.tpl.php </li></ul><ul><li>Render arrays </li></ul><ul><li>Module changes </li></ul><ul><li>Database changes – DBTNG </li></ul>
    4. 4. Contrib modules in Drupal Core <ul><li>CCK became Fields API </li></ul><ul><li>Imagecache became Image Styles </li></ul><ul><li>Tokens </li></ul><ul><li>Admin </li></ul><ul><li>jQuery UI </li></ul><ul><li>And many more – drupal.org/node/895314 </li></ul>
    5. 5. How does this affect site maintainers <ul><li>Can keep the site’s look and feel to the average user </li></ul><ul><li>May encounter drastic shifts in modules and site administration </li></ul><ul><li>Will possibly require retraining (for site editors, content producers, etc) </li></ul>
    6. 6. Why not just stay in Drupal 6? <ul><li>New modules developed for Drupal 7 only </li></ul><ul><li>Focus shift to Drupal 8, support for Drupal 6 will dwindle to security updates. </li></ul><ul><li>Drupal 7 allows for bigger scale (database replication, storage engines) </li></ul>
    7. 7. Know when it's time <ul><li>Don’t get left behind – Module development shifts to D7, D6 support will dwindle </li></ul><ul><li>Site cruft – As a site ages, cruft keeps a site from being maintainable in its current state </li></ul>
    8. 8. Upgrading vs. Migration <ul><li>Determine how much of your site can easily be upgraded </li></ul><ul><li>Some modules have been deprecated, abandoned, or replaced </li></ul><ul><li>Inventory your site </li></ul><ul><li>Know that some content must still be migrated (CCK, user profiles, Image files) </li></ul>
    9. 9. What about my theme? <ul><li>Most likely, you’ll need to rebuild it </li></ul><ul><li>Converting themes from Drupal 6 to Drupal 7 – drupal.org/node/254940 </li></ul><ul><li>Render Arrays in Drupal 7 – drupal.org/node/930760 </li></ul><ul><li>jQuery UI is in core now </li></ul>
    10. 10. What do I need? <ul><li>Dev environment (vhosts or localhost) </li></ul><ul><li>SSH or FTP </li></ul><ul><li>MySQL access to create new databases </li></ul><ul><li>Drush – drupal.org/project/drush </li></ul>
    11. 11. Site inventory <ul><li>Show-stoppers – required functionality </li></ul><ul><li>Next round upgrades – What’s used but not required? </li></ul><ul><li>A better way? – Context and Features </li></ul><ul><li>Nice-to-have or not worth the effort? </li></ul><ul><li>Alternative replacements – 3 rd party plugins </li></ul><ul><li>Cut list – Identify site cruft </li></ul>
    12. 12. Site inventory: Show stoppers <ul><li>Check project page for 7.x version or core status </li></ul><ul><li>Consider dependency change </li></ul><ul><li>Look for upgrade paths or replacement modules </li></ul><ul><li>If missing, you’ll probably want to rebuild and migrate </li></ul>
    13. 13. Determine upgrade paths <ul><li>Drupal core always has an upgrade path – See UPGRADE.txt </li></ul><ul><li>Many popular modules have upgrade paths </li></ul><ul><li>Some modules include documentation to migrate to other modules </li></ul>
    14. 14. Replace deprecated modules <ul><li>Nodewords is replaced with Metatags – no backwards compatibility </li></ul><ul><li>Thickbox is replaced by Colorbox – a drop-in replacement </li></ul>
    15. 15. Upgrade process <ul><li>Find a way to quickly instantiate a copy </li></ul><ul><li>Backup and work on a new instance </li></ul><ul><li>Disable all contrib modules …and test </li></ul><ul><li>Upgrade Drupal core …and test </li></ul><ul><li>Upgrade contrib modules in order of importance to the site …and test </li></ul>
    16. 16. Upgrade process: Core <ul><li>See drupal.org/node/570162 </li></ul><ul><li>Set theme to a core theme </li></ul><ul><li>Disable all contrib modules </li></ul><ul><li>Remove settings.php </li></ul><ul><li>Copy 7.x over existing site </li></ul><ul><li>Run update.php </li></ul><ul><li>Upgrade CCK content </li></ul>
    17. 17. Upgrade process: CCK to Fields API <ul><li>See drupal.org /node/ 1144136 </li></ul><ul><li>Install CCK 7.x </li></ul><ul><li>Admin > Structure > Migrate Fields </li></ul><ul><li>May need additional CCK-related modules </li></ul><ul><li>Test content and content types </li></ul>
    18. 18. Upgrade process: Contrib modules <ul><li>Download and install 7.x versions </li></ul><ul><li>Check project page for migration instructions </li></ul><ul><li>Drush is your friend </li></ul><ul><li>drush dl module </li></ul><ul><li>drush en module </li></ul><ul><li>drush updatedb </li></ul>
    19. 19. Additional tools to help upgrade <ul><li>Upgrade Status and Upgrade Assist – drupal.org/project/upgrade_status </li></ul><ul><li>Coder – drupal.org/project/coder </li></ul><ul><li>Module Builder – drupal.org/project/module_builder </li></ul><ul><li>Advanced Help – drupal.org/project/advanced_help </li></ul>
    20. 20. Or migrate... <ul><li>Sometimes the easiest thing is to rebuild the site from scratch and migrate content and users </li></ul>
    21. 21. Security concerns <ul><li>When migrating content, you risk exposing your data to the outside world </li></ul><ul><li>Especially true with custom migration – using XML/feeds to export data may be open to anyone </li></ul><ul><li>Best practice is to migrate from a local snapshot of production </li></ul>
    22. 22. Tools to migrate <ul><li>Migrate – drupal.org/project/migrate </li></ul><ul><li>Backup and Migrate – drupal.org/project/backup_migrate </li></ul><ul><li>Custom development – sometimes to meet the needs of your site, you’ll need to do some custom migration </li></ul>
    23. 23. Migrate includes: <ul><li>API for building a complete migration </li></ul><ul><li>Drush commands that use Batch API </li></ul><ul><li>Migrate UI </li></ul><ul><li>Migrate Example – See how Migrate module is implemented with a working example </li></ul><ul><li>Documentation – drupal.org/node/415260 </li></ul>
    24. 24. Backup and Migrate <ul><li>Selectively choose database tables to migrate </li></ul><ul><li>Doesn’t handle relational data like User Profiles </li></ul><ul><li>Perfect for porting custom tables that won’t change </li></ul>
    25. 25. Custom migration <ul><li>Often, data must be exposed to pull content and users </li></ul><ul><li>Exportable data via Views </li></ul><ul><li>Feeds – import data in a variety of formats </li></ul><ul><li>Many contributed Feeds modules that extend Feeds’ parsing capabilities </li></ul>
    26. 26. Database connections <ul><li>Table prefixing in settings.php – ‘other_database.’ as a prefix </li></ul><ul><li>Switch database connections with db_set_active() – watch for errors and Schema API caching </li></ul>
    27. 27. Database prefixing <ul><li>$databases['default']['default'] = array( </li></ul><ul><li>'prefix' => array( </li></ul><ul><li>'default' => '', </li></ul><ul><li>'users' => 'shared.', </li></ul><ul><li>'sessions' => 'shared.', </li></ul><ul><li>'role' => 'shared.', </li></ul><ul><li>'authmap' => 'shared.', </li></ul><ul><li>), </li></ul><ul><li>); </li></ul>
    28. 28. Other considerations <ul><li>Security – don’t expose your data, especially users </li></ul><ul><li>PHP timeout and memory settings </li></ul><ul><li>Make backups and database dumps at every milestone </li></ul><ul><li>drush sql-dump > backup.sql </li></ul>
    29. 29. Files migration <ul><li>Backup and Migrate Files – drupal.org/project/backup_migrate_files </li></ul><ul><li>Recent Files – drupal.org/project/recent_files </li></ul><ul><li>rsync </li></ul><ul><li>Drupal 7 introduces public and private files </li></ul><ul><li>drupal.org/documentation/modules/file </li></ul>
    30. 30. Questions?
    31. 31. Contact <ul><li>thagler@phase2technology  </li></ul><ul><li>@phase2tech </li></ul><ul><li>703-548-6050 </li></ul><ul><li>d.o: tobby </li></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.