WordPressのダッシュボードを開くといきなり出てくる、
- サイトアドレス (URL)
- WordPress アドレス (URL)
言うまでもなく、それぞれ
- ユーザーがアクセスするURL(例:http://example.com)
- WPのファイルそのものが入っているURL(例:http://example.com/sub)
なのだが、この表面上の名称と内部的な名称が交錯しており、大変に紛らわしい。正確に言うと、内部的にはある程度統一されているが、このダッシュボードの表記の日本語が紛らわしいということだ。
たとえば、「サイトアドレス (URL)」というのは、内部的には
home_url()
で取り出すのだが、「WordPress アドレス (URL)」の方は
site_url()
で取り出す。直感的にはsite_url()と「サイトアドレス」が結びついてしまい、混乱を招く。この混乱は投稿画面での「公開」「公開状態:公開」の混乱と同じく、意訳・誤訳が原因と思われ、改善を望みたい。
とは言っても、ユーザーがアクセスする「いわゆるサイトのアドレス」を「サイトアドレス(URL)」と呼称するのも間違いではない。
問題は、WP内部では「いわゆるサイトアドレス」を”home”と呼び、WPが入っている方のURLを”site url”と呼び分けるという基準が出来上がっており、そこがいまひとつ直感的ではないことに原因があるのかも知れない。
とにもかくも、慣れなければいけない。
まとめてみたのが以下だ。
ユーザがアクセスするURL | WPが入っているURL | |
例 | http://example.com | http://example.com/sub |
ダッシュボード上の表記 | サイトアドレス (URL) | WordPress アドレス (URL) |
取得関数 | home_url() | site_url() |
定数 | WP_HOME | WP_SITEURL |
bloginfo()【非推奨】 | bloginfo(‘url’) | bloginfo(‘wpurl’) |
optionテーブル | home | siteurl |
bloginfoはどうやら非推奨のようで、忘れた方が良いだろう。定数を生で使うのももちろんご法度だ。
ちなみに、定数はwp-config.phpで定義することにより、optionテーブルに入っている値を上書きすることができる。サイトの引越しやステージングにはその方が便利そうだが、いかんせん他のレコードやwp_postsなどのテーブルにはURLが直書きされている箇所が多く、簡単にサイトを移設できるわけではない。WPはポータビリティに関してはかなりしんどい仕様になっている。
もうひとつ、サイトの引越しの際などでよくcssや画像などのアセットが表示されないことがあるが、ここで「原因はhtaccessだ!」と不用意に弄ってしまうとさらに深みにハマってしまう。確かにhtaccessはルートおよびサイトディレクトリ・ルートにそれぞれ必要だが、その中身は同じもので良い。
リダイレクトループの原因はhome siteurlの誤った設定によることが多いので、まずここを確認してみるべきだ。
コメント