3年くらい Plone を使いつづけたぼくの忌憚のない率直な意見、そして WordPress に移行した理由。
※個人の感想です
Plone のよかったところ
Plone を選んだ理由。こういう部分を評価して Plone を導入した。
導入を検討している人は、お手軽に Plone サイトを作れる ←サービス終了したようです。Ploud で一度試してみるといいかも。Plone は機能自体は悪くないから。
全部入り。
CMS としての比較ではないんだけど、Plone の利点としてよく挙げられることなので一応書いておく。
Plone は WordPress と違い「Python」＋「アプリケーションサーバ」＋「DBMS」＋「CMS アプリケーション」を一度にすべてインストールすることができるので、「PHP」＋「Web サーバ」＋「MySQL」を別途用意しなければならない WordPress より導入そのものは簡単にできる。つまり環境構築の手順自体がほぼ不要で、インストーラをダウンロードして PC にインストールした直後から使用可能になる、のが大きかった。
そのかわり Plone の使えるホスティングサービスは少なそうだから裏を返せば欠点にもなる。これに関しては後述。
フォルダの概念があるため、コンテンツの管理が自然でやりやすい。
Plone は「フォルダ」と「それ以外のコンテンツ」でしっかりと役目が分かれてる。なので普段使っている OS と同じ感覚で自然にコンテンツを管理できて、大体の操作が直感的に理解しやすく迷うことが少ない。
WordPress に慣れてるとそうは感じないかもしれないけど、実際に使ってた身としてはフォルダがあるのとないのとでは違いがけっこう大きかった。
文書管理に使うにはうってつけなのかもな。
ユーザロールの管理がしっかりできる。
個人でやるには特に関係のない話。
設定画面での見た目がかなりわかりやすいので、特に説明がなくても誰をどのコンテンツにアクセス可能にするか、もしくは編集可能にするか、など簡単にかつ細かく管理できる。WordPress でもプラグインを入れれば似たようなことはできるらしくて、一回入れてはみたけど直観的でなくてかなりわかりづらかった（もしかしたら今は改善されてるのかもしれない）。
ワークフローが組み込まれている。
これまた個人でやるには関係ない。
上司が承認しないと記事が公開されないとかそういうやつ。一人で作業する分にはどうでもいい機能だけど企業で使うにはほぼ必須の機能で、これが最初から組み込まれているのはやっぱりデカイ。WordPress の場合プラグインで同様のことができるらしいけど以下同文。
かなり融通の利くポートレット。
WordPress でいうウィジェットのこと。このページにはこれとこれを出して、これは上位階層から引き継いで、このページは別のポートレットを出して…とかそういったことがごく普通にできる。というかできるのが普通だと思ってたから、WordPress ではできなくて困っちゃったんだよね。プラグインで解決できたけど…
あとコレクションの存在が大きい。これのせいでどんなリストでも自由に出すことができて、WordPress に移行するとこれくらいのことがすごく便利だったんだなぁと実感する。
細かい日付の管理が可能。
作成日付や変更日付はもちろんのこと、有効日付や満了日付、開始日付や終了日付など細かく設定できるのがとても便利。よく考えられてると思う。WordPress の予約投稿なんかよりもっと柔軟に自由に日付の管理ができる。ニュースやイベントなどは専用のコンテンツタイプまで用意されているほど。
コンテンツタイプによる情報の使い分け。
上にもちらっと書いたけど、Plone には「コンテンツタイプ」というものがあって、一般的な「ページ」や「画像」などの他に、「コレクション」「ニュース」「イベント」「リンク」など多くの種類が用意されていて、カスタマイズ次第では自分で作成した独自のタイプを追加することもできる（WordPress のカスタム投稿タイプに近いかもしれない）。
ややこしく見えるけど使ってみるとこれが便利で、よく考えられてるなぁと感心すると思うよ。
言うほど重くない。
Plone は CMS の中では重い方といわれているけど、ちょっと多めにプラグインをぶち込んだ WordPress よりは軽い、体感的に。キャッシュ系プラグインを使えば話は変わってくる。
Plone の嫌だったところ
はっきりいって上記のメリットをすべて吹き飛ばしてお釣りが来てしまうレベル。
情報・ノウハウが少なすぎる。
コミュニティは小さく、Web 上の日本語情報も少ないし、関連書籍もほとんどない。あったとしても、後述のように後方互換性が低いため少しでもバージョンが古いと役に立たなくなる場合も多く、読む方にとっても書く方にとってもあまり喜ばしくない状況。
何か迷ったら海外のサイトを巡るしかないんだけど、Plone の場合は海外のサイトですら情報が少なく、ほとんどの場合ソースを調べて自力で何とかするパターンになる。しかも中身が割合複雑なので、少しの修正でもそれなりのコストがかかってしまってツライ。
アーキテクチャが独自すぎるのが問題なんだろうな。Python はいいとしても、Zope に ZODB に ZPT に…ホント情報が少ない。
ZMI（Zope の管理メニュー）についてもユーザに厳しい UI で、なんか見るだけでへこたれてくる。しかもこれを細かく解説してくれるところがこれまた無い。でもこれを使いこなせないと本格的な管理ができない。実際は ZMI が実質上の管理メニューであって、Plone の管理メニューなんかおまけ程度のものでしかないんだよね。
というか Plone の管理メニューの存在意義ってあるの？ロゴ画像や favicon すら変えられない管理メニューって何なんだよ。最終的には Plone の管理メニューは一切開くことがなくなるレベルで使わなくなるから。マジで。ちゃんと管理しようとしたらブックマークに ZMI の URL 入れることになるからね。
それからこれも。他の CMS ではほぼすべて RDBMS を使ってるから、ODBMS である ZODB からのデータ移行は非常に困難。ZMI 経由でエクスポートした XML も複雑怪奇だし、サーバにアップロードした画像や添付ファイルは BLOB で管理されてるからサクッと抜き出せない。1
他システムへの移行は一切考えないという決意を持って導入するか、そうでなければあらかじめ移行に関しての取り組みを進めておくくらいじゃないと厳しい。
移行についてのヒントはこれ。http://www.len.ro/work/plone-to-wordpress-migration/
※ 2008 年の記事であることに注意。これに限らずネット上の Plone の記事には古いものが多い。あなたが見ているこの記事もいずれそれらの仲間入りをするだろう。
移行したときの記事は以下。
アップデートが面倒。
Plone には正式なアップデートのやり方があるんだけど、それについて解説してあるサイトが意外と無くてびっくりする。俺も最初のうちはその方法を知らなかった。
その手順もめんどくさい。なにしろ buildout.cfg をいちいち手で書き直す必要がある。そして buildout 実行時に「-n」オプションが必要。これを忘れると取り返しがつかなくなるくらい壊れたりする。
それ以外にも、たとえばポート番号だけ変えたい場合も buildout をしなきゃいけないんだけど、うっかり「-N」オプションを付け忘れるとやりたくもないプラグインの更新が始まっちゃうとか、いろんな面でミスを起こしやすくなってる。そして一度失敗すると取り返しがつかなくなるくらい壊れたりする。そんなに人為的ミスを起こさせたいのか。
buildout のドキュメントを読むとオプションでいろいろ細かく設定できるっぽくて、「特定のプラグインだけ更新して他は無視する」みたいなこともできそうな雰囲気なんだけど（本当にできるかどうかは知らない）、はたしてこれ見てやる気になるかね？たかがそれだけのことにここまで頑張んなくちゃいけないの？という感じ。
（特にプロダクト絡みで）後方互換性がなさすぎる。
Plone のアップデートは心臓に悪いことこの上ない。
3.x → 4.x へのメジャーアップデートでいろいろと動かなくなったりするのは仕方ないよ。他の CMS でも起こりうる事だとは思う。さすがにそれくらいは覚悟して使ってる。
けど、Plone は 4.0 → 4.1 みたいなマイナーバージョンのアップデートですら大幅に仕様が変わって、何かのプロダクトがエラーを吐いて動かなくなってしまうことがよくある。少なくとも以前運用していたサイトでは、セキュリティアップデート以外では更新のたびに毎回何かしら止まってた。アップデートがすんなり終わったためしがない。手順自体がメンドクサイうえにこれだからな。
上にも書いた通りとにかく情報が少ないので、面倒を起こしたくなければプロダクトを極力入れないようにするか（さすがにプロダクト一切なしで更新に失敗することはないはず）、情報を発信する側になるくらい勉強するしかない。
「Product がいっぱいでカスタマイズ性が高い」はウソ。
Plone 推しのだいたいのサイトに書いてあることとして「機能拡張性が高く Product というアドオンがいっぱい揃っておりカスタマイズ性が高い」というものがある。しかしこれははっきりいってウソ。詭弁。もしくは情報がとんでもなく古い。
確かに公式サイトに行きプロダクトを検索すると数自体はたくさんあるように見える。しかし前述の通り Plone はバージョンアップによりプロダクトが動かなくなることが多く、そうしたものを除外していくと現実的には最新版で動くプロダクトなんて絞られちゃって選択の余地がなかったりする。
そもそも名の知れた CMS の大部分はアドオンやプラグインのような仕組みを持ってるじゃないか。なにも Plone の専売特許というわけではないし、さらに言えば開発のハードルや導入のしやすさなどを考慮するとむしろ他のシステムより劣る面なんじゃないかと思ってる。
そういえば Plone ではテーマもプロダクト扱いなのがまたきつい。公式サイトに行くといろんなデザインのテーマがあるんだけど、ためしに入れてもエラーが出たりして全然動くものがなくて（動かないだけならいい方で、最悪の場合サイトが落ちる）、実質的な選択肢はほとんどなかった。つまり Plone のスキンなどというものは存在しないと考えた方がいい。自分でデフォルトスキンの CSS だけいじってカスタマイズするのがほぼ唯一の道。
運よくエラーなしでうまく動くものがあったとしても今度は本体のアップデート時にエラーが出る危険性がある。スキン変更に対するリスクが高過ぎる。
ただ、4.1 からは Diazo によってスキン周りの事情は多少改善されたから、今後はマシになるかもしれない。
アップデートごとにハードルが上がっている。
Windows 版の Plone には Plone Controller という GUI ツールがあって、以前はそれを使ってポート番号の変更やら何やらの設定ができた。
自分みたいな初心者にもわかりやすくていいと思ってたんだけど、それが 3.x（正確にはいつ頃かわからない）にはサーバの起動と停止しかできないツールになってしまって、各種設定は設定ファイルを手で書き換えてコマンドを叩く方式に統一されて初心者に厳しくなってて…そして 4.2 を入れてみたら GUI ツールそのものが廃止されてた。4.1 はインストールしたことないからわからないけど、どっちかのタイミングでなくなっちゃったらしい。
インストール時に勝手にサービスに登録されるようになったせいで起動・停止の作業自体が要らなくなったという判断なんだろうか。そもそもその辺の説明からしてどこにもないし、最初はサーバの起動の仕方すら迷っちゃうでしょ？これ。普通サーバソフト入れたら起動・停止ができるウィンドウか、最低でもバッチファイルくらいはあるだろうに。
だいたいインストール時の挙動からして違ってきてるんだよ。
以前はインストールの途中で管理者のユーザ ID ・パスワードなんかを入力するようになってたから、初回起動時はそのとき入力したユーザとパスワードでログインして設定やらなんやらできた。ところが 4.2 では入力を促すものは何も出ずにインストールが終わり、デフォルトでは決められたユーザとパスが管理者として設定されているのでそれを使用して（もしくは手動で設定ファイルを書き換えて任意の ID ・パスに変更して）ログインする方式になっている。
しかもインストールが完了するとわけわからん宣伝ページみたいなのが開いたりしてユーザを混乱させる気満々。なのに、Windows 版のユーザが少ないせいか 4.2 以降に言及している日本語のサイトがほとんどなくて、そもそも日本語版公式サイトですらその辺りのことに触れていない。
さらに、2013年 5月の時点で最新だった Windows 版 4.3 を入れてみたら途中でエラーが出てインストールが失敗した！使わせる気ないだろ！今は 4.3.1 が出てるみたいだけど直ってるかどうかは知らん。その前に WordPress に移行しちゃったから。
普通こういうのって「以前はコマンドラインでいろいろ叩かせてましたけど新しいバージョンでは GUI 化したからこっちでも同じことができますよ」とか初心者にもやさしくなるように進化するもんじゃないの？なんでより面倒に、より不親切になっていくんだろう？
新規ユーザの獲得を放棄しているとしか思えない。
対応するホスティングサービスの少なさ。
WordPress、MT、Joomla!、Drupal、XOOPS Cube 等の PHP + MySQL で動くシステムに対応するホスティングサービスは山ほどある。というか今はこの構成こそがメインストリームで、各社各プラン色々検討して必要なサービスを選定することができる。ボタン一発で WordPress をインストールできる機能を導入しているところも多い。
ところが Python + Zope + ZODB に対応してあるところを探すとなると…。現実的には VPS を使う以外の選択肢はほぼ無いと言っていい。もしくは自前でサーバを用意して運用するか。
場合によってはこれが導入の一番の障害になる可能性もある。
結果、将来性を全く感じることができず不安だけが募った。
そんなことがいろいろ重なった結果「将来的に廃れたりサポートが切れたりして動かなくなったらどうしよう？」という不安な気持ちから「こりゃだめだ、ポシャる前に移行しなければ」という焦りのようなものに気持ちが変化。「早いうちに別システムに移行しちゃおう」と考えて、改めて移行対象システムを吟味。
結局、高いシェアを誇りノウハウも十分で将来性に不安が少なく、しかもたまたま導入の経験があった WordPress に移行を決定した。だったら最初からこれにしときゃよかったよなぁ。
WordPress のいいところ
しばらく使ってて思ったこと。
情報がいっぱいある。
とにかくこれに尽きる。いろんな情報がいろんなところに散らばっているし、最新情報についても早いうちに広まってる印象。WordPress 自体の情報についてもそうだけど、PHP そのものの情報量も多いからな。
ユーザの活動も活発で、いかにも勉強したくなるような活気にあふれている。
修正が簡単。
PHP はいい！情報の少ない ZPT と違って直したいところをさっさと直せる。ソースを見て何がどうなっているか理解しやすいのもいい。俺は Java ラーだけど PHP は簡単でとっつきやすいから意外と直せる。学習コストの低さは驚異的だわ。
プラグインの仕様についてもわかりやすく、サンプルも豊富なためハードルが低く感じた。簡単な機能ならプラグイン探して試行錯誤するよりガンガン自作した方が手っ取り早いかも。
ユーザーフレンドリーな UI。
最初管理画面見たときは「項目多すぎ！なんじゃこりゃ！」って思ったけど、慣れると結構きれいにまとめられててとても使いやすい。見た目もきれいで、編集画面なんかはパネルの配置も自由に変えられたりしてかなりユーザに優しい。
Ajax も的確に使われていて、いかにも今どきのツールという感じがした。
管理画面上でアップデートができる。
テーマやプラグインのみならず、本体のアップデートまで Web 上で行えるのは Plone に慣れた身としては画期的だった。それどころか更新通知まで来る。
もちろんバックアップ等は取っておく必要はあるけど、バックアップを作成できるプラグインなんかを入れてしまえば解決。
手順自体も簡単なので、単純な作業ミスで環境が壊れることがないのがとても優しい。
テーマが超いっぱいある。
なにしろ Plone にはスキンについて選択肢がほとんどなかったし、CSS のカスタマイズも素人には限界があった。一度直そうと思ったんだけどあまりにも複雑怪奇すぎて部分的な修正で精いっぱいだったんだよなぁ。プロの Web デザイナの人とかにとってはそうでもないのかな。
ところが、メニュー周りだけのささやかな修正でさえ 4.0 → 4.2.5 にアップデートした際にレイアウト崩れが起きてしまい、結局手を入れた部分がガタガタになってしまった。DOM ツリーか、もしくはデフォルトの CSS に手が入ったんだろうな。こういうところが嫌なんだよ！
でも WordPress なら無料のテーマから有料のテーマまでものすごい数がある！レスポンシブデザインに対応したものもいっぱい（一応 Plone にもあるにはあるけど少ない。記事書いてる時点で1つか2つ）。いくつか試したけど特にエラーも出なかったし。これだけでも WordPress を選ぶ価値はあるんじゃないかってくらいのもんだ。
ただ、基本機能自体は劣っているのは否めない。
Plone と同じことをしようとするとどうしてもプラグインの導入やカスタマイズが必要になってくる。言い方を変えればカスタマイズすればほぼ同じことができるということだけど、基本機能として組み込まれているのとそうでないのとではやはり違うわけで。
でも Plone だって足りない部分をプロダクトで補って使ってたわけだし、これ自体はどの CMS にもついて回る問題だろうから、だったら心臓にやさしい WordPress を使いたいなぁ。カスタマイズのコスト自体が低いこともあるし、WordPress は後方互換性に注意して開発されているので安心感が違う。
おまけ：他の CMS を試した時の感想
Joomla!
最初はこっちを導入しようかと考えてた。というのも WordPress よりも高機能で汎用的っぽかったんだよね。シェアも WordPress に次ぐ感じだったしいいかなと思って。
でも開発機に入れて動かしてみるとどうもわかりづらい。管理画面がレスポンシブでスマホ対応というのはスバラシイんだけど、各種操作が直観的でないというか、モジュールがどうとかポジションがなんだとかのつくりが複雑でいまいちピンとこないというか。
わからないことがあまりにも多いのでいろいろ検索してみても同じサイトばっかりヒットする。しかもそのサイトの記述も古いぞ…。こりゃあまり情報は多くなさそうだ。
特に「Joomla!女子部」とかいうサイトは、とある Joomla 構築業者が宣伝目的で立てたサイトであることが丸わかりで、全体的に嘘くさく胡散臭さで満ち溢れており、こんなんでユーザが増えるとでも思ってるのか本気で問いただしたくなる内容。むしろ Joomla! 界隈にとってマイナスになっている気がする。
テーマもいっぱいあるようで実は最新バージョン対応のものはそんなになく（3.0 対応と謳っているのにエラーが出たりすることも多かった。20ほど試してエラーが出なかったのは半分に満たなかった）、かといってわざわざ古いバージョンを導入する気にもならない。これは Plone と同じ苦労をすることになりそうだと考え不採用が決定。
ImpressPages
次にこれ。比較的新しい CMS らしく、ドラッグ＆ドロップでアイテムを配置するなどかなり楽しそうだったので、その時点の最新バージョン 3.0 を落としてインストール。
しかしいざ管理画面を開いてみれば、どのアイテムもドラッグすらできない。Chrome が悪いのかと思い IE や Firefox でも試したがすべてダメ。にっちもさっちもいかず、試しにひとつ前のバージョンである 2.6 を入れてみたらなんとちゃんと動いた。
「最新版を入れたら最大の売りであるはずの機能が動かない」というまさかの状態だったことに加え、スマホやタブレットで編集するのが厳しそうというところ、あと日本語情報サイトの更新が止まっていて先行き不安だったというところもあり、大していじらずに不採用が決定。
Drupal
入れてみたらあまりにも何もなさ過ぎて絶望感が襲ったためそのまま削除。あの初期テーマは寂しすぎる。やめた方がいいんじゃないかな…。
- 元のファイル名や拡張子が変更された状態でファイルに保存されてしまうので復元に非常に手間がかかる。以前のバージョンではこんなことはなかった（オリジナルのファイル名・拡張子で保存されていた）んだけど、どこかのアプデから内部処理が変更されてしまったようで急にわかりづらくなった。 ↩