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 ExtensionsThin Out Revisions をよろしくお願いします! (結局宣伝w)

(参考: Researching Code History With SVN Annotate)

WordPress プラグインリポジトリの動作

ちょっとニッチな話題ですが (いつものことだ!)、プラグインを作って WordPress.org のリポジトリへプラグインをアップロードするときの Stable Tag 関連の細かい動作についてまとめておきます。 英文ドキュメントだけではわかりにくい気がするので。

trunk/readme.txt は原則 Stable Tag だけ参照される

プラグインのページからダウンロードできる安定バージョンを指定するには trunk/readme.txt の Stable Tag を使用します。 ここで注意が必要なのは、プラグインページの表示は trunk/readme.txt ではなく、Stable Tag で指定したバージョンの tags/安定バージョン/readme.txt の内容を元に表示されることです。 つまり、例えばプラグインページで typo があったりしたときに、それを訂正するにはわざわざそれ用の新バージョンを作って Stable Tag を更新しなければならないということです。

Stable Tag で指定したバージョンがなかったら?

例えば trunk の下のファイルを更新して開発を進めたところ、いい感じになったのでリリースしようと考え trunk/readme.txt の Stable Tag を 1.2 へ更新したとします。 しかし、タグ付けし忘れて、対応する tags/1.2 のディレクトリを作成し忘れていたらどうなってしまうのでしょう?

この場合は、プラグインページ上のダウンロードリンクの表示は「Download Version 1.2」となり、ダウンロードできるパッケージは trunk の内容を固めた Zip ファイルとなるのです。 問題ないですね。

であれば、プラグインページが枯れて (typo 等がなくなって) 安定するまでは trunk をダウンロードしてもらうというのも一つの手かなと思いました。 ともかく、Stable Tag 更新 → タグ付けの間に時間が空いても問題はないということです。

Stable Tag 更新とタグ付けは順番に実行

一度、trunk の更新 (含 Stable Tag 更新) と対応するバージョンのタグ付けを同時に check in したところ、「Download Version *」の表示が変化しないことがありました。 (ダウンロードできるパッケージは変化したように記憶しています)

というわけで Develop Center で紹介されている手順通り trunk (Stable Tag) の更新とタグ付けは別々に check in した方が良いようです。

ああ、何てニッチな話題なんだろう!

Standard Widget Extensions 1.0

拙作の Standard Widget Extensions がバージョンアップして 1.0 となりました。 このサイトのサイドバーの動きはこのプラグインを使用しています。 今回のバージョンアップでは派手な機能追加はないもののそれなりに変化しています。 私の書いた怪しい英語を英語の苦手な平均的日本人が読むと、きっと伝わらないような気がするので、要点を書いておくことにします。

主な変更点は以下の通りです。

  1. サイドバーに複数のウィジェットエリアをもつテーマに対応しました。これにより、スクロール動作に関してはサイドバー全体の大きさで計算させながらも一部のウィジェットエリアでのみアコーディオン動作をさせることができます。
  2. 設定された ID やクラスを元に見出しアイコン用の style タグが動的に生成されるようなりました。 これで非標準テーマでも使いやすくなったと思います。
  3. 管理画面が日本語表示されるようになりました。

1. に関連して新たに「次の ID を持つウィジェットエリアのみで有効」というオプションが増えているのでこれについて説明します。 このオプションは複数のウィジェットエリアを持つサイドバーに対し、アコーディオン動作をするウィジェットエリアを指定するときにに使います。 Twenty Twelve や Twenty Eleven のように 1つのウィジェットエリアがそのままサイドバーになっているテーマではこのオプションは空欄にしておき、「サイドバーの ID」にそのウィジェットエリアの ID を入れてください。

2. ですが、もし既に非標準テーマ + Standard Widget Extensions という組み合わせでお使いになっていて 1.0 へバージョンアップする場合は生成される style タグが余計なことをすることになるので、「デフォルト CSS を生成する」を無効にしてください。

このサイトのサイドバーと同じような動作をさせたいときは是非使ってみてください。

日本語で書くのは気楽だ…。

WordPress 用プラグイン Standard Widget Extensions を公開しました

WordPress のウィジェットの動作を拡張するためのプラグイン「Standard Widget Extensions」を公開しました。 既にWordPress.org のリポジトリに登録済みです。 私にとって Thin Out Revisionsに続く 2つめの WordPress プラグインです。

現バージョンで提供している機能はウィジェットというよりサイドバーの拡張用という感じですが、以下の内容をお手軽に実現できます。 Twenty Twelve/Twenty Eleven であればデフォルト設定のままで動きます。

  • Accordion Widget (開閉するウィジェット)
  • Sticky Sidebar (スクロールが止まるサイドバー)

スクロール関係については世の中にサンプルやら部品があふれているのですが、境界でぎこちない動作になるものが多く、レスポンシブ Web デザインやサイドバー伸縮との組み合わせを考えると結局自分で作った方がよいと思い開発しました。 ちなみにレスポンシブ Web デザイン対応という点では、ウィンドウ幅が指定された値より小さくなると機能が無効化されます。

開閉動作もありふれてますが、見出しのアイコンを変えたりできるので JavaScript の苦手な人がちょっと使うのには便利だと思います。 独自の CSS は最低限にしてテーマのスタイルをそのまま使用するようにしています。 以下は Twenty Twelve/Twenty Eleven/Twenty Ten に適用した場合の例です。 そのままではマージンが大きいので微妙かも知れませんが、最低限の追加スタイルということを理解していただけると思います。

Standard WE

動作についてはこのサイトの左側にあるサイドバーを見ていただくのが一番早いと思います。 WordPress 標準テーマの Twenty Twelve/Twenty Eleven/Twenty Ten で動作確認していますが、メインカラムとサイドバー、ウィジェットの ID/クラス名を設定することができるので、標準テーマと同じつくりのテーマであれば対応できると思います。 もし、興味があれば、是非 WordPress の管理メニューから検索してインストールしてみてください。

以下、プラグインのホームページです。

WordPress プラグインを開発して WordPress.Org に登録するまで

今回 WordPress プラグイン「Thin Out Revisions」を書いて公式リポジトリに登録したわけですが、その辺の流れを書いてみたいと思います。 プラグインを作る動機としては、何かしら個人としてのアウトプットを世間に出したいというのがあったのと、出すならやっぱりグローバルだよね、ってのがありました。 とはいっても私の場合、決して PHP も WordPress も jQuery も熟練者とは言えない状況でした。 それでもプラグインを作ろうとしたきっかけは先のエントリで紹介した「Professional WordPress Plugin Development」で、この内容ががあまりにもよくまとまっていたので、「何か自分でも書いてみたい!」と思ってしまったのです。 そこへ手頃な大きさの課題を見つけることができたので勢いで書きあげてしまいました。

今回作った Thin Out Revisions は、プログラムのボリュームとしては大したことがありません。 しかし、jQuery も Ajax も使ったし、きちんと Nonce も使って (CSRF対策)、I18N も対応しました。 色々な要素が詰まっていますが、「Professional WordPress Plugin Development」がこれらを包括的に取り上げていたおかげで、さほど苦労せず書き上げることができました。 この本がなければプラグインを書いて公式登録することはなかったでしょうから、著者に感謝です。

以下時系列に書いてみます。

9/20 に予てより気になっていた「Professional WordPress Plugin Development」の Kindle 版をダウンロード購入しました。 そして読んでいると自分でもコードを書きたくなり、「そういえばあのリビジョン管理なんとかならないのか」といつも感じていたことを思い出しました。 そこから構想を練り、コードを書き始めました。

最初のモックアップをローカル git リポジトリにコミットしたのが 9/23 になっています。 その後、作業を続け、9/28 の深夜には終わりが見えてきたので、そろそろ公式リポジトリの登録申請をしておくかという状況になりました。

9/29 に申請を行い、wordpress.org のチームとメールのやりとりの後 svn リポジトリが用意されたのが 9/30。 そして 10/1、初めて使う subversion のコマンド (私は cvs -> git) でファイルをアップロードし、無事公式サイト上で公開されることとなりました。

ちょっと焦ったのが svn リポジトリが提供されるよりも先にプラグインパッケージの提出を求められたことです。 「Professional WordPress Plugin Development」での説明順もそうですし、国内開発者のブログ記事でも「まずプラグインの登録申請を行い、後から Subversion をセットアップしてコード登録」という手順になっているので、「リポジトリが用意されるまでに時間がかかりそうだし、早めに申請しておいた方がよいんだろうなあ」と思っていました。 しかし、私の場合は申請後すぐに「プラグインがダウンロード可能な URL を教えるか、ZIP ファイルでプラグインを送ってねー」というメールをもらってしまいました。 ほとんど活動がなかった私のアカウントからの登録申請だったので、チェックが入ったということかも知れません。

ここで「7日間のうちにレスポンスせよ」と期限を切られていたので急いで最後の調整を行い、初回 ZIP を送付し、その間にマイプラグインページを準備します。 1日も経たず readme.txt がないのを指摘をするメールが届いたので、「readme.txt? 何それ?」という状態からマークダウン記法で readme.txt を仕上げて更新 ZIP を再送付しました。 申請から 2日間でこのやりとりを完結させているのですが、wordpress.org の中の人もレスポンスが良かったのは週末だったお陰かも知れません。

まあ、日本人としては readme.txt を仕上げるのにも時間がかかるし、普通の会社勤めでは急にまとまった時間が取れないことも多いでしょうから、プラグインを完成させ、(サイトとして完成させていなくても) プラグインホームページ URL や Donate 用 URL を決めてから登録申請を行った方がよいでしょう。 それと readme.txt の内容も本当は時間をかけてプラグイン検索でヒットしやすい様な文章を狙うべきだったと後から気づきました。

何にせよ、今回の一連のやりとりでいろいろと経験値が貯まったのは確かです。 「手頃な大きさの問題を見つけられたので登録まで行けたんだよな」とも思うので、最初は無理をせず簡単なプラグインを書いて完成させることが重要だと思います。 とは言っても Thin Out Revisions はリビジョン管理好きの人には確実に便利なプラグインに仕上がっており、多くの人に使ってもらえればと思っていますので、興味がある方は是非ダウンロードしてください (宣伝!)。 もし気に入っていただけたら、公式サポートフォーラムで怪しげな英語 (ローマ字?) のやりとりをしましょう!

WordPress リビジョン管理のための「Thin Out Revisions」

WordPress を使い始めて最初に気が付くのは投稿/固定ページのリビジョンがどんどん増えていくことです。 基本的にそれらが更新されるたびにリビジョンが増えていく仕様なのですが、これを気にして気軽に保存できなくなるようでは本末転倒です。 そのままだとデータベース使用量が増えるということもあって、リビジョン削除用プラグインは定番カテゴリーを形成しているように見えます。

しかし、実際には全てのリビジョンを綺麗さっぱり削除してしまうようなプラグインが多く、それではせっかくリビジョン機能が実装されているのにもったいないと思ってしまいます。 世代数で制限をかけるプラグインもありますが、一番最初の版とどう変わったかをみたいときもあると思うので世代数による一律保管制限では機能不足という場合も多いでしょう。 そんな中 Revision Control というプラグインは個別にリビジョンを削除できるので重宝しますが、もう少しスマートにやれればと思ったのでした。

というような考えで生まれたのがこの Thin Out Revisions プラグインです。 このプラグインを有効化するとリビジョン比較画面 (revision.php) で選択した新旧リビジョンの間にある中間リビジョン全てを一括で削除できます。 使い方は簡単で削除対象を確認してボタンを押すだけです。

Thin Out Revisions

また、隣り合った2つのリビジョンを選択した時は、古い方のリビジョンを削除対象とする動作にしました。 これで一番最初に自動保存されてできてしまった目障りな空リビジョンを削除することができます! (私だけ?)

Thin Out Revisions 2

公式リポジトリからダウンロードできますので、興味のある方は是非使ってみてください。 ちゃんと日本語対応してます。(日本語のスクリーンショットが必要か…。)


2012.12.21 追記
バージョン 1.1 になって余計なリビジョンを作らないための機能が追加されています。→ 関連記事

2013.2.24 追記
更にメモをつける機能も追加されました。

2014.6.14 追記
日本語公式サイトはこちら。

WordPress のプラグインを書こう

「Kindle で技術系洋書を読もう!」シリーズ (?) の第 2弾です。 WordPress のプラグインを書くのに最適な本を見つけました。 「Professional WordPress Plugin Development」という本です。

Amazon.com で目次が見れますが、下に各章の概要を書いておきます (章のタイトルそのままもありますが)。 ある程度経験がある方が見ればわかると思いますが、プラグイン開発で必要なものは一通り含まれています。 Kindle 版は約 2千円で、この価格で一通りの情報が得られるので PHP からしてビギナーの私としては大変助かりました。

WordPress のカスタマイズのためにコードを書こうとしたときに最初に感じたのは情報を見つけにくいことでした。 検索をしても内容が古かったり、特に日本語の情報はテーマのカスタマイズ中心でプログラミングに関しては断片的な情報が多いように感じます。 一応プラグイン開発に関しては公式情報 (日本語英語) がありますが、手を動かし始めると他にも様々な情報が欲しくなってきます。 英語圏まで広げても状況はあまり変わらないようで、序文を読むと著者も同じように感じ、それが執筆の動機となったようです。 確かにこれだけ包括的な情報を一箇所で手に入れるのは難しいと思います。

プラグイン開発をしなくても、WordPress の動く仕組みを知りたい、あるいはカスタマイズしてみたいというプログラマにはとても有用だと思います。 プログラミング関連書籍の英語は難しくないので興味があれば是非読んでみてください。

ただし、テーマのカスタマイズ (CSS やマークアップ関連) の情報はありません。 そこは和書がたくさん出ていたと思います。

1/2章
プラグインについての基本知識。 推奨コーディングスタイルや開発チェックリストも含まれる。
3章
フック (Action と Filter) について。 フック関数としてクラスのメソッド (メンバ関数) を登録する方法。
4章
メニューの追加。ウィジェットの作成。メタボックス (投稿等の画面上のボックス区画) 作成と内容の保存。
5章
I18N。コードの対応と翻訳ファイルの作り方。
6章
セキュリティ。ユーザーのパーミッションやサニタイズ、Nonces (CSRF 対策) 等。
7章
設定を保存するための各種 API → *_option()、*_settings_*()、*_transient()、*_user_meta()。 カスタムテーブルへの保存。
8章
ユーザの管理。
9章
HTTP リクエストを使って Web サービス API を利用する方法。
10章
ショートコード。
11章
投稿 (post) の拡張。 カスタム投稿タイプやカスタムタクソノミー。
12章
JavaScript (jQuery) と Ajax。 フックを使ったサーバーサイド処理。

13章
Cron を使ったプログラムのスケジュール実行。
14章
URL の Rewrite。
15章
マルチサイト。
16章
デバッグと最適化。
17章
ライセンスの選択。 公式リポジトリへの登録等。
18章
各種情報リソース。