wp-config.phpをWordPressの一つ上へ置くときは探索条件と公開領域を確認する

WordPressは、通常の設置場所にwp-config.phpがなければ、WordPress本体の一つ上の階層も探します。ただし、どの上位階層でも読めるわけではありません。また、一つ上へ移すだけで、必ずウェブの公開領域から外れるとも限りません。

移動する前に、WordPress本体の場所、ウェブサーバーが公開する場所、移動先に別のWordPressがないことを確認します。目的はファイルの位置を変えることではなく、データベースの接続情報や認証用の値を、不要な相手から読めない状態で管理することです。

WordPressは二つの場所を順に探す

WordPress 3.8のwp-load.phpは、wp-config.phpを次の順で探します。

1. ABSPATHの直下
2. ABSPATHの一つ上

ABSPATHは、WordPress本体を読み込む基準となるディレクトリです。標準のwp-load.phpでは、自分自身が置かれたディレクトリをABSPATHとして定義します。

説明用に、WordPress本体が次の場所にあるとします。

/srv/www/example/wordpress/

最初に探す場所は次のとおりです。

/srv/www/example/wordpress/wp-config.php

そこになければ、次に一つ上を調べます。

/srv/www/example/wp-config.php

二階層以上さかのぼった場所や、任意に決めた別ディレクトリまでは探しません。移動先を自由に指定できる設定ではなく、標準処理が確認する候補が二つあると捉えます。

本体ディレクトリにあるwp-config.phpが先に使われる

二つの場所へ同名ファイルを残した場合、WordPress本体と同じ階層にあるwp-config.phpが先に使われます。一つ上のファイルを編集しても、動作へ反映されません。

移動するときは、現在のファイルをいきなり削除せず、非公開の場所へ控えを作ります。移動先へ複製して内容と所有者を確認したあと、本体側のファイル名を一時的に変えて動作を確認します。問題があれば、元の名前へ戻せる順序にします。

動作確認後も、古いwp-config.phpを.bakや.oldという名前で公開ディレクトリへ残しません。ウェブサーバーがその拡張子をPHPとして処理するとは限らず、設定内容を文字として返す可能性を管理できないためです。控えは公開対象ではない保存場所へ移します。

一つ上に別のWordPressがある場合は読まない

wp-load.phpは、一つ上にwp-config.phpがあるだけでは読み込みません。同じ階層にwp-settings.phpがないことも確認します。

これは、親ディレクトリと子ディレクトリへ別々のWordPressを置く構成で、子側が親側の設定を誤って使わないための条件です。

/srv/www/example/wp-config.php
/srv/www/example/wp-settings.php
/srv/www/example/blog/wp-load.php

この仮例では、blog側から見た一つ上にwp-settings.phpがあります。標準の探索条件では、親のwp-config.phpをblog側の設定として読みません。

複数サイトを同じ契約領域へ置いている場合は、ディレクトリ名だけで判断せず、移動先とその一つ下にあるwp-load.php、移動先にあるwp-settings.phpを一組で確認します。

一つ上の階層とウェブ公開領域は同じ意味ではない

WordPress本体の一つ上が、ウェブサーバーの公開領域より外にあるかどうかは、設置構成で変わります。

/home/example/public_html/wordpress/

この仮例で公開領域がpublic_htmlなら、WordPress本体の一つ上は次の場所です。

/home/example/public_html/

ファイルはWordPress本体の外へ出ますが、ウェブの公開領域からは出ていません。一方、WordPress本体がpublic_html直下にあるなら、その一つ上は公開領域の外になる可能性があります。

移動先を評価するときは、FTP画面やファイル管理画面の「一つ上」という表示だけで決めません。サーバーの管理資料でDocumentRootを確認し、その配下からHTTPで到達できる範囲を分けます。DocumentRootが分からない場合は、移動より先にサーバー管理者へ確認します。

読み取り権限はウェブサーバーの実行者から決める

wp-config.phpを一つ上へ移しても、PHPから読めなければWordPressは起動しません。反対に、同じサーバーの不要な利用者まで読める状態なら、位置だけを変えても管理範囲は狭まりません。

必要なのは、ファイル所有者、PHPまたはウェブサーバーの実行者、保守担当者です。三者のうち誰に読み取りが必要かを決め、利用中のサーバー方式に合う所有者と権限を設定します。すべての環境へ共通する数値を決め打ちしません。

共用サーバーでは、利用者が所有するPHPとして動く場合と、ウェブサーバーの共通利用者として動く場合があります。契約先の推奨値を確認せずに読み取りを狭めると、サイト全体がデータベース接続前に停止します。権限を広げて解決する前に、実行者と所有者を確認します。

移動後は表示だけでなく更新経路も確認する

移動後は、公開ページが一枚表示されただけで完了にしません。少なくとも、公開ページ、管理画面へのログイン、投稿の保存、画像の表示、予約処理や更新処理の入口を確認します。別の入口からWordPressを読み込む処理でも、同じwp-load.phpと設定へ到達できるかを見るためです。

作業記録には、WordPress本体の絶対パス、DocumentRoot、wp-config.phpの新しい絶対パス、所有者と権限、確認した入口、元へ戻す手順を残します。パスワード、認証用キー、データベース接続値そのものは、画面写真や作業報告へ貼り付けません。

制作や保守を委託しても、設定ファイルの所在と復旧手段はサイト所有者が把握します。担当者が変わったときに場所が分からなければ、バックアップの範囲から漏れたり、接続障害時に別のファイルを編集したりします。

最初の一手は、現在のwp-load.phpとwp-config.phpの絶対パス、サーバーのDocumentRootを一枚へ書くことです。一つ上が公開領域の外か、別のwp-settings.phpがないか、PHPが読める所有者かを確認してから移動します。