スポンサーリンク

先日、Drupal 6からDrupal7へのアップグレードを行ってみましたが、いろいろあって現在はDrupal 6にしています。

Drupal 7がダメというわけでもなく、現行のDrupal 6ではレスポンスが遅いためアップグレードをためしたわけですがレスポンスは間違いなく良くなっているように感じました。
アップグレード方法に問題があったのかレポートにメッセージが大量に出力される状態になってしまったのと、さくらのレンタルサーバでは9月末にデータベースの強化が予定されていますので、その後に完全移行することにしました。
一言であらわすなら「タイミングの問題」です。

情報元:「さくらのレンタルサーバ」データベース機能の強化について
この変更内容は
(1)MySQLのバージョンが5.1⇒5.5
(2)ストレージエンジンがMyISAM⇒MyISAM/InnoDB
(3)データベースの数が1個⇒50個
となります。

バージョン5.5は新規で作成した場合のみになりますので、妻のサイトと自分のサイトのデータベースを分けることができ、これまでリストアのたびドキドキすることもなくなります。
Drupal7への本格的な移行は、10月になってからを予定しています。動画用サイトとブログ用サイトに分離することも可能ですし、サイトが2つあればDrupal7へのアップグレード方法の選択肢も増えるはずです。

Drupal6に戻したとはいえ貴重な経験をしたので、Drupal7へのアップグレードに関して備忘録として残しておきたいと思います。

参考サイト1:Read UPGRADE.txt
参考サイト2:Make an Upgrade Plan

ステップ1:現状把握

アップグレードを成功させるには、稼働中のサイトの状況と現在のDrupal7の開発状況を把握する必要があります。
Drupal6を運用している間も、セキュリティアップデートによりコアのアップグレードを実施したり、モジュールを個別でアップグレードしたりは行ってきましたのでアップグレードの手順自体は何度も経験しています。
しかし、Drupal6からDrupal7へのメジャーバージョンのアップグレードはそれらマイナーバージョンのアップグレードとは状況が大きく異なります。
通常のマイナーバージョンのアップグレードはDrupal管理画面の入手可能な最新版(admin/reports/updates)ページで最新版が存在することをハイライト表示で知らせてくれます。
そのため、アップグレードが可能であることを自動的に知ることができます。
しかし、今回のようなコアのメジャーバージョンのアップグレードでは「何から」「何へ」の情報はDrupal管理画面から知ることはできませんので自分で調査することから始まります。
※サイトによってはまずDrupal6での最新版へのアップグレードが必要になるケースもあります。

1.D7システム要件

まず、現在使用しているサーバの環境がDrupal7のシステム要件を満たしているかを確認します。
DrupalはAMP環境を推奨していますが、開発がすすむにつれサポートしているWEBサーバやデータベースサーバが追加されています。またそれぞれのサポートバージョンも更新されています。
しかし、コアモジュールがサポートしているからといってすべてのContrib(寄贈モジュール)で同じようにサポートしているわけではありませんので、特に理由がなければ推奨環境で使用することをお勧めします。

参考サイト:システム要件

※Drupal公式サイトではありませんが日本語です。

2.D7プロジェクトの存在確認

「何へ」を調査する前に「何を」を把握しておく必要がありますので、まず、サイトで利用しているコアのバージョン、Contrib(寄贈モジュールなど)のバージョン、Themeのバージョンなどを調査する必要があります。
これらの情報はアップグレードの手順を決めるために重要になります。

「何を」について、正確な情報を入手するには、Drupal管理者ユーザでログインしてそれぞれの管理ページにアクセスするのが確実です。

(1)現状報告(admin/reports/status)

コアの現在のバージョンと最新かどうかの状況以外に、データベースやPHPのバージョンが確認できます。
また、PHP欄のリンクボタンからphpinfo()の出力結果を確認できますのでPHPの情報などが入手できます。

(2)入手可能な最新版(admin/reports/updates)

インストール済みモジュールやテーマの入手可能な最新版の情報を入手できます。
一覧からはそれぞれのモジュールの現在のバージョンと最新版の情報さらにプロジェクトサイトへのリンクボタンがあります。
モジュールに含まれる内部モジュールについての記載もあります。
このリンクからプロジェクトサイトへアクセスすればD7の対応状況やD7モジュールの入手が楽になります。

(3)モジュール(admin/build/modules)

実際に有効にしているモジュールが確認できますが、モジュール(プロジェクト)単位ではなくどちらかというと機能単位になります。
(※この一覧に内部モジュールも表示されますが同じカテゴリに表示されるとは限りません)
この一覧に表示されるのは「sites/*/modules」と「sites/all/modules」にモジュールを配置したものすべてが対象になります。(ロードする優先順位あり)
チェックがあるモジュールは有効になっているものですのでサイトで利用されています。
しかし、チェックのないものに関しては様々な状態が考えられます。
・Throttle(スロットル)モジュールが有効の場合はインストールされていても一時的にチェックが外されている状態
・Throttle(スロットル)モジュールが無効の場合は
ディレクトリに配置しただけの状態
アンインストールはしていないが無効にした状態
アンインストールした状態
※この3通りの状態によりDrupalデータベース内にテーブルがあるかないかが異なります。
 

(4)テーマ(admin/build/themes)

利用可能な状態(「sites/*/themes」と「sites/all/themes」に配置されたものすべて)の一覧が確認できますが、モジュールのような最新版の確認はこのページではできません。
最新版の確認は有効にしているテーマに限り入手可能な最新版のページで確認可能です。

Drupalコアのメジャーバージョンのアップグレードでは、データベースにそのモジュール関連のテーブルが作成されているかどうかがポイントになると思います。
モジュールのバージョンアップの際にもupdate.phpを実行すると思いますが、ここで行われる主な内容はデータベースの変換です。
Drupal6とDrupal7で大きくことなるのはこのデータベースの構造が異なる点でDSOライブラリを使用して高速にアクセスできるようになっています。
その効果の恩恵でデータベースのアクセスタイムが短縮できているのだと思います。
そのため、データベース内のテーブルに影響のないモジュールはアンインストールしておいてDrupal7へコアをアップグレードしてから新規インストールしても問題ないように思います。
ただし、各モジュールには依存関係があるので、そのモジュールがないがためにテーブルを利用しているモジュールが正しく動作しないといったことも考えられますので一概にはいえません。
また、プロジェクト(モジュール名)は同じでもDrupal7コアに一部機能のみ吸収された場合(データベーステーブルもそれぞれ独自にもっている場合)、コアに含まれず新プロジェクトもない(D7モジュールがない)状況ではどうすればよいのかが良くわかりません。
たとえばfilefield metaを使用しているケースです。filefield metaはfilefiledの内部モジュールでデータベース上にfilefiled_metaテーブルがあります。
D7モジュールは提供されていませんし、GetID3モジュールと依存関係があります。

以上、現状のDrupal6システムの情報とさらにそれらのDrupal7の状況を確認し、サイトにあったベストなアップグレードパスを選定するための正確な情報を入手してください。
場合によっては、プロジェクト(モジュール)単位ではなく内部モジュール単位やデータベースのテーブル単位で考えなければならないケースもあるかと思います。

3.コアに吸収されたモジュール

Drupal6ではContribとして提供されていた中で需要の高い(スタンダード的になっていた)モジュールはDrupal7のコアに吸収されました。
注意が必要なのは、プロジェクト名(モジュール名)が同じだからといって機能も同じとはいえない点です。基本的な部分のみの吸収のみで内部モジュールなどに関しては吸収されていないケースもあります。

参考サイト:Drupal 6 contributed modules that are in Drupal 7 core

コアに吸収されたモジュールで注意が必要なのはCCK関連です。
CCKでフィールドが作成できますが、作成したフィールドはデータベーステーブル内に格納されているのでD7で利用可能な構造に変換しなければなりません。またフィールド作成時にはウィジットを選定しており、このウィジットはCCKに含まれているものと別モジュールで追加されているものとがあります。
フィールドは対応していてもその中で使用しているウィジットが別モジュールであればそのウィジットもD7版を用意しなければD7システム上では利用できません。
フィールドに関しては、FileFileやImageFIledがコアに吸収されていますが、FileFIeldの内部モジュールであるField Metaはコアには吸収されていないようです。またEmbedded Media FiledはD7モジュール自体が存在していません。
このようにフィールドだけみても、コアに吸収されているものと吸収はされていないがD7版モジュールとして存在するものやD7版モジュールが存在しないものもあります。

ステップ2.ベスト・プラクティスの選定

参考サイト1:Upgrading contributed modules and themes from Drupal 6 to Drupal 7
参考サイト2:Converting 6.x themes to 7.x

大切なデータベース内のデータがアップグレード後に使用できなくなってはアップグレードをする意味がありません。
安全であり、なおかつ手順が簡素化されてている方法がベストだと思いますが、稼動サイトの環境次第のためベストプラクティスはサイトごとに異なると思います。

理想をいうのであればDrupal6システム上で独自のデータのみをエクスポートし、Drupal7をクリーンインストールしたのち先ほどのエクスポートデータをDrupal7システム上でインポートできればベストだと思えますが、そういうパスは存在しないようです。(※一部設定ファイルなどは可能なケースはあるようです)
そのため、アップグレードはモジュールごとにその関連するデータベーステーブルを変換することになるようで、手順を間違えると変換できないもしくは変換後に利用できないことになってしまい、結局、独自のデータは新規で再登録が必要になってしまいます。最悪はテーブル構造自体がおかしくしくなるとDrupal7システムからアクセスができなくなるため大量のメッセージが出力される事態も考えられます。数十程度の独自のデータであるなら一旦削除して新規登録のほうがアップグレード後のトラブルの可能性も少ないように思います。これが数百~数万単位になるとアップグレードなどのプログラムで変換してもらいたいと考えるでしょう。

どんなシチュエーションでも万が一に備えてバックアップを取得することを徹底していれば、最悪の事態は回避できます。
D7モジュールがあるからといってもそれがD6からのアップグレードに対応しているかどうかは別です。
モジュールの状況として考えられるものとそのアップグレード方法は次のとおりです。

1.アップグレード(update.php)対応

Drupalで提供されている通常のアップグレードはupdate.phpによる方法です。
アップグレード対応モジュールには多くの場合、UPGRADE.txtが同梱されていますし、INSTALL.txtやREADME.txtなどに記載があるものもあります。
プロジェクトサイトにD7について明示されている場合もあります。
 

その1.標準的なアップグレードに対応

セキュリティアップグレードなどモジュールのみのバージョンアップ時のように最新バージョンのモジュールを配置したあとにupdate.phpを実行するだけのケースです。
データベースの変換などはすべて新モジュールが担ってくれますので一番楽な方法でもあります。
しかし、D7の安定版モジュールは数がまだすくないのでそういったモジュールは希少ですし、安定して動作するかも不安です。
さらに条件付(一部のみなど)のケースもありますのでよく調査してください。
 

その2.migrate後に標準的なアップグレードに対応

先に書いたCCKのようなケースです。
CCKの場合は、コアをD7にアップグレードしたのちmigrateでまずフィールドを変換してからD7モジュールのアップグレードをする方法です。
CCKとフィールド関連のモジュール(FileFiled、ImageFieldなど)は親密な関係があるのでまずコンテンツのアップグレード前に登録されているフィールドを変換する手順になっています。
このmigrateでおこなっているのは、おそらく、D6と同じフィールド名でD7にフィールドの作成を行っているだけだと思います。
対象となるフィールドは作成されているすべてのフィードになりますので、不要なフィールド(D7未対応なフィールド)はコアをアップグレードする前のD6システム上で削除しておくべきです。
たとえばEmbedded Media Fieldを使用しているフィールド(emfiled)は、migrateできません。あとDateモジュールを導入した際のdateフィールドもmigrateできませんでしたが、これについてはD6のフィールド一覧になく作成しているという意識はありませんでした。D7版モジュールを用意すればmigrateできたのかもしれません。
※データベース上(content_node_filedとcontent_node_field_instance)には登録がありましたがDrupal管理画面から削除はできません。
コアに吸収されたモジュールの場合は、最初はモジュールが無効の状態ですので有効にしなければmigrateできません。たとえばFile、Image、Text、Numberなどです。
 

その3.別プロジェクトで標準的なアップグレードに対応

D6の別プロジェクトに吸収され、そのモジュール間でのmigrateが可能で、migrate後のプロジェクトであれば標準的なアップグレードに対応しているケースです。
知っている限りでは、Feed APIです。これの後継がFeedsになります。FeedsであればD7版モジュールがあります。
ただ、このときに使用するmigrateプログラム(API)はプロジェクト以外のサイトからダウンロードするようなので非公式なのかもしれません。
この場合、FeedAPIではURLを設定したサイトからRSSフィードを取得してサイト内で再利用しているだけでしょうから、登録数がすくなければその設定値だけわかるようにしておけば、わざわざアップグレードしたりエクスポートしなくてもよさそうですが、これまでの取得したフィードデータをすべて再利用するのであればアップグレードパスを選択するべきなのかもしれません。
この辺りの判断は、登録数とアップグレード後の確実性によると思います。

2.アップグレード未対応

このケースのほとんどがD7について全く情報がありません。
明示的に未対応である旨が記載されているケースは少なく全く触れられていないケースがほとんどです。
中には別プロジェクトに吸収されている旨が記載されている場合もあります。

その1.D7版モジュールは存在するがアップグレードには未対応

MediaFrontモジュールではD7版モジュールもありますが、アップグレードには未対応のようでした。
このモジュール自体はD6とD7で同じことができるのかは不明ですが、要件にEmfiledやServicesなどがなかったことやMedia Mover+MediaFrontの例があったことからD6版とD7版は別物と考えたほうがよさそうです。このようにプロジェクト名は同じでも機能がことなっているケースではよくあることだと考えられます。
D7モジュールの多くはまだ安定版は少なく開発途中で機能制限されているのかもしれないので仕方がないでしょう。

その2.D7版モジュールが存在しない

開発がD6版でとまっているケースです。他と依存関係もなくデータベースを使用していないのであればアップグレード前にアンインストールしてD7にしてから考えてもよさそうですが、データベースにテーブルを作成しているとその変換ができないので悩みます。待てば済む話なのか良く似たプロジェクトがありそちらが主流であきらめるしかないのか・・・
D7にすれば不要になるケースも考えられるので、データベースなどのバックアップと可能であればエクスポートを保管してアンインストールというのもありかと思います。

※注意が必要なのはD7版がないモジュールやアップグレードに対応していないモジュールはD7システム上ではアンインストールもデータベースの変換もできませんのでモジュールからデータベースの該当データを操作できません。そのため不要なモジュールはアップグレード前にアンインストールしなければデータベースに残ったままになり、それが動作に影響をあたえることも考えられます。

ステップ3.カスタマイズ箇所のD7対応

モジュールを追加した以外でD6システムにカスタマイズした部分、たとえばテーマテンプレートファイルなどで実現していた機能をD7システム上でも同じように動作するようにしなければなりません。こればかりは実際にD7システムを使ってみないとどうしようもないかもしれません。

ステップ4.テスト環境でアップグレード手順の確立

インターネット上からアクセスできるサーバ上で試すのはセキュリティ上もよろしくありません。
実際、先日のアップグレードはインターネット上のサーバ(いわゆる本番環境)で行いましたが、さくらのレンタルサーバではOptionsディレクティブが使用できないので.htaccessの内容と/index.phpの有無が影響して、ディレクトリ内の一覧が表示できる状態が何時間も続きました。ディレクトリの中には他人にのぞかれると危険な情報がある場合もありますので、ぐだぐだする作業はローカルサーバのテスト環境で行うことをお勧めします。
アップロード時間が短縮できるので作業効率もUPすると思います。

長くなったので実際に行ったアップグレード手順については別の記事にしたいと思います。

スポンサーリンク

この記事が気に入ったら
フォローしよう

最新情報をお届けします

Twitterでフォローしよう

おすすめの記事