カテゴリー: WordPress

PhpStorm 環境構築編の 2回目です。 前回で、PhpStorm と XAMPP、WordPress の基本インストールを終了しました。 今回は WordPress プラグイン開発用の PhpStorm プロジェクトを作成します。

プロジェクトの作成

External Libraries として WordPress のコアコードを参照させるやりかたもあるようですが、今回は WordPress 全体をプロジェクトとしてしまいます。 その場合もプラグインごとに Git (Subversion) リポジトリを管理することができるので問題ないでしょう。 では操作を進めて行きます。

PhpStorm を起動すると初回はプロジェクト作成画面が表示されます。 「Create New Project from Existing Files」を選択します。

続いてサーバーとソースファイルの構成を選択します。 今回は「Web server is installed locally, source files are located under its document root.」を選択し、直接 Web サーバーの参照するファイルを編集対象とします。 ここの選択を変えることでリモートサーバーにも対応できます。

WordPress インストールディレクトリを選択してから「Project Root」ボタンを押します。 「Next」を押すのはその後です。

サーバーを指定します。 今回は初回なので新規サーバーエントリとしてローカルサーバーに名前を付け、ルート URL (「http://localhost」)を指定します。 次回以降は新規追加だけでなく登録済みサーバーを選択することもできるようになります。

最後にプロジェクトルートに対応する Web URL のパスを入力します。今回は「/」です。

以上でプロジェクトが作成されます。

PhpStorm Settings

続いて PhpStorm での設定です。 「File」－「Settings」と選んでダイアログを表示し、もろもろを設定していきます。

「PHP」

「Interpreter」の右隣の「…」をクリックした後に表示される画面で「＋」ボタンを押し XAMPP 用のエントリを追加します。 PHP ホームディレクトリを指定し、Xdebug を「Debugger」として選んでおきます。

「Include path」も必要に応じて設定しておきます。 これで「PHP」のページは以下のようになったはずです。

「PHP」－「Debug」

「Xdebug」のところのポートの設定を前回編集した php.ini の設定と合わせます。

「Version Control」－「Git」

私は Git for Windows (msysgit) を使用しています。 この git.exe のパスを正しく設定します。 設定したら「Test」ボタンを押して正常性を確認しておきましょう。

ちなみに Subversion の方は外部コマンドを用意しなくても SVNKit を用いたクライアント機能が PhpStorm に実装されています。 WordPress.org のリポジトリは Subversion で管理されていますが、そちらにも対応できます。

私の場合、Git で仕上げたソースコードを Subversion で WordPress.org にチェックインするという何となくイケてない方法を採っているので、ソース管理をどうやって行くかは個人的な課題だったりします。(追記: その後、git-svn を使っています)

次回は Git (Version Control) 機能とデバッグ機能関連を設定します。

まじめに WordPress のプラグイン開発環境をつくろうと思い立ち、PhpStorm + XAMPP を導入しました。 PhpStorm はリモートのサーバーにも対応していますが、ヘルプファイルの記述はローカルサーバーでテストを行いリモートサーバーにデプロイする想定で書かれています。 ですので、XAMPP をインストールし、ローカルに PHP のデバッグが行える環境を構築することにしたのです。

この環境構築手順を数回にわたって紹介します。 WordPress のプラグインやテーマを開発されている方はもちろん PHP 開発者の方にも参考となるのではないかと思います。 ちなみに私の場合、これまでのプラグイン開発は Emacs + タグファイル (デバッガなし) で行っていました…。

さて、今回は初期インストールです。 一連の記事は PhpStorm 6.02、XAMPP Portable 1.8.1、Windows 7 をベースとして書いています。

PhpStorm のインストール

PhpStorm のインストーラーはPhpStorm のサイトで「Get PhpStorm 6」というボタンを押すことで入手できます。 インストール自体は特に難しいことはないので割愛します。 さて、PhpStorm を起動してみましょう。

初回起動時に既存設定をインポートするか聞かれますが、今回初導入なので「I do not have a previous version of Phpstorm or I do not want to import my settings」を選択します。

ライセンスは「User name」も正しく入力しましょう。 ユーザー名とライセンスキーが正しく入力されれば有効期限が表示されるはずです。 「Evaluate for free for 30 days」を選んで30日間評価用に使うこともできます。

ライセンス同意確認は「Accept all terms of the license」をチェックして「OK」を押します。

IDE 初期設定画面がでるので好きなものを選択します。 とりあえず私はキーマップとして Emacs を選択し他はデフォルト値のままにしました。

この後プロジェクト作成画面が表示されますが、続きは次回以降に説明します。 また、初回起動時に Windows ファイアウォールの警告が出るかも知れません。 「プライベートネットワーク」を選んでアクセス許可しておきましょう。

XAMPP のインストール

XAMPP については for Windows の XAMPP portable lite を導入しました。 このポータブル版ではメールサーバーなどいくつかのパッケージが省略されていますが、WordPress プラグイン開発を行うには十分です。

XAMPP のインストールも特に難しいことはなく、インストーラパッケージをダウンロードし実行するだけです (環境によっては Microsoft Visual C++ 2008 SP1 Redistributable Package (x86) をインストールする必要があるようです)。 最後に以下のようなメッセージが表示されます。 レジストリエントリを持っておらず、アンインストールは手作業でファイル削除するようにとのことです。

サーバーをスタート／ストップさせる操作にはインストール先ディレクトリ直下にある xampp-control.exe を起動して使用します。 こちらも Windows ファイアーウォールの警告がでるかも知れませんが、PhpStorm の場合と同様に許可しておきます。

Xdebug の有効化

PhpStorm は PHP 用デバッガとして Xdebug と Zend Debugger に対応しています。 XAMPP の PHP パッケージには Xdebug が含まれているのでこれをそのまま使用します。

ヘルプを参照しながら php.ini の Xdebug のセクションを編集します。 私の場合は以下のようになりました。 (追記: ちなみに XAMPP Portable 1.8.3 ではパスに「c:」をつけないと XDebug が動きませんでした。)

[XDebug]
zend_extension = "\xampp-portable\php\ext\php_xdebug.dll"
xdebug.remote_enable = 1
xdebug.remote_port = 9000
xdebug.profiler_enable = 1
xdebug.profiler_output_dir = "\xampp-portable\tmp"

WordPress のインストール

PhpStorm の IDE に統合された Subversion を使って最新ソースを追いかけることもできますが、とりあえず 3.6 ベータ3 を導入することにします。

1. phpMyadmin (http://localhost/phpmyadmin/) を使ってデータベースとユーザーを追加します。 データベースの Collation は utf8_general_ci を選択しました。
2. WordPress の ZIP ファイルをダウンロードして C:\xampp-portable\wordpress として展開します。
3. wp-config.php を編集して DB_* と WP_DEBUG あたりを設定します。
4. httpd.conf を編集して DocumentRoot を /xampp-portable/wordpress に変更し、Directory の設定を追加します (後述)。
5. http://localhost/wp-admin/install.php にアクセスしインストールを実行します。

httpd.conf は DocumentRoot を /xampp-portable/wordpress に変え以下を追加します。 XAMPP Control Panel からエディタ (デフォルトは Notepad) を起動して編集することもできます。

<Directory "/xampp-portable/wordpress">
    Options Indexes FollowSymLinks Includes ExecCGI
    AllowOverride All
    Require all granted
</Directory>

次回に続きます。

連休中に iPad に WordPress アプリを入れて、ついでにサイトに Jetpack プラグインを導入しました。 WordPress アプリに Jetpack プラグインを組み合わせることで統計情報が参照可能になります。 このとき、WordPress.com のアカウントが必要です。

さて、この Jetpack プラグインですが、他に OGP メタタグを出力するプラグインと組み合わせると二重に OGP メタタグを出力してしまうという記事をみかけました。 私も Facebook プラグインを使っているので慌てて調べると確かに二重出力しています。 そこで Jetpack の設定でこれを抑止できないかと管理画面を確認したのですが、特に設定はないようです。

よその記事をそのままうのみに出来ない (fb_xd_fragment の件もありました！) ので、コードを覗くと jetpack.php に以下のような関数がありました。 Jetpack のバージョンは 2.2.5 です。

    public function check_open_graph() {
        if ( in_array( 'publicize', Jetpack::get_active_modules() ) || in_array( 'sharedaddy', Jetpack::get_active_modules() ) )
            add_filter( 'jetpack_enable_open_graph', '__return_true', 0 );

        $active_plugins = get_option( 'active_plugins', array() );

        $conflicting_plugins = array(
            'facebook/facebook.php',                                                // Official Facebook plugin
            'wordpress-seo/wp-seo.php',                                             // WordPress SEO by Yoast
            'add-link-to-facebook/add-link-to-facebook.php',                        // Add Link to Facebook
            'facebook-awd/AWD_facebook.php',                                        // Facebook AWD All in one
            'header-footer/plugin.php',                                             // Header and Footer
            'nextgen-facebook/nextgen-facebook.php',                                // NextGEN Facebook OG
            'seo-facebook-comments/seofacebook.php',                                // SEO Facebook Comments
            'seo-ultimate/seo-ultimate.php',                                        // SEO Ultimate
            'sexybookmarks/sexy-bookmarks.php',                                     // Shareaholic
            'shareaholic/sexy-bookmarks.php',                                       // Shareaholic
            'social-discussions/social-discussions.php',                            // Social Discussions
            'social-networks-auto-poster-facebook-twitter-g/NextScripts_SNAP.php',  // NextScripts SNAP
            'wordbooker/wordbooker.php',                                            // Wordbooker
            'socialize/socialize.php',                                              // Socialize
            'simple-facebook-connect/sfc.php',                                      // Simple Facebook Connect
            'social-sharing-toolkit/social_sharing_toolkit.php',                    // Social Sharing Toolkit
            'wp-facebook-open-graph-protocol/wp-facebook-ogp.php',                  // WP Facebook Open Graph protocol
            'opengraph/opengraph.php',                                              // Open Graph
            'sharepress/sharepress.php',                                            // SharePress
        );

        foreach ( $conflicting_plugins as $plugin ) {
            if ( in_array( $plugin, $active_plugins ) ) {
                add_filter( 'jetpack_enable_open_graph', '__return_false', 99 );
                break;
            }
        }

        if ( apply_filters( 'jetpack_enable_open_graph', false ) )
            require_once dirname( __FILE__ ) . '/functions.opengraph.php';
    }

一瞬、「ここに挙げられているプラグインがアクティブならば、ちゃんと OGP タグ出力は抑止されるのでは？」と思ったのですが、よく見るとマルチサイトでネットワークレベルで他のプラグインをアクティベートしたときはこのチェックから漏れてしまいます。

従って (現行バージョンの Jetpack では) この二重出力問題はマルチサイト環境のみで生じます。 ワークアラウンドは、ネットワークレベルで他のプラグインをアクティブにするのはやめて個別のサイトでアクティブにすることです。 実際に私も Facebook プラグインをこの方法でアクティベートすると問題は解消されました。 ちなみに OGP 出力については fb_xd_fragment の件もあるので Facebook プラグインが私のお勧めです。

参考までに書くと、ネットワークレベルでアクティベートされたプラグインは以下のオプションの内容を参照することで確認できます。

get_site_option( 'active_sitewide_plugins') 

パッチをつくって送ってみようかな…。

nonce ってナンスか？

春だというのに寒いですねぇw

それはさておき、みなさんは nonce という言葉を聞いたことがあるでしょうか？ 日本ではあまり馴染みがないように思いますが、コンピュータ (というか暗号) の世界では一度だけ使われる使い捨てのユニークな数 (英語版 Wikipedia の説明) のことを言います。

WordPress には CSRF 対策として nonce という機能が実装されています。 wp_create_nonce で nonce を生成し、wp_verify_nonce でこれを検証することができます。 リンク先の Codex にも例がありますが、wp_create_nonce で生成した nonce を HTML のフォームに埋め込み、サーバーで受けたその値を wp_verify_nonce で検証する、というような使い方ができます。

ただし、注意点が一つあります。 WordPress の nonce は本来の意味の nonce とは異なり、ワンタイムの使い捨てというわけではありません。 12時間ごとに変更され、検証に際しては 24時間有効です。 もっとも CSRF 対策として考えたとき、ワンタイムである必要はありません (例えば高木先生の記事)。 推測されないようにきちんとランダムであれば、そして有効期間が適切であれば CSRF 対策として十分です。

wp_verify_nonce は、現在の nonce の値と同じならば 1、1つ前の nonce と同じならば 2を返します。 つまりデフォルトでは 0-12時間で 1、12-24時間で 2が返されることになります (時間の数え方は後述)。 nonce が一致しなければ wp_verify_nonce は 0を返すので、通常はこれをそのまま真偽判定条件式として使用します。

有効期間の短縮

その有効期間ですが、デフォルトの 24時間を短縮したいときは add_filter することで変えられます。

add_filter( 'nonce_life', 'my_nonce_life' );

function my_nonce_life() {
    return 3600; /* 1 hour */
}

このテクニックはテスト時にも使えそうですね。

なお、この有効期間は wp_create_nonce を呼んだ時からカウントダウンが始まるわけではなく、time() の値を使って周期的に変えているだけなので、ちょうど変わり目 (GMT の 0時とか 12時とか) にあたると短時間で値が変化することになります。 それでも先述の通り一つ前の nonce まで有効と判定されるので通常は問題ないでしょう。

nonce の素

さて、この nonce ですが、以下の情報を元に生成されます。

1. ユーザー ID
2. 時刻 (といっても 12時間単位)
3. wp_create_nonce に渡された引数 $action
4. サイト毎に持っている秘密キーと Salt

これらが同一であれば同じ値になります。 ここで開発者にとって気になるのは 4. の秘密キーと Salt ではないでしょうか？ そして自分の wp-config.php に以下のような記述を見つけて焦るわけです。

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

これを見ると「げっ、ウチのサイト、ヤバい？？！」と思ってしまいますよね。

でも、安心してください。 実はこのような wp-config.php となっている場合は、自動的に秘密キーと Salt を生成してデータベースに保存し、それを使ってくれます。 このままでも「put your unique phrase here」をキーとして使うことにはなりません。

となると wp-config.php を書き換えたくなるのは定期的にキーを変更したい場合ぐらいでしょうか。 生成には https://api.wordpress.org/secret-key/1.1/salt/ を使いましょう。

学習のために

興味のある人は wp-include/pluggable.php の nonce 関連関数を読んでみましょう。

私が WordPress の nonce について知ったのは「Professional WordPress Plugin Development」という書籍によってです。 この書籍は WordPress のプラグイン開発に必要な情報が一通りまとまっており、分量も重くないのでお勧めです。 英語も難しくないですし。

英語ついでですが、こちらの WordPress の nonce についての記事も参考情報として挙げておきます。

---

2013.4.17 追記

nonce の変わり目の際の動作について訂正。(一つ前の値も有効なので変化してもすぐに verify エラーになるわけではない)

WordPress 3.6 のβ1がリリースされました。 今回はそれをとっかかりに近況をまとめる感じで書いてみます。

WordPress 3.6 のリビジョン画面

WordPress 3.6 ではリビジョン画面が刷新されます。 下のスクリーンショットを見てください！ これまでのリビジョン選択用テーブルの代わりに上部にスライダーが用意され、Ajax でリビジョン選択を行なえるようになります。

そして、この画面のプログラミングには Underscore.js と Backbone.js が使用されています。 私は JavaScript 界隈に詳しいわけではないのでアレですが、どちらも人気のあるライブラリのようです。 で、私は Thin Out Revision というリビジョン画面に機能を追加するためのプラグインをリリースしているのですが、jQuery で画面に機能追加するような動作なのでそのままでは WordPress 3.6 で動かないわけです。 「ああ、困ったなあ」と思ったのがβ1 前のα版を触っていた 3月下旬のことでした。

Backbone.js

Backbone.js は MVC フレームワークです。 WordPress 3.6 のリビジョン画面も Model と View を使ってプログラミングしています。 そうすると画面ロード時に jQuery でちょっといじる程度では対応できないのです。 もしそれをやったとしても、画面が動的なのでボタンを押したりスライダーを使うとすぐに効果が消えてしまいます。 ああ、困った。

そこで Backbone.js を学習せねば、ということになるのですが、結局本家マニュアルと WordPress の wp-admin/revision.php と wp-admin/js/revisions.js が一番の材料でした。 その他に役に立ったのは以下のチュートリアルです。

• Hello Backbone.js (チュートリアル)
• Backbone 入門 (IBM のチュートリアル)

あと、Waviaei さんの記事で紹介されている WordPress 3.5 関連動画で Underscore.js と Backbon.js が結構な時間を使って紹介されていて何ができるかを知るのには良いと思います。 結構早口な英語ですが。 ちなみに私はこの動画を見て JavaScript コンソールを使用するために Chrome をインストールしました。 まだそんなレベルです。

Prototypal inheritance

そして、もろもろ考慮した結果「リビジョン画面を拡張するにはそれ用の View を継承して手を入れるしかないでしょ」との結論に至りました。 現在は以下のようなコードを書いていて、何とか Thin Out Revisions を WordPress 3.6 に対応させることができそうです。

  TOR = {
    View: wp.revisions.view.Diff.extend({
      events: {},

      initialize: function() {
        _.bindAll(this, 'render');
        this.events = _.extend({'click #tor-thin-out': 'thinOut'},
                                wp.revisions.view.Diff.prototype.events);
      },

継承についてやってみてよくわからなかったのはやはり prototype 関連です。 JavaScript はクラスベースではなくプロトタイプベースの言語ということで、ここをしっかり理解せねばなりません。 これについては「JavaScript: The Good Parts」という本を読むのが良いと思います。 (私は自分の記事に従い洋書 Kindle 版を購入しましたが)

この部分についてはネット上にもきちんとまとめられた記事があります。私には今のところ __proto__ は必要なさそうですが。

その他

あと、関連する JavaScript ファイルは非同期に読み込まれているようなので SetTimeout (あるいは _.delay) で実行を遅らせねばなりません。 このあたりは色々な方が書いているのを参考にさせてもらいました。

それと WordPress 3.5 と 3.6 で動作を変えなければなりませんが、これについては PHP の方でクラスを階層化しました。 カレントバージョン用のベースクラスに対し 3.5 用サブクラスで必要な関数をオーバーライドするようにしています。

というわけで色々苦労していますが、JavaScript の経験値を積んでおり、プラグインのバージョンアップを WordPress 3.6 のリリースに間に合わせるのは何とかなりそうな気がしています。 後はもうちょっと利用者が増えたらなあ、という感じですね。

すぐ忘れちゃうのでメモ書きしておきます。 Ticket #16215 の件。 現行バージョン 3.5.1 でおかしくて次期バージョン 3.6 で修正される予定。

現象

簡単に再現できます。

1. 最初にユーザー admin で記事を作って投稿する
2. 次にユーザー blogger323 でその記事を更新する
3. リビジョン画面に行って作者欄を見る

こうなっているはずです。

• 第 3版: 作者 = admin、内容 = blogger323 が更新した内容
• 第 2版: 作者 = blogger323、内容 = admin の投稿した最初の内容
• 第 1版: 作者 = admin、内容 = 空 (自動生成される初版!)

どうしてこうなった？状態なのですが、これは今のリビジョン操作が、更新時に現行の内容をコピーしてリビジョン用レコードを新たに作成するようになっているからです。 つまり、blogger323 が admin の内容をコピーしたリビジョン用レコード (= 第 2版) を作成するので、第 2版の作者は blogger323 としてデータベースに記録されます。 投稿として表示されるレコードには更新がかけられるのですが、作者フィールドは更新対象とならず最初に作成した admin のまま変わらないのです。

3.6 に向けて

日々更新されていくので、どのような対策をしようとしているか興味のある方は Ticket #16215 を参照してみてください。 私は自分のプラグインの処理に関係するかも知れないので気にしていますが、とりあえず 3/13 予定のβ1 待ちです。