はじめに
WordPressで会員向けページを作成するときに便利なプラグイン「WP-Members」。
今回、公開前のテスト環境でWP-Membersの動作確認をしていたところ、「ログイン自体はできているのに、保護ページを開くと再びログインフォームが表示される」
という、少し分かりにくい症状が発生しました。
最初はWP-Membersの設定やユーザー権限、ほかのプラグインとの干渉などを疑っていましたが、最終的に原因を切り分けるきっかけになったのが、ConoHa WINGのコンテンツキャッシュでした。
今回の検証では、ConoHa WINGの管理画面からコンテンツキャッシュの削除やON・OFFを簡単に切り替えることができたため、状態を比較しながら原因を確認することができました。
結果として、WordPressへのログイン処理そのものは正常で、未ログイン時に表示された保護ページのキャッシュが影響していたと考えられる状態でした。
この記事では、実際に発生した症状と、原因をどのように切り分けていったのかを紹介します。
※この記事は、筆者が公開前のテスト環境で実際に確認した事例をもとにしています。WordPress、WP-Members、サーバー、テーマ、その他のプラグインの設定によって原因や対処方法が異なる場合があります。
WordPressには正常にログインできていた
ログイン後にWordPressの管理画面を確認すると、正常にログインできていました。
また、WP-Membersで制限していない一般公開ページでは、「こんにちは、sample-userさん」のように、ログイン中のユーザー名も正常に表示されました。
つまり、WordPressへのログイン処理そのものは成功していたということです。
今回の原因を切り分けるうえで、ここが非常に重要なポイントになりました。
※今回は公開前のテスト環境で検証を行っているため、WordPressの管理画面URLについても初期状態の構成で確認しています。本番公開時のセキュリティ設定については、サイトの構成や運用方法に応じて別途対応します。
なお、WordPressのセキュリティ対策は、管理画面URLだけで判断できるものではありません。
ログイン試行への対策、強固なパスワード、適切なユーザー権限、WordPressやプラグインの更新など、複数の対策を組み合わせることが重要です。
最初にWP-Membersの設定を確認
保護ページだけが正常に表示されなかったため、まずはWP-Members側の設定を確認しました。
保護対象ページの設定
ログインユーザーだけに表示したい固定ページが、正しく制限対象になっているかを確認しました。
今回のテスト環境では、対象ページについては意図した設定になっていました。
カスタム投稿タイプの設定
固定ページだけでなく、一部のカスタム投稿タイプもログインユーザーだけが閲覧できるようにしていました。
そのため、
- カスタム投稿タイプが制限対象になっているか
- ログインフォームが表示される設定になっているか
- 一覧ページと個別ページで意図した動作になっているか
なども確認しました。
こちらにも、今回の症状につながる設定ミスは見つかりませんでした。
一般公開ページまで制限されていないか
サイト全体が意図せずログイン必須になっていないかも確認しました。
一般公開ページはログインせずに正常に閲覧できていたため、サイト全体の制限設定が原因ではないと判断しました。
Password Protectedとの干渉も確認
今回のサイトは公開前のテスト環境だったため、外部から簡単に閲覧されないよう「Password Protected」も利用していました。
そこで、「Password ProtectedとWP-Membersが干渉しているのではないか」という可能性も考えました。
一度Password Protectedを停止し、WP-Membersのみを有効にした状態でも確認しましたが、症状は変わりませんでした。
最終的に今回のテスト環境では、
- Password Protected:有効
- WP-Members:有効
- ConoHa WINGのコンテンツキャッシュ:OFF
という状態で正常に動作することを確認できました。
ただし、これはあくまでも今回使用したWordPress環境で確認できた結果です。
WordPressやプラグインのバージョン、テーマ、サーバー設定などによって動作が異なる可能性があります。
そのため、同じ構成で利用する場合でも、実際の環境で十分に動作確認を行うことをおすすめします。
functions.phpやCSSも念のため確認
ログイン後の表示やリダイレクトに影響する処理がないか、テーマ側も確認しました。
主に確認したのは、
- functions.php
- ログイン状態を判定する処理
- リダイレクトに関する処理
- WP-Membersに関連して追加したコード
- 表示・非表示に関するCSS
などです。
今回確認した範囲では、原因となる記述は見つかりませんでした。
ここまで確認しても原因が見つからなかったため、「ログイン処理ではなく、表示されているページ側に原因があるのではないか」と考えました。
サーバー設定を見直したことで、
原因を特定しやすくなった
今回の検証環境ではConoHa WINGを利用していました。
ConoHa WINGでは、管理画面からコンテンツキャッシュの状態を確認し、キャッシュの削除や機能のON・OFFを切り替えることができます。
- キャッシュを削除した場合
- コンテンツキャッシュをONにした場合
- コンテンツキャッシュをOFFにした場合
と条件を変えながら確認することができました。
今回のように、ログイン状態によって表示内容が変わる機能を検証するときは、こうした設定を管理画面からすぐに変更できるのは助かります。
なお、今回の症状は「ConoHa WINGに不具合があった」という意味ではありません。
コンテンツキャッシュはWordPressのページ表示を高速化するための機能です。
今回のように、ログインしているかどうかで表示内容が変わるページでは、キャッシュとの組み合わせによって確認が必要になる場合があるという事例になります。
発生した症状
今回のテスト環境では、WP-Membersを利用して、一部のページだけをログインユーザー向けに公開する設定を行っていました。
主な構成は次のようなものです。
- 特定の固定ページを「制限付き」に設定
- 一部のカスタム投稿タイプをログインユーザー限定に設定
- それ以外の一般公開ページは制限しない
- 制限対象ページではWP-Membersのログインフォームを表示
この記事では、実際の案件やサイト構成が特定されないように、投稿タイプ名やユーザー名などは架空のものに置き換えています。
テスト用のユーザーIDとパスワードを入力してログインすると、一度ページは読み込まれます。
しかし、保護ページが表示されず、再びWP-Membersのログインフォームが表示されました。
一見すると、「WP-Membersでログインに失敗しているのでは?」と思ってしまう状態です。
ところが、実際には少し違いました。
ログインできているのに、
なぜログインフォームが表示されるのか
今回の症状を整理すると、次のような状態でした。
- WordPressにはログインできる
- 管理画面にも入れる
- 一般公開ページではログインユーザー名が表示される
- 保護ページだけWP-Membersのログインフォームが表示される
もしユーザーIDやパスワードが間違っていたり、WordPressのログイン処理そのものに失敗しているのであれば、一般公開ページでもログイン済みのユーザーとして認識されないはずです。
しかし、実際にはWordPress側でログイン済みと確認できていました。
そこで、次に疑ったのがサーバー側のキャッシュです。
原因は未ログイン時の
ページキャッシュ
ConoHa WINGの管理画面からコンテンツキャッシュを削除し、さらに機能をOFFにした状態で動作を確認しました。
すると、ログイン後の保護ページが正常に表示されるようになりました。
今回の状況から、WordPress内部ではログイン済みでも、未ログイン時に生成された保護ページのキャッシュが表示されていたと考えられます。
未ログイン状態で保護ページを開くと、WP-Membersのログインフォームが表示されます。
その状態のページがキャッシュされ、ログイン後にも同じ内容が返されると、
- ID・パスワードを入力する
- WordPressへのログインは成功する
- 保護ページへ移動する
- 未ログイン時のページが表示される
- 再びログインフォームが見える
という状態になる可能性があります。
利用者から見ると、「ログインしたのに、またログインフォームに戻された」ように見えるわけです。
※ここで紹介している原因は、今回の検証結果から判断したものです。同じ症状でも、Cookie、リダイレクト設定、セキュリティ系プラグイン、CDN、別のキャッシュ機能などが原因になっている可能性があります。
ConoHa WINGで行った確認方法
今回の環境では、ConoHa WINGの管理画面からコンテンツキャッシュの設定を確認しました。
管理画面から、サイト管理 → 高速化 → コンテンツキャッシュを確認します。
まず、保存されているキャッシュを削除して動作を確認しました。
それでも症状が続いたため、検証目的でコンテンツキャッシュを一時的にOFFにしました。
その状態でログインから保護ページへの移動を確認すると、正常に表示されるようになりました。
ConoHa WINGでは管理画面からこうした設定変更が簡単にできたため、キャッシュの有無で挙動が変化するかを比較しやすく、今回の原因を切り分ける際に役立ちました。
なお、コンテンツキャッシュを常にOFFにすることがすべてのサイトに適しているわけではありません。
サイトの構成や利用する機能によって、キャッシュの利用方法は検討する必要があります。
シークレットウィンドウで
確認するときの注意
ログイン機能の検証では、通常のブラウザとシークレットウィンドウを使い分けることがあります。
今回もシークレットウィンドウを利用して動作確認を行いました。
設定を変更したあとも以前の状態が表示される場合は、一度開いているシークレットウィンドウをすべて閉じ、新しいシークレットウィンドウで確認すると切り分けしやすくなります。
ただし、シークレットウィンドウを利用したからといって、サーバー側のキャッシュまで無効になるわけではありません。
ブラウザ側の状態と、サーバー側のキャッシュは別々に考えて確認する必要があります。
同じ症状が出た場合の切り分け方法
WP-Membersでログイン後に保護ページが表示されない場合、今回の経験では次のような順番で確認すると分かりやすいと感じました。
- ユーザーID・パスワードが正しいか
- WordPress自体にはログインできているか
- 一般公開ページでログインユーザーとして認識されているか
- WP-Membersの制限設定が正しいか
- ログイン・アクセス制限系プラグインとの干渉がないか
- テーマやfunctions.phpに影響する処理がないか
- WordPress側のキャッシュ機能を確認する
- サーバー側のコンテンツキャッシュを確認する
- CDNなどを利用している場合は、そのキャッシュも確認する
特に重要なのは、「ログインそのものに失敗しているのか」それとも、「ログインは成功しているが、表示されているページが正しく切り替わっていないのか」を分けて考えることです。
ここを切り分けるだけでも、確認する範囲をかなり絞ることができます。
コンテンツキャッシュが悪いわけではない
今回の原因を調べていく中でコンテンツキャッシュが関係していることが分かりましたが、キャッシュ機能そのものが悪いわけではありません。
コンテンツキャッシュは、一度生成されたページを再利用することでWordPress側の処理を減らし、表示速度の向上につながる便利な仕組みです。
一般的な企業サイトや店舗サイトなど、閲覧者によってページ内容が変わらないサイトでは、大きなメリットがあります。
一方で、
- 会員専用ページ
- ログインページ
- マイページ
- ユーザーごとに内容が変わるページ
- カートや決済に関係するページ
などでは、キャッシュの扱いに注意が必要になることがあります。
今回も、ConoHa WINGの高速化機能が通常どおり働いていた中で、ログイン状態によって表示が変化するページを検証したことで気づくことができた事例でした。
大切なのは、「キャッシュを使わない」ではなく、「サイトの機能に合わせて適切に設定する」ことだと思います。
本番環境でもログイン系ページの
キャッシュには注意
今回はConoHa WING上のテスト環境で確認しましたが、考え方としてはほかのレンタルサーバーやキャッシュプラグイン、CDNなどを利用する場合にも共通する部分があります。
会員機能を利用する場合は、
- ログインページ
- 会員専用ページ
- 保護対象の一覧ページ
- 保護対象の個別ページ
- ユーザーごとに表示内容が異なるページ
などがどのようにキャッシュされるのか確認しておくと安心です。
また、ログインユーザーをキャッシュ対象から除外する機能や、特定のURLだけキャッシュしない設定が用意されている場合もあります。
利用しているサーバーやキャッシュ機能の仕様を確認したうえで設定するのがおすすめです。
※サーバーやキャッシュサービスの仕様・管理画面・設定項目は変更される場合があります。実際に設定する際は、利用中のサービスの最新情報もあわせてご確認ください。
まとめ
WP-Membersで正しいユーザーID・パスワードを入力しているにもかかわらず、保護ページが表示されず、再びログインフォームが表示される場合があります。
今回のケースでは、WP-Membersのログイン処理そのものには問題がありませんでした。
WordPressでは正常にログインできていましたが、未ログイン時に表示された保護ページのコンテンツキャッシュが影響していたと考えられる状態でした。
特に、
- WordPressにはログインできる
- 一般公開ページではログインユーザーとして認識される
- 保護ページだけログインフォームが表示される
という場合は、WP-Membersの設定だけでなく、サーバー側やWordPress側のキャッシュについても確認してみるとよいでしょう。
今回利用していたConoHa WINGでは、管理画面からコンテンツキャッシュの削除やON・OFFを簡単に切り替えることができたため、原因を一つずつ切り分けながら確認することができました。
WP-Membersの設定を何度確認しても原因が分からない場合は、「ログインできていない」のではなく、「ログイン前のページがキャッシュされていないか」という視点も加えて確認してみると、解決につながるかもしれません。




