WordPressのログインを繰り返すときはCookieとURLを先に確認する

WordPressへ利用者名とパスワードを入れた後、エラーがないままログイン画面へ戻るなら、パスワードを何度も変更する前にCookieとURLを確認します。WordPressは、利用者名とパスワードの照合後に認証Cookieを発行し、移動先の管理画面でそのCookieを検証します。

ブラウザーがCookieを保存しない場合や、ログイン前後でwwwの有無、HTTPとHTTPS、設置ディレクトリが変わる場合は、照合に必要なCookieが移動先へ送られません。まず一つの正規URLを決め、同じブラウザーでCookieを作り直します。

パスワードエラーとログインループを分ける

症状が違えば、最初に調べる場所も違います。

明確なパスワードエラーが出る場合は、標準の再設定手順を使います。正しい情報を受け付けた後に画面が戻る症状は、ログイン状態を次の要求へ渡せているかを調べます。

TEST_COOKIEでブラウザーがCookieを返すか確認する

WordPressのログイン処理は、ログイン画面を開いたときにTEST_COOKIEを設定します。フォーム送信時にこのCookieが戻らなければ、Cookieがブロックされているか、ブラウザーが対応していないというエラーを表示します。

最初のテストは、一つのブラウザーと一つのURLに絞ります。

1. ログイン画面のURLを、方式、ホスト名、設置先まで記録する。
2. そのホストに属するWordPressのCookieを削除する。
3. ブラウザーでCookieを許可し、同じURLからログイン画面を開き直す。
4. 利用者名とパスワードを一度だけ入力する。
5. 送信後のアドレス欄を見て、方式、ホスト名、パスが変わった箇所を記録する。

すべての閲覧履歴や保存パスワードを消す必要はありません。対象ホストのCookieから試します。別のブラウザーで成功するなら、WordPressの利用者情報より、失敗するブラウザーのCookieまたはキャッシュを先に調べます。

認証Cookieはホストとパスが合う要求だけに送られる

ログインに成功すると、WordPressは認証用CookieとLOGGED_IN_COOKIEを作ります。認証Cookieの公式ソースでは、管理画面用のCookieをADMIN_COOKIE_PATHへ、ログイン状態用のCookieをCOOKIEPATHとSITECOOKIEPATHへ設定しています。

Cookie定数の公式ソースでは、COOKIEPATHをサイトアドレスから、SITECOOKIEPATHとADMIN_COOKIE_PATHをWordPressアドレスから組み立てます。したがって、ブラウザーで開くURLと、WordPressがCookieへ指定するホストやパスが合っている必要があります。

次の三点を、ログイン画面、送信先、移動先で比べます。

ログイン画面だけを正しいURLへ直しても、フォームの送信先や管理画面の移動先が別なら解決しません。ブラウザーのアドレス欄を、送信前と送信後の両方で確認します。

WordPressアドレスとサイトアドレスを記録して比べる

WordPressアドレスは本体の設置先、サイトアドレスは公開側の入口です。同じ値になる構成も、異なる値になる構成もあります。異なること自体を誤りとは決めません。WordPress本体の設置場所と、利用者が開くURLに合っているかを確認します。

WordPressのログイン障害に関する公式文書も、siteurlとhome、wwwの有無、外部から開けるURL、転送設定を確認項目に挙げています。

管理画面へ入れない状態でデータベースを変更する前に、現在値を控えます。wp-config.phpにWP_SITEURLやWP_HOMEが定義されていれば、管理画面やデータベースだけを変えても表示URLは変わりません。作業担当者へ、現在値、正しい公開URL、本体の設置ディレクトリ、転送規則を一組で渡します。

HTTPSの切り替えはCookie確認と分ける

WordPressは、SSL接続かどうかに応じて認証Cookieの種類とsecure属性を選びます。ログイン前後でHTTPとHTTPSを往復する場合、まずサーバーとWordPressが同じ方式を正としているかを確認します。

この段階でFORCE_SSL_ADMINを追加したり外したりして試行を重ねません。HTTPSのログイン画面が証明書エラーなく開くか、転送先が同じホストと設置先か、WordPressがSSL接続を認識しているかを記録し、管理画面SSLの設定として別に直します。

URLとCookieが合ってからプラグインを切り分ける

Cookieを作り直し、ログイン前後のURLも一致しているのに戻される場合は、ログインや転送を変更するプラグインとテーマを調べます。公式文書も、プラグインの停止とテーマの切り替えを候補に挙げています。

本番サイトでいきなりファイルを削除しません。バックアップと復旧手順を用意し、可能なら複製環境で、プラグインを一つずつ止めます。管理画面へ入れず、ディレクトリ名の変更で全プラグインを認識させない方法を使う場合は、元の名前、実行時刻、停止した機能、戻し方を記録します。全停止は問い合わせ、販売、会員機能にも影響するため、確認時間を決めます。

「headers already sent」という警告がある場合も、Cookie設定より前に出力が始まった可能性を先に調べます。警告文、ファイル名、行番号を保存し、デバッグログで原因を追います。警告を非表示にするだけでは、認証Cookieが送られる状態へ戻ったか確認できません。

最終的に残す記録は、正規のログインURL、WordPressアドレス、サイトアドレス、wwwとHTTPSの転送規則、Cookieを試したブラウザー、停止したプラグインです。制作会社へ復旧を頼んでも、管理者の利用者名、正規URL、バックアップ、サーバー契約は事業者側で管理します。