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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
カートページで数量を変更すると違う数になる時の対処法
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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooPaymentsでカード追加ページが真っ白になる原因と解消手順
WooCommerceでWooPaymentsを使っているサイトで、購入時のカード保存は正常に動くのにマイアカウントのカード追加ページだけが真っ白になる場合、多くはJavaScriptエラーかプラグインによるテンプレート競合が原因だ。開発者ツールでエラーの実体を特定し、プラグインとテーマの切り分けを順に行うと短時間で解消できる。
なぜカード追加ページだけが真っ白になるのか
WooPaymentsのカード入力フォームは、チェックアウト画面でもマイアカウント内でもJavaScriptで動的に描画される。特にカード追加ページでは、WooPaymentsが提供するStripe Elementsという入力部品を読み込んでフォームを生成する仕組みだ。
このとき、他のプラグインが読み込むスクリプトと衝突したり、テーマがマイアカウントのテンプレートを上書きしてフォームの置き場所が消えたりすると、ページが真っ白に見える。PHPの致命的エラーが起きている場合も同様の症状になる。
保存済みカードの一覧表示は正常なのにカード追加だけが空になるのは、表示に異なる読み込み経路が使われるためだ。一覧はすでにデータベースへ保存された情報をPHPだけで描画できるが、カード追加フォームはJavaScriptの実行が必須になる。だからこそ、スクリプトエラーが症状としてそのページだけに出やすい。
また、WooPaymentsのアップデート時にファイルの一部が欠けた場合もフォームが表示されない。エラーがどこにも出ないまま空白だけになるケースでは、プラグイン本体の再インストールも選択肢に入る。
ブラウザの開発者ツールでエラーを特定する手順
まず最初に、ブラウザの開発者ツールを使って実際に何が止まっているのかを確認する。エラーが特定できれば、その後の切り分けが大幅に短くなる。
このデモは、エラー特定までの基本フローを示している。コンソールとネットワークの両方を確認すると原因ファイルが見つかりやすい。
コンソールでJavaScriptエラーを確認する
カード追加ページを開いた状態でF12キーを押し、「コンソール」タブを開く。赤い文字で表示されるエラーが1件以上あれば、その内容を控えておく。英語表示の場合は「Uncaught TypeError」や「Failed to load resource」のような記述が手がかりになる。
エラーの右側に表示されるファイル名も重要だ。どのプラグインのスクリプトが失敗しているかが分かれば、無効化の対象を特定できる。たとえば `woocommerce.js` や `stripe.js` が読み込めていなければ、キャッシュやプラグイン本体の問題を疑う。
ネットワークタブで読み込み失敗を確認する
同じく開発者ツールの「ネットワーク」タブを開き、ページを再読み込みする。ステータスが「404」や「500」になっているファイルがないかを確認する。404はファイルが存在しない、500はサーバー処理の失敗を意味する。
とくにカードフォームの描画に必要なJavaScriptファイルが404になっていると、ページが白いまま何も表示されない。この場合はWooPaymentsのファイルが不完全な可能性が高い。
プラグインとテーマの競合を切り分ける手順
開発者ツールで原因が特定できない場合は、定番の切り分け作業を順に行う。目的は、どのプラグインまたはテーマがカード追加ページの表示を妨げているかを絞り込むことだ。
切り分け前
全プラグインが有効のまま「カード追加」を開くと
ページが真っ白でフォームが表示されない
どのプラグインが影響しているか不明
切り分け後
WooCommerceとWooPaymentsだけを有効にすると
カード入力フォームが正常に表示される
原因プラグインをひとつずつ有効化して特定できる
このデモは、プラグイン競合の切り分け前後で何が変わるかを示している。競合元を特定しなければ恒久的な解決にはならない。
全プラグインを無効化してWooCommerce系だけ有効化する
管理画面の「プラグイン」へ移動し、(WooCommerceとWooPayments以外の)すべてのプラグインを無効化する。この状態でカード追加ページを開いてフォームが表示されるか確認する。
フォームが表示された場合は、無効化したプラグインをひとつずつ有効化して、どのプラグインを有効にした時点で再発するかを確認する。マイアカウントの表示をカスタマイズするプラグインや、管理画面用のスクリプトを全ページに読み込むプラグインが原因になりやすい。
この作業で一時的にサイト機能が変わるため、アクセスの少ない時間帯に行うか、ステージング環境があればそちらで再現させる。WooCommerceとWooPaymentsは必ず有効のままにして検証する。
標準テーマに切り替えてテーマの影響を除外する
プラグインをすべて無効化しても症状が続く場合は、テーマが原因の可能性がある。管理画面の「外観」→「テーマ」で、Twenty Twenty-FourなどのWordPress標準テーマへ一時的に切り替える。
標準テーマでカード追加フォームが表示されるなら、元のテーマがマイアカウントのテンプレートを上書きしていることになる。テーマに含まれる `woocommerce` フォルダの `myaccount` 関連ファイルが、カード追加ページの表示を妨げているケースが多い。
テーマを切り替えるとウィジェットやカスタマイズ設定が変わることがあるため、検証後は必ず元のテーマへ戻す。できればステージング環境での検証を推奨する。
WooPaymentsの設定とパーマリンクを再確認する
切り分けを行っても原因が見つからない場合、WooCommerceの設定とパーマリンクを再確認する。設定が正しくても保存し直すだけで直るケースがある。
カード追加エンドポイントの設定を保存し直す
管理画面の「WooCommerce」→「設定」→「詳細設定」タブを開き、「アカウントエンドポイント」欄を確認する。カード追加の項目が正しく入力されていることを確認し、入力内容そのものに変更がなくても一度「変更を保存」を押す。
パーマリンクの内部マップがずれていると、ページ自体は存在してもWooCommerceがエンドポイントを認識できないことがある。保存し直すだけでマップが再構築されるため、手軽に試せる。
保存済みカード決済の設定を確認する
「WooCommerce」→「設定」→「決済」タブでWooPaymentsを開き、「カード決済」が有効であることと「保存済みカードによる支払いを有効にする」にチェックが入っていることを確認する。購入時のカード保存は正常でも、この設定が外れるとマイアカウントからの追加だけが動作しないことがある。
パーマリンクを更新してエンドポイントを再マップする
管理画面の「設定」→「パーマリンク」へ移動し、設定を変更せずそのまま「変更を保存」を押す。これでリライトルールが再生成され、マイアカウントの各エンドポイントが正しく認識されるようになる。
パーマリンク更新後は必ずキャッシュプラグインのキャッシュを全削除する。キャッシュが残っていると、古い状態のページが配信されて症状が続いているように見える。
再発を防ぐための更新前チェックとログ確認
根本解決できたら、次回のアップデートで同じ問題が起きないように更新前チェックの習慣をつけておく。WooPaymentsは更新頻度が高いプラグインのため、更新後に特定のページだけが壊れるリスクは常にある。
WooCommerceのログでPHPエラーを確認する
管理画面の「WooCommerce」→「ステータス」→「ログ」タブを開き、直近のエラーログに「fatal-errors」のようなファイルがないかを確認する。PHPの致命的エラーが記録されていれば、その内容から原因ファイルを特定できる。
ログが存在しない場合は、WooPaymentsの「ログ」タブから決済関連の動作記録を確認する。カード追加フォームの読み込みに失敗した形跡がないかを探る。
WooPaymentsのファイルを再アップロードする
アップデート時にファイルの一部が欠けた疑いがある場合は、管理画面からプラグインを削除して再インストールする。その際、決済データはサーバー側に保存されているため、プラグインの削除で売上情報や顧客情報が消えることはない。
FTP接続でWooPaymentsのフォルダだけを最新版のファイルで上書きする方法もある。管理画面に入れる状態なら「プラグイン」→「プラグインの新規追加」からWooPaymentsを検索して入れ直す方が確実だ。
マイアカウント系ページをキャッシュ対象から除外する
キャッシュプラグインの設定で、マイアカウント関連のURLをキャッシュ対象から除外しておく。具体的には `/my-account/` で始まるパスを除外リストへ追加する。これにより、カードフォームや認証情報が古いキャッシュで表示される問題を防げる。
よくある質問
カード追加ページだけが真っ白になるのはなぜ？
そのページだけテンプレートやJavaScriptが干渉されている可能性が高い。WooPaymentsのカード入力フォームはJavaScriptで描画されるため、他のプラグインのスクリプトが衝突するとフォームが生成されず真っ白に見える。
開発者ツールにエラーが表示されない場合は？
コンソールにエラーが出ない場合、PHPの処理途中で止まっている可能性を疑う。wp-config.phpでデバッグを有効にしてエラーを可視化するか、WooCommerceのログを確認する。あわせてテーマのマイアカウント用テンプレートが正しいかも調べる。
WooPaymentsのバージョンを一つ前へ戻すと直る？
互換性が問題の場合は直ることがある。バージョン固定のダウングレードは応急処置として有効だが、セキュリティ更新を含む場合は推奨しない。まず競合の特定を優先し、どうしても手がかりがない場合に実施する。
キャッシュプラグインが原因になることはある？
ある。特にマイアカウント系のページをキャッシュしてしまう設定だと、カードフォームの読み込みだけが古い状態で配信されることがある。キャッシュ対象からマイアカウントを除外する設定も併せて確認する。
マイアカウントの表示をカスタマイズするプラグインは原因になりやすい？
なりやすい。カード追加ページのテンプレートやフックを書き換えるタイプのプラグインは、WooPaymentsのフォーム表示に直接影響する。無効化して症状が消えるかどうかを最初の切り分けで確認する。
この記事のポイント
- 開発者ツールのコンソールでJavaScriptエラーを特定する
- 全プラグインを無効化してWooCommerce系だけ有効化して切り分ける
- 標準テーマに切り替えてテーマ競合を除外する
- パーマリンクとエンドポイント設定を保存し直す
- WooPaymentsを再インストールしてファイルの健全性を回復する
- マイアカウント系ページをキャッシュ対象から除外する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
hCaptcha 5.2.0更新後にログインできない時の対処法とダウングレード手順
hCaptcha プラグインを 5.2.0 に更新した直後からログイン画面に「Bad hCaptcha signature!」と表示され、管理画面へ入れない場合は、5.1.0 へのダウングレードと全キャッシュの削除で解決する。この不具合は 5.2.0 の署名検証リグレッションが原因で、サイトキーやシークレットキーの設定ミスではない。
なぜhCaptcha 5.2.0への更新後にログインエラーが起きるのか
hCaptcha 5.2.0 はログイン時の署名形式を変更している。署名とは、データが改ざんされていないことを証明する値のことだ。この変更が原因で署名検証フローにリグレッション（回帰不具合、以前は正常だった機能が更新によって壊れること）が混入した。
WordPress のログイン統合と別のログイン統合が、同じ wp-login.php エンドポイントを通じて送信される際に署名の検証が失敗する。複数のプラグインがログイン画面に同時に作用する構成で、この問題が顕著に現れる。
「Bad hCaptcha signature!」というエラーは、プラグインがローカルで生成している。hCaptcha API にリクエストを送る前の段階で発生するため、サイトキーとシークレットキーの検証が成功していてもエラーが消えない。この点が原因の切り分けを難しくしている。
「ログイン試行前のhCaptcha」の設定値を 0 にしている場合、この不具合はすべてのログイン試行で発生する。0 に設定すると署名検証を回避する余地がなくなり、毎回エラーに遭遇する。
ログイン不能な状態から管理画面へ入る手順
管理画面に入れない状態でも、FTP や SSH でサーバーへ接続すれば hCaptcha プラグインを一時停止できる。プラグインを停止するとログイン経路が確保されるため、その後は通常どおり管理画面へアクセスできる。
この手順で管理画面へ入り、ダウングレードの準備を整える。
FTPまたはSSHでプラグインを停止する
FTP クライアントでサーバーへ接続し、wp-content/plugins ディレクトリへ移動する。hcaptcha というフォルダを見つけたら、フォルダ名を「hcaptcha-disabled」のように変更する。WordPress はプラグインを読み込まなくなるため、ログイン画面からキャプチャが消えて通常のログインフォームが表示される。
SSH を使える環境なら、wp-content/plugins ディレクトリで mv コマンドを実行する方法が速い。コマンドラインでの操作に慣れている場合は、この選択肢が確実だ。
管理画面に入ったらhCaptcha設定を確認する
プラグインを停止してログインできたら、WordPress 管理画面の「プラグイン」を開く。hCaptcha が停止状態になっていることを確認し、これから行うダウングレードに備えて現在の設定メモを残しておくとスムーズだ。
hCaptcha 5.2.0を5.1.0へダウングレードする手順
管理画面へ入れるようになったら、hCaptcha 5.2.0 を削除して 5.1.0 をインストールする。設定データは削除しても保持されるため、サイトキーとシークレットキーを再入力する必要はない。
5.1.0 へ戻すと署名検証の不具合が解消され、ログインできるようになる。
5.2.0を削除して5.1.0をインストールする
WordPress 管理画面の「プラグイン」から hCaptcha 5.2.0 を削除する。削除しても設定はデータベースのオプションテーブル（デフォルトでは wp_options）に残るため、サイトキーやシークレットキーが消えることはない。
次に 5.1.0 の ZIP ファイルを公式リポジトリなどから入手する。「プラグイン」メニューの「新規追加」を開き、「プラグインのアップロード」から ZIP ファイルを選択してインストールする。インストール完了後に有効化する。
サイトキーとシークレットキーを再確認する
インストール後、hCaptcha の設定画面を開き、サイトキーとシークレットキーに値が入っていることを目視で確認する。5.2.0 から戻しても設定は残っているはずだが、念のため両方のフィールドをチェックしておく。
キーの検証ボタンを押して成功すれば、API との通信自体は正常ということだ。ただしこの不具合は通信前にローカルで発生するため、検証成功の表示が出ても油断はできない。あくまでキーの有効性を確認するだけの操作だと理解しておく。
モードをLiveに設定して保存する
設定画面でモードが Live になっていることを確認し、変更があれば保存する。サイズが invisible になっているかも確認する。設定を保存したら、次のキャッシュ削除の手順へ進む。
キャッシュを削除してエラーを完全に解消する
バージョンを 5.1.0 に戻しただけではエラーが残ることがある。5.2.0 が署名形式を変更した影響で、以前のバージョンが生成したログイン HTML が各種キャッシュに残っていると、同じエラーが引き続き表示される。
ページキャッシュとサーバーキャッシュを削除する
使用しているキャッシュプラグイン（WP Super Cache や W3 Total Cache など）の管理画面を開き、ページキャッシュとオブジェクトキャッシュを削除する。サーバー側のキャッシュ機能（Varnish や LiteSpeed Cache など）が有効な場合も、同じく削除操作を行う。
CDNのキャッシュを削除する
Cloudflare やその他の CDN を利用している場合、CDN の管理画面からキャッシュをパージする。ログインページの HTML がエッジサーバーに残っていると、WordPress 側の設定が正しくても古い署名形式のページが配信され続ける。
プライベートウィンドウで動作確認する
キャッシュ削除後、通常のブラウザタブではなくプライベートウィンドウ（シークレットウィンドウ）でログインページを開く。ブラウザのローカルキャッシュや Cookie も残っていると、修正後のページを正しく読み込めないことがある。
プライベートウィンドウでログインを試み、キャプチャを通過して管理画面に入れればダウングレードは成功だ。通常のブラウザタブでまだエラーが出る場合は、ブラウザのキャッシュと Cookie を個別に削除して再試行する。
自動更新を止めて再発を防ぐ
修正版がリリースされるまで、自動更新で 5.2.0 に戻らないようにしておく。プラグインの自動更新は個別に無効化できるため、hCaptcha だけ更新を止めておくのが安全だ。
hCaptchaの自動更新を無効化する
WordPress 管理画面の「プラグイン」一覧で hCaptcha の行を確認し、自動更新を無効にする。プラグインごとの自動更新設定はプラグイン一覧画面から切り替えられる。WordPress 本体の自動更新とは別の設定なので、本体は更新を継続したまま hCaptcha だけを固定できる。
修正版のリリースを確認する方法
プラグインの公式ページやリポジトリを定期的に確認し、5.2.1 以降の修正版がリリースされたかをチェックする。修正版が出るまでは 5.1.0 のまま運用し、更新前には必ずテスト環境でログイン動作を確認する。
本番環境へ修正版を適用する際も、まずステージング環境でログイン、キャプチャ表示、ユーザー登録、パスワードリセットの一連の動作を検証してからリリースするのが安全だ。
よくある質問
プラグインを削除するとhCaptchaの設定は消えますか
いいえ、消えない。プラグインを削除しても設定はデータベースに保持される。アンインストール時にデータを削除するクリーンアップ設定を事前に有効化していた場合のみ、削除される仕組みだ。ダウングレードでサイトキーを再入力する必要はない。
ダウングレード後に「インストールが不正です」と表示されます
5.2.0 から 5.1.0 へ手動で戻す際、WordPress が古いバージョンのインストールを「不正」と判定することがある。この場合は一度 5.2.0 を完全に削除してから 5.1.0 を新規インストールする。設定が残っているため、再設定の手間はかからない。
サイトキーとシークレットキーの検証は成功するのにエラーが続きます
「Bad hCaptcha signature!」は、プラグインが API へリクエストを送る前のローカル段階で生成される。キーの検証は API との通信が正常であることを示すだけで、署名検証の不具合とは無関係だ。そのためキーが正しくてもエラーは消えない。
ログイン時にキャプチャテストが表示されるのは正常ですか
「サイズ」を「invisible」に設定しているにもかかわらず画像選択テストが表示される場合、設定が正しく反映されていない可能性がある。ダウングレード後にキャッシュを削除し、プライベートウィンドウで再度確認するとよい。それでも表示される場合は、ログイン試行前の設定値や他のログイン系プラグインとの競合を調べる。
自動更新で勝手に5.2.0に上がるのを防げますか
防げる。WordPress 管理画面の「プラグイン」一覧から hCaptcha の自動更新を個別に無効化できる。また、複数のプラグインを一元管理している場合は、更新ポリシーで hCaptcha を除外する設定を行う。
この記事のポイント
- 5.2.0 の署名検証リグレッションがログインエラーの原因
- エラーはAPI通信前のローカル処理で発生する
- 5.1.0 へのダウングレードが確実な対処法
- プラグイン削除後も設定データは保持される
- 全キャッシュ削除とプライベートウィンドウでの確認が必須
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.1で標準サイトマップが404になる原因と解消手順
WordPress 7.1 に更新した後、プラグインなしのサイトで標準 XML サイトマップが 404 になる場合は、パーマリンク設定の再保存でリライトルールを再生成する。同じ環境で 7.0.4 では正常だった場合は WordPress 7.1 本体のリグレッションの可能性が高いため、急ぎなら 7.0.4 へ戻すのが確実だ。
WordPress 7.1 で標準サイトマップが 404 になる原因
標準 XML サイトマップは WordPress 5.5 から搭載された機能だ。パーマリンク設定に基づき wp-sitemap.xml という URL でインデックスを出力し、wp-sitemap-posts-page-1.xml のように投稿タイプ別・ページ番号別の子サイトマップを生成する。検索エンジンがサイトを巡回する入り口の役割を持つ。
WordPress 7.0.4 から 7.1 へ更新した直後から wp-sitemap.xml と wp-sitemap-posts-page-1.xml の両方が 404 を返す場合は、プラグインの競合やテーマの影響を疑う前に、WordPress 本体のリライト処理と更新後のルール再生成状況を確認する。特に Nginx を Apache の前段に置くリバースプロキシ環境では、拡張子 .xml を静的ファイルとして振り分ける設定や、Apache 側の .htaccess にリクエストが届かない構成が原因になることがある。
同じ環境・同じテーマ・プラグインなしで 7.0.4 に戻すと直る場合、WordPress 7.1 の標準サイトマップ機能に起因する不具合の可能性が高い。設定を見直しても直らないときは、コア側の更新によるリグレッションを視野に入れる。
最初に試すパーマリンク再保存とキャッシュ確認
WordPress はバージョン更新後に、パーマリンクのリライトルールが内部にキャッシュされたままになることがある。最初に管理画面の「設定」→「パーマリンク」を開き、内容を変更せずに「変更を保存」を押す。これによって .htaccess やデータベース上のルールが再生成される。
保存後は、ブラウザのシークレットウィンドウか curl で wp-sitemap.xml の HTTP ステータスコードを確認する。キャッシュ系プラグインを入れていなくても、レンタルサーバーや Nginx、CDN がレスポンスをキャッシュしている可能性があるため、まずキャッシュを削除する。
この切り分けで、リライトルールの再生成だけで直るのか、Nginx と Apache の設定まで必要なのかが区別できる。
ここで 200 OK に戻れば、更新によるリライトルールの再生成漏れが原因だったことになる。それでも 404 なら次の転送設定の確認へ進む。
Nginx リバースプロキシと Apache の転送設定を確認する手順
Nginx をリバースプロキシとして Apache の前に置く構成では、location / が proxy_pass で Apache へ向いているかを確認する。もし location ~* \.(xml)$ のような拡張子判定があり、Nginx が XML を静的ファイルとして処理してしまうと、WordPress に到達せず 404 になる。
Apache 側の .htaccess は、# BEGIN WordPress から # END WordPress の間に標準の mod_rewrite.c ブロックがあるかを確認する。独自の RewriteCond や RewriteRule を追記していないこと、RewriteBase / がサイトの設置パスに合っていることが重要だ。
curl で example.com/wp-sitemap.xml と example.com/?sitemap=posts&sitemap-subtype=page&paged=1 をそれぞれ確認する。クエリ形式でも 404 なら、WordPress がサイトマップを出力できていないか、Nginx から Apache への転送が正しくない可能性がある。
WordPress 7.1 から 7.0.4 へ戻す一時対処と注意点
設定変更でも症状が変わらない場合は、バックアップを取得したうえで WordPress 7.0.4 へ戻す。公式パッケージの 7.0.4 でコアファイルを置き換え、管理画面にデータベース更新の案内が出た場合はそれを実行する。
このデモは 7.1 で 404 を返していたサイトマップが、7.0.4 へ戻すと 200 OK に変わることを示している。
ファイルとデータベースのバックアップを取らずにダウングレードすると、予期しない不整合からの復旧が難しくなる。WP Downgrade のようなダウングレード用プラグインを使う場合も、更新前のスナップショットが必須になる。
7.0.4 へ戻すと、同じ URL wp-sitemap.xml が正常に XML を返すようになる。ただし 7.1 の修正版がリリースされたら、そのまま使い続けずに安全なタイミングで更新する。
Google Search Console の再読み込みと標準サイトマップの再送信
サイトマップが正常に戻ったら、Google Search Console の「サイトマップ」で登録済みの wp-sitemap.xml を確認する。「取得できませんでした」と表示されていた場合は再読み込みを行い、ステータスが「成功しました」に変わるのを待つ。
古いレポートが残っている場合は、一度サイトマップを削除してから wp-sitemap.xml を再送信する。フェッチが完了するまで数分かかることがあるため、すぐに結果が出なくても時間を置いて再確認する。
再発防止と WordPress 7.1 の修正状況の追い方
WordPress 7.1 の後続リリースで標準サイトマップの修正が含まれるかは、ダッシュボードの更新通知と WordPress のリリース情報で確認する。本番環境へメジャー更新を適用する前には、ステージング環境で wp-sitemap.xml が 200 OK を返すことを必須のチェック項目にする。
Nginx と Apache を併用している構成では、更新前後の curl の応答コードを記録しておくと、今回のような更新起因のリグレッションを素早く特定できる。SEO プラグインのサイトマップで代替することも一時的には可能だが、パーマリンク全体の不具合を隠す可能性があるため、先に WordPress 本体とサーバー設定の切り分けを行う。
よくある質問
標準サイトマップが404になったらまず何をすればいい？
管理画面の「設定」→「パーマリンク」を開き、内容を変えずに保存してリライトルールを再生成する。これで直らない場合は、Nginx の静的ファイル判定や Apache の .htaccess を確認し、それでも再現するなら WordPress 7.0.4 へ戻して切り分ける。
Nginx リバースプロキシだと何が問題になる？
Nginx が .xml のリクエストを静的ファイルと判断すると、Apache へ渡さずに 404 を返す。Apache の前段で location 設定を見直し、WordPress の index.php までリクエストが届く構成になっているか確認する。
WordPress 7.1 に更新しない方がいい？
通常の単純な LAMP 構成では問題が起きにくいが、標準サイトマップを運用中のサイトで更新直後の 404 が許容できないなら、修正版が出るまで 7.0.4 を使う判断も現実的だ。本番更新前にステージングで確認するのが基本になる。
7.0.4 に戻した後、Google Search Console で何をすればいい？
サイトマップの再読み込みを行い、ステータスが成功に変わるのを確認する。エラーが残っている場合は一度削除して wp-sitemap.xml を再送信し、数分後にもう一度確認する。
SEO プラグインのサイトマップに切り替えてもいい？
切り替え自体は可能だが、WordPress 標準のサイトマップが壊れた原因を残したままだと、他のパーマリンクでも同様の不具合が出る可能性がある。一時的な代替には使えるが、本体側の切り分けを先に行う。
この記事のポイント
- WordPress 7.1 更新後に標準サイトマップが 404 になる場合、最初にパーマリンクを再保存する
- Nginx と Apache の組み合わせでは静的ファイル判定や .htaccess を確認する
- 7.0.4 で同じ環境が正常なら WordPress 本体のリグレッションを疑う
- 急ぐ場合はバックアップを取って 7.0.4 へ戻すのが確実
- 修正版のリリースと Google Search Console のステータスを確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressでデータベースのテーブルが見つからないエラーの原因と対処法
WordPressで「テーブルが見つからない」エラーが表示されたら、まずwp-config.phpのテーブル接頭辞（$table_prefix）とデータベース内の実際のテーブル名を照合する。接頭辞が一致していなければ設定を修正し、そもそもテーブルが存在しない場合はバックアップからの復元が必要になる。
なぜWordPressで「テーブルが存在しない」エラーが発生するのか
WordPressは投稿や固定ページ、ユーザー情報をすべてデータベースに保存している。データベースの中には複数のテーブルがあり、それぞれ「接頭辞＋テーブル名」という形式で管理される。接頭辞はセキュリティ対策としてサイトごとに変えられる仕組みだ。たとえば初期状態ではwp_posts、wp_optionsという名前になる。
この接頭辞はwp-config.phpという設定ファイルの$table_prefixで指定する。実際のデータベースにあるテーブル名と、この設定ファイルの値が食い違うと、WordPressが存在しない名前のテーブルを探しに行き「テーブルが見つからない」エラーを起こす。サイト移転や手動バックアップの復元時に、データベースだけ別の接頭辞で持ってきてしまった場合に起きやすい。
データベース修復機能は破損したテーブルを直すためのもので、存在しないテーブルを新しく作ることはできない。そのため「修復」を実行してもエラーは解消されない。問題の切り分けには、まず実際にどんなテーブルが存在するのかを確認する必要がある。
データベース内の実際のテーブル接頭辞を調べる方法
エラーの原因が接頭辞の不一致か、それともテーブル自体が消えているのかを切り分けるには、データベース管理ツールを開いて実在するテーブル名を確認する。レンタルサーバーの管理画面にログインし、phpMyAdminと呼ばれるデータベース管理ツールを選択するのが最も確実だ。
テーブル一覧にwp_postsやwp_optionsという名前が見えたら、実際の接頭辞はwp_だ。この場合、設定ファイルが別の値を指していることが原因なので、次の手順で修正する。一方、テーブル一覧が空だったり、別の名前でも見当たらない場合は、テーブル自体が失われている可能性が高い。
wp-config.phpのテーブル接頭辞を正しい値に直す手順
設定ファイルの修正は、FTPソフトかレンタルサーバーのファイルマネージャでwp-config.phpを直接編集する。WordPressをインストールしたルートディレクトリにあるこのファイルを開き、$table_prefixが書かれた行を探す。
保存後にサイトを再読み込みすると、これまで表示されていたテーブル関連のエラーが消えて通常の画面が戻る。管理画面にもアクセスできるようになるはずだ。なお、wp-config.phpを編集する前には必ずファイルのバックアップを取っておくこと。
ファイルマネージャで編集できない場合は、FTPソフトでサーバーに接続して同じファイルをダウンロードし、テキストエディタで修正してアップロードする。文字コードはUTF-8のまま保存する。
テーブルが実際に消えている場合の復元方法
phpMyAdminで確認しても該当するテーブル自体が存在しない時は、設定の不一致ではなくデータが失われている状態だ。この場合は修復機能では戻らないため、バックアップからの復元が必要になる。
- レンタルサーバーの自動バックアップ機能を確認する
- 運用中に取得していたバックアップデータから復元する
- ホスティング事業者のサポートに問い合わせる
バックアップが手元にない場合でも、ホスティング事業者が定期的にサーバー全体のバックアップを保持していることが多い。データベースだけを復元できるか、サポートに確認するのが得策だ。復元後は接頭辞の一致を必ず確かめる。
テーブル接頭辞の不一致を防ぐための確認ポイント
サイト移転やバックアップ復元の後に同じエラーを再発させないためには、接頭辞とデータベースの状態を習慣的に確認しておくとよい。最低限のポイントを挙げる。
- サイト移転時は設定ファイルとデータベースの接頭辞を照合する
- テスト環境と本番環境では同じ接頭辞にそろえる
- wp-config.php を編集する前に必ずバックアップを取る
- 不要なデータベース修復を連続実行しない
よくある質問
接頭辞を直したのにまだテーブルが見つからないエラーが出る
設定ファイルを保存した後もブラウザやサーバーのキャッシュが残っていると表示が変わらない場合がある。ブラウザをスーパーリロードし、サーバー側のキャッシュを削除してから確認する。それでも出る場合は、実際に存在するテーブル名と設定値をもう一度照合し、データベース名やホスト名も確認する。
phpMyAdmin を使わずに接頭辞を確認できるか
wp-config.php の設定だけでは実際のテーブル名は分からない。データベース管理ツールか、ホスティング事業者の管理画面にあるデータベース一覧で確認する。どうしても見つからない時はサポートに問い合わせると接頭辞を教えてもらえる場合がある。
WordPress の修復機能でテーブルが消えることはあるか
修復機能は既存テーブルの破損を修復するのが目的で、テーブル自体を削除する動作ではない。ただし存在しないテーブルは作成できないため、修復を実行してもテーブルがないエラーは解消しない。元のテーブルが消える主な原因はデータベースの操作ミスやインポート時の上書きだ。
バックアップからデータベースだけ復元する手順は
ホスティングの管理画面にあるバックアップ機能を開き、復元したい日時のデータベースを選ぶ。phpMyAdmin からインポートできる SQL ファイルがある場合は、該当するデータベースを選択してインポートを実行する。操作前に現在のデータを追加でエクスポートしておくと安全だ。
接頭辞を wp_ に変更すると既存データは消えるか
接頭辞の変更そのものはテーブル名を読み替えるだけで、データを削除しない。ただし実在しない接頭辞に変更すると WordPress がテーブルを見つけられず、同じエラーになる。必ずデータベース内の実名と一致する値に変更する。
この記事のポイント
- テーブルが見つからないエラーは接頭辞の不一致が第一原因
- phpMyAdmin で実際のテーブル名を確認する
- wp-config.php の $table_prefix を実在の接頭辞に合わせる
- テーブル自体が無い時はバックアップ復元が最短ルート
- 設定変更前に必ず wp-config.php とデータベースのバックアップを取る
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerceのApple PayとGoogle Payがクラシックカートで表示されない時の直し方
ECサイトでWooCommerceのクラシックカートとクラシックチェックアウトにApple PayやGoogle Payのボタンが表示されない場合、原因の多くはStripeが提供するホスト型決済方法設定がショートコード版ページのJavaScript初期化と衝突していることにある。商品ページやブロックカートでは正常でも、ショートコード版だけ動かないという状況では、決済ゲートウェイの初期化スクリプトが正しく読み込まれていない可能性が高い。
なぜクラシックカートだけApple PayとGoogle Payが表示されないのか
WooCommerceのStripeゲートウェイは、ページの種類に応じて決済ボタンを表示するためのJavaScriptを別々のタイミングで初期化する。ブロックカートとブロックチェックアウトは新しいGutenbergブロックとしてレンダリングされるため、StripeのExpress Checkoutボタンを配置する専用のコンテナが自動で用意される。
一方、クラシックカートとクラシックチェックアウトはショートコード（[woocommerce_cart]と[woocommerce_checkout]）でページに埋め込まれる。この方式では、テーマのJavaScriptやjQueryの読み込み順によってStripeの初期化スクリプトが正しく実行されず、ボタンが表示されないことがある。特にカスタムテーマやテーマビルダーを使っている場合は競合が起きやすい。
もう一つの有力な原因が、WooCommerceのログに出力されている「Stripe-hosted payment method configuration（ホスト型決済方法設定）」への切り替えエラーだ。Stripeがホストする決済方法設定に切り替わると、従来のローカル設定で動いていたExpress Checkoutボタンの初期化ロジックと整合しなくなることがある。これはStripeアカウント側の設定変更によって発生する。
つまり、症状がショートコード版ページに限定されるのは、決済ゲートウェイ自体の設定ミスではなく、ページのレンダリング方式とStripeスクリプトの初期化タイミングのずれが主因であるケースがほとんどだ。
JavaScriptコンソールでエラーを確認する手順
真っ先に調べるべきは、クラシックカートとクラシックチェックアウトのページでJavaScriptエラーが出ているかどうかだ。ブラウザのデベロッパーツールを使えば、原因となるスクリプトを特定できる。
Chromeの場合、クラシックカートのページを開いた状態で「F12」キーを押し、「Console」タブを確認する。赤いエラーメッセージが表示されていれば、その内容を記録する。特にwc_stripe_upe_paramsやwp.escapeHtmlに関連するエラーはStripeゲートウェイの初期化失敗を示す代表的なものだ。
FirefoxやEdgeでも同様に、開発者ツールのコンソールから確認できる。スマートフォンで確認する場合は、パソコンのブラウザでデベロッパーツールを開き、デバイスエミュレーションモードにして同じページを読み込むとよい。
Stripeのホスト型決済方法設定を無効化する
WooCommerceのログにホスト型決済方法設定への切り替えエラーが出ている場合、Stripeダッシュボード側の設定を変更するか、プラグイン側でホスト型設定を手動設定に戻す必要がある。
このデモはStripe設定の確認から修正までの手順の流れを示したものだ。実際の管理画面の項目名はWooCommerce Stripeプラグインのバージョンによって若干異なる。
Stripeダッシュボードでは、ホスト型決済方法設定が有効になっていると、決済方法の組み合わせがStripeサーバー側で管理される。これがWooCommerce側のExpress Checkoutボタン初期化と競合し、クラシック版ページでのみボタンが出ない状態を引き起こすことがある。WooCommerce側のStripe設定画面で「決済方法を手動で管理」するオプションを選択し、Apple PayとGoogle Payを明示的に有効化すると改善するケースが多い。
プラグインの再設定だけでは直らない場合は、Stripeアカウントの接続を一度解除して再接続するのも有効だ。WooCommerceの「決済」タブからStripeを選び、「接続を解除」を押した後、再度Stripeアカウントで接続する。この操作でプラグインがStripeサーバーから最新の設定を取得し直し、ホスト型決済方法設定とのずれが解消されることがある。
クラシックカートのショートコードとページ設定を再確認する
クラシックカートとチェックアウトのページに正しいショートコードが貼られているかも併せて確認する。カートページには[woocommerce_cart]、チェックアウトページには[woocommerce_checkout]が必須だ。
WooCommerceの「設定」→「詳細設定」タブにある「カートページ」と「チェックアウトページ」の指定が、実際にショートコードを貼ったページと一致しているか確認する。別のページを指定したままだと、表示されている地図ページとStripeの初期化対象ページがずれて、ボタンが出ないことがある。
ページビルダー（ElementorやBeaver Builderなど）でカートページを作成している場合は、ショートコードウィジェットを配置しているか確認する。ページビルダーのテキストブロックにショートコードを直接入力していると、WooCommerceのテンプレートフックが正しく読み込まれず、StripeのExpress Checkoutボタン用のフックが実行されないことがある。
キャッシュとCDNを削除して再テストする
設定変更後もボタンが表示されない場合は、サーバー側のキャッシュとCDNのキャッシュが古いスクリプトを配信し続けている可能性がある。WooCommerce専用のキャッシュプラグインを使っている場合は、そのキャッシュを全削除する。CDN（コンテンツデリバリネットワーク / 配信網）を利用している場合は、CDNのダッシュボードからキャッシュをパージする。
その後、シークレットウィンドウ（プライベートブラウジング）でクラシックカートのページを開いて確認する。通常のブラウザに残っているクッキーやサービスワーカーが古いスクリプトを参照していることがあるため、シークレットウィンドウで確認するとキャッシュの影響を排除できる。
それでも直らない場合、一時的にすべてのプラグインを無効化して標準テーマに切り替え、WooCommerceとStripeゲートウェイだけを有効化した状態でテストする。この最小構成でボタンが表示されれば、別のプラグインかテーマが原因だ。影響しているプラグインを一つずつ有効化して切り分けていく。
よくある質問
商品ページではボタンが出るのにクラシックカートでは出ないのはなぜか
商品ページとクラシックカートではExpress Checkoutボタンを初期化するJavaScriptのフックが異なる。商品ページはWooCommerce標準のフックで動くが、カートとチェックアウトはページテンプレートの構造に依存するため、テーマやプラグインの競合で初期化が妨げられることがある。
ブロックカートに切り替えれば解決するのか
ブロックカートとブロックチェックアウトはGutenbergブロックとしてレンダリングされるため、Stripeゲートウェイが専用コンテナを確実に配置でき、ボタンが正常に表示される。どうしてもクラシック版を使い続ける必要がなければ、ブロック版への移行は有効な回避策になる。
Stripeアカウントの再接続だけでは直らない場合はどうするか
再接続で直らない場合は、WooCommerceのStripe設定画面でExpress Checkoutボタンの表示オプションを一度すべてオフにして保存し、再度オンにして保存する。これでプラグインの設定値がリフレッシュされ、クラシックページ用のフックが再登録されることがある。
ログに出るホスト型決済方法設定のエラーは無視してよいか
無視しないほうがよい。ホスト型決済方法設定への切り替えエラーは、Stripe側の設定とWooCommerceプラグインの設定が同期していない状態を示している。この状態を放置すると、クラシックページでのボタン非表示だけでなく、支払い処理自体に影響が出る可能性がある。Stripeダッシュボードで決済方法設定を確認し、手動設定に切り替えることを推奨する。
スマートフォンでもボタンが表示されないのは同じ原因か
基本的には同じ原因だ。ただしスマートフォンではApple PayとGoogle Payの表示条件が端末の対応状況にも左右される。iPhoneならSafari、AndroidならChromeで、ウォレットにカードが登録されていないとボタン自体が表示されない。パソコンで表示されることを前提に原因を切り分けるほうが正確だ。
この記事のポイント
- クラシックカートとチェックアウトだけボタンが出ないのはStripeスクリプトの初期化タイミングのずれが主因
- デベロッパーツールのコンソールでJavaScriptエラーを確認する
- Stripeダッシュボードのホスト型決済方法設定を手動設定に切り替える
- ショートコードの貼付位置とWooCommerceの設定ページ指定が一致しているか確認する
- キャッシュとCDNを削除し、シークレットウィンドウで再テストする
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressでHTTPS切替後に画像やメニューが崩れる時の直し方
WordPressサイトをHTTPからHTTPSへ切り替えた直後に、メニューが反応しない、画像ギャラリーが表示されない、ページレイアウトが崩れるといった症状が出る場合は、データベース内に残った「http」形式のURLが原因だ。Better Search Replaceというプラグインで旧URLを一括置換し、ElementorのCSSを再生成すれば解消できる。
なぜHTTPS切替後にサイト表示が崩れるのか
HTTPSへ切り替えただけでは、WordPressのデータベースに保存された古いURLは自動的に更新されない。投稿本文やメタ情報、ウィジェット設定、ElementorのCSSファイル内に「http」形式のURLが残ったままになるためだ。
ブラウザはHTTPSページの中にHTTPの画像やスクリプトが混在している状態を「混合コンテンツ」と呼び、セキュリティ上の理由で読み込みをブロックする。この結果、画像が途中で消える、メニュークリックが反応しない、ギャラリーのスライドが止まるといった症状が起きる。
HTTPとHTTPSが混在するとブラウザがリソースをブロックする仕組みのデモ。
Better Search Replaceでデータベースを一括置換する手順
壊れたURLを手作業で直す必要はない。Better Search Replaceという無料プラグインを使えば、データベース内のすべての「http」形式のURLを「https」形式に一括で置換できる。事前に必ずバックアップを取っておくこと。
Better Search ReplaceによるURL置換の全体の流れのデモ。
バックアップが最優先だ
置換操作はデータベース全体に影響を与えるため、失敗すると復旧が難しくなる。必ずプラグインやサーバー側のバックアップ機能で、データベースとファイルの両方を取得してから作業する。
検索と置換のURL指定を間違えない
検索フィールドには「http、自サイトのドメイン」、置換フィールドには「https、自サイトのドメイン」を入力する。ドメインの前後やスラッシュの有無を間違えると置換が正しく行われないため、コピーアンドペーストで正確に入力するのが安全だ。
置換後の確認ポイント
置換が完了したら、ブラウザのシークレットモードでサイトを開き、画像やメニューが正常に表示されるか確認する。管理画面の「設定 → 一般」に記載されたURLもHTTPSになっているか合わせてチェックする。
WordPress設定とElementorを修復する手順
データベースの置換後も、WordPressの「一般設定」に記載されたサイトURLとWordPress URLが正しいHTTPS形式になっているか確認する必要がある。管理画面にログインできる場合は、設定画面から変更するだけでよい。
管理画面に入れなくなった場合はphpMyAdminから修正する
URLを誤って書き換えてログインできなくなった場合は、サーバーの管理画面からphpMyAdminを開き、wp_optionsテーブルの「siteurl」と「home」の2つの値を正しいHTTPSのURLに戻す。これでWordPressに再ログインできる。
ElementorのCSSを再生成する
ElementorはCSSを自動生成して保存しているため、URL変更後はこのCSSが古いHTTPのURLを参照したままになることがある。Elementorの設定画面から「CSSを再生成」を実行し、合わせて「Elementorのデフォルト設定を更新」も確認する。
ElementorのCSS再生成の手順と修復後の状態のデモ。
置換しても直らない場合の追加対策
一括置換後にキャッシュやサーバー設定が原因で症状が残ることがある。順番に確認していくことで、残りの問題を特定できる。
ブラウザのデベロッパーツールで混合コンテンツを探す
ChromeやEdgeのデベロッパーツール（F12）を開き、コンソールタブを確認する。「Mixed Content」という警告が出ていれば、まだHTTPのURLが残っている。該当するURLをメモし、Better Search Replaceで追加の置換をかける。
キャッシュ系プラグインとサーバーキャッシュを削除する
キャッシュプラグイン（WP Super CacheやW3 Total Cacheなど）が古いHTTPのページを保存していると、データベースを置換しても表示が変わらない。プラグインの設定からキャッシュを全削除し、あわせてサーバー側のキャッシュも管理画面からクリアする。
htaccessでHTTPをHTTPSへリダイレクトする
WordPressサイトのルートにあるhtaccessファイルに、HTTPアクセスをHTTPSへリダイレクトする設定を追加する。これにより、古いHTTPのURLにアクセスしても自動的にHTTPSへ転送され、検索エンジン評価の分散も防げる。不安であればサーバー会社のサポートに設定を依頼してもよい。
よくある質問
Really Simple SSLプラグインでは直らないのか
Really Simple SSLはHTTPSへのリダイレクトと、管理画面のURL更新を自動で行うプラグインだ。ただし、データベース内のすべてのHTTP URLを置換する機能は制限版では一部に限られる。画像やElementorのCSSに残るURLを完全に直すには、Better Search Replaceによる一括置換が必要になる。
置換後にログインできなくなったらどうするか
URL設定を誤るとログアウトして再ログインできなくなることがある。その場合はphpMyAdminからwp_optionsテーブルの「siteurl」と「home」を正しいHTTPSのURLに戻す。これで管理画面に再アクセスできる。
置換しても一部の画像が表示されない場合は
置換後の画像不表示は、キャッシュが古いHTTPのページを返しているか、CDNや外部サービスが元のURLを参照している可能性がある。キャッシュを全削除し、CDNを利用している場合はCDN側のキャッシュもクリアする。
HTTPS化後のSEOへの影響はあるのか
HTTPS化はGoogleのランキングシグナルとして評価されるため、正しくリダイレクトを設定すればSEOにはプラスに働く。サイト側でHTTPとHTTPSが両方アクセスできる状態を放置すると評価が分散するため、リダイレクト設定まで済ませておく。
Elementorで編集画面が真っ白になった場合は
URL変更後にElementorの編集画面が読み込めない場合は、CSS再生成とあわせて「Elementorのデフォルト設定を更新」を実行する。さらにWordPressのパーマリンク設定を一度「保存」して書き換えることで、内部リンク構造がリフレッシュされる。
この記事のポイント
- HTTPS切替後もデータベースにHTTPのURLが残り、混合コンテンツとしてブロックされる
- Better Search Replaceでhttpからhttpsへ一括置換する
- 置換前に必ずフルバックアップを取る
- ElementorはCSS再生成とデフォルト設定の更新が必要
- キャッシュ削除とリダイレクト設定で仕上げる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Two-Factor 0.15.0で2FAコードが無効になる時の対処と原因
Two-Factor プラグインを 0.15.0 に更新後、認証アプリのコードが「無効な確認コード」と拒否される場合、一時的に 0.14.2 へ戻すのが最も確実な対処だ。並行してサイト環境とプラグインの互換性を確認し、根本原因を切り分ける。
なぜ 0.15.0 で 2FA コードが無効になるのか
Two-Factor 0.15.0 では認証コード検証の内部処理が見直された。その結果、特定の環境で「それまで使えていたコード」が突然拒否される症状が報告されている。すべてのサイトで起こるわけではなく、PHP バージョンや共存プラグインの組み合わせが影響する。
典型的なエラーは「ERROR: Invalid verification code.」だ。日本語環境では「無効な確認コード」と表示されることが多い。認証アプリ側の時刻ずれではないのに毎回弾かれる場合、プラグイン側の検証処理が疑わしい。
0.14.2 では問題なくログインできていたなら、ユーザーが設定した秘密鍵そのものは生きている。鍵の保存形式やハッシュ計算の互換性が 0.15.0 で崩れた可能性が高い。
このデモは、バージョン更新前後の認証結果の違いを概念的に示したイメージだ。
まず 0.14.2 に戻してログインを復旧する手順
複数ユーザーが締め出されているなら、何より先にアクセスを回復する。0.15.0 を無効化し、0.14.2 を入れ直す手順を紹介する。
管理画面に入れる場合の戻し方
管理者自身はログインできる場合、プラグイン画面から操作できる。ただし 2FA が有効なサイトでは、管理者もログイン時にコードを要求される点に注意する。
- 「プラグイン」→「インストール済みプラグイン」で Two-Factor を無効化する
- プラグインを削除する
- 「新規プラグインを追加」から Two-Factor を検索する
- バージョン 0.14.2 をダウンロードしてインストールする
バージョンを指定してインストールするには、WordPress.org のプラグインページにある「詳細」画面下部の「旧バージョンをダウンロード」から取得できる。
管理画面に入れない場合の対処
管理者も含めて誰もログインできない場合、FTP またはサーバーのファイルマネージャーからプラグインフォルダーを操作する。
- FTP で
wp-content/plugins/に接続する two-factorフォルダーを一時的にリネームする（例two-factor-old）- ログイン画面から通常のパスワードのみで入れるようになる
- その後、管理画面から 0.14.2 を再インストールする
このデモは、管理画面に入れない状態から復旧するまでの手順を示している。
ログインできた後に確認すべき環境要因
アクセスを回復したら、なぜ 0.15.0 だけが問題を起こすのかを切り分ける。同じプラグインを更新しても、環境によっては正常に動くケースがあるためだ。
PHP のバージョンと拡張
0.15.0 は PHP 8.4 系で問題が出た事例がある。一方、8.3 系で動いているサイトでは同じ更新が成功する報告もある。PHP のバージョンだけでなく、ハッシュ計算に関係する拡張機能の有無も差を生む。
レンタルサーバーの管理画面から PHP バージョンを確認し、可能なら 8.3 系へ一時的に切り替えて 0.15.0 の動作を試す。ただし、PHP を変更すると他のプラグインやテーマに影響するため、事前にバックアップを取ってから実施する。
WPML など多言語プラグインとの共存
複数ドメインで動かす WPML 構成では、認証に関係する URL やクッキーの扱いが変わる。0.15.0 でこれが悪さをした可能性も考えられる。WPML を使っているサイトで問題が再発するなら、Two-Factor と WPML の両方の設定を見直す。
認証アプリ側の時刻と再同期
「無効な確認コード」は時刻ずれでも起きる。認証アプリの「設定」から時刻の同期を行い、それでも 0.15.0 だけが通らない場合は時刻ずれではないと判断できる。
バージョン固定と更新タイミングの判断
0.14.2 で問題が起きていないなら、修正版が出るまで 0.14.2 に固定するのが実務的だ。ただし、セキュリティプラグインの古いバージョンを長期間使い続けるのは望ましくない。公式の変更履歴とサポートフォーラムを確認し、修正版が出たら速やかに更新する。
プラグインの自動更新が有効だと、意図せず再び 0.15.0 に上がる恐れがある。更新を止めるには、プラグインの自動更新設定をオフにするか、サイト全体の更新管理を見直す。
このデモは、0.15.0 を避ける運用方法と注意点を整理したものだ。
よくある質問
0.15.0 で一部のユーザーだけログインできないのはなぜ？
ユーザーごとに秘密鍵の保存形式が異なる可能性がある。古いバージョンで作成された鍵と新しい検証処理の相性が悪く、特定のユーザーだけ弾かれることがある。
0.14.2 に戻してもユーザーに再設定してもらう必要はある？
通常は必要ない。0.14.2 に戻せば、以前作成した認証情報とアプリのコードがそのまま使える。再設定を求めるのは、認証情報が壊れている場合に限られる。
認証アプリのコードが「無効な確認コード」になる他の原因は？
サーバーと端末の時刻ずれ、秘密鍵の保存不備、キャッシュによる画面の不整合などが考えられる。まず認証アプリの時刻同期を行い、その後プラグインのバージョンを確認する。
0.15.0 の修正版はいつ出る？
リリース時期は未定だ。公式のプラグインページとサポートフォーラムの更新を確認する。修正版が出るまでは 0.14.2 固定が安全だ。
この記事のポイント
- Two-Factor 0.15.0 で 2FA コードが無効になる問題が報告されている
- まず 0.14.2 に戻してログインを復旧する
- PHP バージョンや WPML など環境要因を切り分ける
- 修正版が出るまでは 0.14.2 固定と自動更新オフで運用する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている