WordPressサイトが表示されない場合の確認メモ

ありがちなんですが、動きを把握していれば戸惑うとか焦ることも少なくなりそうです。以下ダミーサイトでローカル環境の画面でメモです。

管理画面の設定確認

基本かもしれませんが、おさらいということで。

WordPressアドレス（URL）とサイトアドレス（URL)の違い

この違いが認識出来てないと色々とエラーに遭遇してもなかなか厳しそうです。

WordPressアドレス

WordPress管理画面に入る、つまり管理者向けのURLのこと。URLなのだけど、どちらかといえばファイルパスであり、Wordpressがあるフォルダを指す。

サイトアドレス

WordPress自体を表示する一般の利用者が見るいわゆるURL

僕の解釈

おそらく、URLが括弧書きされているのは、WordpressアドレスはWordpressの所在場所をURLで示すという意味合いであって、サイトアドレス的なURLではない。

WordPressを管理したい、編集したい等、開発、制作などをする、つまりWordpressサイトを立ち上げるみたいな人は、Wordpressアドレスが何かを完璧に近いしておく必要がある。

サイトアドレスは表示のために使われる。ただし、そもそもそのドメインを取得している必要があるので、サイトアドレスに自由に入れて自由に表示されるわけではない。そもそものインターネットの仕組みとして、ドメイン、サーバを理解していないと意味が分かりづらい気がする。

初心者がこれを見て違いを理解できるかは怪しいと思っていて、やはりURLと書かれるといじりたくなるんですよね（笑）

WordPressアドレスとサイトアドレスが違うこともある

これはケースバイケースなのですが、自分でもやっている設定だが、
WordPressアドレスは、wordpressというフォルダ以下に配置し、サイトアドレスはwordpressというフォルダ名を出さない場合がある。

要するにWordpressアドレスとサイトアドレスは一致させるとかで覚えちゃうのもあれなわけです。ここらへん難しいですよね。

メリットは、サイトアドレス直下にフォルダを置いたりファイルを置いてもwordpressとは別として管理しやすい点がある。

また、サイトアドレスがドメインのみなのでわかりやすい。

もちろんこれは好みだが、http://sample.comがいいか、http://sample.com/wordpress　がいいかというと、前者がいいと思うのだが、そのようにWordpressアドレスは表示でなく管理先であり、サイトアドレスとは別も可能ということ。

デメリットは、ずばり、このWordpressアドレスとサイトアドレスを理解していないと、例えば同じようなURLを入れておけばいいと覚えてしまったなどは悲劇が発生する。

例えば、Wordpressをあまり触っておらず久しぶりにみたら、URLが違うから治そうとする。その時に、Wordpressアドレスを修正してしまうと、当然ながらログインアドレスが変わるためアクセスできなくなる恐れがある。
つまり、Wordpressが管理できなくなる可能性がある。これはそうなるということでなく、理解していないとなるので、きちんと理解すれば大丈夫だ。

ローカル環境で検証してみる

こういうのは自分で動かして遊んでみるのが手っ取り早いので動かしてみました。

WordPressアドレスを間違えた場合：スラッシュを間違えて付与

結論からいえばこれらはDB値は違う違和感があるが動作に問題はなかった。が、このようにやることはまずないだろう。

修正前：http://local.bird.com
修正後：http://local.bird.com/

このように「スラッシュ」がないのはおかしいよね？と勘違いして、スラッシュをつけてしまったケースを見てみる。

実際につけてみると、何が起きるか？

修正後に、「変更を保存」してみる。

すると、「スラッシュ」が除去され、修正前のスラッシュなしに戻った。
つまり、この動きにおいては、最後のスラッシュは自動除去される動きとなっている。

しかし、DBを確認すると、wp_optionsテーブルのoption_name「siteurl」が
http://local.bird.com/ とスラッシュ付きになってしまっている。

これは動作に問題はないのだろうか？
サイト表示や管理画面へのアクセスは問題なさそうである。
つまり、スラッシュをつけてしまった程度で動かないとかはなさそうだ。

では、
http://local.bird.com//
のように、２連続スラッシュであればどうなるか？
こちらも一般設定画面はスラッシュがクリアされるが、DBでは、スラッシュ２個がついた状態となる。ここで明確なのは、一般設定画面とDB状態が一緒とは限らないということがいえる。

この場合はどうなのだろうか？
この場合も問題がなく動いた。

WordPressアドレスを間違えて存在しないファルダ名を指定した場合

これは明らかにエラーとなるが、動きを以下で検証する。

では、スラッシュのような間違いでなく、間違えてフォルダ名を指定する場合はどうだろうか。
例えば、wordpressというフォルダが存在しないにも関わらず、wordpressと打ってしまう場合だ。

修正前：http://local.bird.com
修正後：http://local.bird.com/wordpress

さすがにこれは動かないと思うが、やはりエラーが出てしまった。
動きとしては管理画面の情報を変更し、再度表示する際に以下のようなエラーとなった。

実際のサイトアドレスは修正していないが、http://local.bird.com　を見てみよう

cssが効いてない、つまり素の状態となって見える。これはWordpressが作動してないといっていい。
ここで明確なのは、Wordpressがないフォルダを指定すれば当然ないので、Wordpressは動かないので、サイトアドレス側の表示も正しくないとなる。

WordPressアドレスをいじったのだから、サイトアドレスは正しくは見えないが表示は見えるというのは一つポイントかもしれない。ただ、ぱっとみて壊れているので「おかしくなった」と感じるはずだ。しかし、修正を何をしたかは覚えていなければ焦ってしまう感じはする。

この状態の時、まずは管理画面に入ろうとする。
修正後：http://local.bird.com/wordpress　には存在しないのでそちらにアクセスをしても意味がない。
そもそもどこにWordpressがあるか分からないならその場所を確認すべきとなる。
今回は当然、修正後：http://local.bird.com　にあるので、で管理画面に入ってみよう。

すると、かなりcssが崩れているが、かろうじて出てきている。
ここでログインはできるのだろうか？

残念ながら、ログインができない。
この時のURLが、
http://local.bird.com/wp-login.php
でログインボタンを押すと、
http://local.bird.com/wordpress/wp-login.php
に動くことに注目したい。
つまり、ログイン時にWordpressアドレスがある場所にアクセスしても、レスポンスが返ってくるときに、
http://local.bird.com/wordpress/wp-login.php
と、存在しないURLになってしまうのだ。

もう少し我慢をして調べてみよう。

先程の崩れたログイン画面にヒントが存在する。

この画面では、「パスワードをお忘れですか？」というリンクがある。
これをクリックするのでなく、マウスポインタをあててリンク先を見てみよう。

すると、http://local.bird.com/wordpress/wp-login.php　と表示されている。
何を言いたいかというと、このログイン画面の状態で上のリンクを確認すれば、そもそもWordpress側がどこを管理画面と認識していることが分かる。

再度確認すると、URLアドレスバーと想定する移動先が違うということだ。
つまり、

このように、アドレスバーが
http://local.bard.com/wp-login.php　
となっているが、
ログインボタンでアクセスしているのは、
http://local.bird.com/wordpress/wp-login.php
なので、結果的にアクセスできないとなったわけだ。

さて、この場合どうすればいいのだろうか？
管理画面に入れないので、この場合はDBを修正する、wp-config.phpで定義を追加する、他の方法を考えるが考えられる。
ちなみに、このエラーが出る状態のDB状態としては、

のようになっている。この動きは正しいと言えるだろう。

WordPressアドレスを正しく入れなければエラーが出るというところで、以下はこのエラーに対して修正方法を検証する。

WordPressアドレスを修正する方法

いくつか方法があるが、検証したのは以下となる。

１．DBを直接修正する

２．wp-config.phpにsiteurl等定義で修正

３．wp-config.phpにRELOCATEで修正

４．functions.phpにupdate_option命令で修正

他にもwp-cliなどが面白そうだが、これはWindowsでXampp環境ではインストールが難しく一旦保留。機会があれば試してみたい。

結論的に上の４つでおすすめはどれかというのはあまり変わらないという印象だが、一番手っ取り早いのは１のDB修正であり、２，３，４は結局一時的で変更した命令は削除すべきで、また管理画面に入ってもDB修正はするor確認する必要はあると思うので、素直にDB修正がベターと思われる。

ただ、何かしらの事情でDBを触りたくない運用的な意味なら他の手法がありだが、これらも一時的であるので結局二度手間となる可能性が高い。

１．DBを直接修正する

phpMyAdmin等のデータベースツールでログインする。

複数Wordpressを同一データベースに入れている場合は接頭辞を間違えないようにしたい。ここを間違えると悲劇なので、接頭辞はwp-config.phpで確認しておこう。

この場合は、wp_optionsのsiteurlという（homeではない）が存在しないアドレスとなっているのでそこを修正する。
ここを、
http://local.bird.com
に修正した。

では再度管理画面にアクセスしてみよう。

見慣れた画面が出てきた。
つまり、このログイン画面を見ても分かるのが、
cssが効いていてデザインされた画面であればWordpressが動いているといえる。
また、「パスワードをお忘れですか？」のリンクも確認しておくと、
http://local.bird.com/wp-login.php　という位置を指している。
これでログインをすると無事管理画面にログインができた。
サイト自体の表示もおかしかったが、

無事元通りのサイトが見えている。

phpMyAdmin等のデータベースツールを触りたくない、またはそもそもログインが分からない、データベースのどこにいけばいいか分からないとなるとこの方法は厳しい。

２．wp-config.phpにsiteurl等定義で修正

次の方法は、wp-config.phpを修正する方法となる。
こちらもwp-config.phpの記述箇所を間違えると動きがおかしくなる可能性もあるため、DBにアクセスするわけではないが、オペレーションが軽いわりにリスクもあるかもしれない。
とはいえ、適切な位置におけばいいので、やってみるのもいいだろう。

wp-config.phpを修正する。
wp-config.php自体はWordpressをインストールしたフォルダに存在する。
http://local.bird.com　にインストールしたのであれば、http://local.bird.com　にあるはずだ。
プロバイダによっては書き込み禁止権限になっているので書き込みONにする必要がある。

追加するのは以下の二行となる。

 define('WP_HOME','http://local.bird.com');
 define('WP_SITEURL','http://local.bird.com');

defineは定義命令で、WP_HOMEに対して、後ろの文字列を意味するという命令となる。
この場合は厳密にはWP_SITEURLだけでいいのだが、管理上両方設定するほうが都合が良いと思われる。

この挿入箇所に留意したい。
/* 編集が必要なのはここまでです ! WordPress でのパブリッシングをお楽しみください。 */
とそもそもコメントがあるが、その上に配置することだ。
よくある間違いとして、上の画面では99行目の最下部以下に突っ込むことだ。

ちなみに、間違えた場合はどうなるかも試しみよう。

ログイン画面にアクセスする。
http://local.bird.com/wp-login.php

アクセス先も問題なさそうだ（パスワードをお忘れですかのリンク先も正しいようにみえる）。

ログインをしてみる。
しかし、管理画面に遷移せず、リロードしてログイン画面に戻るという状態になる。

これはつまり、先程の修正が有効ではないということがいえる。
もし、wp-config.phpで上のような定義をして動かない場合は、挿入箇所が間違ってないかを確認するのが有効といえる。

では、正しい位置に戻してみよう。

戻しておいた。
これでログインしてみる。
無事ログインでき、サイト表示も正しく見える。

さて、このwp-config.phpは実はdefineで上のようにすると最適でないという話がある。

wp-config.php の編集 #wp-config.php の編集
wp-config.php ファイル内で、サイト URL を手動設定できます。

以下の2行の “example.com” をサイトの正しいアドレスに置き換え、wp-config.php ファイルに追加してください。

define( ‘WP_HOME’, ‘http://example.com’ );
define( ‘WP_SITEURL’, ‘http://example.com’ );
これは最適な方法とは言えないかもしれません。サイトの値を決め打ちしているだけです。この方法を使うと、サイトの一般設定ページで値を変更することはできなくなります。

https://ja.wordpress.org/support/article/changing-the-site-url/

この修正は何が問題かというと、今の状態を見ればわかりやすいだろう。
まず、管理画面の一般設定は、グレイアウトし、説明通り変更ができない。

管理者がこの状態を知っていれば何もおかしなことはないが、仮に変更したいという場合などはできなくなる。

さらに、DBもみてみよう。

このように、siteurl自体は変わっていない。今回はhomeもdefineしているが、どちらもDB値の変更はされないという動きになる。
つまり、wp-config.phpでdefineしてWP_HOMEとWP_SITEURLを定義するのは一時的にはもちろん良いが、それをして終わりでなくあくまで一時的な対応という印象を受ける。

このDB値が変化なしというのは、逆にいえば
上のsiteurlをphpmyadminで直しても変化がない＝wp-config.phpの値が優先されるためだが、これはwp-config.phpの動きを知らないと不一致なので頭が混乱してくる。

例えば、DB値を変えればいけると思い込んでいる場合にこのwp-config.phpが修正されていれば、一生治らないとなる。だからこそ、一般設定でグレイアウトしているのだろう。ここがグレイアウトされていたら、どこかでいじられている、ここではwp-config.phpだが、そこを疑ったほうが良いとなる。

つまり、wp-config.phpでは入れたら、ここでは正しいWordperssアドレスである
http://local.bird.com
に、上のDBでsiteurlを修正すべきとなる。
そして、DBを修正したら、wp-config.phpの追加部分を削除し、動くかを確認すべきとなる。
この方法は一時的には良いが、結局DB値を変えることをするのであれば素直にDBを直したほうがいいだろう。

DB値を修正し、wp-config.phpの先程追加した２行を除去した。

これで再ログインをしてみる。
無事ログインできた。

一般設定画面は、グレイアウトが消え、編集可能となっていることを確認しよう。

３．wp-config.phpにRELOCATEで修正

wp-config.phpでリロケート命令を書くやり方です。
リロケートとは、再配置みたいな意味かと思われます。

動きとしては、ログイン画面にアクセスしたパスを参照してくれる動きです。ただ管理画面へのアクセスまでであって、他の値が変わるわけではないので、他は手動で治す必要があるようです。

とりあえず、これも動きを見てみましょう。

エラーが起きたとして、wp-config.phpを以下のようにRELOCATEメソッドを入れてみます。

 define( 'RELOCATE', true);

ではログイン画面に行ってみましょう。

この時点で正しいアドレスにアクセスしそうな気がします。
ログインを押すと・・・
管理画面に無事入れました。この時アドレスが正しいアドレスになっているかは要確認というところです。
一般設定画面も問題なさそうです。サイト表示も問題ありませんでした。

DB値も確認すると、更新されて正しいアドレスになっていました。

こちらも正しい状態を確認できれば、RELOCATE命令は削除することをお忘れなく。
RELOCATE命令の動きから、home=サイトアドレス側は変わらないので、そちらも変わっていた場合は手動で修正という気がします。

少し試してみましょう。

今回はサイトアドレスも変えてみます。
これでエラーとなるはずです。

想定どおりエラーとなりました。

ちなみにこの状態で、サイト表示で、
http://local.bird.com/
へアクセスすると、
http://local.bird.com/wordpress/
へリダイレクトされて、

と、正しくない状態で表示されます。
おそらく、サイトアドレスが
http://local.bird.com/wordpress/
なのでリダイレクトするということなのでしょう。

DB値はこのように更新されていました。当然の動きですが、念の為。

では、RELOCATEしてみましょう。
先程のようにwp-config.phpにRELOCATEを追加します。

ログイン画面にアクセスします。
ここで正しいログイン画面パスはなにかが分からなくなってきそうですが、
そもそも
http://local.bird.com/wordpress
はないので、設定しようがないものはないので、
http://local.bird.com
が正しいものとなります。
よって、ログイン画面とはここでは、
http://local.bird.com/wp-login.php
となります。
アクセスすると、この時点で、wp-config.phpのRELOCATE命令が動いているようで、
DB値もログイン画面にアクセスした時点で変わっていました。

この動きは文字通り、Wordpressがインストールされているドメインにsiteurlを置き換えくれるというものです。
home値が変わってないのも想定通りです。
ログインしたのでなく、ログイン画面にアクセスした時点で変わるという点は留意が必要かもしれません。
ログインします。

この時、URLが正しいアドレスになっているかということを確認すべきとなります。
http://local.bird.com/wp-admin/
となっているため、正しそうです。
一般設定画面を見ましょう。

このように、Wordpressアドレスは変わっているのでログインできましたが、
サイトアドレスが変わっていません。
この時点で、サイト表示をすれば、
http://local.bird.com/wordpress/
で正しく見えますが、ここでは、
http://local.bird.com
にしたいので、サイトアドレスを変えておくことを忘れないようにしましょう。
とはいえ、この時点でWordpressアドレスが変わっているので、ログインは問題なく出来るようになるということです。
サイトアドレスを直して保存します。

RELOCATE文を消すのをお忘れなく。
消して再ログインします。

管理画面にログインし、一般設定も問題なさそうです。
サイト表示を確認すると、おっと、
http://local.bird.com
にアクセスしても、
http://local.bird.com/wordpress/
へリダイレクトされます。
リダイレクト系プラグインも入れてないので上でいえば、サイトアドレス変更で何か生じたかもしれません。

DB値は問題なさそうです。

キャッシュクリアで問題なく表示できました。こういうのは焦りますね。

４．functions.phpにupdate_option命令で修正

この方法はfunctions.phpに命令を書くというやり方。

functions.phpを編集する。ただしこのfunctions.phpが現在有効となっているテーマである必要があるので、テーマを複数入れていてどれを使っていたか忘れてしまった場合は厳しくなる。とはいえ、自分が使っていたテーマを忘れる可能性は著しく低い（５テーマあれば５個変えるのかというとそれは判断次第）ので、そこは分かっているものとする。

 update_option( 'siteurl', 'http://example.com' );
 update_option( 'home', 'http://example.com' );

今回も検証してみよう。
現在、エラーが起きていて入れない状態とする。

今回はsiteurlが間違えたのが明確なのでWordpressアドレスに該当するsiteurlを修正する命令のみとする。

define('WP_SITEURL','http://local.bird.com');

実際に追加してみる。

が現状のfunctions.phpなので、
<?php のすぐ下に挿入する。

このように書いてみた。

これでログインを試みる。
http://local.bird.com/wp-login.php
でログインをする前に、DBを確認すると、この時点で、DB値が変更されたのが確認できた。

つまり、functions.phpはログイン画面へのアクセスで有効となっているといえる。もちろんここでDB値を確認できないのであれば、そのままログインすればいいだろう。
無事ログインができた。

一般設定を確認すると、

このようにsiteurlが修正されており、上でも確認済みだが、DBは、

となっており、変更されているのが分かる。

留意点としては、この記述は強力なため、wp-config.phpでのdefineと同様、正しくログインできて確認できたら、すぐ消すことだ。

この記述を消さないと常にfunctions.phpに書かれた命令で更新されてしまうことになる。
こちらも、一時的な対応であり、動作確認後消すということが必要だ。

wp-config.phpのdefineよりも、functions.phpのほうが慣れている人が多いかもしれない。
ちなみに記述自体を間違えるケースもありえるのではないか？

実際に記述を間違えた場合はどうなるか検証してみよう。

 //bad sentence
 update_option( 'site_url', 'http://local.bird.com' );

これでどうなるか早速修正して保存してみよう。
これでログイン画面に行くと、
http://local.bird.com/wp-login.php
この時点でCSSが崩れているのでおそらく駄目そうだといえる。

ログインしてもエラーとなり管理画面にアクセスできない。
当然ながら、上の命令文が正しくない（site_urlは存在しない）ためだろう。
DBはどうなっているかというと、当然更新されてない。

このfunctions.phpを間違えるというケースはよくある話であり、相当慎重にやる必要がある。
wp-config.phpでdefineの位置を間違えたというケースはログイン画面が繰り返し表示されるということだったが、やはり正しい命令を正しい位置に書かないと対応できないとなる。

では、さらにいじわるだがありえるケースとして修正を以下のようにして、セミコロン（命令を区切る意味）を忘れた場合どうなるだろうか。phpに慣れていればあまりないが、慣れていなければ非常にありえるだろう。

 // careless miss , miss the semicolon
 update_option( 'siteurl', 'http://local.bird.com' )

これでfunctions.phpを保存して、再度ログインしてみよう。
どうなるだろうか？

CSSが崩れている。
このままログインをすると・・・

PHPエラーが発生となってしまった。
ちなみに上のURLは、存在しないつまり間違ったままのWordpressアドレスである、
http://local.bird.com/wordpress/wp-login.php
となっている。

このエラーは、すでに記述があるadd_actionの前のupdate_optionがセミコロンがないため、つながってしまい、正しく命令が実行できないということで起きていると思われる。セミコロンがないだけなのだが、全く動きがわからないと焦るエラーでもある。

define( 'WP_DEBUG', false );

さて、セミコロンがないので、それをつけて再度ログインしてみます。
無事、ログイン画面が表示され、管理画面にアクセスできました。
DB値も元に戻っています。
functions.phpの記述した部分は削除しておきましょう。

以上がfunctions.phpにupdate_option命令での修正方法でした。

動きを理解する

どの方法が最適かというのはケースバイケースですが、基本的にDBがいじれるほうがいいと。とはいえ、いじったところで何が影響するかを把握しつつ動かせるとより理解が深まるという感じですね。

他に関連しそうなのは、

.htaccessとかの変更で動かないとかですが、こちらはアクセス制御という印象なので関連はありますが（例えばリダイレクトするなど）今回は別ということで切り分けつつ。とはいえ、動かないとか期待どおりでないなら調べるべきというところですね。どちらかといえばキャッシュクリアとかのほうがでかい気がしますね。