ふと見ると、子供とカミさんがメインで使っている PC で Windows Update がエラーとなっていました。 何と、半年近くアップデートができてません。 それはまずいだろうと解決を試みました。 カミさんは気づかないんだなあ…。
以下のような状況でした。
いろいろ検索して試しましたが、結局以下のページの「対処方法 2. Windows Update のコンポーネントをリセットする」の部分に書かれている通りに Fix it を実行したら解決できました。
Fix it の直リンクは以下の通りです。 実行時に、「積極的な修正を実行する (非推奨)」を有効にするところがポイントです。
というわけで、現在 70個もの更新を適用中です (笑)。
ロリポップの事件が話題になっていますが、「『当社のパーミッションの設定不備を利用』されたことが原因」とのことです。 ここでは、備忘録を兼ねて Unix 系システムのパーミッションについてまとめてみたいと思います。
Wikipedia に詳しくまとまっているので、ここで細かくは書きませんが、「ユーザー＝自分 (u)」、「グループ (g)」、「その他 (o)」の 3つのクラスに分けて管理しているというのがポイントです。 それと「リード (r)」、「ライト (w)」、「実行 (x)」ですね。
まず、わかりにくいのが、あるファイルにアクセスするためにディレクトリにどのパーミッションを設定すれば良いかです。 アクセスするには、そのファイルのフルパスのディレクトリ階層を辿っていく途中の全てのディレクトリに x が必要です。
つまり、自分のホームディレクトリのパーミッションを確認して x があるのが u (自分) のみであれば他のユーザーから (サブディレクトリ含めて) ホームディレクトリ以下にあるファイルにアクセスされることはありません。 該当ファイル (例えば wp-config.php) のパーミッションだけを見てもアクセス可能かどうかはわからないのです。
なお、ディレクトリに設定された r はそのディレクトリに存在するファイル名一覧を取得するためのパーミッションで、各ファイルの内容にアクセスできるかどうかとは関係ありません。
某共有レンタルサーバーを契約して使ってみて最初に違和感を覚えたのは、ホームディレクトリのパーミッションが 705 になっていることでした。 以下のようになっているわけです。
drwx---r-x 11 blogger323 users 1024 Jul 13 19:33 ./
「その他 (o)」に「リード (r)」と「実行 (x)」が許可されているので、普通の感覚だと「あれ？ ホームディレクトリが公開されてる？」と思うわけです。 しかし、これは共有レンタルサーバーであるが故の設定だったのです。 「グループ (g)」で許可がなければ「その他 (o)」が許可されていても同じグループのユーザーはアクセスが拒否されます。 この共有レンタルサーバーのユーザーは全て users グループのみに所属するよう設定されているのでしょう。 「同じグループには許可しないけれど、他のグループならばリードと実行オッケー！」というとトリッキーな感じがしますが、そう考えてみると納得できます。
では何故そこまでして「その他」にパーミッションを与えるのでしょう？ 通常 Apache などのデーモン (サービス) は root でない、そのアプリケーション固有のランタイムユーザーID、グループID で実行されています。 そのため、それらのサービスがファイルにアクセスするために許可が必要なのです。 このようなときは私の感覚だとグループを使ってアクセス制御しそうになるのですが、共有サーバーではそれが難しいので「その他」に許可しているのです。
ファイルシステムのアクセス制御だけを考えるならばここまでで十分なのですが、実際にはサービス経由のアクセスも考慮する必要があります。 Apache サービスがファイルにアクセスできるので、Apache 経由で他のユーザーがアクセスできるようになっていないか、すなわち Apache の設定についても考慮が必要となるのです。
ロリポップの件ではここにも問題があったようで、SymLinksIfOwnerMatch が未設定だったためシンボリックリンク経由で他のユーザーのファイルを読み出せていたようです (参考)。
ロリポップでは suEXEC を導入していて CGI の実行権限は各ユーザーの権限となるようです (参考)。 であれば、今回の対応で変更したように wp-config.php のパーミッションはオーナーのみアクセス可能な 400 で十分ということになります。
今回は濡れ衣を着せられた WordPress ですが、テーマやプラグインは信頼できるところから入手したものでない限り使ってはなりません。 ブラウザの管理画面から新しいテーマやプラグインが導入できるということは WordPress、すなわち Apache サービスがファイルを書き換えることができるということです。 もちろん、WordPress はデータベースのデータの読み書きも可能です。 ということは WordPress で動作するテーマやプラグインに悪意のあるコードが含まれている場合はもちろん、脆弱性が含まれる場合も悲惨な結果を招いてしまいます。
ちなみに私はそうとうメジャーなものと自分で開発したもの (その1、その2) のみ使うようにしています。
404 の話になってないし。ま、いっか…w
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番目のウィジェットエリアにウィジェットを追加すると自動的にサイドバーが表示されるようになります。 テーマ開発者の意図としては、基本的にフッターのウィジェットエリアを使ってサイドバーは使わなくても良いでしょ、ということの様です。 ですが、やっぱりサイドバーは必要ですね (＝ポジショントーク)。 というわけで、まずはこの副ウィジェットエリアに必要なウィジェットを追加しましょう。
ウィジェットを加えてサイドバーが現れたら、次にテーマファイルに手を加えます。 というのも、サイドバーとして扱いたい div 要素に ID 属性がないからです。 そのままでは Standard Widget Extensions は使えないので、以下のように Twenty Thirteen の sidebar.php を修正します (diff 形式表示)。 ま、「mysidebar」でなくてもいいんですが…。
if ( is_active_sidebar( 'sidebar-2' ) ) : ?>
もし、オリジナルに手を加えたくないというのであれば、子テーマを作りましょう。 子テーマファイルを用意したのでご利用ください。
あとは Standard Widget Extensions の設定画面で以下のように設定するだけです。
Twenty Twelve と Twenty Eleven はそのまま使えるのですが、Twenty Ten も Twenty Thirteen 同様に一工夫必要なテーマです。 と言ってもこちらはずっと簡単です。 以下のパラメータを設定して、「ウィジェットエリア1」のみ使用してください。(「ウィジェットエリア2」は空のままにします。)
宣伝しておきます。
気に入ったら是非 Twitter や Facebook で広めてください。 Thin Out Revisions もよろしく！
WordPress.org のリポジトリは Subversion が使われているので、プラグインを登録・更新する際は Subversion を使わなければなりません。 しかし、普段は git を作っているのでどうしたものかと思っていました。 以前から良さそうな記事を見つけてはいたのですが、英語で分量が多かったのでブクマのみで放置したままでした。 今回、Windows 上に PhpStrom 開発環境を作ったの機にこの記事を参考に git-svn を使ってみたのでこれをまとめます。 私の場合、Git for Windows を使っていますが、他の環境でも同様にできるでしょう。
追記 (2013.1.10)
その後に得た知見を反映し、大幅に書き換えました。
こちらの記事も参照ください。
以下のような想定です。
今回は 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.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 を使えばよいと思うので説明は割愛します。
さあ、いよいよリリース作業です。 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 ディレクトリについては専用のブランチを割り当てて作業します。 詳細はこちらの記事をご覧ください。 あまりにも日本語での需要が少ないようなので英語で書いてしまいましたが、コマンド実行例を見れば何を実行しているかご理解いただけると思います。
今回のバージョンアップでは結構パラメータが増えました。 詳細は SWE 日本語ページをつくったのでそちらを参照してください。
従来よりお使いの方は設定画面で一瞬「指定できる項目が減った？」と思ってしまうかも知れません。 初めて使う方が戸惑わないように最初は必要最低限のオプションのみ表示するようにしたからです。 ちょっと一手間増えてしまいましたが、各種設定を行うには「Show Expert Options」を押してみてください。
今回の目玉はこれです。 これを有効にすると逆方向にスクロールし始めたときにすぐ追随するようになります。 サイドバーの底部を強調するよりも全体的に見せたいときに有効な動作で、本文とサイドバーが長めのサイトにお勧めです。 従来の動きと比較動画を作ればよいのでしょうが、そこまで手が回らず…。
コメントをいただいた皆様、ありがとうございました。 全部の要望を取り入れるのは難しいのですが、なるべくカスタマイズしやすくわかりやすいところを目指したつもりです。 それでも物足りないときは遠慮せずソースをいじってしまってくださいw
WordPress 3.6 がリリースされていないので宣伝し辛いのですが、Thin Out Revisions の最新バージョンも頑張りました。 WordPress で投稿のリビジョンコントロールをお考えの方は是非ご利用ください。
環境構築シリーズ 4回目の今回は PHPUnit を使って WordPress プラグイン用のテストを書くところまでです。 XAMPP を使う等いろいろ環境の前提条件があるので初回から読んでいただけると良いと思います。
まずは 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 プラグインのテストの準備をしましょう。 この部分は 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 ダイアログ左上の入力欄に文字列を入れると該当するメニューのみの表示となるので便利です。
さて、本題です。
自作プラグインのコードを 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 のデバッグをし始めるのは思ったより簡単でした。
まず、準備として JetBrains のブックマークレット作成用サイトにアクセスし、ブックマークレットを作成します。 IDE key は PHPSTORM のままでオッケーなので、Xdebug の方の「Generate」をクリックし、表示されたリンクをブラウザにブックマークします。 とりあえず、「Start debugger」と「Stop debugger」が最低限ですが、一通りブックマークしておきましょう。 以下のようにブックマークツールバーに入れておくといいのではないでしょうか。
後は PhpStorm がデバッガからの情報を待ち受ける状態としてからデバッガをスタートします。 具体的には電話アイコン (「Start Listen PHP Debug Connections」) をクリックしてから、先ほどの「Start debugger」ブックマークをクリックするだけです。
続いて 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 関連はいろいろ試してからまた記事にしたいと思います。
ついでと言っては何ですが、せっかく 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 での設定です。 「File」－「Settings」と選んでダイアログを表示し、もろもろを設定していきます。
「Interpreter」の右隣の「…」をクリックした後に表示される画面で「＋」ボタンを押し XAMPP 用のエントリを追加します。 PHP ホームディレクトリを指定し、Xdebug を「Debugger」として選んでおきます。
「Include path」も必要に応じて設定しておきます。 これで「PHP」のページは以下のようになったはずです。
「Xdebug」のところのポートの設定を前回編集した php.ini の設定と合わせます。
私は Git for Windows (msysgit) を使用しています。 この git.exe のパスを正しく設定します。 設定したら「Test」ボタンを押して正常性を確認しておきましょう。
ちなみに Subversion の方は外部コマンドを用意しなくても SVNKit を用いたクライアント機能が PhpStorm に実装されています。 WordPress.org のリポジトリは Subversion で管理されていますが、そちらにも対応できます。
私の場合、Git で仕上げたソースコードを Subversion で WordPress.org にチェックインするという何となくイケてない方法を採っているので、ソース管理をどうやって行くかは個人的な課題だったりします。(追記: その後、git-svn を使っています)
次回は Git (Version Control) 機能とデバッグ機能関連を設定します。