投稿者: blogger323

WordPress 用プラグインの Standard Widget Extensions の新バージョン 1.2 をリリースしました。 現在、Standard Widget Extensions はサイドバースクロール時固定機能とウィジェット伸縮機能を持っています。

さて、今回のリリースでは「伸縮時間」、「再計算タイマー」の 2つのパラメータを追加しました。 これらについて説明します。

伸縮時間

ウィジェット伸縮時のアニメーション時間を指定します。 内容としては jQuery slideDown/slideUP に渡す duration パラメータそのもので、ミリ秒単位で指定します。

これまでは 400 固定でしたが、今後はこのオプションで指定することになります。

再計算タイマー

サイドバースクロール時固定機能 (Sticky Sidebar) はどうしても動的なコンテンツと相性が悪いです。 例えば、このサイトでも Hatena のブログパーツや SyntaxHighlighter を使っていますが、これらは要素の高さを後から変えてしまうので、最初に計算した値で動作している Standard Widget Extensions とずれが生じます。 その結果、サイドバーとフッターが重なったりして悲しい思いをします。

これを解消するにはコンテンツの高さが確定したところで swe.resizeHandler() を呼べばよいのですが、各ライブラリの動作終了時ハンドラにこれを登録する作業は大変ですし、そもそもライブラリがそのあたりを考慮していないとどうしようもなかったりします。

そこで、今回 Standard Widget Extensions の初期化処理終了から指定秒数後に swe.resizeHander() を呼び出せるように「再計算タイマー」オプションを追加しました。 安易な解決策と言えばそうなのでしょうが、他ライブラリの終了を見計らって再計算を実行することができます。 例えば「3」に指定すれば、初期化処理の終了から 3秒後に swe.resizeHander() が呼び出されます。 デフォルトでは 0 = 無効となっていますが、もしサイドバーとフッターが重なって困っている方は 3 ～ 5 ぐらいに設定して様子を見てください。

ちなみに遅延画像ロードを行うプラグイン等を使用するときは height を指定しておけばきちんと動作するはずです。

日本語ホームページをよろしく！

全然アクセスされていないのですが、Standard Widget Extensions には日本語ホームページが存在し、そちらに個々のパラメータを詳しく説明しています。 是非一度チェックしてみてください！

WordPress 3.6 で Thin Out Revisions を使用しているとき、投稿編集画面で以下のような警告が出力されることがあります。

コピーリビジョンが見つかりません。
編集前に一度更新ボタンを押してコピーリビジョンを作成しておくことをお勧めします。

WordPress 3.6 よりリビジョンの扱いが変わって、現在の投稿と全く同じ内容のリビジョン (これを「コピーリビジョン」と呼んでいます) を持つようになりました (関連記事)。 従って保存された投稿は必ず最低 1つのリビジョンを持つことになります。

この警告は本来あるはずのコピーリビジョンがない場合に表示されます。 そのまま編集すると編集前の情報は失われるので、一度編集を加えずに保存することをお勧めしているのです。

3.6 RC が出て、もう少しで WordPress 3.6 が日の目を見ることになりそうです。 もともと 5月に出る予定だったのにすったもんだがあって、7月のこの時期にやっと Release Candidate が出た、ということですね。

さて、Standard Widget Extensions ですが、本日アップデートを行って Version 1.1.1 となりました。 今回のアップデートのメインテーマは WordPress 3.6 に漏れなく付いてくる (予定の) Twenty Thirteen への対応です。 いや、何が難しかったかというと、サイドバーの親要素に position = absolute なんてのがいるし、メインとサイドバーの要素は最初から top の値がずれてるし…、みたいなところです。

でも、それらをきちんと対応しました。 恐らく非標準テーマでも使いやすくなったことでしょう。 ただ、Twenty Thirteen のサイドバー要素の ID が無いのはいかんともし難いのでそこはテーマファイルの方に手を加えていただかねばなりません。 というわけで、Twenty Thirteen と共に Standard Widget Extensions を使うための方法を説明するのが今回のエントリの趣旨です。

サイドバーがなくなった！

Twenty Thirteen を使ってまず最初に気づくのはサイドバーが無いことなんですね。 ありゃー、Standard Widget Extensions の出る幕なし。

…と思いきや、「副ウィジェットエリア」(リリース前なので名称変更の可能性あり！) という名の 2番目のウィジェットエリアにウィジェットを追加すると自動的にサイドバーが表示されるようになります。 テーマ開発者の意図としては、基本的にフッターのウィジェットエリアを使ってサイドバーは使わなくても良いでしょ、ということの様です。 ですが、やっぱりサイドバーは必要ですね (＝ポジショントーク)。 というわけで、まずはこの副ウィジェットエリアに必要なウィジェットを追加しましょう。

Twenty Thirteen に手を加える

ウィジェットを加えてサイドバーが現れたら、次にテーマファイルに手を加えます。 というのも、サイドバーとして扱いたい div 要素に ID 属性がないからです。 そのままでは Standard Widget Extensions は使えないので、以下のように Twenty Thirteen の sidebar.php を修正します (diff 形式表示)。 ま、「mysidebar」でなくてもいいんですが…。

 if ( is_active_sidebar( 'sidebar-2' ) ) : ?>
        

もし、オリジナルに手を加えたくないというのであれば、子テーマを作りましょう。 子テーマファイルを用意したのでご利用ください。

あとは Standard Widget Extensions の設定画面で以下のように設定するだけです。

メインカラムの ID

primary

サイドバーの ID

mysidebar

ウィジェットのクラス名

widget

次の幅以下で無効化

1000

ついでに Twenty Ten

Twenty Twelve と Twenty Eleven はそのまま使えるのですが、Twenty Ten も Twenty Thirteen 同様に一工夫必要なテーマです。 と言ってもこちらはずっと簡単です。 以下のパラメータを設定して、「ウィジェットエリア1」のみ使用してください。(「ウィジェットエリア2」は空のままにします。)

メインカラムの ID

container

サイドバーの ID

primary

ウィジェットのクラス名

widget-container

日本語公式サイト

宣伝しておきます。

• Standard Widget Extensions 日本語公式ページはこちらです。
• まだ使っていない方は是非「Quick Switchback モード」を試してみてください。 記事とサイドバーが長めのサイトには有効だと思います。

気に入ったら是非 Twitter や Facebook で広めてください。 Thin Out Revisions もよろしく！

WordPress.org のリポジトリは Subversion が使われているので、プラグインを登録・更新する際は Subversion を使わなければなりません。 しかし、普段は git を作っているのでどうしたものかと思っていました。 以前から良さそうな記事を見つけてはいたのですが、英語で分量が多かったのでブクマのみで放置したままでした。 今回、Windows 上に PhpStrom 開発環境を作ったの機にこの記事を参考に git-svn を使ってみたのでこれをまとめます。 私の場合、Git for Windows を使っていますが、他の環境でも同様にできるでしょう。

追記 (2013.1.10)
その後に得た知見を反映し、大幅に書き換えました。 こちらの記事も参照ください。

概要

以下のような想定です。

• git によるバージョン管理をメインにして開発。GitHub を用いる。
• プラグインリリースの準備ができたら work ブランチを使用して Subversion に送るコミットを一つにまとめる。 コミットの数が多いと顰蹙買うようなのでこうする。
• assets ディレクトリの更新は専用のブランチを割り当てる。

SVN リポジトリの取得

今回は Subversion での更新履歴を一通り git 側に持ってくる方法を説明します。 まずは WordPress.org のリポジトリで最初のコミットのリビジョン番号を探します。 以下自分の例で書いてしまいますが、適宜読み替えてください。

svn log http://plugins.svn.wordpress.org/standard-widget-extensions

最初のコミットは一番下に見えると思うので、そのリビジョン番号をメモします。 私の場合は r630258 でした。 次にこのリビジョン番号を使って git svn clone を実行します。

git svn clone -s -r630258 --no-minimize-url http://plugins.svn.wordpress.org/standard-widget-extensions standard-widget-extensions

次は fetch するのですが、これがやたらに時間かかります。

cd standard-widget-extensions
git svn fetch

ハングアップしたのかと思ってしまうほどなので、以下のように GIT_TRACE=2 を設定して実行すると進み具合が見えて (?) 良いかもしれません。

GIT_TRACE=2 git svn fetch

まあ、結局時間はかかるので、しばらく放置しておくことになりますが…。

fetch が終了してもまだワーキングコピーはありません。 好みで改行コードの設定を今のうちにしておきましょう。 私は LF のみでやりたいので以下の設定をしておきます (注: Windows なのでこんなことをしてます)。

git config --local core.autocrlf false

最後に git svn rebase を実行して最新のファイルを取得します。 ここで初めて master のワーキングファイルができます。

git svn rebase

なお、Subversion 上のこれまで履歴を一通り git 側に持ってくる前提で説明しましたが、それが不要であれば最初の git svn clone で最新リビジョン番号を指定することでずっと時間を短縮できます。 こうすると clone が終了した時点でワーキングディレクトリが作成されると思います。

GitHub での公開

GitHub についてはあちこちで説明されているので簡単に済ませます。 GitHub で公開するには、まず GitHub 側で予め空のリポジトリを作っておきます。 github.com で「Create a new repo」とすればよいです。 続いて Git for Windows で認証関連で必要な準備をします。 まず、鍵ペアを生成します。

ssh-keygen -t rsa -C "blogger323@example.com"

そして、出来た公開鍵 ~/.ssh/id_rsa.pub の内容をそのまま github.com に登録します。 「Account settings」「SSH Keys」で「Add SSH key」から実行することができます。

公開鍵の登録が終わったら実際に動作を試します。

ssh -T git@github.com

「Hi ****! You’ve successfully authenticated, but GitHub does not provide shell access.」と表示されればオッケーです。

では GitHub に push してみましょう。 github.com で指定したリポジトリ名に .git をつけてアクセスします。

git remote add origin git@github.com:blogger323/standard-widget-extensions.git
git push origin master

push し終わるとこれまで WordPress.org の SVN リポジトリで行ってきたコミットが一通り GitHub に送られます。 最新のコミットだけ送るのでも良かったような気がしますが、どうやるかよくわからないので気にしないことにしますw

普段の開発

普段は git リポジトリにに対してのみコミットを行います。 普通に master ブランチで git commit や git push を使えばよいと思うので説明は割愛します。

WordPress リポジトリへのリリース

さあ、いよいよリリース作業です。 git のコミットは粒度が細かいので、Subversion リリース時に 1つにまとめて送ります。 このためにマージ用ブランチ work を用意します。 初回リリース時のみの作業となりますが、remotes/trunk に対応する work ブランチを作ります。

git checkout -b work trunk

普段は普通にブランチを切り替えるだけでよいです。

git checkout work

そして、これまでの master の履歴を work にマージします。 –no-ff が重要です。 この時のコミットメッセージが WordPress リポジトリに記録されるので、–edit オプションをつけて明示的にコミットメッセージを編集しておくとよいでしょう。

git merge --no-ff --edit master

これを WordPress.org リポジトリに送るのですが、git svn dcommit は master ブランチで行わなければなりません (参考記事)。 また、git push は必ず git svn dcommit の後に行います。

git checkout master
git merge --ff work
git svn dcommit --username blogger323
git push origin master

–username オプションは初回のみ付けておけば、あとは記憶しておいてくれます。

そしてタグをつければリリースされます。

git svn tag 1.1

Git 側もタグをつけておきましょう。

git tag v1.1
git push origin --tags

work ブランチは remotes/trunk からずれてしまっていると思うので、次回のために reset しておきます。

git checkout work
git reset trunk

ここまでで、master、work、remotes/origin/master、remotes/trunk の全てが同じコミットを指しているはずです。

assets ディレクトリの扱い

assets ディレクトリについては専用のブランチを割り当てて作業します。 詳細はこちらの記事をご覧ください。 あまりにも日本語での需要が少ないようなので英語で書いてしまいましたが、コマンド実行例を見れば何を実行しているかご理解いただけると思います。

今回のバージョンアップでは結構パラメータが増えました。 詳細は SWE 日本語ページをつくったのでそちらを参照してください。

エキスパートモードの導入

従来よりお使いの方は設定画面で一瞬「指定できる項目が減った？」と思ってしまうかも知れません。 初めて使う方が戸惑わないように最初は必要最低限のオプションのみ表示するようにしたからです。 ちょっと一手間増えてしまいましたが、各種設定を行うには「Show Expert Options」を押してみてください。

Quick Switchback モード

今回の目玉はこれです。 これを有効にすると逆方向にスクロールし始めたときにすぐ追随するようになります。 サイドバーの底部を強調するよりも全体的に見せたいときに有効な動作で、本文とサイドバーが長めのサイトにお勧めです。 従来の動きと比較動画を作ればよいのでしょうが、そこまで手が回らず…。

もろもろ

コメントをいただいた皆様、ありがとうございました。 全部の要望を取り入れるのは難しいのですが、なるべくカスタマイズしやすくわかりやすいところを目指したつもりです。 それでも物足りないときは遠慮せずソースをいじってしまってくださいw

WordPress 3.6 がリリースされていないので宣伝し辛いのですが、Thin Out Revisions の最新バージョンも頑張りました。 WordPress で投稿のリビジョンコントロールをお考えの方は是非ご利用ください。

環境構築シリーズ 4回目の今回は PHPUnit を使って WordPress プラグイン用のテストを書くところまでです。 XAMPP を使う等いろいろ環境の前提条件があるので初回から読んでいただけると良いと思います。

PHPUnit のインストール

まずは PHPUnit をインストールしなければなりません。 ここでは XAMPP に付いてきた pear.bat を使ってインストールします。

まず、現在の pear の設定を確認し必要に応じて修正をしましょう。

cd \xampp-portable\php
pear config-show

出力を確認するとデフォルトの設定ファイル (User Configuration File/System Configuration File) の位置が C:\Windows になっていました。 環境変数 PHP_PEAR_SYSCONF_DIR を指定すると変えることができるようですが、私はそのまま C:\Windows\pear.ini (pearsys.ini) で行くことにしました。 従って、config-set コマンドを実行するには管理者権限で開いたコマンドプロンプトを使う必要があります。

私のダウンロードしたバージョンの XAMPP は一部のディレクトリ構成が残念な感じだったので、管理者権限のコマンドプロンプトで以下を実行しました。 最後の 1行は PHPUnit インストール用です。

pear config-set doc_dir \xampp-portable\php\pear\docs
pear config-set cfg_dir \xampp-portable\php\pear\cfg
pear config-set data_dir \xampp-portable\php\pear\data
pear config-set test_dir \xampp-portable\php\pear\tests
pear config-set www_dir \xampp-portable\php\pear\www

pear config-set auto_discover 1

それでは PHPUnit をインストールしましょう。 こちらは通常のコマンドプロンプトでオッケーです。

pear install pear.phpunit.de/PHPUnit

環境によっては install コマンド実行前にプロキシサーバーを設定しておく必要があるでしょう。

set http_proxy=http://proxy.example.com:8080/

続いて PhpStorm の設定です。 PHPUnit が実行できるように「Settings」の「PHP」のページで pear ディレクトリが「Include path」に含まれるようにします。 連載 2回目で設定していたと思いますが、念のため確認しましょう。

「PHP」－「PHPUnit」ページで「PHPUnit library」が「Load from include path」となっているのを確認します。

ここまでで PHPUnit を使う準備はできました。

WordPress プラグインテストの準備

さて、WordPress プラグインのテストの準備をしましょう。 この部分は stackoverflow の記事を参考に多少アレンジを加えています。

まずは GitHub から WordPress のテスト用コードを clone し、もろもろの準備をします。 私の場合、wp-admin や wp-content と同じディレクトリに置きました。

cd wordpress
git clone https://github.com/nb/wordpress-tests.git wordpress-tests

次に clone した wordpress-tests の中の unittests-config-sample.php を参考に unittests-config.php というファイルを作ります。 データベースはユニットテスト専用に用意してそれを設定しましたが、テスト用インストールが既にあるのであればそれを使っても良い気がします。 その他に wordpress コアファイルのパスやドメインの設定もしました。

私の場合、以下の項目をいじりました。

define( 'ABSPATH', 'C:\\xampp-portable\\wordpress\\' );
define( 'DB_NAME', 'wordpress_test' );
define( 'DB_USER', 'wpuser' );
define( 'DB_PASSWORD', 'password' );
define( 'WP_TESTS_DOMAIN', 'hetarena.com' );
define( 'WP_TESTS_EMAIL', 'blogger323@example.com' );

そして初期テーブルを用意する (いわゆる WordPress のインストールを実行する) 必要があるので、wordpress-tests\bin ディレクトリにある install.php を実行します。

C:\xampp-portable\wordpress\wordpress-tests\bin>\xampp-portable\php\php.exe install.php

テストをするにはマイプラグインを有効化した状態にしなければならないと思います。 update_option() を実行する等いろいろやり方はあると思いますが、既に存在しているデータベースの内容を参考に直接 SQL 操作してしまうのが早いかも知れません。

UPDATE wp_options
SET option_value = 'a:1:{i:0;s:41:"thin-out-revisions/thin-out-revisions.php";}'
WHERE option_name = 'active_plugins';

続いて bootstrap.php とそれを呼び出す phpunit.xml を作って PhpStorm に登録します。 この 2つのファイルは wp-content\test\thin-out-revisions に置きました。

bootstrap.php

<?php
$path = '../../../wordpress-tests/bootstrap.php';

if( file_exists( $path ) ) {
	require_once $path;
} else {
	exit( "Couldn't find path to wordpress-tests/bootstrap.php\n" );
}

phpunit.xml

<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false"
				 backupStaticAttributes="false"
				 colors="true"
				 convertErrorsToExceptions="true"
				 convertNoticesToExceptions="true"
				 convertWarningsToExceptions="true"
				 processIsolation="false"
				 stopOnFailure="false"
				 syntaxCheck="false"
				 bootstrap="./bootstrap.php"
		>
	<testsuites>
		<testsuite name="Thin Out Revisions Test Suite">
			<directory>./tests/</directory>
		</testsuite>
	</testsuites>
</phpunit>

前回も使った「Edit Configurations…」から「PHPUnit」を選び「Defined in the configuration file」を選択後「Use alternative configuration file」で先ほど作った phpunit.xml を指定します。

このように作成した Configuration を使って Run コマンドや Debug コマンドを実行すると PHPUnit が走るようになります。

テストケースの作成

後はテストケースを作るだけです。 私は最初の一歩として以下のようにとても簡単なテストケースを作成しました。 作成したファイルは phpunit.xml で指定している tests ディレクトリの下に置き、*Test.php という名前にしなければなりません。

<?php
class HM_TOR_Plugin_LoaderTest extends WP_UnitTestCase {
	public function testCheckInstance() {
		global $hm_tor_plugin_loader;
		$this->assertNotNull($hm_tor_plugin_loader);
	}

	public function testGetOption() {
		global $hm_tor_plugin_loader;
		$this->assertEquals($hm_tor_plugin_loader->get_hm_tor_option('quick_edit'), 'off');
	}

}

Run コマンドを実行すれば Run ウィンドウに以下のように結果が表示されます。

これでプラグインの単体テストができるようになりました。

前回までで WordPress プラグイン開発用の PhpStorm プロジェクトが作成されました。 今回はバージョン管理とデバッグ関連ですが、いろいろと開発環境の前提があるのでまだご覧になっていない方は初回よりご確認ください。

ちょっとその前に

前回説明していませんでしたが、Settings ダイアログはちょくちょく呼び出すことになると思いますが、メニューよりもアイコンから呼び出す方が簡単ですね。 下のアイコンが Settings なのですが、表示されていない場合は「View」-「Toolbar」で表示されます。

また、Settings ダイアログ左上の入力欄に文字列を入れると該当するメニューのみの表示となるので便利です。

Git リポジトリの追加

さて、本題です。

自作プラグインのコードを PhpStorm プロジェクトに追加します。 具体的には Git リポジトリを wordpress/wp-content/plugins の下に clone します。 Git for Windows を使っても良いですが、PhpStrom の中から「VCS」－「Checkout from Version Control」－「Git」で行うこともできます。 私の場合、対象は Thin Out Revisions と Standard Widget Extensions の 2つです。 このように、一つの PhpStorm プロジェクト内で複数の Git リポジトリを使っても問題ありません。

外部コマンドで clone したときはそのことを PhpStorm に認識させるため Settings ダイアログの「Version Control」の画面でディレクトリを追加します。

ここまでで Git のメニューが表示されるようになり、様々な操作が IDE 内から出来るようになります。

私は家では Git 主体で使っているのですが、WordPress.org で管理されているリポジトリを直接扱いたいのであれば「VCS」－「Checkout from Version Control」－「Subversion」で開発を始めることができます。 ただし、頻繁なコミットは嫌われるらしいので、個人的には git-svn とか git merge –squash を覚えて Git で管理するようにしたい今日この頃です (参考記事)。

PHP のデバッグ

PHP のデバッグをし始めるのは思ったより簡単でした。

まず、準備として JetBrains のブックマークレット作成用サイトにアクセスし、ブックマークレットを作成します。 IDE key は PHPSTORM のままでオッケーなので、Xdebug の方の「Generate」をクリックし、表示されたリンクをブラウザにブックマークします。 とりあえず、「Start debugger」と「Stop debugger」が最低限ですが、一通りブックマークしておきましょう。 以下のようにブックマークツールバーに入れておくといいのではないでしょうか。

後は PhpStorm がデバッガからの情報を待ち受ける状態としてからデバッガをスタートします。 具体的には電話アイコン (「Start Listen PHP Debug Connections」) をクリックしてから、先ほどの「Start debugger」ブックマークをクリックするだけです。

JavaScript のデバッグ

続いて JavaScript のデバッグです。 最初に言っておくと .php の Web ページでの JavaScript のデバッグはまだうまく出来ていません。 しかし、.html ページでの JavaScript 実行については次の手順で可能です。

まずは JavaScript のデバッグに必要な設定を行います。 JavaScript のデバッグは Firefox と Chrome に対応しています。 どのブラウザをデフォルトとするかは Settings の「IDE」－「Web Browsers」で設定できますが、初期値は OS デフォルトなので、OS デフォルトのブラウザを Firefox か Chrome にしていれば設定不要です。 ただし、次で説明するデバッグ用 Configuration の一部として個別に保存されるので、必要に応じてこれを複数作って使い分けます。

では Configuratin を作成してみましょう。 メニューの「Run」－「Edit Configurations」を選択し「Run/Debug Configurations」ダイアログを表示します。 そして、「＋」ボタンを押し「JavaScript Debug」－「Remote」を選択します。

Local を選択するとスタートポイントとなる HTML ファイルが必須となる (PHP ファイルは NG) ので、今回は Remote の方を選んで URL 指定を行っています。 Local と言ってもファイルシステムではなくローカルサーバーを通して .html ファイルにアクセスすることになるので (当たり前か…)、.html ファイルからスタートできるのであればこちらで Configuration を作成しましょう。

作成したら、ツールバーで使用する Configuration を選択しておきます。(Edit Configurations もここからできます）

次にブラウザ側の設定です。 ヘルプによると最初のデバッグを開始すると拡張機能がブラウザに自動的にインストールされるとのことで特に設定は不要なはずです。 Firefox は確かにその通りだったのですが、Chrome でやったときはうまくいかなかったので手動でウェブストアより JetBrains IDE Support をインストールしました。

さあ、あとは Debug を開始すればよい、…はずなのですが、先に書いた通り .js の呼び出し元が .php ファイルだともう一工夫必要な様でうまく行きません。 それでは .html + .js ならばすんなり行くと思いきや、debugger 文をブレークポイントの前に入れないと止まらなかったりもします。 JavaScript 関連はいろいろ試してからまた記事にしたいと思います。

LiveEdit

ついでと言っては何ですが、せっかく　JetBrains IDE Support を入れたのでもう一つ機能を紹介しておきましょう。 Settings ダイアログで「Plugins」を表示し、「Install JetBrains plugin…」より「LiveEdit」をインストールします。 するとブラウザでサーバー上のページ (http://localhost/…) を表示し、デザインをリアルタイムに確認しながら PhpStorm 上で .html ファイルを編集できるようになります。 やり方は「Open in Browser」などで PhpStorm からブラウザを呼び出して表示するだけです。

次はテストについて書く予定です。

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>

次回に続きます。