Scrapdiary

DesigningとEngineeringの架け橋

さくらのレンタルサーバーでマルチドメイン利用時のDOCUMENT_ROOT

連日さくらネタ。

www.sakura.ne.jp

さくらのレンタルサーバでは「マルチドメイン」といういわゆるバーチャルホスト機能が手軽に使えます。ただコントロールパネルでの設定と実際の稼働環境での認識に差異がありハマったので備忘録です。

コントロールパネルでの設定値

その際コントロールパネルの設定にて当該ドメインに対応するディレクトリを指定します。指定したディレクトリ以下にファイルを配置すると、そこを起点に当該ドメインでアクセスした場合にコンテンツとして展開されます。

 

  • ドメイン設定: site1.hostname.tld
  • パス設定:   /home/user_name/www/site1

 

上記の場合、DNSを設定した後にsite1.hostname.tldへアクセスすると、/home/user_name/www/site1 以下に設置したファイルがドキュメントルートとみなされて表示されます。

 

  • サーバ上パス: /home/user_name/www/site1/index.html
  • アクセスURI: site1.hostname.tld/index.html

 

サーバ上のファイル、この場合マルチドメインで設定したディレクトリの直下に配置したファイルは、マルチドメインで設定したドメインのホスト直下にマッピングされます。

つまり、コントロールパネル上パス設定したディレクトリはそのドメインで稼働させているホストのドキュメントルートとして機能していると理解できます。

環境変数での参照値

しかし、このドメインのホストでApacheから渡される環境変数(例はPHP)を確認すると

 

  • $_SERVER['DOCUMENT_ROOT']:/home/user_name/www

 

という値が返されます。

DOCUMENT_ROOTという環境変数は比較的よく参照される値かと思われますが、これがマルチドメインで設定したディレクトリの指定と異なる仕様というのは少々ツライところです。

詳細は不明ですが、恐らくApache側でのバーチャルホスト設定は初期ドメイン1つであって、マルチドメインについては別の方法でマッピングしているということなのでしょうか…。

 

ただホスト名に関する値はマルチドメインで設定した値になっていました。

 

  • $_SERVER['HTTP_HOST']:site1.hostname.tld

 

こちらはコントロールパネルで設定したものと合致しますので、なぜDOCUMENT_ROOTだけが合致しないのかは不可解です。

 

何が問題だと認識しているのか

この仕様ですと、マルチドメインにて展開したコンテンツ内にDOCUMENT_ROOTを参照する記述をした処理が含まれると、コンテンツ内で正しいパスが把握できなくなってしまいます。

WordPressを標準(クイックインストール)で提供しているのでWordPress本体は問題なさそうなのですが、例えばテーマやプラグインなどでDOCUMENT_ROOTを参照する処理が含まれていた場合には不都合が発生していまいます。

FAQ等事例に記述が見つけれれなかったので公式サポートにて技術の方に確認させていただきましたが、これは仕様(本投稿時点)とのことですのでマルチドメイン機能を使ってPHPCGIを利用する場合には注意が必要です。

 

この環境変数「DOCUMENT_ROOT」はバーチャルホストで稼働させる際には難いものと理解していましたが、そもそもDOCUMENT_ROOTを安易に参照する処理は推奨されないものなんでしょうか。

 

ま、その名の通り環境に左右されるからあまりよくないのでしょうね。

 

 

<追記>

お名前.comのレンサバでもユーザのホームディレクトリよりかなり上位のディレクトリがセットされていたので、レンタルサーバ系では比較的よくある仕様なのかも。