upgrade.html 4.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100
  1. <h1>Using Drush to Upgrade Drupal 6.x to Drupal 7.x</h1>
  2. <p>
  3. The drush site-upgrade command supports upgrades from Drupal 6.x
  4. to Drupal 7.x. Upgrades from Drupal 7.x to Drupal 8.x will be
  5. supported in the future. Use the drush pm-update command to do minor verison
  6. updates for Drupal 5.x, 6.x and 7.x.
  7. <p>
  8. To begin, consult the UPGRADE.txt file from the root folder of the
  9. version of Drupal you are upgrading to. Drush will handle some of
  10. the steps described there, but not all. In particular, you should
  11. make sure that your current Drupal installation is running on the
  12. most recent minor version available.
  13. <p>
  14. n.b. At the time of this writing, Drupal 6.20 and Drupal 7.0 were
  15. the most recent versions available. Always check primary sources
  16. prior to upgrading to see if anything may have changed.
  17. <h2>Upgrade a Copy of your Site</h2>
  18. <p>
  19. Drush will always upgrade <i>from</i> the specified Drupal site
  20. <i>to</i> an empty Drupal site. It is necessary to create a
  21. site alias to describe the destination site. Site aliases are
  22. described in `drush topic docs-aliases`. A canonical site alias
  23. is adequate to define your target site for upgrade:
  24. <p>
  25. $aliases['onward'] = { <br>
  26. 'root' => '/path/to/upgraded/drupalroot',<br>
  27. 'uri' => 'http://onward.mysite.org',<br>
  28. }<br>
  29. <p>
  30. Optionally, you might also want to define 'db_url' to specify
  31. the name of your target database. If you do not, drush will
  32. compose a database name for you based on the name of your site alias.
  33. <p>
  34. <h2>Running the `site-upgrade` Command</h2>
  35. <p>
  36. Drush will upgrade the current bootstrapped site, and will
  37. put the result in the target site specified by the argument
  38. to the command. For example:
  39. <p>
  40. drush @from site-upgrade @onward
  41. <p>
  42. The site-upgrade command will perform the following operations:
  43. <ol>
  44. <li>Download the next major release of Drupal and store the files
  45. in the target site.</li>
  46. <li>Write a new settings.php file with an appropriate databases
  47. structure for the new target site.</li>
  48. <li>Make a copy of the SQL database for the new site.</li>
  49. <li>The default theme for the new site will be set to "garland",
  50. and the admin theme will be set to "seven".</li>
  51. <li>All non-core extensions will be disabled in the target database,
  52. and updatedb will be run on Drupal core.</li>
  53. <li>All of the modules disabled in the previous step will be
  54. downloaded again, if they have an appropriate version for the
  55. target Drupal site available.</li>
  56. <li>updatedb will be run again to update the non-core modules.</li>
  57. <li>All of the non-core modules will be enabled again.</li>
  58. </ol>
  59. <p>
  60. Before drush begins this process, it will first print out a list
  61. of warnings for any modules that may not be ready to upgrade yet.
  62. Please read all of these messages carefully before proceding.
  63. Here are some of the situations you may encounter.
  64. <ul>
  65. <li>If a module has no <i>recommended</i> release, then drush
  66. will continue, downloading an available release for the upgrade.</li>
  67. <li>If a module has no release at all, then drush will skip it.
  68. The module's data will remain in the database.</li>
  69. <li>You may discover that some modules, such as date_api, might
  70. cause the Drupal core updatedb to fail. In this instance, you
  71. may use the --uninstall option to list the modules to uninstall
  72. prior to upgrade. Modules uninstalled in this manner will have
  73. all of their data removed from the target database; the database
  74. of the source site is not affected.</li>
  75. </ul>
  76. <p>
  77. When drush is enabling the modules in the upgraded site, if there
  78. are any new dependencies, they will also be identified and downloaded
  79. if possible. For example, views-7.x depends on the ctools module
  80. from the Chaos tool suite, whereas views-6 did not; drush will therefore
  81. download and enable ctools when upgrading the views module from
  82. Drupal 6 to Drupal 7.
  83. <p>
  84. There will still be some work left to do after the site-upgrade
  85. command has completed; for example, you will still need to port your
  86. theme and any custom modules to the new version of Drupal, and some
  87. contrib modules may require additional work to update their configuration
  88. settings. Using site-upgrade will all the same save you a considerable
  89. amount of time. There is no risk in trying it; if it does not work,
  90. you can always start over, or run it at a later date when more contrib
  91. modules have been updated. If you do run site-upgrade a second time
  92. on the same site, drush will ask you if you want to replace the existing
  93. target site, effectively starting over from the beginning, or re-use
  94. the site that is already present. In the later case, drush will use
  95. the existing code, but will re-copy the source database and run updatedb
  96. on it again. This will all you to attempt to fix any non-working contrib
  97. modules yourself to get your site-upgrade working.
  98. <p>
  99. Enjoy!