現在地

Movable TypeとDrupalの魅力とは?

作成者:assi 作成日:木, 12/17/2015 - 15:56

本記事はMovable Type Advent Calendar 2015及びDrupal Advent Calendar 2015の17日目の記事です。

普段は仕事でMTばかりやっていますが、最近趣味でDrupalを使い始めました。
どちらのCMSもそれぞれ充分にユニークであり、魅力的な特長があると思っています。

本記事では2つをとりとめもなく比較しつつ?魅力の紹介をしていきたいと思います。

ちなみにDrupal歴は数ヶ月のまだまだ初心者なので、至らぬ点は多々あるであろうことをご了承ください。。。
間違いがございましたら、ご指摘くださいませ。

目次

それぞれの特長

まずはそれぞれの特長について、簡単にまとめておきたいと思います。

MT

もともとブログベースのCMSであるため、初期状態でとても簡単にブログを構築することができます。
ウェブサイト内に子としてブログを設置する形で、共通・ブログ独自のデータをそれぞれ管理します。

メジャーバージョン6より、Data APIを用いてMT内のデータにREST/JSON形式で取得可能になりました。
これにより、ウェブサイト内外に関わらずコンテンツを管理・利用する、という方向にシフトしてきています。

Drupal

要件に合わせたCMSを作成するためのCMSのような位置づけで、普通のウェブサイト・ブログからECサイト、ポータルサイト、ネイティブアプリまで何でも作成可能です。
その柔軟性、拡張性からアプリケーションフレームワークとも呼ばれますが、モジュールで機能拡張することを前提に設計しているため、コア自体はとてもスリムです。

同じくメジャーバージョン8より、RESTによるデータアクセスがデフォルトで可能になりました。

投稿タイプについて

MT

基本的に

  • ウェブサイトのウェブページ
  • ウェブサイトのブログ記事
  • ブログのウェブページ
  • ブログのブログ記事

の4つしかありません。
いわゆるカスタム投稿タイプがないので、専用のカテゴリやブログを作成することで、その問題を解決することはままあります。
慣れればどうってことないんですが、運用が始まり要件が追加されるにつれてどうしても複雑になりがちなので、ここは今後のバージョンアップに期待したいところですね。。。

ただし逆に言えば、その4つに限られているからこそ、分かりやすく、学習コストの低さを実現できているのだとも思います。
また、そこまで数が多くなければ、インデックステンプレート(テンプレートと出力ファイルが1:1になっているもの)で自由にファイルを生成して対応することもできます。
MTインデックステンプレート一覧画面

1ヶ月ほど本気で向きあえばほぼ手に馴染んでしまうところが、MTの好きなところです!

Drupal

Drupalの投稿タイプは、デフォルトで用意されているものこそブログ記事と固定ページですが、それらはノードという1つの基底タイプから派生しています。
なので後からいくらでもオリジナルのものを追加でき、またブログ記事・固定ページは「用意されている」に過ぎないので、削除することも可能です。
(管理画面に広告が出ているのは私のミスですよ!)
Drupalコンテンツタイプ設定画面

これがMT脳の人間からするとびっくりしたポイントで、Drupalがいかに拡張性と柔軟性を第一に設計されているのかを思い知りました。
Drupalすごい。

カスタムフィールドについて

MT

MTのカスタムフィールドの特長は、「作成できる対象が多い」ということと、やっぱり「わかりやすい」ということでしょうか。
ウェブページやブログ記事等のコンテンツタイプにカスタムフィールドを作成できるのはもちろん、ウェブサイトやブログ、ユーザーの設定画面にまでカスタムフィールドを作成することができます。

これが実はなかなか重要なことで、運用中に変更があると思われる項目をカスタムフィールドにして設定画面にまとめておくことにより、お客様にもわかりやすいMTを構築することができます。
MTカスタムフィールド画面1

一方でMTのカスタムフィールドはシンプルな分、基本的に1つのカスタムフィールドに1つの値しか保存することができません。
端的に言えば「画像1」「画像2」と1つずつ作成しなければならないので、横展開しているサイトほどカスタムフィールドの作成が大変になります。
MTカスタムフィールド画面2

カスタムフィールドをより高機能に、便利にするプラグインは、藤本壱さん(FreeLayoutCustomField)やアイデアマンズさん(FlexField)により既に開発されています。

Drupal

Drupalのカスタムフィールドの作成方法はMTと異なり、先に対象のコンテンツタイプの設定画面へ行き、そこで設定を行っていきます。
既存のフィールドも同じように「用意されている」に過ぎないので、Title以外は削除可能です。
Drupalカスタムフィールド画面1

またDrupalで再度驚いたのは、「値の数」を調整するプルダウンが予め用意されていたことでした。
1つのフィールドを用意するだけで、幾つでも値を格納することができます。
Drupalカスタムフィールド画面2

ただやはり何でもできてしまうがゆえに、MTと比べて設定が少し複雑と感じています。
未だに、完全には使いこなせてません……(あんまり時間も取れてない私が悪いんですが)

アーカイブ出力について

MT

MTのアーカイブマッピングが優れている、ということは至るところで話されており、私自身、何度もこの柔軟でパワフルなアーカイブ出力の機能に助けられています。
固定的な文字列やMTMLを使用して規則的にアーカイブパスを量産する、という方式で、1つのテンプレートを用いてページ種別ごとにパスを変える、といったことも可能です。
MTアーカイブ出力画面1

実はアーカイブパス自体に条件分岐を記述して、「特定の条件下でパスを変える、出力しない」等のより高度なファイル出力制御をすることもできます(あまりおすすめできる方法ではありませんが)。

Drupal

DrupalはDrupalで、アーカイブ出力を司る非常に強力なモジュールのViewsが存在します。
というよりもViewsの機能は全てのデータを対象にフィルターをかけ、適合したものをリスト表示するというものなので、アーカイブ出力という言葉には留まりません。
MTが基本MTMLを記述して出力するのに対し、Viewsは基本GUIで出来てしまいます。
キャプチャ画像はD7なのでモジュールとして追加していますが、D8からはコアに組み込まれました。

今回試しにこのようなページを作ってみましたが、1行もコードを書きませんでした。
http://www.thinkingsalad.com/taxonomies
5分ほど、こちらの設定画面でポチポチしただけです。
Drupalアーカイブ出力画面2

もちろん、これをより望むような形式にするにはコードを書く必要があると思いますが、GUIだけでここまでできる(AJAXのオプションまでありますし……)のはさすがDrupalです。

参考:ViewsがわかるとDrupalがわかる! Vol.1(ANNAI 紀野さんによるスライド)

機能拡張について

MT

MTCMSPowerCMSのようなセット的な考え方もありますが、基本的にMTのプラグインは他に依存しません。

Drupal

対してDrupalのモジュールは、他のモジュールと依存関係を持つものも少なくありません。
これも、Drupalに触れて驚いたことの1つでした。さすがOSS。
もちろんモジュール管理画面では、どのモジュールに依存して動作するかはきちんと明記され、かつチェックも走っています。
Drupalモジュール設定画面

CLIについて

MT

Movable Type for AWSに限りですが、yum updateでアップデートを行うことができます。これは凄く便利ですね!

Drupal

Drupalをコマンドラインで操作するDrushというものが存在します。
こちらもコアのアップデートをはじめ色々とできますが、いかんせんまだまだ使いこなせていないので、参考リンクを貼らせていただきます。

Drush コマンドリファレンス 日本語訳 | Umi->d

we just drush cc all!

ふんわりざっくりしたまとめ

MT

どうしてもMTの決まりきったデータ構造からは逃れられないため、かなり複雑なことをしようとしたり、MTであまり想定されていないような使い方をしようとすると、設計が担当者独自の発想力に依存する形になりがちです。
ただしMTMLはJSやPHPとも連携できるため、それら(どうしても不可能な場合はPerlも)でどう解決するか考えるのは、とても楽しい作業でもあります(もちろんその体制がプロジェクトとしてどうか、プログラムの設計としてどうかは別問題ですが)。

MTMLはモディファイアという形で様々なオプションが使用でき、中には
「なんでそんなピンポイントなものまで…」
というものもあります。
初心者でも扱いやすいのに、上級的なテクニックも生まれるほど奥深いMTML(およびそれを含めた設計)は本当によく考えられており、きちんと昨今の開発者のニーズにも応えてくださっているな、とひしひし感じます。

それでいて、管理画面はシンプルで分かりやすいので、運用者にとってもあまり負担になることはありません。

MTの魅力はやはり、開発者・運用者双方があまり高くないハードルで、かつ不自由なく扱えるバランスの良さだと思っています。

MTML大好き。

Drupal

Drupalの魅力は、やはり何といっても高度にモジュール化された設計の素晴らしさでしょう。
私のようなペーペーが今更言えることは何もなく、というかそもそもまだしっかり理解し切れていないところもありますが、学べば学ぶほど本当に洗練されていると感じています。

「Drupalにできないことはない」とはよく聞く言葉ですが、その言葉はきちんとソースコードに裏付けされています。

学習コストの高さはやはり感じていますが、そこはきっと設計やプログラムではなく、コミュニティのレイヤーで解決すべき問題なのでしょう。
コミュニティの方々には、いつも大変お世話になっていますm(_ _)m

それに、あくまで一つのレベルの目安ですが、Drupalの設計や、そこに使われている技術をきちんと理解できるくらいのWeb屋じゃないと、今後生き残る、もしくは他者と差別化を図るのは難しいと考えています(もちろん、他にも戦略はたくさんあると思いますが)。

まとめ

以上、かなりの長文になってしまいましたが、自分の視点から両CMSの素敵と思われるところを紹介してきました。

そもそも設計思想が違い過ぎますし、静的/動的出力の違いで同じ選択肢に並ぶことも稀なので、単純に比較できるものでもありません(MTは一応動的もできますが)。
どちらにも強みがあり、またユニークな魅力があるため、やっぱり私はどちらも大好きです(結論)。

尊敬できるほど素敵で優秀な方も両コミュニティにたくさんいらっしゃいますので、何と言いますか、本記事が何かのきっかけになれば幸いです。

参考書籍

本記事を書くにあたり、下記の書籍を参考にいたしました。
いずれもバージョンは最新ではありませんが、いまだに参考になる、色褪せない良書です。

categories:

関連記事