はじめに

FacebookでWordPressの限界点という記事がシェアされていて、もっともだと記事に賛成するコメント、いやここは違うというTwitterでの意見など様々ですが、自分なりの感想を書いてみたいと思います。

最初にお断りしておきますが、元の記事と同様にWordPressが使いも似にならないというつもりはまったくありません。何しろ私自身の立ち位置として、BlogやCMSといったウェブサイトの構築を本業にしているわけではなく、あくまでも専ら自分自身の興味と職場での利用を前提にこれらの技術に携わっている立場であり、いわゆるビジネスといった観点で動いている訳でもありません。このような立ち位置で、特定のCMSがダメといったことが言えるわけがありません。

前提はこれくらいにして、記事で触れている内容について簡単に私なりの考えを書いてみます。

DBの問題

ここでは2つの問題について触れています。

1. データベースの構造の問題
2. ウェブサイトのアクセスで発生するデータベースアクセスの問題

まず、データベースの構造の問題ですが、記事では「DB構造が非常にややこしい」と書かれています。Twitterでは複雑ではないとか、決してテーブルの数も多くない、といった意見が出ていました。ざっとWordPressのソースは眺めてみました(読んだとはいえません)が、どんなテーブルを作成するのかはこれだけでは正直よくわかりませんでした。

もう少し余裕があれば実際にWordPressをインストールして確認してみたいところなのですが、そこまではちょいと時間を取れません。

次に、2.の問題は記事では「HTML吐き出し型では無く、アクセスの度にDBにクエリを投げる形」と書かれています。世の中には静的CMSという用語もあるそうですが、PHPベースのCMSの多くは確かにアクセスの毎にデータベースをアクセスしている場合が多いと言えます。

CMSによっては、前回に生成したウェブページの内容をキャッシュして、必ずしも毎回データベースのアクセスを必要としないモノもあります。また、アクセスしてきたユーザーに対して、何らかのカスタマイズしたような内容を提供するといった場合にはデータベースのアクセスが避けられない場合もあります。

つまり、データベースのアクセス自体が問題というわけではなく、いかにしてデータベースのアクセスの負荷を減らすか、言い替えれば毎回同じ様にデータベースにアクセスして負荷を上げないような設定をできるかどうかがCMSを実装する側の力量であると言えます。ある意味では、このデータベースへの負荷はCMSを比較する1つの尺度とも言えるでしょう。

拡張機能の問題

元の記事ではプラグインという用語を使っていますが、ここでは一般的な意味で拡張機能と呼ぶことにします。機能拡張は、CMSの開発者と同じとは限らない第三者が作成したかもしれない、CMS本体の機能に追加や変更を行うソフトウェアです。CMSによっては登録された拡張機能を簡単にインストールできるものもあります。

元の記事で問題としている点は、このような第三者による機能拡張による問題について触れています。

1. 機能拡張を手軽に導入できすぎる。
2. その一方で機能拡張の中身を知らなかったり、脆弱性が残っていないか。
3. 機能拡張の是弱生から問題が起きたときに責任を取れるか。

確かに、機能拡張のような手軽なところから、脆弱性を取り込んでしまうというのは嬉しくないことです。ただ、これは「WordPressのプラグイン」に限らず、いわゆるオープンソースのソフトウェアを利用した時点で背負った十字架という面もあります。CMSの機能拡張という面では、

• 機能拡張を審査してから、ダウンロード可能とする。
• 積極的に登録された機能拡張のセキュリティ検査を行う。

といったことを行っているケースもあるようです。

また、元の記事で「導入したが有効化していないプラグインの脆弱性を突かれて、サイトの中身を改ざんされたという記事を目にした」という記述がありましたが、これは機能拡張にダメダメなスクリプトが含まれていたのでしょう。CMS側の枠組みがしっかりとできていれば、機能拡張のPHPファイルを直接実行(HTTPでアクセス)できる必要はなくせるでしょう。

一方、機能拡張を作成する側にとっては、注意が必要なところをCMS側が面倒をみてくれるAPIを用意してくれているかどうかに注意すべき点です。例えば、

• フォームに入力した内容を検証して渡してくれるかどうか。
• データベースのアクセスにプレースホルダーを使用したくなるAPIを用意しているかどうか。

といった辺りが充実しているかどうかによって、間接的ながら機能拡張の安全性も変わってくるでしょう。

直接のカスタマイズの問題

元の記事の見出しからそのままいただいてますが、本文では以下の点を問題として挙げています。

1. WordPressがPHPで作られていて、最小限のPHPの知識があればある程度のカスタマイズが可能
2. 中途半端な知識は脆弱性の温床
3. WordPress独自関数は整備状況が甘く、命名ルールや挙動すらも統一されていないという惨状

私はよく知らないのですが、1.でのカスタマイズは直接WordPressの元のファイルを直接変更してしまうのでしょうか。もしそうだとすると、そのような方法を前提にカスタマイズするCMSというのは、あまり感心しません。あくまでも本体には変更を加えず、必要なファイルの追加と何らかの設定の変更でカスタマイズできるようになっているべきです。

最後の点はWordPressのことを知らない立場なので何も書きません。

おわりに

以上、元の記事の内容で取り上げている内容を自分なりに整理してみました、といってもどこまで整理になっているのかどうかは定かではありませんが。いずれにしろオープンソースのCMSで同様に抱えている問題というわけではなく、個々の事項についてはCMSそれぞれで違いがあって、オープンソースのCMSを選択する場合の材料にもできると言えるでしょう。

全然まとまってない気がしなくもないのですが、これくらいで止めておきます。