.htaccessのRewriteRuleを編集する前に準備すべきこと（仕様の確認、FireFoxの設定、テストページの作成、環境変数の確認）を概説します。Cut&Tryになりがちですが、段階を踏んだ方が結果的に早く終わることが多々あります。
はじめに
WordPressを始めると、.htaccessのRewriteRuleを編集する機会が多少あります。例えば
- マルチサイトの導入
- フォームのページをSSL接続限定にする
- 固定リソースをWordPressを経由しないようにする
などです。
私は多少凝ったことをやろうとして、始めはRewriteRuleについて解説しているブログ等を見ながらCut&Tryで行っていました。
しかし失敗も多く、途中から環境の整備を始めました。結果的に、最初から順を追ってやったほうが時間のロスをせずに済んだと思います。
本稿では、私が「最初からやっていれば良かった…」と思う、編集前の準備を書きたいと思います。
仕様の確認
いろいろなサイトのサンプルを参考に、いきなり弄るより、最初にちゃんとした仕様を確認しましょう。
いろいろなブロガーさんも解説してくださっていますが、apache.orgの中のページが一番確実です。
http://httpd.apache.org/docs/current/mod/mod_rewrite.html
疑問の際はこのページを参照して頂き、なおかつ実験をされることをおすすめします。
私の理解も限定的ですが、基本的な点のみご説明いたします。（すべての仕様、正確な仕様は先のページをご参照ください。）
RewriteRule
Usage: RewriteRule Pattern Substitution [flags]
URLをPatternでテストし、マッチした場合はSubstitutionで書き換えます。
Patternには、.htaccessが置かれたディレクトリから後のURLで、最初に’/’がつかないものについてのマッチパターンを正規表現で指定します。
Substitutionには、ファイルパス、URLパス（URLの、ホスト名より後ろのパス）、絶対URL（httpあるいはhttpsなどから始まるURL）、’-‘を指定します。普通は‘/’から始まるドキュメントルートからのURLパスを指定すると混乱が少ないと思います。（’/’で始まらない相対URLパスにはRewriteBase が適応されます。）また’-‘を指定した場合には、書き換えは行われません。
flagsは主に以下の2つを使います。
- L：以降のルールは処理しません。
- R：リダイレクトします（他のページに転送すること）。R=404のようにステータスコードを指定することもできます。
RewriteCond
Usage: RewriteCond TestString CondPattern
RewriteRuleの前に書いて、それが適応される条件を指定します。
TestStringには、テストしたい環境変数や、ファイルやディレクトリのパスを書きます。
CondPatternには、普通は正規表現によるマッチパターンを書きます。先頭に’!’を書いた場合はNOTの意味で、そのあとのパターンにマッチしないことがRewriteRuleの適応条件になります。TestStringにファイルやディレクトリのパスを書いた場合、CondPatternには’-d’、’-f’を指定して、そのディレクトリやファイルがあるかどうかをテストすることができます。
RewriteCondを複数書いた場合それらの条件はAND結合になりますが、最後に'[OR]’を書くことで、条件をOR結合することができます。
RewriteCondのTestStringに%{REQUEST_URI}を指定した場合、それは‘/’から始まるURLパスですので、CondPatternの正規表現もそれに合わせて書く必要があります。
（私の混乱した点が、「RewriteCondのCondPatternや、RewriteRuleのPatternやSubstitutionに書かれるURLはどこから書くの？先頭に’/’は入るの？」という点でしたので、それに関して詳しく書かせていただきました。）
WordPressの作成した.htaccessを見てみる
ではWordPressの作成した.htaccessを見てみましょう。（/wp/以下にインストールした場合です。）
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /wp/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wp/index.php [L]
</IfModule>
# END WordPress
指定したURLに対応するファイルやディレクトリが存在しない場合、9行目のRewriteRuleによって、そのディレクトリ自体へのリクエスト以外の、ほぼすべてのリクエストがindex.phpに書き換えられます。（WordPressはindex.phpですべてのリクエストを処理します。）
そしてindex.php へのリクエストは、5行目のRewiteRuleで書き換えせずに終了です。
9行目と5行目の処理は独立しているような気もしますが、実際に実験してみると9行目の書き換えの後に5行目の評価がなされているようです。
FireFoxの準備
私の場合、.heacessの編集の目的はフォームのページを常にSSL接続にすることでした。フォームのページにhttp://で接続してきた場合は、https://にリダイレクトすることになります。最初はChromeを使っていたのですが、.htaccess以外にもWordPress内部でもリダイレクトが発生したり、カオスな状態になりました。
Chromeでリダイレクトを制限することはできなさそうなので、FireFoxを使いました。
FireFoxのインストール
FireFoxはmozillaのページからダウンロードします。
http://www.mozilla.jp/firefox/
アドオンのインストール
次にデバッグに必要なFireFoxのアドオンをダウンロードします。各アドオンは、各URLにFireFoxからアクセスすることで、簡単にFireFoxに組み込むことができます。
Firebug
デバッグツールです。
https://addons.mozilla.org/ja/firefox/addon/firebug/
NoRidirect
特定サイトでのリダイレクトをブロックします。
https://addons.mozilla.org/ja/firefox/addon/noredirect/
NoRedirectの設定
NoRedirectを設定します。
FireFoxの左上のオレンジ色のボタンから、オプション＞NoRedirect、を選択します。
枠線のように自分のサイトに対する規則を追加することで、リダイレクトの前に停止してくれるようになります。（URLは各位の環境に合わせてください。）
Firebugの使い方
FireFoxの右上に、テントウムシのようなアイコンがあるので、それをクリックするとウィンドウ下部にFirebugの画面が表示されます。
Firebugの情報のバーの「ネット」をクリックすると、サーバへのアクセスの様子を表示するツールが現れます。（初回の起動では「有効化」するよう促されますので、クリックして有効化します。）
テストページの作成
テストページを作成し、適当なディレクトリ（例えば/wp/）に置きます。（前回の投稿のテストページと同じです。）
test.php
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>テスト</title>
</head>
<body>
<?php
// 環境変数、コールスタックを表示する関数
function yjd_debug_print($show_all=false) {
ob_start();
debug_print_backtrace();
$str = ob_get_clean();
echo nl2br( $str );
echo "<br />\r\n";
// ハイライトしたい環境変数はここに追加する。
$high_light = array(
"HTTP_HOST",
"HTTPS",
"SERVER_PORT",
"REQUEST_FILENAME",
"REQUEST_URI",
"HTTP_X_SAKURA_FORWARDED_FOR"
);
// 表示したい環境変数のテーブルはここに追加する。
$tables = array(
'_SERVER' => $_SERVER,
'_ENV' => $_ENV,
'_GET' => $_GET,
'_POST' => $_POST,
);
foreach( $tables as $tname => $table ) {
foreach( $table as $key => $val ) {
$show_key = $key;
$is_high_light = in_array( $key, $high_light );
if( $is_high_light ) {
$show_key = "<strong>" . $key . "</strong>";
}
if( $show_all || $is_high_light ) {
print( "\$${tname}['$show_key'] = $val<br/>\r\n");
}
}
echo "<br />\r\n";
}
}
yjd_debug_print(true);
?>
</body>
</html>
以上で環境の整備は完了です。
環境変数の確認例
上の環境の具体的な使用例として、.htaccess内の環境変数の確認例を示します。（前回の投稿と同内容ですので、既読の方は飛ばしてください。またFireFoxは登場しません。m(_ _)m）
WordPressをインストールしたディレクトの.htaccessの先頭に、先のtest.phpを呼び出すRewritRuleを追加します。
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# テスト用のルール
RewriteRule ^echo$ /wp/test.php?HTTP_HOST=%{HTTP_HOST}&REQUEST_URI=%{REQUEST_URI}&REQUEST_FILENAME=%{REQUEST_FILENAME}&SERVER_PORT=%{SERVER_PORT} [L]
（以下略）
7行目が追加したRewriteRuleです。echoへのリクエストをtest.phpに書き換える際に、環境変数をGETメソッドのクエリの形にして追加しています。ブラウザからechoにアクセスすると、test.phpの$_GETの内容を表示する部分で環境変数の内容が確認できます。
この例では実際にRewriteCondで使いそうな環境変数を確認しいています。実際にRewriteCondのCondPatternを書く前に、一度環境変数の内容を確認することをおすすめします。
（実際にさくらレンタルサーバーの共有SSLでは、SSL接続でも%{HTTPS}はセットされません。前回の投稿では、さくらレンタルサーバーの共有SSLに特有な環境変数を確認しています。）
まとめ
.htaccessのRewriteRuleを編集し始める前に、準備として以下を行っておくとよいと思います。
- ご本家（apache.orgのページ）での、仕様の確認
- リダイレクトを目的としている場合は、FireFoxとFirebug、NoRedirectのインストール
- テストページを用いての、環境変数の確認
次回は、「最初からこの準備を行っていればよかった」と思わせた、ちょっと凝ったRewriteRuleの編集について書こうかと思っています。