「WordPress プラグイン開発のバイブル」買いました

WordPress プラグイン作者としては買っておかねばと思い、先月発売された「サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル」を買いました。 一応プラグイン作者なので知っていることも多いためざっと読んだだけですが、感じたことをまとめておきます。

  • プラグインをつくるために必要な知識が一通りまとまっています。 面白いと感じたのは、技術的な面だけでなくライセンスや収益モデルなどビジネス的な側面に関わることもまとめられていることです。
  • 私はプラグインの作り方を洋書で学びましたが、これからプラグイン作成を行おうとする方には間違いなく本書の方がお勧めです。
  • 強いて挙げるならば、Ajax 関連と Cron 関連もあると良かったかも知れません。
  • ただし、WordPress のコアの部分の解説は本書の範囲ではないので、そこは期待してはいけません。

どれぐらいの数の日本人がプラグイン開発に興味を持っているのかが想像できないのですが、興味があれば是非本書を手に取っていただきたいところです。

以下は私の個人的な意見や補足です。

  • 公式レポジトリへプラグインを登録し、ある程度メンテナンスもしていこうと考えているのであれば、情報としては日本語サイトではなく本家を参照するようにしましょう。
  • 怖がらずに英語でメッセージやドキュメントを書き、サポートも WordPress.org 内に用意されるそのプラグイン用サポートページを第一の場にするといろいろなものが得られるはずです。
  • 私は紙の本を買いましたが、Kindle で慣れているのであればそちらの方が検索したりするのには便利かも。 もう少し Kindle 版が安くなればなあ…。
  • gettext については msgmerge を知っていると良いかも。私の書いた記事はこちら。
  • 公式リポジトリへの登録には subversion が必要ですが、普段は GitHub を使っていて WordPress.org への登録のみ svn という人も多いようです。 そういう人は大抵最新ファイルをコピーして svn commit するスクリプトを使っているようです (検索すればサンプルが見つかるはず)。 ちなみに私は git-svn 派ですが、ちと面倒なので少数派です。もし、git-svn で行くのであればこちらの記事を参考にしてください。
  • 本書のコラムにもありますが、Settings API について学習すると良いと思います。 ちなみに私のプラグインでは、管理画面で入力された値のチェックは admin_init のコールバック関数内で行うのではなく、Setting API に含まれる register_setting() の第 3引数で指定する関数内で行っています。 このチェックでエラーがあった時は add_settings_error() を呼ぶようにしています。

何にせよ、本書の影響で日本人が作ったプラグインが公式リポジトリにもっと登録されるようになれば良いと思います。

SWE の JavaScript プログラミング

Standard Widget Extentions (SWE) という WordPress プラグインを作って公開しています。 先日は SWE のスクロール時固定機能 (Sticky Sidebar について「そこらへんに落ちているサンプルコードとは動きが違うんだよ」という話を書きました。 今回は JavaSciprt 的にいろいろ苦労したところを書いておきます。

なお、ここで紹介している関数は特に断りがなければ jQuery の API です。

幅やマージンの %指定

レスポンシブ Web デザインでは以下のように width や margin がパーセント表示で比率指定されていたりします。 テーマ製作者はピクセルの比率から値を計算しているのでこのように結構エグい小数になっていたりします。

.content-sidebar {
  margin-left: -29.04761904%;
  width: 29.04761904%;
}

ここで一つ問題となったのが、width が %指定のままで position = fixed にして位置を固定すると比率の基準となる要素が変わるため幅が変化してしまうことです。 これを避けるには一度取得した値を再度設定しピクセル値で固定することです。

var w = $('#sidebvar').width();
$('#sidebar').width(w);

では、ブラウザがリサイズされたときはどのようにすれば良いでしょう？ リサイズ前の幅のままではレイアウトが意図通りになりません。しかし、新しい幅はどうやって計算すればよいのでしょうか？ 比率を取得するために CSS ファイルを自力で読まねばならないのでしょうか…。

わかってしまえば簡単なのですが、一旦 width をクリアすることで解決します。

$('#sidebar').css('width', '');

jQuery API リファレンスをよく読むと書いてあるのですが、空文字列に指定するとこれまでの API 経由で設定したスタイル指定をクリアし CSS ファイルの記述通りに振る舞うようになります。まとめて書くと以下の様に一旦クリアし再度取得したピクセル値で設定することになります。

$('#sidebar').css('width', '');
w = $('#sidebvar').width();
$('#sidebar').width(w);

一瞬なんだかわからないコードですよね。

サイズ関連

.width() で取得した値と .css(‘width’) で取得した値は異なることがあります。 一方が 250 なのに他方は ‘310px’ などと返ってきたりします。 型の差は置くとして、異なる数値になっているので困ります。 これは box-sizing プロパティのせいだったりするのですが、この値を見て動作を変えるようなコードを書くのはいろいろ面倒です。

それで結局どうしたかというと以下のようにしました。

  • 位置計算等に使用する幅の取得は .outerWidth(true) を使って、いつでも border や margin 込みの値を用いる。 jQuery の .width(), .innerWidth(), .outerWidth() は box-sizing の値に依って動作が変わることはない。
  • 先述の width の操作についてのみ、取得・設定とも統一して .css() で行う。

このように jQuery の関連関数は box-sizing プロパティに依らず使えるので便利です。

座標関連

座標取得には document を基準として位置を取得できる .offset() が便利でした。 ただし、以下のように .css(‘top’) を使って操作するときとで対象としている座標の位置が異なるので注意が必要です。

jquery-offset

ちなみに position = absolute のときの基準要素を見つけるには .offsetParent() が便利です。jQuery にはいろいろな関数が揃っていますね。

position と z-index

position = static だと z-index が指定されているテーマで不具合を起こすため、position = static を使うのでなく position = relative で (top, left) = (0, 0) としています。

小数点の扱い

サイズ関連でもう一つ困ったのは小数の扱いがブラウザによって異なることです。 整数 (ピクセル値) に直す時に四捨五入なのか切り捨てかみたいな話です。 深入りしたくなかったこともあり細かい挙動は忘れてしまったのですが、気になる方は検索してみるとこの話題を扱っているサイトが見つかると思います。 SWE では先の .css(‘width’, ”) を使うテクニックにより、これらの問題を避けています。

というわけで、Standard Widget Extensions のサイドバースクロール時固定機能はその辺のサンプルコードと違うのです！ 興味がわいた方は使ってみてください。

誰かがサイドバー固定のコードは簡単と言ってたけど

WordPress 用プラグイン Standard Widget Extensions (SWE) をリリースしていますが、このプラグインはスクロール時にサイドバー (Widget Area) を固定する機能 (Sticky Sidebar 機能) を持っています。 世の中にその動作を実現するサンプルコードは溢れていますが、よく見るとそれらは動作条件が限られていることがほとんどです。 プラグインとしてリリースするにはより汎用化して幅広い条件で安定して動くことが求められます。 今回は SWE の Sticky Sidebar 動作のこだわりを説明します。 この記事を読むと、きっとあなたもこのプラグインを試してみたくなるはず！

止まる位置を自然に

SWE ではウインドウサイズと比べて長いサイドバーと短いサイドバーで表示位置の基準を変えています。 長いサイドバーであればサイドバー下端が画面下端となって止まります。 短いサイドバーはサイドバー上端が画面上端で止まります。

上端で合わせる動作のみのプラグイン／コードが多いと思いますが、SWE はより自然な動作となっています。

フッターが来たら再び動き始める動作

サイドバーが固定されてから更にスクロールし続けると、フッターとかぶさらないように再度サイドバーが動き始めます。 SWE では、この動作を開始する位置はコンテンツ要素とサイドバー要素の位置と高さから計算します。

スクロール再開位置の決定方法は他にも以下のようなやり方があると思いますが、それぞれ欠点があり、特に 2本のサイドバーを使っているテーマでは困ることになります。

フッター要素の位置とスクロール量から再開位置を計算する
レスポンシブ Web デザインでは、画面サイズに応じてサイドバーがフッター化する等でコンテンツ要素の直後にくる要素が変わってしまったりします。 それに合わせて計算に用いるフッター要素を変えるような仕組みがないとうまくいきませんが、この実装はなかなか難しいと思います。
予めページ最下端からのマージンを決め数値をセットしておく
やはりレスポンシブ Web デザインでコンテンツの後の要素が増えていくと固定されたマージンでは困ることになります。

というわけで、これらの方法よりも SWE の方法の方が優れています。

レスポンシブ Web デザイン対応

このように SWE ではレスポンシブ Web デザイン対応テーマでの動作にこだわっています。 要素の幅やマージンが ‘%’ 指定されていたりすると固定時やブラウザリサイズ時の動作が怪しくなるコードが多いですが、SWE ならばこれも大丈夫です。 このあたりの動作は Version 1.5.2 でかなり改善しましたので、昔使って今一つと思った方も最新バージョンでは納得いただけるのではないかと思います。

様々なプラグイン／コードでブラウザをリサイズ時動作を比較してみると違いがわかりますよ！

2本のサイドバーの動き

SWE では 2本までサイドバーを指定することができます。 コンテンツより長いサイドバーがある場合、コンテンツではなくその長い方のサイドバーに合わせて他方のスクロールバーのスクロール停止位置を決めます。

応用として、この動作を裏技的に使うと長い方に合わせてスクロール停止するような 2カラムレイアウトを実現することもできると思います。

折り返しの動作

あんまり話題にならないのですが、Quick Switch Back モードというモードがあり、これを有効にするとスクロール方向を変えた時にすぐにサイドバーが動くようになります。 作者的には密かに目玉だと思っています。

動的コンテンツへの対応

SWE ではページロード後にコンテンツサイズが変化するようなテーマに備えて、タイマー + カウンターを使って固定位置等の再計算を実行する仕組みがあります。 ただし、Quick Switch Back モード使用時は再計算時の位置調整が目立つので再計算の実行は必要最小限にするのがお勧めです。

丁寧な計算処理

padding や border、margin が 0 でなかったり、box-sizing が指定されていたり、z-index を使っていたりするテーマでは注意してコードを書かないとすぐに動かなかったり、ぎこちなかったりしてしまいます。 その点、SWE ならば大丈夫です。

この記事を読んで興味を持った方は是非 Standard Widget Extensions を試してみてください。もちろんこのサイトでも使用しているので動作を確認いただけます。 日本語公式ページはこちらです。

Minecraft Forge で Mod づくり

子供が Minecraft にハマっていて Mod づくりに興味がありそうなので、とりあえず開発環境を用意してみました。 ネット上を探すと Mod 製作の情報はあるにはあるのですがどうも古いようなので、自分の行った手順を簡単にまとめておきます。

自分の使った　Minecraft/Minecraft Forge バージョンは Windows 用の 1.7.10 です。

環境の構築

以下のように環境を構築しました。

  1. まずは Minecraft 1.7.10 をダウンロードし、一度は実行しておく。
  2. JDK と Eclipse をインストールしてする。 私の場合は、JDK 1.8.0 の 64ビット版と Eclipse Standard 4.4 (Luna) の 64ビット版を入れました。
  3. ダウンロードページより、1.7.10-Recommended の Installer-Win と Src をダウンロードする。 Installer-Win の代わりに Installer (.jar ファイル) を使うのも可。
  4. Installer-Win を実行する。 Minecraft 1.7.10 を起動したことがないと失敗するので、1度は起動しておく。
  5. ダウンロードした Src を適当なディレクトリに展開する。
  6. Src 展開後のディレクトリ内に存在する README.txt の手順に従う。具体的には以下を実行。

    • gradlew setupDevWorkspace
    • gradlew eclipse
  7. Eclipse を起動し、Src 展開後ディレクトリ内の eclipse ディレクトリをワークスペースとして指定する。

ここまでで作業環境ができます。

プログラムの作成

ワークスペースを開くと Minecraft プロジェクトが存在します。 その中の src/main/java にサンプル ExampleMod.java があります。 自分用の package をこの隣に作成後、ExampleMod.java をそこにコピーし作業を始めればよいと思います。

また、実行時 Program arguments として以下を指定する必要がありました。

--assetIndex 1.7.10

これがないと実行時に以下のエラーが発生してしまいます。

Exception in thread "main" java.lang.RuntimeException: java.io.FileNotFoundException: C:\Users\blogger323\.gradle\caches\minecraft\assets\indexes\{ASSET_INDEX}.json (指定されたファイルが見つかりません。)
	at com.google.common.base.Throwables.propagate(Throwables.java:160)

開発を進めるには

結構困るのが公式の API のリファレンスマニュアルが存在しないことです。 ここまで検索して探してみた結果は、どうやらデコンパイルされた「ソースを読め」ということのようです。 古いサンプルコードは動かすのに修正が必要で、1.7.10 の情報はまだ少ないようです。 リファレンスとしてはダウンロードページより JavaDoc をダウンロードできます。

ついでに忘れないように用語メモ。 今ひとつそれぞれの境界がわかっていないですが。

Forge
Mod 開発フレームワーク
FML
Forge Mod Loader
MCP
Mod Coder Pack。開発用基本ツールパック

Mod の置かれる場所

インストール後は、Minecraft 起動時に「Forge」プロファイルを選択すると Forge の Mod を読み込むようになります。 Mod をただ使うだけであれば %APPDATA%\.minecraft\mods の下に置けばよいです。 参考まで。

開発者向け情報の日本語化プロジェクトは不要

「日本語化」と一口に言ってもいろんな対象範囲があるので一緒くたにはできません。 エンドユーザー向けの情報やユーザーインターフェイスが日本語化されるのはとても意義のあることだとは思います。

でも、オープンソースなソフトウェアの開発者情報を日本語化することに労力をかけるのであれば、そのリソースは別のところで使った方が有効だと思います。 それなりの質の翻訳をするにはその技術を理解している人が翻訳する必要がありますが、英語が出来て技術を知っている人は別のところでそのプロジェクトに貢献すべきです。

例えば、本家情報を参照するためのガイド記事や補足記事を書いたりすることは有効だと思います。 また、日本の貢献を世界へ発信することも必要です。 開発情報の和訳をするぐらいであれば、これらの活動を行う方が良いと考えています。

何故こんなことを書くのかというと、以下のような状況があるからです。

  1. 訳した情報が陳腐化するスピードが速くて、タイムリーに翻訳していくにはコストがかかりすぎる。
  2. 古い情報が混じったり一部が未翻訳だったりするとまともな開発者は英語の本家情報を参照するようになってしまう。
  3. 参照する人が少ない情報は質・量を向上させることができず、結局悪循環となってしまう。 ならば無駄なことはしない方がよい。

ここまではオープンソースなプロジェクトを念頭に置いて書きましたが、例えば Microsoft 製品に関しても技術者は公式英語資料を参照することが多いと思います (昔からですね)。 その状況に不満を持つ方もいるのかも知れませんが、完璧な和訳情報を企業に求めても結局は製品価格に跳ね返るだけでしょう。

オープンソースプロジェクトからの視点で考えると、企業体でも出来ていないものをでやるのだから難度が高いということなのだと思います。

何にせよ個々の技術者としては、きちんとした知識を身に着けたいのであれば本家の情報を英語で参照すべきです。 自分達より若い世代ならば英語情報が標準になるのではなかろうかと思っていたのですが、どうもそうでもないようなので今更ながらに書いてみました。

英語が苦手という方もいるでしょうが大丈夫です。言葉は慣れれば何とかなりますから。

パスコード忘れでロックされた iPhone とリカバリーモード

古い iPhone 4 を Wi-Fi 専用端末として 10歳の息子に渡しています。 その息子が思い立ってパスワードを変更したところ、見事に新パスワード忘れてしまいロックされてしまいました。

パスコードを入力し繰り返し間違えた場合、最初のうちはしばらくの間ロックされ、時間が経つとパスコード入力が可能なように復帰します。 しかし、それを何度も続けると最後はパスコード入力ができなくなり、 iTunes に接続してリカバリーするよう促されるようになります。 こうなると緊急通話以外の操作はできず、PC (または Mac) と接続して復旧するしか方法はありません。

適切にバックアップを取っていれば iTnues からリストアすることもできるようですが、私の場合はなかったため初期化することになりました。 パスコード忘れからのリカバリー方法も初期化の方法も公式サイトで説明されていますし、その他にも検索すればたくさんのサイトの記事がヒットします。

で、それに従ってやってみたのですが、私の場合何故か普段使っている PC でリカバリーモードの iPhone を認識しなかったのです。 公式サイトの認識されない場合の対処を全部試してもダメでした。 更に DFU モードでも試したのですが、それでもダメです。 ちなみに通常起動した iPhone は認識し、パスコードが必要な旨を警告表示してくれます…。

結局どうしたかというと、別の PC に新規で iTunes をインストールし、そちらではリカバリーモードの iPhone を無事認識することができました。 ちなみに認識した PC は 32ビット Windows 8 で普段使いの PC は 64ビット Windows 7 です。 OS の違いよりも以前接続したときの情報が何か悪さをしているような気がするのですが、あくまでも推測です。

この先も同じことが発生しそうな気がするのでエントリにしてみました。 こういうのって忘れた頃に再発するので。

Thin Out Revisions が WPML 互換リストに載りました

Thin Out Revisions のサポート対応の流れから WPML の開発者向けプログラムに申し込んだのが 4月の終わり。 そして、先日無事にチェックをパスして互換リストに載せてもらうことができました。

ああ、もう一か月経っていたのか…

WPML certified

補足説明しておきます。 WPML は多言語化のための WordPress 用プラグインです。 一つの記事を他の言語に翻訳して使うようなサイトを作ろうとしたときにこれがあればページ／投稿の管理がとても楽になります。

実際にどんな感じかというと、投稿一覧で以下のように複数言語版を管理できるようになります。 これは英語＋中国語、仏語、日本語の例です。 「＋」サインはまだ翻訳版が無いことを表していて、ここをクリックすると翻訳版の編集画面に移ります。

WPML

投稿を表示した際の言語切り替え方法はいくつか用意されていますが、例えば以下の様にサイドバーに表示された言語リストで切り替えることがきます。 これは Twenty Fourteen のサイドバーです。

WPML

もちろんアーカイブ表示などでは選択言語のみ表示されます。素晴らしい！

ちなみに多言語化ということでは qTranslate を紹介しているサイトもありますが、残念ながら 2014年 6月現在きちんとメンテナンスができていないようです。 ユーザーレビューがひどいことになってますが、サポートやアップデートを求める人は居ても Donation してくれる人は少ないでしょうし、作者に同情してしまうところがあります。 「サポート要るなら金をくれ！」っていうと叩かれちゃうのかなあ (ぼやき)。

…ということで、お手軽に WordPress サイトを多言語化しようとすると今は WPML しか選択肢がないのではないでしょうか。

そして Thin Out Revisions ですが、これは私が作成したリビジョン管理のためのプラグインです。 WPML を使ったマルチリンガルなサイトならばリビジョン管理機能を使用することが多いと思いますが、Thin Out Revisions ならば柔軟な管理ができます。 詳しくは日本語公式ページで！

WPML の力で少しは認知度があがらないかな… (他力本願)

魔法少女まどか☆マギカ 叛逆の物語を観ました

今更なんですが、まどマギ「叛逆の物語」を初鑑賞しました。 BD を Amazon で購入していたものの時間が取れずにいてやっと観たのでした。

私にとって「まどか☆マギカ」は震災後に 3話連続で TV 放送された回を観たのが初めてでした。 ネット上で話題になっていたのは知っていましたが、「魔法少女だし、子供と一緒に観る時間の番組でもないしなあ」という感じであまり期待していなかったのですが、良い意味で裏切られました。 「謎の白い液体」は余分でしたが。

最後の 3話から世界に入った私にとって「まどか☆マギカ」はほむらの物語という印象が強いのです。 ほむらがループの中でもがきながら成長し、喪失のような幸福のような、を経験する物語。 当然ほむら押し。

そんな私ですが「叛逆の物語」を割とすんなり受け入れることができました。 年寄りの感想かも知れないけど、冷静で良い子だったほむらの人間っぽいところが出たのが良かったです。 人間じゃなくなっちゃったのかも知れないけど。 比べるものじゃないのだろうけど、スターウォーズのアナキンを思い出しました。

ちなみに最初はまどかが黒幕だと思ってしまったのですよ。 だって、何故か人間に戻っているし。 と思ってたら、ほむら、お前なのかい！

というわけで賛否両論と言われているようですが私は賛成の方です。 ただ、抽象化されたビジュアルは苦手ですね。 特にいつもは娘とプリキュアの変身シーンを見ているから、魔法少女の変身シーンは重いというか何というか。

何はともあれ、ほむら押しであることは変わっていないですw やはりまどマギはほむらの物語なんだな、と。 ほむら、万歳！

でも、買ったのは通常版です。 1st テイクを観たらまた感想が変わるのかも知れませんが、何度も繰り返し観て分析する時間は取れなそうなので私には通常版で十分でした。

WordPress Core 変更箇所の追い方

Release Candidate が出され、WordPress 3.9 正式リリースも秒読み段階です。 私は WordPress プラグインを作って (その1、その2) 公開していますが、新しいバージョンの WordPress がリリースされた際は動作を確認せねばなりません。 動作を試しておかしければ、どのような変更が WordPress に加えられたかソースコードを追いかけることとなります。 この記事では WordPress 3.9 リリース直前の現行ソースと WordPress 3.8 との間の変更を追いかけるための手順を説明します。

3.8.2 ではなく 3.8 と比べる理由

先日 3.8 系のメンテナンスリリース 3.8.2 もリリースされていますが、差分を取る対象はこれではなく 3.8 です。 当たり前と言えば当たり前かも知れませんが、このあたりを説明しておきます。

3.8 がリリースされる時点で WordPress 開発の Subversion リポジトリ上は 3.8 ブランチが作成され、trunk は 3.9 開発用となります。 3.8 リリースから 3.8.2 リリースまでの間にも trunk 上で 3.9 用の開発が行われており、これらの変更も含めて調べなければなりません。 従って、3.8.2 ではなく 3.8 のリビジョン番号を調べそのリビジョンから最新リビジョンまでに行われた trunk 上での変更を確認するのです。

WordPress 3.8 のリビジョン番号を取得

Trac Browser を使って 3.8 に対応するリビジョン番号を調べます。 タグ一覧はこちらです。

これをみると 3.8 リリースのリビジョン番号は #26861 であることがわかります。

差分の取得

差分取得画面より差分取得したい範囲とリビジョン番号を入力し、「View changes」ボタンを押すことで差分が表示されます。

まず先ほど確認した 3.8 に対応するリビジョン番号を入力します。 また、現行ソースについては現行リビジョン (= デフォルト値) をそのまま使います。 更にここでは対象ディレクトリを絞って差分取得してみましょう。

From:
/trunk/src/wp-includes/ at revision 26861
To:
/trunk/src/wp-includes/ at revision 28084 (デフォルト値)

「View changes」を押して表示されたページより、個々に「view diffs」を実行しても良いですし、「Unified Diff」を選んで差分を一括ダウンロードすることもできます。 一括ダウンロードは wp-includes だけでも結構な量になるのでよく考えて実行しましょう。

まとめ

以上で 3.8 から何が変わったかを確認できるはずです。

というような苦労をしながら最新バージョンの WordPress に対応している (予定の) Standard Widget Extensions と Thin Out Revisions をよろしくお願いします！ (結局宣伝w)

(参考: Researching Code History With SVN Annotate)

WordPress プラグインの選び方

WordPress がブログプラットホームとして多くの方に利用され、そのプラグインを紹介するブログ記事も多数書かれています。 WordPress プラグイン作者としてそれらを見て思うところがあったので、この記事を書いています。 正確には選び方というより、危ないプラグインの避け方、つまりこのような特徴があったらそのプラグインは避けた方が無難、という内容です。

プラグインは信頼できるものを

WordPress のプラグインは機能拡張するためのプログラムであり、ある意味プラグイン作者は何でもできます。 作者に悪意がなくても、処理の漏れからプラグインが脆弱性を持っている場合もあり、そのようなプラグインを導入するとサイトが危険にさらされることになります。 WordPress はプラグインを使って機能拡張できるところが魅力ではありますが、自分としては信頼できる必要最小限のプラグインを導入することをおすすめしたいです。

本記事は信頼できないプラグインを見抜くためのガイドです。

ダウンロード数やレーティングだけじゃ足りない

WordPress.org の各プラグインページに表示されるダウンロード数やレーティングだけで評価するのは危険です。 何故なら、ダウンロード数は累計表示なので初回リリースの時期が早ければ早いほど大きな数字となります。 レーティングについても過去に高評価を得ていたけれど、今はメンテナンスされず誰も見向きもしなくなったため、高レーティングのままになっているだけかも知れません。

放置されているプラグインはやめよう

まず、以下のような警告が出ているプラグインには手を出すべきではありません。

warning

この警告は最後のアップデートから 2年間以上経過しているプラグインのページに表示されます。 例えば、2013年は WordPress 3.6、3.7、3.8 がリリースされ、UI も内部的にも大きく変わった部分があり、その結果、多くのプラグインでそれに対応する修正が必要となりました。 1年ですらそのような大きな変化が起こっていることを考えると、2年以上放置されているということは作者がメンテナンスする意思がない可能性が高いです。

ダウンロード状況を確認する

累計ダウンロード数だけでなく、プラグインの「Stats」ページも確認しましょう。 きちんとメンテナンスされ、ユーザーもついているプラグインには、下図のようにきちんと波ができているはずです。

stat-fb

一週間周期のさざ波に加えて、更新版リリース時の大きな波ができています。 上の図は累計ダウンロード数 140万超の人気プラグインですが、ダウンロード数が少ない場合でも同じです。

stat-swe

この図は累計ダウンロード数 8,000程度のプラグインですが、少なくともバージョンアップ期の大きい波はきちんと出ています。 特に累計ダウンロード数が比較的少ないプラグインではこのように大波がだんだん高くなっている方が安心です。 それは利用者が増えている、すなわち利用者にとって価値のあるプラグインである可能性が高いことを示しているからです。

Stats を確認してこのような波ができていないということは、メンテナンスがされていない等何かしら問題があるように思えます。

サポートフォーラムを確認する

プラグインの「Support」ページも確認しておきましょう。 サポートフォーラムで質問が少なく、たまにあったとしてもポスト数 (Posts) が 1のまま放置されているようなプラグインは避けた方が無難でしょう。

また、個々のトピック (Topic) を確認した時、作者からのポストには author-mark のような目印がついています。 すぐに作者のポストが見つかれば安心ですが、見つからないときは次に紹介する手順で作者の詳細をチェックしましょう。

作者の詳細をチェック

プラグインページの「Author」に示されているリンクを辿ると作者のプロフィールページにジャンプします。 例えば私のページはこちらです。

ここで、最近の Activity や、その作者が作成した他のプラグインやテーマを確認することができます。 Activity の中でフォーラムへのポストがあれば内容を確認しておくと良いでしょう。 作者が信頼できなさそうであれば、その人の作ったプラグインは導入すべきではありません。

まとめ

というわけで WordPress プラグインを導入するときにチェックしておきたい点を挙げておきました。 本当はプラグインのソースコードを見て判断できると良いのですが、なかなかそうは行かないのでこのようなチェックポイントを参考にしてみてください。 もちろんこれだけで脆弱性のあるプラグインの導入を全て防げるわけではありませんが、何も考えずに導入するよりはずっとましだと思います。

巷のブログ記事で紹介されているプラグインの中にもこれらのチェックポイントにひっかかるものがあります。 そのようなプラグインを紹介しているブロガーが信頼に足るとは思えません。

繰り返しますが、WordPress プラグインの導入は信頼できる必要最小限のプラグインのみとすることをおすすめします。