僕がDrupalをやめた理由

2009年08月11日 23:50

Druplicon

2005年にある個人サイトに導入したDrupal。最初はその可能性と拡張性の高さに感動していたものの、実際に運用してみると困ることもあり、本サイトの立ち上げにあたって、改めてCMSを評価・選定しました。

Drupalは良い面について語られることが多いので、たまには短所について取り上げておくのも良いかと。
そこで、このサイトにDrupalを採用しなかった理由についてまとめてみました。

【デザインの自由度が低い】

Drupalでは、サイト内の全ページに同じテンプレートが適用されます。これはブログ的な発想で、デザインにこだわりたいサイトや、セクションによってコンテンツの性質が変わる(からこそUIやテンプレートを変えたい)サイトには不向きです。

もともとコミュニティサイト向けのCMSであり、それ以上の使い方はハックでしかないのかもしれません。テンプレートにはPHPでロジックを書けるので、PHPコードを書けば何でもできますが、長期的なメンテが大変になってしまうので避けたいところです。

【画像を管理できない】

Drupalの管理対象はページのテキストコンテンツのみで、画像はFTP等で別アップロードする必要があります。Web上でアップロードできるモジュールもありますが、それでも管理対象外であることに変わりなく、バージョン管理や公開期間の設定、メタデータ(画像に関するプロパティ)保存などはできません。どの画像がどのページで使われているかの関係性も管理されないので、ファイル名を変えるとリンク切れが発生します。

【リンクが切れやすい】

ページ間でリンクを貼る場合、リンク先のURLをベタ書きする必要があります。WYSIWYGエディタなどのモジュールを使ってGUIでリンク先ページを選んだりしても、最終的にはURLがベタ書きされたHTMLが生成されます。

このため、リンク先ページのURLを変更したり削除した場合は、そのページへのリンクをすべて探し出して修正しないとリンク切れが発生してしまいます。

【カスタマイズが難しい】

Drupalはシステムのアーキテクチャがしっかりしているので、拡張性とカスタマイズ性が高いです。

だからこそ、しっかりと設計書と実装の記録を残さないと、後で何をどうしたか思い出せず、アップグレード時に再現できなくなってしまいます。

【動作が遅い】

Web担当者ForumのDrupalはいろいろチューニングしているそうですが、レンタルサーバーにインストールした個人サイトでは、システム的な自由度がありません。私の場合は後述の理由でDrupal 6や7にメジャーアップグレードすることができなくなったので、もうあきらめ状態です。

【モジュールの開発が頓挫することも】

Web STRATEGYの連載でも少し書きましたが、Categoryという画期的なモジュールを使いたいのでDrupalを選んだようなものです。

ところが、そのモジュールの管理人が引退して開発が頓挫。新しい人がようやく引き継いだと思ったら「大きなバグが残っているので作り直す」と宣言し、また音沙汰無しになりました。その間にDrupalは5から6にメジャーアップグレードしているものの、Categoryモジュールは6に未対応なままです。何百ページのカテゴリ設定を手で直すわけにはいかないので、Drupal 5を使い続けるしかありません。

モジュールでいろいろ機能拡張できるのは魅力的ですが、個人に依存したマイナーなモジュールは開発やサポートが安定しないので、要注意です。頓挫したら自分が開発を引き受ける、くらいの技術力と意気込みが必要かもしれません。

【バージョンアップが頻繁でついていけない】

2年半の間に19回もバージョンアップし、ほぼ40日に1回のペースです。

ファイルとデータベース(MySQL)を完全同期してテスト環境を構築してからバージョンアップの動作確認をし、問題なければ本番適用するようにしているので、Windows Updateのように1クリックで、というわけにはいきません。しかも、機能追加や改善ではなくセキュリティ対応やバグ修正が多いので、弱小個人サイトの管理者にとっては前向きなモチベーションになりません...。

が、これは良いことではあります。脆弱性が見つかるとすぐに対策版がリリースされるので、システム管理の面で安心できます。また、Drupalはコアな部分(Drupal本体)を最低限の共通機能のみに絞込み、モジュールをいろいろ入れてカスタマイズするタイプのCMSです。そのコアな部分が頻繁に仕様変更されると、モジュールやサイトの開発者が変更対応に追われてしまうので、コアは基本的にバグ修正のみで、メジャーアップグレードで新機能追加やアーキテクチャ見直しを行う、というのは正しい考え方だと思います。 

【成長速度が遅い?】

国内外で画期的なCMSや直感的なCMSが次々と登場する中、Drupalは進化が遅いような...。5から6、6から7、とメジャーアップグレードはするものの、機能・操作・パフォーマンス面ではあまり良くなっていない?現状維持が基本のレガシーなツールになりつつあります。コミュニティが大きくなったので、大胆な変更や改善の舵取りができないのかも?

まとめると、

機能面

  • デザインの自由度が低い
  • 画像を管理できない
  • リンクが切れやすい
  • カスタマイズが難しい
  • 動作が遅い

体制面

  • モジュールの開発が頓挫することも
  • バージョンアップが頻繁でついていけない
  • 成長速度が遅い

と、いろいろ文句を並べてしまいましたが、万人向けの最高のCMSは存在しません。それぞれのCMSが持つ特徴が、自分のサイトや組織にとって長所になるのか、短所になるのか、が重要ですね。

逆にDrupalの何がスゴくて採用したのか、という視点のレビュー記事も近いうちにポストします。

1/20追記

半年前のこの記事へのアクセスが増えたので、その後について追記しておきます。

年末年始のまとまった時間を使って、ようやくDrupal 6にアップグレードしました。

  • レンタルサーバーのMySQLが5も使えるようになった
  • 重視していたCategoryモジュールのRC2が12月にリリースされた
  • いずれはDrupal 7にもアップグレードしたい

という理由のためです。

インストールしていた27のモジュールのうち、5つのモジュール(Amazon associate tools, Node Teaser, TinyMCE, Google Search, Textfield Autocomplete)が6に対応していないので、別のモジュールに差し替えました。コアやモジュール、テーマをカスタマイズしたのは4年以上前で、メモも残していなかったのですっかり忘れてしまい、完全にクリーンな状態から設定し直しました。あまり力を入れていないサイトなので、今回はなるべくデフォルト状態のままを目指しました。1100ノードを超える既存コンテンツを引き継ぐのに苦労し、SQLでデータを直接エディットしつつ作業を終えて、安定稼動しています。パフォーマンスも若干改善。これでようやく、マイナーアップデートにも気軽に対応できる状態になりました。。

狙っているのはDrupal 7化です。CCKやImagefieldと同等の機能がコアに統合され、Categoryモジュールも必要なくなりそうです。コアやモジュールのアップデートも管理画面から行えるので、メンテの負荷が減るかも、と期待しています。企業のサイトの場合は時間やお金をかけてしっかり運用しますが、私がDrupalを入れたサイトは基本的に放置であり、コンテンツを投入するのはPHPどころかHTMLも書けない一般ユーザーなのです。要件(どんな状況で何を期待するか)によって、選ぶべきCMSは変わりますね。