Drupal6 から 7への移行手順
Drupal 7.0がリリースされたのは今年（2011年）の1月5日。それから順調にリリースを重ねて7.10がリリースされたのが今月（12月）の5日、約一年の経過を経てそろそろVersion7も安定してきたのではないか、と個人的に思い始めた。
すでにVersion8が開発段階に入っていることや、Version6の最終リリースから半年ほど経過していることもあいまって、そろそろ6から7に移行する時期だろう。
現在Drupal公式ではVersion7が新しく作成するウェブサイトでは推奨のシステム（recommended）ということになっている。
が、現状ではまだまだVersion6で稼動しているサイトが多い。
Version7への移行が積極的におこなわれていない原因のひとつにDrupal6から7への完全なUPDATEがかなり難しいという事実が挙げられる。
移行手順自体は公式サイトで提示されているため自力でVersion6のサイトを構築できた方なら、さほど混乱することなくおこなうことができるはずだ。
ただし、公式サイトで想定されている（もしくは移行テストで使用された）Version6で構築されたサイトは基本モジュールのみの構成なのではないかと、私は推測している。
どういうことかというと、公式の移行手順を完璧に実行したとしても構築しているサイトの規模（構成）によってさまざまなエラー（もしくは警告）が発生してしまうからだ。これは特に、サイト構築時に独自の環境を構築した場合に多発する。
つまり、さまざまな拡張モジュールを追加インストールしたり、独自のモジュールやテーマを組み込んでいたり、階層いっぱいまで使用した複雑なメニューやBookを構築していたり、インストール時にスタンダード（英語）以外のプロファイルを使用してDrupalをインストールしていた場合・・・等々で、ある。
特に最後の、”スタンダード以外のプロファイルによるインストール”は、英語に忌避意識の強い日本人のサイトでは多い事例ではなかろうか。斯く言う私もいくつかのサイト構築に於いて、日本語のプロファイルを使用していた。当然ながら日本語のプロファイルなどが公式からリリースされるわけもなく、有志（その労力と理念には感謝と敬意を感じます）の手によるものだったわけなのだが、このような形で非公式の悲しさに見舞われたわけである。公式フォーラムでもちらほらと似たケースを見かけるので日本に限らずローカライズしたプロファイルを使っていた海外ユーザーも以外に多かったようだ。
さて、毎回同じ前置きで申し訳ないが
ここで解説するUpgrade手順は、筆者個人が筆者の構築したサイト環境上で独自に試行錯誤を繰り返して導き出したものであり、読者がこれを基に作業をおこなった場合の結果についてはまったく保証も補償もしない。あくまでも自己責任で。
Upgrading from Drupal 6 to 7 for midnight.
事前準備１
実際のUpgrade作業に入る前に、まずはローカル環境で一連の手順を実行できるようにしておく。どのような場合でも不測の事態というのは起きるものなので、100%の確信がない限り、まずはテスト環境での動作確認をおこなうべきだ。
以前にも書いたとおり、筆者の環境は Windows Vista 32bit であるのでWeb開発環境として、ほぼオールインワンであるXAMPPをつかってローカルの実行環境を構築している。XAMPPのインストールや環境構築についてはネット上に詳しい解説サイトや文献が見つかると思うのでそちらを参照してもらいたい。
事前準備２
ローカルの環境が整ったなら、まずはweb上の環境で、データベースのバックアップをおこなっておく。
つぎにweb上の環境の全てのモジュールを無効にする。サイトメンテナンスモードにするかどうかは読者の判断に任せる。
無効にするモジュールは、後から追加したモジュールはもちろん、Drupal Core モジュールも無効に出来るものは全て無効にしておく。ただし、間違ってもアンインストールはしないこと。アンインストールをおこなうとデータベース上から関連データが消去されるので最悪の場合環境の再構築が不可能になる。やってしまった場合はバックアップから復元をおこなうこと。
モジュール同様にテーマも全て無効にし、基本テーマの Garland のみ有効にしてデフォルトテーマに設定しておく。
web上の環境が以上の状態になったら、その状態のデータベースをコピーしてくる。方法は読者にお任せするが、筆者はDrupalインストール時にMySQLを選択しているので、PhpMyAdminを使用して目的のデータベースを選択し、エクスポートを使って全テーブルデータを出力する手法をとった。
事前準備３
つぎにローカル環境にDrupal7をクリーンインストールする。Drupal6とインストール手順はほぼ同じなので迷うこともないだろう。
注意点は３つ、
- web上の環境と同じ名前のデータベースを作成すること。
- インストール時のprofileで Standard を選択すること。
- 言語の選択（Choose language）でEnglish (built-in)を選択すること。
途中で設定するサイト管理用のアカウントデータなどは適当でもかまわない。web環境からコピーしてきたデータベースで上書きされるからである。
さて、ここですこし手間をかける必要がある。詳細な理由は後述するが、インストール時のProfileに関連して発生するエラーを解消するために必要となる手順である。
クリーンインストールの成功した Drupal7 のデータベースからいくつかのデータを抽出しておく。
ひとつは”variable”テーブル内のnameフィールドの値が、”install_profile”の行。
もうひとつは”system”テーブル内のfilenameフィールドの値が、”profiles/standard/standard.profile”となっている行。
どちらも一行なのでチェックボックスにチェックを入れた後エクスポートで一行分のSQLを吐き出して保存しておけばよい。
更新手順１
クリーンインストールしたDrupal7のデータベース内のテーブルを全て削除する。
更新手順２
事前準備２で用意した”モジュールを全て無効にしたDrupal6サイト”のデータベースのデータを空にしたDrupal7のデータベースにインポートする。
更新手順３
Drupal7をインストールしたアドレス/update.php にアクセスする。
settings.php の $update_free_access が FALSE になってるのでアクセスできない、と怒られたら settings.php の $update_free_access を TRUE に変えて再試行すること。
更新手順４
アップデートが無事終了したら、Drupal7をインストールしたアドレス/user にアクセスして管理ユーザー（Drupal6のサイトで使用していたアカウント）でログインする。
無事ログインできれば一応のアップデートには成功している。
更新手順５
最低限のモジュールのみで稼動しているため大変使いづらい（インターフェースは全て英語）とは思うがもう少し辛抱して更新を続ける必要がある。
まずは Drupal7をインストールしたアドレス/admin/modules にアクセスして無効にしたモジュールを有効にしなければならない。
この時点でなんらかのエラーもしくは警告が表示されているかもしれないが致命的なエラーでない限り、作業には支障が無いので気にせず作業をおこなうこと。
注意点は２つ
- コアモジュールのみを有効にすること。なんらかの追加モジュールをインストールしていた場合それが表示されているとは思うが、それには触らないでおく。
- モジュールの依存関係に注意すること。必須モジュールがある場合、先に必須モジュールを有効にし設定を保存した後、再度関連モジュールを有効にする。同時に有効にしようとしないこと。
環境整備手順１
必要なコアモジュール（たとえばBlog機能をまったくつかっていなかったのならば、Blogモジュールを有効にする必要はない）が全て有効になったら、Drupal6 から 7への更新はほぼ終了である。
ここからは発生する不具合を解消し、環境を整えて本来のDrupal7の機能が稼動できるように調整していく。
まずはこれ、
テンポラリファイルが書き込めないというもの。
これはサイトのコピーをおこなう際によく発生するもので、実際にweb上のサイトを更新する場合には発生しない問題と思われる。
原因はファイルシステムモジュールに設定したテンポラリディレクトリへのPathが間違っているか、テンポラリディレクトリのパーミッションが間違っている（書き込み権限がない）か、どちらかである。
今回の場合はローカル環境にデータベースをコピーしたためにPathが違ってしまったことが原因で発生しているため、Drupal7をインストールしたアドレス/admin/config/media/file-system にアクセスし、テンポラリディレクトリの指定を正しくすれば発生しなくなる。
つぎにこれ、
サイトの現状報告Drupal7をインストールしたアドレス/admin/reports/status などにアクセスすると発生する警告である。
簡単に原因を説明すると、profileは内部的にモジュールとして扱われており、インストール時にアクティブ状態で登録される。何らかの原因でそれが非アクティブになった場合、または該当profileがデータベースに登録されたディレクトリに存在しない場合、さらには該当profileがDrupal7の形式に当てはまっていない場合等にこの現象が発生する。
なので、データベースを確認してprofileデータをアクティブ（Systemテーブルないのfilenameがprofiles/～ではじまるデータのstatusフィールドを1にする）にするか、すでにアクティブ状態ならば、該当のprofileのフォルダおよびファイルをデータベースのfilenameフィールドに登録されている場所に配置するか、もしくは該当profileの記述をDrupal7が解析できる形式に書き換えてやれば発生しなくなるわけである。
上の画像を見てもらうと、InstallProfileの項目にJapaneseとでているのが分かってもらえると思う。
つまり筆者はインストール時にJapanese.profile を使ってインストールをおこなったわけだが、なぜかこのProfile はDrupal7が認識してくれない。
上記のような対処法がすべてダメだった場合の最終策として、事前準備３で用意したデータで現在のデータベースの該当データを上書き（入れ替え）をおこなう。
phpmyadmin を使用して、variable テーブルおよび system テーブルの該当行を削除し、用意しておいたデータをそれぞれのテーブルにインポートする。
これでこの問題は解消される。もしデータ入れ替え後に表示が変わらないようなら、一度キャッシュのクリアをおこなってみるといいだろう。
成功すれば警告がでなくなり現状報告のProfileフィールドが表示されなくなる（default profileで登録されるため）。
環境整備手順２
筆者の環境ではまだほかにも不都合が起きているのだが、それを開設する前にもうすこしサイトの使い勝手を良くしておこう。
それにあわせてDrupal7の新しい機能の一部を紹介する。
Drupal7ではモジュールのインストールがオンラインでおこなえるようになった。FTPをつかってファイルをUploadしたりディレクトリのパーミッションに気を使ったりする苦労から解放されるわけである。
Drupal7をインストールしたアドレス/admin/modules にアクセスすると、”新しいモジュールをインストールする”という項目があるはずだ。
翻訳が完全ではないため英語のままの部分が多いが、そこは了承して欲しい。
リンクをクリックするとインストールするモジュールのURL、もしくはローカルからのアップロードファイルを指定する画面が表示される。
モジュールのURLは公式サイトのモジュールページから目的のモジュールを探し出してコピーしてくるとよいだろう。ためしに次のURLをつかってモジュールをインストールしてみて欲しい。
http://ftp.drupal.org/files/projects/l10n_update-7.x-1.0-beta2.tar.gz
tar.gzで圧縮されているが問題なくインストールできる。このモジュールはサイト内のモジュールの翻訳状況をチェックし、新しい翻訳ファイルがあればメッセージを出してくれる。そして更新機能を使うことで必要な翻訳ファイルをひとまとめでダウンロード、インストールしてくれる優れものだ。このモジュールを入れておけば翻訳に関する作業が確実に半減する。
URLを指定し、インストールボタンを押せばあとは勝手にモジュールがインストールをおこなってくれる。インストール終了後にモジュールの管理ページに行き、Localization update モジュールを有効にすることを忘れないように。
Localization update モジュールを有効にしたあと、現状報告のページに行くとTranslation update status の項目が追加されている。翻訳ファイルの更新が必要な場合はここにそのメッセージが表示されるというわけだ。
Drupal7をインストールしたアドレス/admin/config/regional/translate/update にアクセスすれば現時点での各モジュールの翻訳ファイルの状況がリスト表示される。”翻訳を更新”ボタンをクリックすれば各モジュールに必要な翻訳ファイルを自動的にインストールしてくれる。
これだけでほぼ問題のないレベルまで日本語化が可能になる。
翻訳モジュールに絡めて、移行後に設定しなおさなければならない項目に、地域の設定、日付と時刻の設定がある。どちらも難しいものではなく、Drupal6でおこなっていた設定をもう一度設定しなおすだけの単純な作業だ。
各項目には Drupal7をインストールしたアドレス/admin/config/regional からアクセスできる。
環境整備手順３
翻訳の自動アップデートによってユーザーインタフェイスの翻訳がおこなわれ、かなり移行前のサイトの状態に近づいてきたのではないだろうか？
文字が”読める”ということだけで、かなりのストレスが半減するから不思議なものだ。
つぎにおこなう作業はメニューの整備である。
Drupal7から実装された機能にToolbarが存在する。モジュールとして提供されており有効にすると画面の上部に各項目へのリンクが表示される仕組みだ。Drupal6ではナビゲーションというメニューとしてサイドバーなどのブロックに配置されていたものと同等の機能となる。
Toolbarの利点として、画面がおもいのほかすっきりする、各項目へのアクセスがしやすくなる、といったものがあげられるだろう。まあ、なかったとしてもとくに不便でもなかもしれないが。
さて、筆者の環境ではこのToolbarに配置されるはずのメニューがごっそりと消えてしまっていた。
上の黒いバーの部分にメニューが表示されるはずなのだが。
この現象の発生原因として考えられるのは移行前のサイトで構築したメニューデータの不具合である。
階層構造が極端に複雑だったか、ユーザーが設定できるメニューを多く持っていたか、単純にデータベースの破損という原因も考えられるだろう。
何が原因にしろ起きてしまったものはしかたがない（この現象は、移行によって確実におきるわけではない。現に筆者の管理する他のサイトでは、同等程度のメニュー構造を保持していたにもかかわらず何の問題も無くToolbarが表示された）。
筆者は原因の追究よりも状況の打開のほうを優先するタイプだ。状況が改善されれば原因などはたいした問題ではなくなるのだから。
というわけでこの状況を改善する手段はメニューの再構築である。
再構築などというと聞こえがいいが実際は手作業によってメニューの配置を元に戻す（もしくは新しくつくりなおす）わけである。
Drupal7をインストールしたアドレス//admin/structure/menu にアクセスすると現状で登録されているメニューグループの一覧が表示される。
management、user menuといったDrupal7から実装されたメニューグループもいくつか目に入るだろう。
このメニューグループの中から”管理（Administer）”というメニュー項目を探し出す。たいていの場合management かnavigation グループの中にあるはずだ。
この”管理（Administer）”というメニュー項目の下位のメニュー項目がToolbarの項目として表示される仕組みになっている。
したがってこの”管理（Administer）”以下に
環境整備手順４
Drupal6から7への移行もいよいよ大詰めである。
ここまでの手順はほぼすべての読者に共通の作業といえる部分だったが、ここから先は各個人の構築した環境によってさまざまなパターンの発生が予想される。
その全てを網羅することは非現実的であり、不可能なことでもあるので、筆者としては自身が不具合に遭遇したときにまず試す対処手順を示すことで各読者への解決策の糸口、または問題切り分けの判断基準としてもらいたい。
-
不具合を起こすモジュールのVersionは現行のDrupalに対応しているか？
最新版であっても未対応、またはモジュール自体が不具合を抱えてる場合（Fixされていない）もある。 -
モジュールの設定に不備はないか？
pathの設定や数値の設定にイージーミスがないかどうか。設定したはずでもなんらかの原因でクリアされていないか確認する。依存関係がある場合は依存先の設定に不備がある場合も。 -
サーバーの設定に不備はないか？
パーミッションの設定やディレクトリの配置、あるべきはずのファイルが消えている、など。
設定に不備がなく、およそ原因が思いつかない場合
- データをバックアップする
- 該当モジュールを無効にする
- 該当モジュールをアンインストールする
- 該当モジュールを有効にする
- キャッシュをクリアする
それでも症状が発生する
- データをバックアップする
- 該当モジュールおよび依存関係にあるモジュールを全て無効にする
- 該当モジュールおよび依存関係にあるモジュールを全てアンインストールする
- 該当モジュールおよび依存関係にあるモジュールを全て有効にする、その場合依存関係に注意すること。
- キャッシュをクリアする
以上の手順でほぼ8割がたの不具合は解消されるはずだが、ここまでやってもなお発生する場合は、Drupalのシステムモジュール自体に原因があるか、もしくは該当モジュールにバグが存在している可能性も考えられる。
その場合は一時そのモジュールを無効化して運営する。運営上そのモジュールが必須であり代替手段もない場合はDrupal7への移行自体を再考する必要があるだろう。
更新手順６
ローカル環境での移行テストが問題なく完了したならば、今度はweb環境上で、事前準備３以降の手順を繰り返せば良いだけである。
読者各人が滞りなく移行手順がすすむことを祈る。
長文へのお付き合い、感謝。
最近のコメント