TablePress 3.4更新後にテーブルが表示されない時の原因と安全な復旧手順
TablePress 3.4に更新した後にテーブルがショートコード [table id=28 /] のまま表示されない場合、まずプラグインが停止しているか、ショートコードの処理が途中で失敗しているかを確認する。サイト内検索まで動作しなくなったケースでは、古いテーブルデータの保存形式に不整合が起きている可能性が高いが、バックアップを取ればデータを失わずに復旧できる。
TablePress 3.4への更新後にテーブルが表示されない原因
TablePress は、投稿や固定ページに書かれた [table id=28 /] というショートコードを、実際の表の HTML に置き換えて表示する仕組みになっている。プラグインが無効化されていたり、更新の途中で停止していたりすると、この置き換えが行われず、ショートコードがそのまま画面に出る。
更新直後にショートコードだけが見える症状と、プラグイン停止という原因の関係を表したものだ。停止が原因なら再有効化だけで表は戻る。
ショートコードがそのまま表示される仕組み
ショートコードは、WordPress のプラグインがページ表示のタイミングで処理する仮の置き場だ。TablePress が有効な状態なら表に変換されるが、無効になると [table id=28 /] という文字列が読者に見えてしまう。更新後にこの症状が出た場合は、更新処理が最後まで完了せずプラグインが自動で停止したケースが多い。
更新後にプラグインが自動で停止していないか確認する
WordPress の管理画面で「プラグイン」メニューを開き、TablePress の状態を確認する。「有効化」ボタンが表示されていれば、更新後に何らかの理由で停止している。まず一時的に有効化し、テストページで表が表示されるか、サイト内検索が動くかを順に確かめる。
なぜ更新後にサイト内検索が動かなくなったのか
TablePress のデータは、WordPress の投稿と同じデータベースの wp_posts テーブルに保存されている。テーブル本体は JSON という書式で格納されるため、3.4 更新後に古い形式のデータを読み込む処理が変わると、サイト全体の投稿一覧や検索クエリにエラーを引き起こすことがある。特に公開サイトの検索フォームが正常に動作しなくなる症状が報告されている。
古いテーブルデータの保存形式と不整合のリスク
長年運用してきたサイトでは、TablePress が過去に保存したテーブルデータが現在の期待する形式と異なる場合がある。3.4 ではテーブルの読み込み処理が更新されたため、旧形式のデータをそのまま読み込むと PHP の警告や致命的エラーが発生し、結果として検索機能まで落ちることがある。
検索が壊れたときはプラグイン切り分けで特定する
TablePress を無効化して検索が復活したなら、原因は TablePress 側にある可能性が高い。より正確に切り分けるには、TablePress を有効化したままテーブルを1つずつ再保存し、どのテーブルで検索が止まるかを調べる。これにより、データの破損箇所を特定できる。
バックアップを取ったうえで安全に復旧する手順
復旧作業は、必ず現状のバックアップを確認してから進める。ショートコードが表示されたままの公開ページを放置せず、次の手順で原因の切り分けと復旧を行う。
復旧の作業は5段階で進める。いきなり全テーブルを変更せず、表示と検索を細かく確認しながら原因を絞り込むのが安全だ。
復旧前に実施するバックアップの確認
UpdraftPlus のようなバックアッププラグインで、サイト全体とデータベースのバックアップが最新であることを確認する。バックアップの復元方法も1度確認しておくと、万が一テーブルデータを誤って書き換えても元に戻せる。
プラグインの再有効化と表示確認
プラグイン画面で TablePress を有効化し、問題が出ているページを1つだけ開いて表が表示されるか確認する。このときサイト全体のキャッシュが残っていると古い画面が見えるため、シークレットウィンドウや別ブラウザで確認すると正確だ。
古いテーブルを1つずつ再保存して切り分ける
TablePress の管理画面で「テーブル一覧」を開き、公開している各テーブルを編集画面で開いて「変更を保存」を押す。再保存で現在の形式にデータが整い、古い形式に起因するエラーが解消されることが多い。1つ保存するたびに検索が動くかを確認すれば、問題のあるテーブルを特定できる。
ブラウザとサイトのキャッシュを削除して再確認
再保存後も症状が続く場合は、WordPress のキャッシュ系プラグインやサーバー側のキャッシュを削除し、ブラウザのキャッシュもクリアする。キャッシュが残ったままだと、修正後の状態を確認できない。
古いテーブルデータの不整合を調べて修正する方法
古いテーブルデータの不整合が原因で検索まで壊れた場合は、テーブルを再保存するだけでなく、データの中身を直接確認する方法も有効だ。焦らず1つずつ確認すれば、過去の歴史データを失わずに済む。
どのテーブルが古い形式かを特定する方法
TablePress のテーブル一覧で、更新日時が古いテーブルや、長期間編集していないテーブルを優先して確認する。古い形式のデータは、特に大量の行を持つテーブルで問題を起こしやすい。まず行数の多いテーブルから再保存を試す。
JSONデータの破損を修復する手順
TablePress のテーブルは JSON 形式でデータベースに保存されている。破損が疑われる場合は、TablePress の「エクスポート」機能で CSV として書き出し、内容を確認してから新しいテーブルとして読み込む。これにより JSON の構造が新しく作り直され、破損が解消される。
エクスポートと再インポートでデータを整える
元テーブルをエクスポートして CSV を保存し、TablePress の「インポート」で新しいテーブルとして取り込む。取り込み後にショートコードの ID が変わらないよう、元のテーブルを削除して同じ ID に割り当てるか、元テーブルを編集して CSV を貼り直す。ID を変えたくない場合は、テーブル編集画面で内容を丸ごと貼り直すのが安全だ。
旧バージョンへ戻す一時的な対処と再更新の判断
場合によっては、TablePress 3.4 自体の不具合が原因で、データを整えても検索や表示が直らないことがある。その場合は旧バージョンへ戻して一時的に安定させ、修正版のリリースを待つのが現実的な選択になる。
旧バージョンを入手して手動で戻す手順
WordPress.org の TablePress プラグインページにある「詳細を表示」から過去のバージョンを取得する。管理画面の「プラグイン > 新規追加 > プラグインのアップロード」で旧バージョンの ZIP をアップロードすると、現在のバージョンを上書きして戻せる。アップロード前には必ずバックアップを取り直す。
ロールバック後に再度更新するタイミング
旧バージョンへ戻したら、WordPress の更新通知で TablePress 3.4 の修正版が出るまで自動更新を止めておくことも検討する。修正版が公開されたら、テスト環境か深夜の時間帯で更新し、表示と検索を再確認してから本番に適用する。
よくある質問
TablePress を再有効化したら検索が再び壊れるのでは？
まずテーブルを1つずつ再保存してから検索を確認すれば、問題のあるテーブルだけを特定できる。再保存後も検索が壊れるなら、旧バージョンへ戻すか、プラグインの修正版を待つ。バックアップがあれば元に戻せるため、慌てて全データを消す必要はない。
古いテーブルだけが表示されないのはなぜか
古いテーブルはデータの保存形式が現在の TablePress と一致していない場合がある。編集画面で開いて保存し直すと現在の形式に変換され、表示されるようになることが多い。
TablePress を無効化したままでもデータは消えないか
プラグインを無効化しても、テーブルのデータはデータベースに残る。プラグインを削除しない限り過去のデータは保持される。ただし安全のため、無効化中もバックアップを取っておく。
ショートコードが表示されたまま放置するリスクは？
訪問者に [table id=28 /] という文字列が見え続けると、サイトの信頼性が下がる。検索エンジンのクローラーも表の内容を取得できないため、早めに再有効化か代替表示へ切り替える。
キャッシュ系プラグインを使っている場合の注意点は？
修正後も古い画面が表示され続ける場合は、キャッシュ系プラグインの全キャッシュ削除とブラウザのキャッシュクリアを行う。サーバー側のキャッシュが残っていることもあるため、ホスティングの管理画面も確認する。
この記事のポイント
- 更新後にショートコードが見えるのはプラグイン停止が主な原因
- まずバックアップを確認し、それから再有効化する
- 検索が壊れた場合は古いテーブルデータの不整合を疑う
- テーブルを1つずつ再保存して問題箇所を特定する
- 直らないときは旧バージョンへ戻して修正版を待つ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
セキュリティプラグインがテーマファイルを隔離してサイトが表示されない時の復旧手順
セキュリティプラグインが BeTheme の必須ファイルを誤検知して隔離し、WordPress サイトが表示されなくなった場合、まず隔離画面から「復元」を実行し、失敗したら FTP やバックアップから theme-shortcodes.php を戻す。その後キャッシュを削除してテーマが有効であることを確認すれば、サイトは復旧する。
なぜテーマファイルの隔離でサイト全体が表示されなくなるのか
WordPress はアクセスがあるたびに、有効化しているテーマの functions.php と、そのテーマが読み込む必須ファイルを実行する。BeTheme の場合、テーマ本体が theme-shortcodes.php を include して短コードの定義などを登録している。このファイルが隔離で消えると、PHP の致命的エラーが発生してページ全体が止まる。
セキュリティプラグインの隔離機能は、怪しいと判定したファイルを元の場所から移動するか、拡張子を変えて読み込めない状態にする。マルウェア対策としては有効だが、正規のテーマファイルを誤検知すると、テーマごと起動できなくなる。同様のことはテーマだけでなく、プラグインの必須ファイルでも起こる。
その結果、画面には「このサイトで重大なエラーが発生しました」という趣旨のエラーが表示されるか、真っ白な画面になる。管理画面にも入れないケースが多いため、復旧はサーバー側からの操作が中心になる。
WordPress が BeTheme の functions から theme-shortcodes.php を読み込み、サイトが表示される
theme-shortcodes.php が見つからず PHP の致命的エラーになる。サイトは「重大なエラー」で表示不可
テーマ必須ファイルの隔離前と隔離後の状態の違いを示す。
隔離されたファイルを復元する2つの方法
隔離されたテーマファイルの復元は、セキュリティプラグインの管理画面から試す方法と、FTP やバックアップから直接戻す方法の 2 通りある。まず隔離画面から復元し、エラーになる場合は後者を使う。
ファイル復旧からサイト表示確認までの全体の流れを 4 ステップで示す。
セキュリティプラグインの隔離画面から復元する
CleanTalk のセキュリティ機能では、管理画面のセキュリティメニューから隔離タブを開くと、隔離したファイルの一覧が表示される。各ファイルには「復元」または「Restore」ボタンがあるので、該当の theme-shortcodes.php を選んで復元を実行する。
復元に失敗し「エラーが発生しました」「テクニカルサポートに連絡してください」という趣旨の表示が出る場合、プラグイン側でファイルを書き戻す権限が足りないか、隔離時のコピーが壊れている可能性がある。この状態ではプラグイン画面からの復元はあきらめ、次の方法に移るのが早い。
FTP やバックアップから対象ファイルを直接戻す
FTP クライアントでサーバーに接続し、/wp-content/themes/betheme/functions/ ディレクトリを開く。theme-shortcodes.php が存在しないか、拡張子が .quarantine や .bak のように変わっていないかを確認する。ファイルが残っているのに WordPress が読み込めない場合は、正規のバックアップから同じファイルを上書きアップロードする。
バックアップがない場合は、公式の配布元から BeTheme の同じバージョンの zip を入手し、functions フォルダだけをアップロードする。テーマ全体を上書きしても問題はないが、親テーマの functions.php に直接コードを追記していた場合は消えるため、事前にバックアップを取っておく。子テーマを使っていればカスタマイズは残る。
ファイルを復元してもサイトが表示されない時の確認手順
ファイルの復元が終わってもサイトが真っ白なまま、またはエラーが続く場合、残っているキャッシュやテーマの有効状態、ファイル権限が原因になっていることが多い。次の順で確認する。
キャッシュをすべて削除する
ブラウザのキャッシュに加えて、WordPress のキャッシュプラグイン、サーバー側のキャッシュ、CDN のキャッシュをすべてクリアする。復元したファイルが正しくても、キャッシュに残ったエラーページや読み込み失敗の状態が配信され続けると、ブラウザではサイトが壊れたままに見える。
キャッシュプラグインが管理画面から操作できない場合は、wp-content/cache/ ディレクトリの中身を FTP で削除する。サーバー側のキャッシュはコントロールパネルからクリアし、CDN を使っている場合は配信側のキャッシュ削除も必要になる。
テーマが有効なままかを確認する
WordPress はアクティブなテーマの必須ファイルが読み込めないと、テーマを無効化して標準テーマにフォールバックすることがある。管理画面の「外観」から「テーマ」を開き、BeTheme がアクティブのままか確認する。別のテーマになっていれば BeTheme を再度有効化する。
wp-content/themes/ 配下のフォルダ名がリネームされている場合も同じ事象が起こる。隔離機能がファイルを移動したのか、フォルダ名を変えたのかはサーバー側で確認する。フォルダ名が変わっていれば正しい名前に戻す。
ファイルの権限と所有者を確認する
FTP で復元したファイルのパーミッションが適切でないと、WordPress が読み込めないことがある。PHP ファイルの権限は一般的に 644、ディレクトリは 755 に設定する。レンタルサーバーの場合、ファイルの所有者が FTP ユーザーとウェブサーバープロセスで異なると読み込みに失敗するため、サーバーのコントロールパネルで所有者も確認する。
エラーログで失敗原因を特定する
それでも復旧しない場合は、サーバーのエラーログを見て PHP がどのファイルの読み込みに失敗しているかを特定する。wp-config.php にデバッグ設定を追加してエラーをログに出力させると、どの行で止まっているかが確認できる。
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);誤検知を防いで再発させないための設定
正規のテーマやプラグインが隔離される事故を防ぐには、信頼できるファイルをスキャンの除外リストに登録し、バックアップ体制を整えておく。誤検知は一度きりとは限らないため、同じファイルが再度隔離される可能性も考えておく。
誤検知したファイルをスキャン対象から除外する
CleanTalk のセキュリティ機能を使っている場合、誤検知したファイルをスキャンのホワイトリストに追加できる。管理画面のセキュリティ設定から「除外」または「無視リスト」を開き、隔離されたファイルのパスを登録する。テーマ全体を除外するとセキュリティの効果が薄れるため、対象ファイルだけを追加するのが基本だ。
テーマとプラグインは公式の配布元から入手して更新する
マーケットや公式ディレクトリ以外から入手したテーマには、改ざんされたファイルが含まれていることがある。BeTheme は公式の配布元からのダウンロードに限定し、アップデートが配信されたらすぐに適用する。正規のファイルが最新の状態なら、セキュリティスキャナーが誤検知する確率も下がる。
復旧に使えるバックアップを毎日残す
誤検知でサイトが落ちた場合、最短の復旧手段はバックアップからのファイル復元だ。レンタルサーバーの自動バックアップに加えて、WordPress のバックアッププラグインで週 1 回以上のフルバックアップを取っておく。バックアップの保存先はサーバー内だけでなく、外部ストレージにも残すとより安全だ。
よくある質問
セキュリティプラグインがテーマファイルを隔離するのはなぜ？
マルウェアスキャンがファイルのコードパターンを怪しいと判定したためだ。正規のテーマでも、短コードを定義するコードや eval に似た記述があると誤検知されやすい。BeTheme の theme-shortcodes.php は短コードを大量に登録するファイルで、この種の誤検知が起こりやすい。
隔離解除ボタンを押してもエラーになる理由は？
多くはファイルを書き戻す権限の問題だ。サーバーのディレクトリ権限が狭い、ファイル所有者が違う、隔離時の一時ファイルが壊れているなどの理由が考えられる。この場合 FTP やバックアップから手動で戻すのが確実だ。
FTP が使えないサーバーの場合は？
レンタルサーバーのコントロールパネルにファイルマネージャーがあるなら、それでファイルをアップロードできる。それも難しい場合は、サーバー会社のサポートに連絡し、隔離されたファイルの復元と権限確認を依頼する。
テーマを再インストールするとカスタマイズは消える？
親テーマのファイルを上書きするだけなら、データベースに保存されたカスタマイザー設定は残る。ただし親テーマの functions.php に直接コードを追記していた場合は消えるため、事前にバックアップを必ず取ってから行う。子テーマを使っていれば安全だ。
管理画面にも入れなくなった場合は？
FTP でテーマフォルダの名前を一時的に変えると、WordPress が自動的に標準テーマへ切り替えて管理画面に入れるようになる。その後、正しいファイルを戻してからテーマを再度有効化する。
この記事のポイント
- セキュリティプラグインの隔離でテーマの必須ファイルが消えるとサイト全体が停止する
- まず隔離画面から復元し、失敗したら FTP かバックアップで対象ファイルを戻す
- 復元後はブラウザ・プラグイン・サーバーのキャッシュをすべて削除する
- テーマが有効なままか、ファイルの権限が正しいかを確認する
- 誤検知したファイルはスキャンの除外リストに登録して再発を防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressでwp-adminとwp-login.phpがトップページにリダイレクトされる原因と対処法
WordPressでwp-adminやwp-login.phpにアクセスしてもトップページへリダイレクトされる場合、原因はセキュリティプラグインによるログインURLの変更、.htaccessのリダイレクト設定、またはCloudflareのページルールであることが多い。ホスティング管理画面にアクセスできない状態でも、まずは非表示ログインURLの候補を順に試し、解決しなければホスティング会社に所有証明を添えて連絡するのが最も確実な復旧経路だ。
なぜwp-adminとwp-login.phpがトップページへ飛ばされるのか
ログインページへのアクセスがホームページへリダイレクトされる症状には、いくつか典型的な原因がある。最も多いのがセキュリティプラグインやログインURL変更プラグインによるURLの秘匿化だ。Elementorなどのページビルダーがログインリダイレクトを引き起こすことはほとんどないため、まずはセキュリティ機能まわりを疑う。
セキュリティプラグインによるログインURLの変更
WPS Hide Login、iThemes Security、All In One WP Securityなどのプラグインは、ログインページのURLを任意の文字列に変更できる。デフォルトのwp-login.phpやwp-adminを無効化し、たとえば「/login/」や「/member/」など開発者が設定したURLだけを有効にする。この機能が有効な状態では、元のURLにアクセスするとホームページへリダイレクトされるのが一般的な挙動だ。
.htaccessに記述されたリダイレクトルール
サーバーの.htaccessファイル（Apacheの設定ファイル）に、wp-adminやwp-login.phpを対象にしたリダイレクトルールが記述されているケースもある。セキュリティ対策として意図的に追加された場合と、不正アクセスによる改ざんの両方が考えられる。改ざんの場合は他のファイルにも不正なコードが仕込まれている可能性があるため、注意が必要だ。
CloudflareのページルールやWAF設定
ドメインのネームサーバーがCloudflareに向いている場合、Cloudflare側のページルールやWAF（Webアプリケーションファイアウォール）のカスタムルールがwp-adminやwp-login.phpへのアクセスをブロックまたはリダイレクトしている可能性もある。Cloudflareの管理画面にアクセスできなければこの設定を確認できないため、原因の切り分けが難しくなる。
カスタムコードによるリダイレクト
テーマのfunctions.phpやmu-plugins（マストユースプラグイン、プラグイン画面から無効化できない自動有効プラグイン）に、ログインURLをリダイレクトするカスタムコードが書かれていることもある。制作会社やフリーランスの開発者がセキュリティ目的で追加するケースが多く、ドキュメントが残っていないと原因の特定に時間がかかる。
ホスティングにアクセスできない時にできる確認と対処
ホスティング管理画面もCloudflareも使えない状況でも、できる確認は残っている。順番に試していくことで、サーバーに触らずにログインできるケースもある。下の図は復旧までの流れをまとめたものだ。
ホスティングやCloudflareにアクセスできない状態で行う確認の流れ。非表示URL候補の試行から始め、それで解決しなければホスティング会社への直接連絡に進む。
非表示ログインURLの候補を順番に試す
ログインURL変更プラグインが使われている場合、実際のログインページはデフォルトのwp-adminやwp-login.phpではない。よく使われる候補として「/login/」「/admin/」「/dashboard/」「/member/」「/members/」「/my-account/」「/wp-login.php?redirect_to=/wp-admin/」などがある。サイトのURLの末尾にこれらを付けて、ログイン画面が表示されるかを確認する。
また、サイトのフッターやお問い合わせページにログインリンクが設置されていないかも確認する。リンク先が非表示ログインURLになっていることがある。サイト内検索で「login」「ログイン」という文字列を探すのも有効だ。
シークレットウィンドウでキャッシュとクッキーの影響を排除する
ブラウザのキャッシュやクッキーが原因でリダイレクトが発生している可能性を排除するため、シークレットウィンドウ（プライベートブラウジング）で同じURLにアクセスする。シークレットウィンドウでも同じ症状が出るなら、ブラウザ側のキャッシュではなくサーバー側の設定が原因だと判断できる。
検索エンジンのキャッシュから過去のログインページを探す
GoogleやBingのキャッシュに、過去のログインページのURLが残っていることがある。検索エンジンで「site:example.com ログイン」や「site:example.com wp-admin」のように検索すると、過去にインデックスされたログイン関連ページが見つかる場合がある。キャッシュされたURLが非表示ログインURLの手がかりになる。
ホスティング会社に直接連絡して管理アクセスを取り戻す手順
ログインURLの候補を試しても解決せず、開発者にも連絡がつかない場合、ホスティング会社に直接連絡して管理アクセスを取り戻すのが最も確実な方法だ。契約者が誰であっても、所有証明を提示すれば対応を受けられるケースが多い。
所有証明書類を準備する
ホスティング会社に連絡する前に、サイトの所有者であることを証明できる書類を準備する。具体的にはホスティングやドメインの契約時の請求書、支払い明細、クレジットカードの利用履歴、登録メールアドレスに届いた契約確認メールなどだ。ドメインのwhois情報に自分の名前が登録されていれば、それも有力な証明になる。
サポート窓口に状況を正確に伝える
ホスティング会社のサポート窓口（電話、チャット、メールフォーム）に連絡し、次の3点を簡潔に伝える。「サイトのドメイン名」「wp-adminがホームページへリダイレクトされてログインできない状況」「開発者が管理しているため管理画面のログイン情報を持っていないこと」。所有証明を求められたら、準備した書類を提示する。
アクセス回復後に依頼する作業
ホスティング会社から管理画面やFTPのアクセス権を回復したら、次の作業を依頼するか自分で行う。まず.htaccessファイルのバックアップを取り、リダイレクトルールの有無を確認する。次にwp-content/plugins/ディレクトリを一時的に別名にリネームして全プラグインを無効化し、ログインできるか試す。これが原因の切り分けとして最も確実な手順だ。
サーバーアクセスを回復した後に直すべき箇所
サーバーやFTPにアクセスできるようになったら、原因箇所を特定して修正する。下の図は.htaccessの修正前後のイメージだ。
RewriteRule ^wp-admin$ / [R=301,L]
RewriteRule ^wp-login\.php$ / [R=301,L]
# WordPress デフォルトのルールのみ残す
.htaccessのリダイレクトルールを削除することで、wp-adminとwp-login.phpへのアクセスが正常に戻るイメージ。変更前に必ずファイルのバックアップを取る。
.htaccessを確認してリダイレクト設定を削除する
FTPクライアントやファイルマネージャーでサーバーに接続し、WordPressのルートディレクトリ（通常はpublic_htmlまたはドメイン名のフォルダ）にある.htaccessファイルをダウンロードする。ファイルを開き、wp-adminやwp-login.phpを対象にしたRewriteRule（リライトルール、URL変換の設定）が記述されていないかを確認する。該当する行があれば削除して上書きアップロードする。
セキュリティプラグインを無効化して切り分ける
.htaccessに問題が見つからない場合、FTPでwp-content/plugins/ディレクトリの名前を一時的に変更する（例、plugins → plugins_bak）。これで全プラグインが無効化される。その後wp-adminにアクセスしてログイン画面が表示されるかを確認する。表示されればプラグインが原因だ。プラグインディレクトリを元の名前に戻し、セキュリティ系プラグインを1つずつ無効化しながら原因を特定する。
wp-config.phpとデータベースの設定を確認する
wp-config.phpに、ログインURLを変更する定数（WP_ADMIN_DIRやWP_HOME、WP_SITEURLなど）が追加されていないかも確認する。また、データベースのwp_optionsテーブルにあるsiteurlとhomeの値が実際のサイトURLと一致しているかを確認する。これらが不整合を起こしていると、リダイレクトループが発生することがある。
ログインページが飛ばされないための再発防止策
ログインページにアクセスできなくなる問題は、適切なアクセス管理とドキュメント化で再発を防げる。とくに外部の開発者に管理を委託している場合は、以下の対策を講じておくことが重要だ。
ログインURLの変更内容を記録して共有する
ログインURLを変更するプラグインを使う場合、変更後のURLを必ずドキュメントに記録し、サイト所有者と開発者の両方で共有しておく。パスワード管理ツールにログインURLと資格情報をまとめて保管するのが実用的だ。URL変更の設定をしたこと自体を忘れてしまうと、今回のようにログイン画面へ到達できなくなる。
ホスティングとドメイン管理へのアクセス権を確保する
サイト運営者自身がホスティング管理画面とドメイン管理画面のログイン情報を保持していない状況は、サイトの所有権を実質的に手放しているのと同じだ。開発者に管理を委託する場合でも、管理者アカウントの追加権限だけは共有してもらい、緊急時にアクセスできる状態を維持する。
定期的なバックアップと復旧手順の確認
ログインページがリダイレクトされる問題に限らず、サイトのトラブル全般に備えて定期的なバックアップを取得しておく。バックアップからの復旧手順も一度シミュレーションしておくと、緊急時に慌てずに対処できる。バックアップに含めるのはデータベースとwp-contentディレクトリの両方だ。
よくある質問
セキュリティプラグインを入れていないのにリダイレクトされるのはなぜ？
セキュリティプラグインがなくても、.htaccessのリダイレクトルール、Cloudflareのページルール、テーマのfunctions.phpに書かれたカスタムコードが原因になる。また、サイトが改ざんされている場合は、不正なコードがリダイレクトを引き起こしている可能性もある。サーバーのファイルを直接確認するのが確実な切り分け方法だ。
ホスティング会社に連絡する時に何を伝えればよい？
ドメイン名、wp-adminがホームページへリダイレクトされる状況、管理画面のログイン情報を持っていないことの3点を伝える。所有証明として請求書や支払い明細、契約確認メールを求められた場合に備えて準備しておく。whois情報に自分の名前が登録されていればそれも提示できる。
Cloudflareのページルールが原因だった場合、どうすればよい？
Cloudflareの管理画面にアクセスできるなら、ページルールとWAFのカスタムルールを確認し、wp-adminとwp-login.phpを対象にしたブロックやリダイレクト設定を無効化する。アクセスできない場合は、Cloudflareのサポートに所有証明を提示してアクセス回復を依頼する。ドメインのwhois情報が自分名義であれば回復できる可能性が高い。
ログインURLを変更した覚えがないのに変更されていた場合、ハッキングの可能性は？
可能性はある。サイトの改ざんによって.htaccessやfunctions.phpにリダイレクトコードが仕込まれたケースも報告されている。ログインできるようになったら、WordfenceやSucuriなどのセキュリティプラグインでスキャンを実行し、不審なファイルや管理者ユーザーがいないかを確認する。パスワードの全面変更も推奨される。
開発者に連絡がつかないままサイトを移管するには？
ホスティング会社からFTPと管理画面のアクセス権を取得したら、データベースのエクスポートとwp-contentディレクトリのダウンロードを行い、新しい環境へ移管する。DNS設定を変更して新しいサーバーに向ける。ドメインの管理権限が自分にあれば、移管は比較的スムーズに進む。旧環境の支払いが止まってサイトが消失する前に、早めの移管作業が重要だ。
この記事のポイント
- wp-adminとwp-login.phpがホームへリダイレクトされる主因はセキュリティプラグインのURL変更、.htaccess、Cloudflare設定
- ホスティングなしでも非表示ログインURLの候補試行やシークレットウィンドウ確認は可能
- 開発者に連絡がつかない場合はホスティング会社へ所有証明を添えて直接連絡する
- サーバーアクセス回復後は.htaccess確認とプラグイン無効化による切り分けが有効
- 再発防止にはログインURLの記録共有とホスティング管理権の自己保持が欠かせない
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress管理画面でトグル設定が勝手にオンに戻る時の原因と対処法
WordPress管理画面のトグル設定をオフにしても勝手にオンに戻る場合、原因は主にJavaScriptエラーかキャッシュの不整合にある。トラッキング不具合時の診断メール設定が保存されない症状では、画面の表示とデータベースの値がずれている可能性が高く、切り分け手順を順に試すことが最も確実な対処法だ。
トグル設定が勝手にオンへ戻るのはなぜか
WordPressの管理画面にあるトグルボタンは、押した瞬間にAJAX通信でサーバーへ設定値を送信する仕組みだ。送信された値はnonce検証を経てデータベースに保存される。ここで問題が起きると、画面上ではオフに切り替わったように見えても、データベースには保存されないままになる。
別のページへ移動して戻った時、画面はデータベースから最新の設定値を読み込む。保存が失敗していれば、以前の値がそのまま表示されるためトグルがオンへ戻ったように見える。これが今回の症状の正体だ。
特に「トラッキング不具合時の診断メール」のような通知系の設定は、プラグイン側がデフォルトでオンにする仕様になっている場合がある。保存の失敗とデフォルト値の再適用が重なると、オフにしても戻るという挙動が顕著に現れる。
原因になりやすい要素は以下のとおりだ。
- 管理画面でJavaScriptエラーが発生しAJAX送信が失敗している
- キャッシュプラグインやオブジェクトキャッシュが古い設定値を返している
- テーマや別のプラグインが設定を強制的にオンへ戻している
- セキュリティプラグインがnonce検証やAJAX通信をブロックしている
- データベースへの書き込み権限やオプション保存処理に問題がある
このデモはトグル設定の保存が正常に終わる場合と、途中で失敗して次回表示時に設定が戻ってしまう場合のフローを示している。次節からは原因を特定するための手順を具体的に進めていく。
JavaScriptエラーをブラウザで確認する手順
最初に確認するべきは管理画面でJavaScriptエラーが発生していないかだ。ブラウザの開発者ツールを使えば、AJAX通信が失敗した原因を直接確認できる。Chromeの場合はF12キー、Macの場合はCommand＋Option＋I、Windowsの場合はCtrl＋Shift＋Iで開発者ツールが開く。
開発者ツールが開いたらConsoleタブに切り替える。ここに赤いエラーメッセージが表示されていれば、それがトグル設定の保存を妨げている原因になる。特に「FAILED」「POST」「403」「500」のような表示がある場合は、AJAX通信そのものが失敗している証拠だ。
エラーが確認できた場合は、エラーメッセージの内容を控えておく。ファイル名や関数名が表示されていれば、どのプラグインやテーマがエラーの原因かを特定する手がかりになる。調査を次の段階へ進める前に、まずはエラーの有無を確認するだけで状況が大きく変わる。
このデモはJavaScriptエラーの確認から発生源の特定までを順に示している。トグル操作を再現してエラーが増える場合は、そのトグルに関連するスクリプトでエラーが起きている可能性が高い。
キャッシュを削除して保存状態を確認する方法
JavaScriptエラーが見つからない場合はキャッシュの影響を疑う。サイト全体のキャッシュを削除してからトグル設定を再度オフにし、別ページへ移動して戻るという流れで確認する。WordPressでは複数のキャッシュ層が重なっていることがあり、それぞれを順にクリアする必要がある。
キャッシュプラグインのキャッシュを削除する
キャッシュプラグインを利用している場合は、プラグインの管理画面からキャッシュを全削除する。代表的なプラグインでは「キャッシュを消去」「Purge All」のようなボタンが用意されている。削除後、トグル設定をオフにして別ページへ移動し、戻って状態を確認する。
オブジェクトキャッシュを無効化して確認する
高速化のためにRedisやMemcachedといったオブジェクトキャッシュを導入している場合は、一時的に無効化して確認する。オブジェクトキャッシュはデータベースの値をメモリ上に保持するため、更新処理が古い値を返し続けてしまうことがある。wp-config.phpに記載されているキャッシュ関連の設定を一時的に外すか、サーバー側のキャッシュサービスを停止してテストする。
ブラウザキャッシュを削除する
ブラウザ側のキャッシュが管理画面の表示に影響することは少ないが、シークレットウィンドウを使えば完全にキャッシュの影響を排除できる。シークレットウィンドウで管理画面へログインし、トグル設定をオフに変更してから別ページへ移動し、再度戻って状態を確認する。この方法で問題が再現しなければ、通常のブラウザセッションにキャッシュが残っていたことになる。
プラグイン競合を切り分ける手順
JavaScriptエラーやキャッシュの影響が見つからない場合、次に疑うのはプラグイン同士の競合だ。特にセキュリティ系プラグインや高速化系プラグインは、管理画面のAJAX通信に干渉することがある。テーマに含まれるスクリプトが原因になることも少なくない。
切り分けは次の順序で行う。まず全プラグインを一括で無効化し、標準テーマ（Twenty Twenty-FourやTwenty Twenty-Fiveなど）へ切り替える。この状態でトグル設定をオフに変更し、別ページへ移動して戻る操作を行い、設定が保持されるか確認する。
この状態で問題が再現しなければ、プラグインの1つずつを有効化して同様の操作を繰り返す。問題が再現した時点で、直前に有効化したプラグインが原因の可能性が高い。特定できたらそのプラグインの設定を見直すか、開発元へ情報を集める。
なお全プラグインの一括無効化はサイトの表示にも影響を与える。切り分け作業を行う場合は、アクセスの少ない時間帯を選ぶかステージング環境を利用する。
このデモはプラグイン競合の特定を効率的に進めるための順序を示している。問題が再現したタイミングを記録しておくと、原因プラグインの特定がスムーズになる。
データベースの設定値を直接確認して修正する方法
ここまでの切り分けで原因が特定できない場合は、データベースに保存されている設定値を直接確認する。WP-CLI（WordPress Command Line Interface。WordPressのコマンドライン操作ツール）が使える環境であれば、管理画面を経由せずにオプション値を調べられる。
WP-CLIでオプション値を検索する
トグル設定に関連するオプション名を確認するには、wp option listコマンドを使う。オプション名はプラグインごとに異なるが、diagnosticやtrackingといったキーワードを含むものが対象になる。該当するオプションの値がオン（1やyesと表示される）になっていれば、設定がデータベースに保存されていないことが確定する。
wp option list | grep -i diagnostic
wp option list | grep -i tracking見つかったオプション名を指定して値を確認するには、wp option getコマンドを使う。値がオンを示していれば、トグル設定が保存されていないことになる。値がオフを示していれば、保存自体は成功しているため別の要因が影響している。
wp option get 該当するオプション名phpMyAdminで直接確認する場合
WP-CLIが使えない環境ではphpMyAdminを使う。データベース内のwp_optionsテーブル（プレフィックスが異なる場合は該当するテーブル）から、option_name列にキーワードを含む行を検索する。option_value列の値がオンを示していれば保存が失敗している。
検索にはSQL文を使う。プレフィックスは環境によって異なるため、テーブル名を確認してから実行する。
SELECT * FROM wp_options WHERE option_name LIKE '%diagnostic%';直接データベースを変更する場合は必ずバックアップを取ってから行う。設定値がシリアル化された配列の中に含まれている場合、直接変更するとデータ構造が崩れるリスクがある。不安がある場合は手動更新を避け、プラグインの設定画面から保存し直す方が安全だ。
このデモはデータベースの設定値の状態から原因の方向性を切り分ける方法を示している。保存の成否を知ることで、その後の調査対象を絞れる。
よくある質問
トグル設定が勝手に戻るのはいつどんな状況で起きるのか
主にJavaScriptエラーが発生している場合に起きやすい。管理画面のトグルはAJAX通信で設定を保存するが、他のプラグインやテーマが読み込むスクリプトと競合して通信が失敗すると、画面表示だけが切り替わって保存が行われない。キャッシュプラグインの影響で古い設定値が表示される場合もある。
キャッシュプラグインを使っていないのに設定が戻るのはなぜか
サーバー側のオブジェクトキャッシュやホスティング会社が提供する静的キャッシュが影響している可能性がある。またテーマのfunctions.phpや別のプラグインに、設定を強制的にオンへ戻すコードが含まれている場合もある。データベースの値を直接確認すれば保存の成否がわかる。
セキュリティプラグインが原因になることはあるか
ある。セキュリティプラグインが管理画面のAJAXリクエストやnonce検証をブロックすると、設定の保存が失敗する。ファイアウォール機能が過剰に反応して管理画面の操作を妨げるケースがあるため、一時的に無効化して切り分けを行う必要がある。
設定値をデータベースから直接変更しても問題ないか
問題ない場合が多いが、バックアップを取ってから行うことが必須。WP-CLIでオプション名を確認してからupdate_optionを行う。ただしプラグインの設定構造によってはシリアル化された配列に含まれており、直接変更が難しいこともある。不安がある場合はプラグインの設定画面から保存し直す方が安全だ。
本体のアップデートで解消されることがあるか
ある。プラグイン側のバグが原因の場合は本体アップデートで修正されることが多い。プラグインとWordPress本体を最新版に更新してから再度確認する価値は十分にある。ただし更新前にバックアップを取っておくと安心だ。
この記事のポイント
- トグル設定が勝手に戻る原因の多くはJavaScriptエラーかキャッシュの不整合
- ブラウザの開発者ツールでconsoleエラーを確認するのが最初の切り分け手順
- キャッシュプラグインとオブジェクトキャッシュを順に無効化して特定する
- プラグインを全停止し1つずつ再有効化して競合元を見つける
- 最終手段としてWP-CLIやphpMyAdminからデータベースの設定値を直接確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Rank MathでWooCommerceモジュールが開けない時の原因と対処法
Rank MathのWooCommerceモジュールがグレーアウトして切り替えられない場合、原因はプラグインのデータベースマイグレーションが完了していないことにある。管理画面に表示されるデータベースバージョンが初期値の1のままなら、まずキャッシュの全削除とメモリ上限の確認を行い、その上で不要オプションを削除して再マイグレーションを発生させる。
なぜWooCommerceモジュールだけがロックされるのか
Rank Mathは各機能をモジュール単位で管理している。WooCommerceモジュールもその一つで、商品の構造化データや詳細設定をまとめて扱う。ところがこのモジュールは、プラグインのデータベーススキーマが特定のバージョン以上になった時だけ有効化できる仕組みだ。
管理画面のステータス情報で「database_version」がいつまでも初期値の1のままだと、WooCommerceモジュールを含む一部の機能が「未導入」と判断されたままになる。トグルにマウスを重ねると「Please activate WooCommerce to use this module」という趣旨のツールチップが表示されるが、WooCommerce本体が有効化されていてもこのエラーは出る。
つまり、WooCommerceの有効・無効が問題なのではなく、Rank Math側のデータベース情報が古いまま更新されていないことが本質のトラブルだ。
database_versionが1のまま進まない主な原因
Rank Mathのインストール時やセットアップウィザード実行時、プラグイン内部でデータベーステーブルの作成とデータ移行が走る。この処理が最後まで到達しないと、バージョン情報が初期値の1から更新されない。具体的な原因は大きく三つに分けられる。
キャッシュプラグインが古いオプションを保持している
WP Super Cacheに代表されるキャッシュプラグインは、ページ表示を高速化するために一時データを保持する。まれにデータベースのオプション情報まで古い状態のまま配信することがあり、これが原因でRank Mathのバージョン情報が更新されないケースがある。
PHPメモリ上限が低くマイグレーションが途中で止まる
WooCommerceサイトは通常のWordPressサイトより管理画面のメモリ消費が大きい。Elementorや高機能テーマも動いている場合、PHPのメモリ上限を超えてRank Mathのデータベース処理が途中で終了してしまうことがある。具体的にはwp-config.phpで定義されたWP_MEMORY_LIMITが40M程度だと、重い環境では不足しやすい。
rank_math_db_versionオプションが破損している
WordPressのオプションテーブル（wp_options）には、Rank Mathが利用する複数のオプションが保存されている。このうち「rank_math_db_version」という値が破損したり、不正な状態で固定されたりすると、セットアップウィザードを再実行しても値が更新されない。
モジュールロックを解除する具体的な手順
以下の手順は、データベースバージョンが初期値から更新されない場合に有効だ。順に実行することで、Rank Mathのマイグレーションが正常に走り、WooCommerceモジュールのロックが外れる。
このデモは、Rank Mathのデータベースバージョンを固定している原因を取り除き、マイグレーションを再実行させる流れを示している。
キャッシュを完全に無害化する
管理画面のプラグインページでWP Super Cacheを一時的に無効化する。次に「設定」→「WP Super Cache」からキャッシュの削除を実行し、サーバー上のwp-contentディレクトリにあるcacheディレクトリ内のファイルも手動で削除しておく。
共有サーバーで管理画面から操作できない場合は、FTPソフトでwp-content/cacheに入り、中身を空にする。キャッシュを消した後は、ブラウザのキャッシュも混ざらないようシークレットウィンドウで確認すると確実だ。
WP_MEMORY_LIMITを引き上げる
FTPまたはサーバーのファイルマネージャーでwp-config.phpを開き、WP_MEMORY_LIMITの定義を探す。設定されていなければ「/* That’s all, stop editing! */」の直前に以下の行を追加する。
define( 'WP_MEMORY_LIMIT', '128M' );すでに40Mなど低い値が指定されている場合は、128Mまたは256Mに書き換える。変更後にWordPress管理画面の「ツール」→「サイトヘルス」からPHPのメモリ上限が更新されているか確認できる。
rank_math_db_versionオプションを直接削除する
サーバーのphpMyAdminにアクセスし、該当サイトのデータベースを選択する。wp_optionsテーブルを開き、option_nameが「rank_math_db_version」の行を探して削除する。
SQLを直接実行できる環境なら、次のようにしても同じ結果になる。
DELETE FROM wp_options WHERE option_name = 'rank_math_db_version';テーブルの接頭辞がwp_以外の場合は、実際の接頭辞に置き換える。削除後、Rank Mathの管理画面を開くとマイグレーションが自動的に再実行され、正常ならデータベースバージョンが初期値より大きい値に更新される。
rank_math_modulesオプションも削除する
rank_math_db_versionを削除してもWooCommerceモジュールがロックされたままの場合、rank_math_modulesというオプションも同様に削除する。この値には有効化済みモジュールのリストが保存されており、破損しているとモジュールの出し分けが正常に機能しない。
DELETE FROM wp_options WHERE option_name IN ('rank_math_db_version', 'rank_math_modules');この二つを削除した後、Rank Mathのセットアップウィザードを「詳細モード」で最後まで実行する。WooCommerceモジュールのトグルが青くなり、切り替え可能になっていれば成功だ。
それでも直らない場合の最終確認
データベースユーザーにテーブル作成権限があるか
Rank Mathのマイグレーションは、専用のテーブル（rank_math_analytics_objectsなど）を作成してデータを保存する。データベースユーザーに「CREATE TABLE」権限がないと、処理が裏側で失敗し続ける。レンタルサーバーの管理画面からデータベースユーザーの権限を確認し、不足していれば付与する。
重いプラグインを停止してからもう一度
ElementorやSlider Revolutionなど、管理画面の動作を重くするプラグインがマイグレーションを妨げている可能性がある。Health Check & Troubleshootingプラグインのトラブルシューティングモードを使い、Rank MathとWooCommerceだけを有効化した状態で手順をもう一度試す。
Rank Mathのデータベースツールでテーブルを作り直す
Rank Mathの管理画面から「ステータスとツール」→「データベースツール」を開く。「テーブルを作り直す」や「データベースを修復」といったボタンが用意されているので、順に実行してテーブルの再作成とデータの再構築を行う。
その後、もう一度セットアップウィザードを完了させ、データベースバージョンの値が更新されるかを確認する。それでも値が1のままなら、プラグインのアップデート待ちか、サーバー環境固有の制約が残っている可能性が高い。
よくある質問
トグルをクリックしても何も反応しないのはなぜ？
WooCommerceモジュールがロックされていると、トグル自体がグレーアウトした状態になる。クリックしても切り替わらず、ツールチップだけが表示される。これは操作ミスではなく、Rank Math内部でモジュールが使えない状態として認識されているためだ。
WooCommerce本体が壊れている可能性はある？
WooCommerceがプラグインページで有効化されており、商品管理やカートなど通常機能が動いているなら本体は正常だ。今回の問題はRank Math側のデータベース情報が古いことが原因なので、WooCommerceを再インストールしても解決しない。
Rank Mathを削除して入れ直しても直らないのはなぜ？
プラグインを削除しても、wp_optionsテーブルに保存されたオプションは残る。再インストール時に古いオプションを読み込んでしまい、同じ状態が再現される。必ずデータベースからrank_math_db_versionを削除してから再インストールする必要がある。
キャッシュプラグインは原因になりうる？
WP Super Cacheなどのキャッシュプラグインはページキャッシュが主体だが、環境によってはデータベースの一時情報も保持することがある。Rank Mathのバージョン情報が更新されない状態が続くなら、キャッシュプラグインを停止して切り分けるのが有効だ。
セットアップウィザードは毎回完了しているのに直らない
ウィザード自体は設定画面を進めるだけで、データベースのマイグレーションは別プロセスで走る。マイグレーションが裏側で失敗していると、ウィザード完了後もdatabase_versionが1のままになる。オプション削除とメモリ上限の引き上げを先に行うことが重要だ。
この記事のポイント
- WooCommerceモジュールのロックはRank Mathのデータベースバージョンが原因
- database_versionが1のままならマイグレーションが未完了
- キャッシュ削除とWP_MEMORY_LIMITの引き上げを先に行う
- rank_math_db_versionとrank_math_modulesオプションを直接削除して再実行
- テーブル作成権限の確認と重いプラグインの停止も有効
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WPLP Cookie Consent脆弱性を狙った攻撃からWordPressを守る3つの対策
Cookie同意プラグイン「WPLP Cookie Consent（スラッグ gdpr-cookie-consent）」のバージョン4.4.1以前には、未認証の攻撃者に任意のファイルをアップロードされる脆弱性がある。サイトを守るには、プラグインを4.4.2以上へ更新し、アップロードディレクトリ内でのPHP実行をサーバー側で拒否し、不正な管理者アカウントが作られていないか確認することが最優先だ。
なぜWPLP Cookie Consent 4.4.1が危険なのか
この脆弱性は、プラグインのREST APIエンドポイントに認可の不備があることから発生する。攻撃者は誰でもアクセスできる2つのエンドポイントを悪用し、WordPressのオプション設定を書き換えたうえで、任意のファイルをサーバーに保存できる。特に問題なのが、保存先が通常のアップロードフォルダ（wp-content/uploads）であり、ファイル名や拡張子の検証がまったく行われていなかった点だ。
つまり攻撃者は「画像ファイルに見せかけたPHPプログラム」をサイトに置くだけで、その後の実行に成功すれば管理者権限を奪取できる。バージョン4.4.1は攻撃が確認された時点で最新版だったため、更新を怠っていたサイトだけでなく、常に最新にしていたサイトも危険にさらされた。修正版の4.4.2が公開されてからは、この経路は塞がれているが、攻撃キャンペーンがすでに自動化されて動いている以上、更新前のサイトは今も標的になる。
攻撃の流れと侵入の仕組み
実際に確認された攻撃は、わずか20秒足らずで4段階のプロセスが自動実行される。最初にユーザー一覧を取得して管理者のユーザー名を特定し、次にプラグイン固有のオプションを毒して鍵をすり替え、最後にその鍵を使ってファイルを書き込む。下の図はその一連の流れを表している。
この攻撃チェーンのうち、最初の3段階は特定のプラグインがなければ成立しない。一方で、最後のPHP実行だけはサーバー側の設定次第でどのサイトでも防げる。ここが多層防御の要になる。
まず行う3つの緊急対応
サイトがこの脆弱性の影響を受けるかどうかに関係なく、次の3つを優先して実行する。順番はプラグインの更新、サーバー設定の確認、不正アカウントの確認が推奨される。
プラグインを4.4.2以上へ更新する
WPLP Cookie Consent（gdpr-cookie-consent）を使っている場合、まず管理画面の「プラグイン」から更新が来ていないか確認する。更新が見つからない場合は、WordPress.orgのプラグインページから最新版を手動でダウンロードし、既存のプラグインを上書きする。バージョン4.4.2では、脆弱性の原因だったアップロード用エンドポイントが削除され、残ったREST APIにもHMAC-SHA256署名によるリクエスト検証が追加されている。
更新後は、キャッシュ系プラグインを使っている場合はキャッシュを削除しておく。古いRESTエンドポイントの応答がキャッシュに残っていると、攻撃者からまだ有効に見えることがあるためだ。
アップロードディレクトリ内でのPHP実行を拒否する
今回の攻撃では、脆弱なプラグインによって「wp-content/uploads」ディレクトリにPHPファイルが書き込まれた。しかし、そのディレクトリ内でのPHP実行がサーバー側で拒否されていたため、攻撃は最終段階で失敗している。この設定は多くのレンタルサーバーで最初から有効になっているが、そうでない環境もある。
Apacheサーバーの場合、wp-content/uploads ディレクトリに以下の内容の .htaccess ファイルを置くことで、PHPファイルの実行を拒否できる。
<FilesMatch "\.(php|php5|phtml)$">
Require all denied
</FilesMatch>Nginxの場合は、サーバー設定で該当ディレクトリに対するPHPの処理を除外する。レンタルサーバーを利用しているなら、管理パネルに「PHP実行の無効化」や「セキュリティ設定」が用意されているか確認する。設定を変更できない場合は、サーバー会社に問い合わせて、アップロードディレクトリ内のPHP実行がブロックされているか確認するのが確実だ。
上の対比のように、ファイルが置かれても実行できなければウェブシェルとして機能しない。プラグインの更新とあわせて、このサーバー側の防御を必ず確認する。
不正な管理者アカウントを探す
今回確認されたマルウェアは、実行に成功すると管理者アカウントを自動生成する。しかも、登録日時を既存ユーザーの日時に合わせて改ざんするため、「新しく作られたユーザー」を探すだけでは見つからない。次の3つの兆候を手がかりに、phpMyAdminやWP-CLIで WordPress の wp_users テーブルを確認する。
- ユーザー名が「サイトのドメイン名＋ランダム3文字」になっている
- 表示名が「Lucas Hayes」になっている
- メールアドレスのドメインが ifuqpatr.com になっている
心当たりのない管理者アカウントを見つけたら、そのユーザーを削除し、全ユーザーのパスワードをリセットする。また、登録日時が既存ユーザーと完全に一致するアカウントがないかもあわせて確認する。
侵害を検知する具体的な手順
すでに攻撃を受けた形跡がないかは、ログとファイルの両面から確認する。攻撃が失敗していても、ファイルの残骸や不審なアクセスが残っていることが多い。
サーバーのアクセスログを精査する
攻撃者は決まったエンドポイントに順番にアクセスする。アクセスログで次のパターンを検索し、該当するリクエストが記録されていないか確認する。
- GET /wp-json/wp/v2/users?per_page=100
- POST /wp-json/wplp-react-gdpr/v1/store-auth
- POST /wp-json/wplp-react-gdpr/v1/upload-logo
これらのリクエストがすべて記録されていれば、攻撃者がサイトに到達した証拠になる。アクセスログはサーバー会社の管理パネルや、レンタルサーバーのログ保存機能から取得できる。ログの保存期間が短いと痕跡が消えるため、普段から長めに保存する設定にしておくことが重要だ。
マルウェアスキャナーでファイルを検査する
サーバーに導入されているマルウェアスキャナーや、WordPress用のセキュリティプラグインを使って wp-content ディレクトリ全体をスキャンする。特に「*.jpg.php」のような二重拡張子のファイルや、最近改変されたPHPファイルが検出対象になる。
スキャナーは攻撃直後の未知のマルウェアを検出できないこともあるが、時間が経ってから見つかることも多い。複数のスキャナーを併用すると検出率が上がる。手動で確認する場合は、wp-content/uploads 以下のファイルで、画像に見せかけたPHPファイルが残っていないかを調べる。
テーマとプラグインの改ざんを確認する
攻撃者はすでに侵入に成功している場合、バックドアを別の場所に仕込んでいる可能性がある。アクティブなテーマの functions.php や、プラグインのディレクトリに不審なコードが追加されていないかを確認する。特に、難読化されたコードや、外部と通信する関数（file_get_contents、curl、eval など）が含まれている場合は注意が必要だ。
再発を防ぐための設定
今回の攻撃は特定のプラグインに依存しているが、同種の攻撃は他のプラグインでも発生する。サイト全体の防御力を上げるために、次の設定を検討する。
REST APIのユーザー一覧取得をブロックする
攻撃の第一段階では、WordPress標準のREST APIからユーザー一覧を取得して管理者のユーザー名を特定している。このエンドポイントを無効化するか、ログイン済みユーザーに限定すれば、攻撃の難易度を上げられる。
子テーマの functions.php に次のコードを追加すると、未認証のユーザー一覧取得を防げる。
add_filter( 'rest_endpoints', function( $endpoints ) {
if ( isset( $endpoints['/wp/v2/users'] ) ) {
unset( $endpoints['/wp/v2/users'] );
}
return $endpoints;
} );このコードはユーザー一覧のエンドポイントそのものを削除するため、ログイン中でも一覧を取得できなくなる。一部のプラグインがこの機能を使っている場合は影響を確認してから適用する。
アクセスログを長期間保存する
攻撃の痕跡は時間が経つと消える。サーバーのアクセスログを最低でも数週間、可能なら数ヶ月保存しておくと、侵害の調査や再発防止に役立つ。レンタルサーバーの標準設定では数日しか保存されないこともあるため、管理パネルやサーバー会社に確認して保存期間を延ばす。
プラグインの選定と更新ポリシーを見直す
Cookie同意プラグインに限らず、インストール数が少ないプラグインでも攻撃対象になる。更新が止まっているプラグインや、あまり知られていない開発元のプラグインを使い続ける場合は、代替手段を検討する。定期的にプラグインの更新を確認し、不要なプラグインは削除する。
よくある質問
WPLP Cookie Consentを使っていないが対策は必要か
今回の脆弱性はこのプラグイン固有のものだが、アップロードディレクトリでのPHP実行を拒否する設定や、REST APIのユーザー列挙対策はどのサイトでも有効な防御策になる。プラグインの更新とサーバー設定の見直しは、サイト全体のセキュリティを底上げする。
更新したのに攻撃された兆候が残っている場合はどうすればいいか
更新してもすでに設置されたマルウェアは消えない。不正な管理者アカウントの削除、マルウェアスキャン、テーマやプラグインの改ざん確認を行い、必要ならバックアップから復元する。確実なのは、クリーンなバックアップに置き換えて、全パスワードを再発行することだ。
アップロードディレクトリのPHP実行を拒否すると何か問題はあるか
通常のWordPressサイトでは、wp-content/uploads にPHPファイルを置く運用は推奨されていない。画像や文書の配信には影響しない。一部の特殊なプラグインやテーマがこの場所にPHPを置く場合は、事前に動作確認を行う。
REST APIを完全に無効化したほうがいいのか
完全な無効化は、ブロックエディタや一部の機能が動作しなくなるため現実的ではない。ユーザー一覧だけを狙ったエンドポイントを制限するか、認証を要求する設定が現実的な落とし所になる。
この記事のポイント
- WPLP Cookie Consent 4.4.1以前には未認証でファイルをアップロードされる脆弱性がある
- まずプラグインを4.4.2以上へ更新し、古いバージョンのままにしない
- wp-content/uploads 内のPHP実行をサーバー側で拒否する
- 不正な管理者アカウントがないか wp_users を確認する
- アクセスログとマルウェアスキャナーで侵害の痕跡を調査する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Product Feed PROでブランド・変動商品・商品カテゴリが出力されない時の直し方
Product Feed PRO for WooCommerceでブランド・変動商品・Google商品カテゴリがXMLに出力されない場合、まず確認すべきはフィールドマッピングの重複定義とキャッシュの遅延だ。症状が3つ同時に出ていても原因はそれぞれ別で、マッピング設定と条件設定を正しく組み替えれば大半は解決する。
ブランドがXMLに間欠的に出力される原因
同じブランドを割り当てた商品の一部にだけ<g:brand>が出力されない場合、最も多いのが「ブランドの取得ソースが複数存在している」ケースだ。WooCommerceの商品編集画面ではブランドが正しく見えていても、フィードプラグインは別のソースを参照して空の値を受け取ることがある。
Product Feed PROにはブランドを取得するための選択肢が複数用意されている。商品ブランド（product_brand）タクソノミー、商品属性（pa_brand）、YITH Brandプラグイン用の「Brand」、WooCommerce Brandsプラグイン用の「Product brand」などが代表だ。これらが混在していると、商品Aはタクソノミーから値を取得し、商品Bは未設定の商品属性を参照して空振りする、という動きになる。
特に複数のプラグインを併用していたり、過去にブランド管理の方法を変更したサイトで起きやすい。商品一覧のCSV書き出しでブランド列を確認すると、同じブランド名でも保存されている場所が商品によって異なるのがわかる。
商品B Dr Coffee → タクソノミーに設定済み → 属性は未設定 → 出力なし
商品B Dr Coffee → タクソノミーから取得 → 出力あり
このデモは、ブランドの取得ソースを属性にしたままタクソノミーのみ設定した商品で出力が欠落する状況を示している。対処は連載の後半でまとめて説明する。
商品ごとにブランドの保存場所を確認する
WooCommerceの商品一覧からCSVを書き出し、ブランドのタクソノミー列と属性列の両方を確認する。片方だけに値が入っている商品があれば、その商品群で出力が欠落しているはずだ。同じブランド名を保ったまま、フィードが参照するソースにデータを揃える必要がある。
フィードプラグインのフィールドマッピングを再定義する
フィードのフィールドマッピング画面で、<g:brand>フィールドの「取得ソース」を確認する。プルダウンに複数のブランド候補が並んでいたら、実際に価値が入っているタクソノミー（product_brand）を選択し直し、フィードを再生成する。
変動商品がフィードから完全に欠落する原因
変動商品（バリエーションを持つ商品）がXMLに一切出力されない場合、最初に確認するのは「デフォルトのバリエーション」の設定だ。WooCommerceの変動商品では「デフォルトのバリエーションを選択」プルダウンが「デフォルトを選択」のままになっていると、親商品がフィードの出力対象から外れることがある。
フィードプラグインの設定で「商品のバリエーションを含める」を有効にしても、親商品のバリエーション自体が正しく構築されていないと出力はできない。各バリエーションに価格・在庫状況・画像が設定されているか、親商品がカタログに表示される設定になっているかも重要なチェックポイントだ。
プルダウン「デフォルトを選択」のまま → フィード生成スキップ
バリエーション3点も非出力
プルダウンで1件選択 → フィードに親商品とバリエーションが出力
価格と在庫のある3バリエーションも表示
このデモは、デフォルトのバリエーション未選択で変動商品が出力から漏れる典型的なパターンを表している。ほかに価格未入力や在庫切れでも同様の欠落が起こる。
バリエーションの設定を一括で点検する
変動商品の編集画面で、各バリエーションに通常価格またはセール価格が登録されているか、在庫ステータスが「在庫あり」または「予約可能」になっているかを確認する。バリエーションが「非公開」や「カタログに表示しない」になっていないかも見る。
親商品の「商品データ」メタボックスでは、プルダウンで「デフォルトのバリエーション」を必ず1つ選ぶ。この操作が済んでいない変動商品は、フィードプラグイン側の設定に関係なく出力対象外になるケースが多い。
フィード設定の「商品のバリエーションを含める」を再確認する
Product Feed PROのフィード編集画面で、変動商品に関するオプションが有効か確認する。「商品のバリエーションを含める」と「親商品も含める」の両方が目に入るが、どちらか一方だけ有効になっていると期待した出力にならない。特に親商品を表示するには、その商品自体がカタログに表示される設定である必要がある。
Google商品カテゴリが出力されない原因
Google商品カテゴリ（<g:google_product_category>）がXMLに出ない場合、原因はほぼ「カテゴリマッピングの条件不一致」か「フィールドマッピングの取得ソースにgoogle_categoryが設定されていない」のどちらかだ。カテゴリマッピング画面でWooCommerceカテゴリとGoogleカテゴリを紐づけただけでは、フィードに反映されない。
カテゴリマッピングの画面では、左側にWooCommerceの商品カテゴリ、右側にGoogleの商品カテゴリを割り当てる。この割り当てが「すべてのカテゴリ」ではなく、一部のカテゴリだけに適用される条件で作られていると、対象外のカテゴリに属する商品からはカテゴリが出力されない。
→ 他のカテゴリ（ドリップ用品など）は
<g:google_product_category>が空のまま→ すべての商品に
<g:google_product_category>が出力このデモは、カテゴリマッピングの条件漏れで一部商品のGoogleカテゴリが空になる状況を示している。カテゴリマッピング画面は商品数が多いほど設定漏れが起きやすいので、全カテゴリを対象にするのが基本だ。
フィールドマッピングでgoogle_categoryが設定されているか確認する
フィードのフィールドマッピング画面で、Google側の<g:google_product_category>フィールドに対して、取得ソースが「google_category」になっていることを確認する。このソースは、カテゴリマッピング画面で定義した対照表を参照する専用の値だ。
誤って商品カテゴリそのものを割り当てていると、Googleが求める形式（例: Home & Garden > Kitchen & Dining > Coffee Makers）ではなく、WooCommerceのカテゴリ名だけが出力される。Google Merchant Center側でエラーまたは警告になるため、ソース設定は丁寧に見直す必要がある。
カテゴリマッピングを全カテゴリに適用する
カテゴリマッピング画面で、WooCommerceの各カテゴリに対応するGoogleカテゴリをすべて埋める。カテゴリが多い場合は「未マッピングのカテゴリ」フィルタを使うと、設定漏れのカテゴリだけを洗い出せる。親カテゴリを割り当てたら、子カテゴリが自動的に引き継がれるかどうかも確認する。
3つの問題をまとめて修正する手順
3つの問題が同時に起きている場合は、それぞれを個別に直すよりも、フィードの基本設定を順番に整える方が早い。次の手順でフィールドマッピング、変動商品設定、カテゴリマッピングを見直す。
このデモは、3つの症状をまとめて修正する際の優先順位を表している。ブランドの取得ソースを先に統一すると、変動商品とGoogleカテゴリの修正結果をXMLで正確に確認できる。
フィード再生成とキャッシュの扱い
設定を変更したあとは、フィードプラグインの「再生成」または「今すぐ更新」ボタンを実行する。WooCommerceやサーバー側のキャッシュが効いていると、更新前のXMLが表示され続けることがある。キャッシュプラグインを使っている場合は、フィードを再生成する前にキャッシュを削除すると確実だ。
生成されたXMLをブラウザで開き、<g:brand>、<g:google_product_category>、変動商品のIDやタイトルが表示されているかをCtrl+F（MacではCommand+F）で検索する。変動商品は親商品とバリエーションが別々の<item>要素として出力されるため、商品IDではなく商品名の一部で検索すると見つけやすい。
よくある質問
ブランドの出力が安定しないのはキャッシュが原因か？
キャッシュだけが原因になる場合は少ない。ブランドタクソノミーと商品属性の両方に同名のブランドが存在し、フィードのマッピングが不安定なソースを参照していることが多い。キャッシュを削除しても再発するなら、取得ソースの統一が先だ。
変動商品だけがXMLから消えるのはなぜか？
変動商品は親商品と各バリエーションが個別の商品として扱われるため、単純商品より出力条件が厳しい。デフォルトのバリエーション未選択、価格未入力、在庫切れ、または「商品のバリエーションを含める」設定のミスが典型的な原因になる。
Google商品カテゴリの出力形式が正しいか確認する方法は？
出力されたXML内の<g:google_product_category>の値を確認し、Google Merchant Centerが求める形式（不等号で区切られた英語の数字付きカテゴリパス）になっているかを見る。WooCommerceのカテゴリ名だけが入っている場合は、フィールドマッピングの取得ソースが誤っている。
設定を変えてもフィードが更新されない場合は？
フィードの再生成ボタンを押したあと、ブラウザでXMLを開いたときに古い内容が表示されることがある。キャッシュプラグインの削除、サーバー側のキャッシュ（OPcacheやVarnish）のクリア、またはクエリパラメータを付けて開く（例: feed.xml?nocache=1）と最新の出力を確認できる。
ブランドが空の商品はどうやって特定するか？
WooCommerceの商品一覧でフィルタ機能を使い、ブランドタクソノミーが空の商品を絞り込む。もし全商品にブランドが付いているのにXMLには一部しか出ていないなら、取得ソースの不一致を疑う。CSV書き出しでブランド列とブランド属性列を並べて比較すると特定しやすい。
この記事のポイント
- ブランドは取得ソースの統一が最優先
- 変動商品はデフォルトバリエーションの選択が必須
- Google商品カテゴリは全カテゴリのマッピングが必要
- 設定変更後はキャッシュを削除して再生成する
- XMLを検索して各フィールドの出力を検証する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
カートページで数量を変更すると違う数になる時の対処法
WooCommerceのカートページで数量を1から2に変更したのに3が表示される不具合は、テーマまたはプラグインの古いJavaScriptが原因で数量更新のイベントが二重に処理されるケースが多い。まずテーマとWordPress本体・WooCommerceを更新し、それでも直らなければプラグインの競合を切り分けるのが最短の解決手順だ。
なぜカートページの数量変更で数がずれるのか
カートページで数量を変更すると、WooCommerceはAjax通信でサーバーに更新を送り、その結果を画面に反映する。このときブラウザ側のJavaScriptが「変更前の数量」と「変更後の数量」を正しく引き算して表示する仕組みになっている。
ところがテーマやプラグインが古いjQueryや独自のAjax処理を持っていると、同じクリックや入力イベントに対して数量加算の処理が2回走ることがある。たとえば「1を2に変更」が「1を3に変更」として解釈され、画面に3が表示される。
特に数量に小数を許可するプラグイン（WooCommerce Decimal Productなど）が有効な場合、数量フィールドの値の扱いが標準と変わるため、テーマ側のJavaScriptとの相性問題が表面化しやすい。プラグインを無効化すると正常になることから、原因がプラグイン単体でなく「プラグインとテーマの組み合わせ」にあると判断できる。
テーマとWordPressを最新版に更新する手順
この不具合は、テーマ・WordPress・WooCommerceのいずれかが古いことで、最近のブラウザやプラグインとの間でJavaScriptの仕様差が生じるために起きることがある。まずは更新作業から始める。
更新後はシークレットウィンドウや別ブラウザでテストする。通常のブラウザに古いCookieやキャッシュが残っていると、修正後も古いJavaScriptが動いてしまうためだ。
JavaScriptの競合を切り分ける手順
更新しても症状が変わらない場合、特定のプラグインやテーマのJavaScriptがWooCommerceの数量更新イベントと競合している。原因を特定するには「無効化テスト」が確実だ。
プラグインを1つずつ無効化して原因を特定する
まずプラグイン一覧から、数量に関係するプラグイン（小数プラグイン・カスタム数量プラグイン・Ajaxカートプラグインなど）を候補として絞り込む。それぞれ無効化してカートページを再読み込みし、数量が正しく更新されるか確認する。
もし特定のプラグインを無効化したときだけ正常になるなら、そのプラグインが原因だ。プラグインの更新版が出ていないか確認し、出ていなければ代替プラグインへの乗り換えを検討する。
ブラウザのコンソールでJavaScriptエラーを確認する
ブラウザのデベロッパーツール（ChromeではF12キー）を開き、「Console」タブを確認する。カートページで数量を変更したときに赤いエラーが表示される場合、エラーのファイル名から競合元を特定できる。
エラーメッセージが「jQuery is not defined」や「$ is not a function」なら、テーマのJavaScriptがjQueryを正しく読み込んでいない。wp_enqueue_script の順序や依存関係の問題なので、テーマ制作者に修正を依頼するか、子テーマ側で読み込みを調整する。
「cart-fragments」や「wc-cart-fragments」に関するエラーなら、WooCommerceのAjaxカート更新機能が別のプラグインと衝突している。該当プラグインを特定して無効化すれば症状は収まる。
キャッシュとCookieの影響を排除する
修正後も古い表示が続く場合は、サーバー側のキャッシュとブラウザ側のCookieが原因で古いJavaScriptが読み込まれている可能性がある。キャッシュプラグイン（WP Super Cache、W3 Total Cache、LiteSpeed Cacheなど）のキャッシュを全削除し、ブラウザのCookieとキャッシュも消去してから再テストする。
また、CDN（Cloudflareなど）を利用している場合は、CDN側のキャッシュもクリアする。CDNが古いJavaScriptファイルを配信し続けると、サーバー上では更新済みでもブラウザには古いコードが届く。
よくある質問
数量が正しく更新されるか確認する方法は？
カートページで数量を複数回変更し、そのたびにカート内の小計と合計が正しく再計算されるかを確認する。加えて管理画面の「WooCommerce→ステータス→ログ」にJavaScript関連のエラーが記録されていないか確認するとよい。
テーマを更新しても大丈夫？
更新前にバックアップを取っていれば問題ない。カスタマイズをテーマ本体に直接書いている場合は、更新で消える可能性があるので、子テーマや独自プラグインに移してから更新するのが安全だ。
小数プラグインを使い続けながら直す方法は？
プラグイン自体に更新版がない場合は、テーマ側のJavaScriptを修正して競合を回避する必要がある。具体的にはカートページの数量更新をWooCommerce標準のAjax処理に任せるよう、テーマのcustom.jsやmain.jsから数量関連のコードを除去する。
テストサイトを作るべき？
本番サイトに影響を与えずに原因を切り分けたい場合は、ステージング環境（多くのレンタルサーバーに標準搭載）か、ローカル環境（LocalやXAMPPなど）で同じテーマとプラグインを再現するのが有効だ。テストサイトで症状が再現できれば、切り分け作業を安全に進められる。
PHPのバージョンは関係ある？
PHPのバージョンが極端に古い（7.4未満など）場合、WooCommerceの最新版が正しく動作しないことがある。サーバー管理画面でPHP 8.0以上に更新できるか確認するのも有効な切り分けのひとつだ。
この記事のポイント
- カートの数量が「1→2」で「3」になるのはJavaScriptの二重処理が主因
- テーマ・WordPress・WooCommerceの更新で解決するケースが多い
- 直らない場合はプラグインを1つずつ無効化して競合元を特定する
- ブラウザとサーバーのキャッシュ・Cookie削除を忘れない
- 小数プラグインを使うならテーマ側のJavaScript競合を重点確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WP to Hootsuite 3.xで予約投稿が失敗するCronエラーの対処法
WP to Hootsuite を 3.x 系へ更新したあと、予約投稿が Hootsuite に公開されない場合は、Cron クラスの reschedule_refresh_token_event メソッドが未定義のままになっている可能性が高い。プラグインを 3.1.4 以降へ更新すれば、この致命的エラーは解消する。
なぜWP to Hootsuite 3.xで予約投稿が失敗するのか
この不具合は、プラグインの更新時に必要なメソッド定義がファイルへ正しく反映されず、呼び出しだけが先に組み込まれた状態で発生する。3.x 系では WPZinc 製プラグイン共通の Social ライブラリへ構成が変わったため、一部のファイルに古いコードと新しいコードが混在しやすくなっている。
具体的には、includes/functions.php が Cron クラスの reschedule_refresh_token_event メソッドを呼ぶ一方、lib/social/includes/class-cron.php にそのメソッド定義がない。存在しないメソッドへの呼び出しは PHP の致命的エラーを引き起こし、その後の処理が止まる。
WPZinc\Social\Cron::reschedule_refresh_token_event()予約投稿の実行は WP-Cron（WordPress の予約実行システム）を経由する。ここで致命的エラーが起きると画面には何も表示されず、プラグイン自身のログ画面にも記録が残らない。管理画面からの手動更新はトークン再スケジュール処理を通らないため成功するので、問題の特定が遅れやすい。
上の図は、予約投稿が致命的エラーで止まるまでの流れを示している。
プラグインのログ画面が空のままなのは、致命エラーが起きた時点で PHP の処理が停止し、ログを書き込むコードまで到達しないためだ。管理画面からの手動更新ではトークン再スケジュール処理が呼ばれないため、問題なく成功する。
3.1.4以降への更新で解消する手順
この不具合はプラグイン側のコード不整合なので、特別な設定変更は不要だ。WP to Hootsuite を 3.1.4 以上へ更新すると、未定義だったメソッドが class-cron.php に追加され、予約投稿の処理が最後まで走るようになる。
更新作業の前に、必ずサイト全体のバックアップを取る。プラグイン更新そのものは数分で終わるが、万一テーマや他プラグインと競合した場合に戻せる状態にしておくことが重要だ。
上のステップは、更新から動作確認までの一連の流れを示している。
更新後はキャッシュ系プラグインの全削除も忘れずに行う。そのうえで、以前に失敗した投稿を一度下書きへ戻すか、公開予定日時を再設定して様子を見ると確実だ。
すぐに更新できない場合はどう対処するか
2.x系へ巻き戻して様子を見る
何らかの事情ですぐに 3.1.4 へ更新できない場合は、動作していた 2.x 系へ巻き戻すのが安全だ。WP Rollback などのプラグインを使うか、FTP で該当プラグインのフォルダを旧バージョンに差し替える。ただし、旧バージョンには以降のセキュリティ修正が含まれない点には注意が要る。
手動公開に切り替えて一時運用する
致命的エラーは予約投稿の実行時に発生するため、更新が終わるまで予約投稿を避け、公開したいタイミングで管理画面から手動で公開する運用も現実的な選択だ。下書きのまま用意しておき、公開直前に「公開」ボタンを押す流れにすると、サイト運営を止めずに済む。
ステージング環境で先に検証する
本番サイトへの更新が不安な場合は、ステージング環境（本番と同構成の検証用サイト）で先に 3.1.4 を適用し、予約投稿のテストを行う。これにより、他プラグインとの競合や認証トークンの再連携が必要かどうかを事前に確認できる。
デバッグログで原因を特定する手順
プラグインのログ画面に何も残らない場合、PHP のデバッグログを有効にすると致命的エラーの内容が確認できる。本番サイトでは通常エラー表示が無効化されているため、管理画面にも何も出ない。
wp-config.php に次の記述を追加すると、エラー内容が wp-content/debug.log に書き込まれる。あらかじめ FTP または管理画面のテーマファイルエディタから wp-config.php を開いておく。
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);設定後にテスト用の予約投稿を実行し、wp-content/debug.log を確認する。未定義メソッドの場合、「Call to undefined method」（未定義メソッドの呼び出し）という趣旨のエラーが残る。日本語環境でも PHP の内部エラーは英語で記録される。確認後は、WP_DEBUG を false に戻してログ出力を止める。
よくある質問
3.1.4に更新しても予約投稿が失敗する場合は？
まずバージョン表記を確認し、本当に 3.1.4 以上へ置き換わったかを確かめる。そのうえでキャッシュを全削除し、Hootsuite との認証を一度解除して再接続する。それでも改善しない場合は、他プラグインとの競合を切り分ける。
更新ボタンが出てこない場合は？
プロ版や一括購入版では、管理画面の自動更新が効かないことがある。WPZinc の配布ページから最新版をダウンロードし、FTP で該当フォルダを上書きする。上書き前には必ずバックアップを取る。
WP-Cronが正しく動いているか確認するには？
WP Crontrol などのプラグインで予約イベントの一覧を確認し、投稿公開のイベントが登録されているかをチェックする。WP-Cron 自体が停止している場合は、サーバー側の cron 設定や wp-config.php の ALTERNATE_WP_CRON 設定を見直す必要がある。
デバッグログが出力されない場合は？
wp-content フォルダの書き込み権限が不足している可能性がある。FTP で wp-content のパーミッションを確認し、debug.log が作成できる状態か確かめる。あわせて、キャッシュ系プラグインやセキュリティプラグインが wp-config.php の変更をブロックしていないかも確認する。
2.xへ戻してもいいか？
一時的な回避として 2.x 系へ戻すのは有効だが、セキュリティ更新が含まれないため恒久対応にはならない。できるだけ早期に 3.1.4 以降へ更新し、検証のうえで運用を戻すのが望ましい。
この記事のポイント
- 3.x 更新後に予約投稿が止まる原因は、呼び出しだけ存在する未定義メソッドによる致命的エラー
- プラグインのログが空でも、PHP のデバッグログを有効にすれば原因が見える
- 更新版 3.1.4 以降では Cron クラスのメソッド定義が揃い、予約投稿が正常に動く
- すぐ更新できない場合は 2.x へ巻き戻すか、手動公開で一時運用する
- 更新前のバックアップと、ステージング環境での事前検証が再発防止につながる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.1でサイトエディターが真っ白になる原因と直し方
WordPress 7.1に更新した後、サイトエディター（wp-admin/site-editor.php）だけが真っ白になる場合は、ブラウザの互換性とJavaScriptエラーを最初に確認し、それでも解決しなければサーバーエラーログとREST APIの応答を調べる。サイトエディターは投稿編集画面と比べてJavaScriptとREST APIへの依存度が高く、原因はこの2系統に集中している。
なぜサイトエディターだけが真っ白になるのか
サイトエディターは、テンプレートやテンプレートパーツ、グローバルスタイルと呼ばれるデザイン設定を、REST API経由でサーバーから取得してJavaScriptで描画する。投稿編集画面が正常でも、サイトエディターだけが真っ白になるのは、この特殊な描画経路のどこかでエラーが起きているためだ。
主な原因は次の4つに分けられる。
- 古いブラウザが最新JavaScript機能に対応していない
- JavaScriptファイルの読み込み失敗や例外が起きている
- REST APIが内部エラーを返してテンプレート情報を取得できない
- PHPのメモリ不足で致命的エラーが発生している
真っ白な画面の原因切り分けは、この4ステップの順で行うと効率的だ。
古いブラウザが原因かどうかを確認する手順
最初に確認するのはブラウザの互換性だ。サイトエディターはブロックエディターと同じく、最新のJavaScript機能をフルに使って動作する。Firefox ESRや数世代前のSafari、旧バージョンのChromeでは、これらの機能に対応できずに画面全体が真っ白になることがある。特に長期的にブラウザをアップデートしていない業務用端末や古いノートPCで起こりやすい。
確認方法はシンプルで、同じサイトを別の端末や別のブラウザで開いてみる。もし最新版のChrome、Edge、Firefoxのいずれかで正常に表示されるなら、使用中のブラウザが古いことが原因だ。その場合はブラウザのアップデートを行うか、対応ブラウザに切り替える。どうしても古いブラウザで作業しなければならない場合は、サイトエディターの使用を避け、投稿編集画面から個別のテンプレートを編集するという回避策もある。
デベロッパーツールでJavaScriptエラーを確認する
最新ブラウザでも真っ白になる場合は、デベロッパーツール（開発者ツール）を開いてJavaScriptエラーを調べる。画面が真っ白になる症状の多くは、レンダリングを途中で止めるJavaScriptの例外や、重要なファイルの読み込み失敗が直接の原因になっている。
ChromeやEdgeではF12キー、MacではCommand+Option+Iキーでデベロッパーツールが開く。Firefoxでは右クリックから「要素を調査」を選ぶとよい。開いたら「コンソール」タブに切り替え、ページを再読み込みする。コンソールに赤い文字で表示されるエラーを上から順に確認する。
TypeErrorやReferenceError、SyntaxErrorの表示があれば、それが画面描画を止めている例外だ。また「Failed to load resource」のようなエラーは、必要なJavaScriptファイルが読み込めていないことを示す。この場合は更新時にファイルが欠損した可能性が高いため、後述するWordPress本体の再インストールで解決することが多い。
サーバーエラーログとREST APIを確認する
ブラウザ側に明確なJavaScriptエラーが見つからない場合、次にサーバー側の状態を確認する。サイトエディターはREST API経由でテンプレート情報を取得するため、サーバーでエラーが発生していても画面上には何も表示されず、真っ白なままになる。
サーバーのエラーログを確認するときは、サイトエディターを開いた直後の時刻に注目する。エラーログには過去のボットスキャンや他のリクエストも大量に記録されている。AH01276のようなDirectoryIndex関連のエラーは、多くの場合ボットがディレクトリを直接スキャンした痕跡であり、エディターの真っ白とは無関係だ。ログを上から眺めるのではなく、症状が起きた時刻に新しいエントリが追加されたかどうかを確認する。
サーバーログと並行して、REST APIが正しく応答するかを直接チェックする。ブラウザのアドレスバーに自分のサイトURLに続けて wp-json/wp/v2/templates と入力して開いてみる。正常ならテンプレート一覧の入ったJSONデータが表示される。ここでエラーページやHTTP 500系のエラーが返るなら、REST API側に問題がある。
PHPメモリ上限と再インストールで直す
確認した内容に応じて対処する。PHPのメモリ不足を示すエラー（Allowed memory size of から始まるFatal error）がログに記録されている場合は、メモリ上限を引き上げる。デフォルトの128Mでは、テンプレートの多いサイトや高機能テーマでサイトエディターの読み込み中に不足することがある。wp-config.phpに次の1行を追加するか、レンタルサーバーの管理画面からメモリ上限を変更する。
define('WP_MEMORY_LIMIT', '256M');エラーログにメモリ不足が出ていない場合や、ブラウザのコンソールにファイル読み込みエラーが出ている場合は、WordPress本体の再インストールが有効だ。ダッシュボードの「更新」メニューを開き、「WordPressを再インストールする」ボタンを押す。wp-admin、wp-includes、ルートのコアファイルが最新版で上書きされ、更新時に欠損したファイルが復元される。テーマやプラグイン、投稿データには影響しない。
再インストール後も症状が続く場合は、一度標準テーマ（Twenty Twenty-Fiveなど）に切り替えてサイトエディターが開くか確認する。標準テーマで開くなら使用中のテーマ側に原因があり、標準テーマでも開かないならサーバー設定やREST APIの応答に原因が残っている可能性が高い。
よくある質問
プラグインをすべて無効化しても直らないのはなぜか
サイトエディターの真っ白はプラグインの競合だけでなく、ブラウザ、JavaScript、REST API、PHPメモリなど複数の要因が絡む。特にREST API経由のデータ取得に失敗している場合はプラグイン無効化だけでは切り分けが不十分だ。ブラウザのコンソールとサーバーログの両方を確認する必要がある。
同じブラウザなのにサイトによって動作が違うのはなぜか
サイトごとに使用中のテンプレートやブロック、グローバルスタイルの構成が異なる。古いブラウザが対応していないJavaScript機能を使うブロックや設定が含まれているサイトだけが真っ白になる。また、サイトごとのメモリ上限やサーバー設定の違いも影響する。
WordPress 7.0に戻した方がよいか
セキュリティ修正を含む更新を戻すのは推奨しない。WordPress 7.1のまま原因を特定して解決する方が安全だ。原因を切り分ける手順を踏めば、ロールバックせずに直せるケースがほとんど。
デベロッパーツールが使えない端末ではどうすればいいか
別の端末やブラウザで同じサイトを開いて症状を再現し、そこからデベロッパーツールやサーバーログを確認する。どうしても別端末が用意できない場合は、サーバーエラーログを症状発生直後の時刻で確認し、PHPの致命的エラーやREST APIの応答を調べるとよい。
この記事のポイント
- サイトエディターの真っ白はブラウザ互換性を最初に疑う
- デベロッパーツールでJavaScriptエラーを特定する
- サーバーエラーログは症状が起きた直後の時刻で確認する
- REST APIの応答を直接チェックして切り分ける
- PHPメモリ不足なら上限を引き上げる
- ファイル欠損が疑わしい場合はWordPress本体を再インストールする
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている