
Wordfence 8.2.2 で前台に preg_replace() 非推奨エラーが出た時の対処
Wordfence 8.2.2 を導入した WordPress 7.0.3 のサイトで、前台ページやログイン画面に Deprecated: preg_replace() から始まる非推奨(デプリケーション)エラーが表示される場合、まず WP_DEBUG 設定を確認して本番環境でのエラー表示を抑制し、次に Wordfence 本体を最新版へ更新する のが最短の対策だ。
なぜ本番サイトの前台に非推奨エラーが表示されるのか

非推奨エラー(Deprecated 通知)は、PHP の将来のバージョンで廃止される古い書き方を使っている場合に発生する。Wordfence 8.2.2 内部のルール処理ライブラリ wf-waf が preg_replace() 関数に null を渡しており、PHP 8.1 以降でこの挙動が非推奨となったことが直接の原因だ。
本来このレベルの通知は、本番サイトでは表示されないよう WordPress が抑制する仕組みになっている。しかし 何らかの理由でデバッグモードが有効になっているか、エラー報告レベルが高く設定されている と、前台に生の PHP エラーメッセージが露出してしまう。これが今回のケースの本質的な問題だ。
さらにこのエラーが「headers already sent」という警告を誘発し、ログイン処理や Cookie 設定などの HTTP ヘッダー操作が失敗する二次被害も報告されている。前台の表示崩れや管理画面へログインできないトラブルに発展するため、早期の対応が欠かせない。
すぐに前台からエラー表示を消す応急処置

更新を待つ前に、まずは本番環境でエラーが一般人に見えている状態を解消する。手順は以下の3ステップだ。
wp-config.php で WP_DEBUG を確認・修正する
FTP クライアントやサーバーのファイルマネージャーで WordPress をインストールしたルートディレクトリにアクセスし、wp-config.php を開く。WP_DEBUG が true になっていれば、以下のように false へ変更する。
define( 'WP_DEBUG', false );開発用途でデバッグログだけは残したい場合は、WP_DEBUG_LOG と WP_DEBUG_DISPLAY を併用する。これで前台にはエラーを表示せず、ログファイルにだけ記録できる。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // /wp-content/debug.log に記録
define( 'WP_DEBUG_DISPLAY', false ); // 画面には表示しないファイルを上書き保存したら、サイトをリロードして前台からエラーメッセージが消えたか確認する。
Wordfence を最新版に更新する
この preg_replace() の非推奨問題は、Wordfence 開発チームが認識して修正に取り組んでいる可能性が高い。管理画面にアクセスできるなら「プラグイン」→「インストール済みプラグイン」で Wordfence の更新を確認し、最新版がリリースされていれば即座に適用する。
管理画面すらエラーで開けないという報告も多い。その場合は FTP で /wp-content/plugins/wordfence/ ディレクトリを一時的にリネーム(例 wordfence_old)して無効化し、管理画面へアクセスできる状態にする。管理画面に入れたら、改めて Wordfence を最新版に更新して再有効化すればよい。
キャッシュを全削除して状態を確定させる
PHP 設定やプラグインを変更しても、キャッシュが残っていると古いエラー画面が表示され続ける。以下のキャッシュを徹底的にクリアする。
- WordPress のキャッシュプラグイン(WP Rocket や W3 Total Cache など)の全キャッシュ削除
- サーバー側の OPcache や Nginx FastCGI Cache のクリア
- CDN を利用している場合は CDN のキャッシュもパージ
それでも改善しない場合の追加対応

上記の手順を実行してもエラーが消えない、あるいは管理画面にまったく入れない状況が続くなら、次の手を試す。
Wordfence を手動で最新 ZIP に上書きする
WordPress 管理画面から更新できない場合、WordPress.org の Wordfence 公式ディレクトリから最新の ZIP ファイルをダウンロードし、FTP で展開する。手順は次のとおり。
- 現在の
/wp-content/plugins/wordfence/をリネームして退避 - ダウンロードした ZIP を解凍し、
wordfenceディレクトリをアップロード - 管理画面から Wordfence を有効化し、WAF の最適化を再実行
PHP のエラー報告レベルを一時的に緩和する
レンタルサーバーのコントロールパネルや php.ini で error_reporting を E_ALL & ~E_DEPRECATED に設定すれば、非推奨通知をまとめて抑制できる。ただしこの方法は問題の先送りになるため、あくまで Wordfence 更新が間に合わない場合の緊急措置と位置づける。
別のセキュリティプラグインへ一時的に切り替える
サイトのセキュリティを完全に落とせない事情があるなら、Wordfence を無効化している間だけ、別の軽量ファイアウォール系プラグインで防御を維持する手もある。ただし切り替えの手間と、切り戻し時に設定がリセットされる可能性は考慮が必要だ。
よくある質問
Wordfence を無効化したまま運用しても大丈夫か
無効化中はファイアウォールとマルウェアスキャンがすべて停止するため、できるだけ数時間以内に最新版へ更新して再開するのが望ましい。どうしても長引く場合は、サーバー側の WAF 機能や .htaccess によるアクセス制限で最低限の防御を維持する。
PHP バージョンを下げればこのエラーは消えるのか
PHP 7.4 など古いバージョンに戻せば preg_replace() の非推奨警告は出なくなるが、PHP 本体のセキュリティサポートが切れているバージョンを使うことは推奨しない。Wordfence の更新で根本対応し、PHP は 8.1 以降のサポート対象バージョンを維持するのが安全な選択だ。
他のプラグインで同様の Deprecated エラーが出た場合の対処は
まず該当プラグインが最新版かを確認する。最新で出るなら、開発元のサポートフォーラムに PHP バージョンとエラー全文を添えて報告する。本番環境では WP_DEBUG_DISPLAY を false にしつつ WP_DEBUG_LOG で記録を取る運用が基本だ。
Wordfence の代わりになる無料プラグインはあるか
無料で総合的な防御を提供する代替としては、Solid Security(旧 iThemes Security)や Sucuri Security が挙げられる。ただし機能や設定項目が異なるため、移行前に必ずテスト環境で動作検証を済ませる必要がある。
この記事のポイント
- 前台に PHP 非推奨エラーが出る原因は WP_DEBUG 設定とプラグインの対応遅れ
- まず wp-config.php で WP_DEBUG を false または WP_DEBUG_DISPLAY false にする
- Wordfence を最新版に更新すれば preg_replace() 問題は解消に向かう
- 管理画面に入れない場合は FTP でプラグインをリネームして緊急アクセスを確保する
- PHP のエラー報告レベル操作はあくまで緊急避難であり恒久対応ではない

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WooCommerce更新後に注文編集ができない場合の権限設定と解決手順
WooCommerce のアップデート後に、注文の編集やステータス変更ができなくなった場合は、該当するユーザーロールに WordPress の基本的な権限である edit_posts を割り当てることで解決する。WooCommerce 9系と HPOS の組み合わせでは、カスタム権限だけでは注文管理画面を表示できなくなる仕様変更が起きている。
WooCommerce アップデート後に注文を編集できなくなった原因

WooCommerce 10.9.4 以降、特に HPOS(高パフォーマンス注文ストレージ)を有効にし、互換性モードを無効化している環境でこの問題が発生しやすい。これまでは edit_shop_order や edit_others_shop_orders といった WooCommerce 固有の権限だけで注文管理ができていた。だが、内部的な権限チェックが強化され、注文画面を表示するために汎用的な edit_posts 権限も必須になった。
この変更は、WordPress のコア機能と WooCommerce の注文データの整合性を高めるためのものだ。「このサイトで重大なエラーが発生しました」といったメッセージではなく、単に「権限がありません」と表示されたり、注文一覧ページ自体が空欄になるといった症状が現れる。PublishPress Capabilities や User Role Editor などのプラグインで、注文管理だけに特化したカスタムロールを作成している場合に特に影響を受ける。
– edit_shop_order
– edit_others_shop_orders
– edit_posts なし
– edit_shop_order
– edit_others_shop_orders
– edit_posts(新たに追加)
edit_posts 権限を追加して問題を解決する具体的な手順

解決策はシンプルだ。注文管理を担当するユーザーロールに edit_posts 権限を付与する。この操作によって、注文以外の「投稿」や「固定ページ」へのアクセス権も与えたくない場合は、後続の「より厳密な権限制御を行うための注意点」のセクションで紹介する追加の調整が必要になる。
現在のユーザーロールの権限を確認する
まず、どのロールに問題が起きているのかを特定する。ユーザーが複数のロールを持っている場合、権限は加算される仕組みだ。管理者権限で問題が起きている場合は、プラグインの競合など別の原因を疑う必要がある。
PublishPress Capabilities の無料版を使っていれば、管理画面の「Capabilities」メニューから各ロールの権限一覧を確認できる。画面上部の「Select Role to View / Edit」ドロップダウンで、問題のロールを選択し、権限の一覧を表示させよう。
edit_posts 権限を該当ロールに割り当てる
権限の一覧画面で「Core」タブを開き、「Posts」セクションを探す。その中にある「edit_posts」のチェックボックスにチェックを入れ、画面下部の「変更を保存」ボタンをクリックする。これで、指定したロールに汎用的な投稿編集権限が付与され、WooCommerce の注文画面にもアクセスできるようになる。
User Role Editor を使っている場合も手順はほぼ同じだ。管理画面の「ユーザー」→「User Role Editor」を開き、対象ロールを選択して、権限リストから「posts」をフィルタリングし、「edit_posts」にチェックを入れて保存する。
より厳密な権限制御を行うための注意点

edit_posts を付与すると、デフォルトでは「投稿」と「固定ページ」の編集画面にもアクセスできるようになる。これは、WordPress の権限システムが投稿タイプごとに細かく権限を分けていないことに起因する。注文だけを管理させたいロールには、これは望ましい状態ではないだろう。
投稿や固定ページへのアクセスを制限するには、別の方法で管理画面メニューを非表示にする必要がある。よく使われるのは「Admin Menu Editor」プラグインだ。このプラグインを使えば、特定のユーザーロールに対して不要なメニュー(投稿、固定ページ、コメントなど)を非表示にできる。メニューを隠すだけでは直接URLを入力されるとアクセスできてしまうため、完全にブロックしたい場合は、current_user_can() 関数を使ったカスタムコードを functions.php に追加する方法もある。
よくある質問
管理者権限でも注文を編集できなくなった場合はどうするのか
管理者はデフォルトで edit_posts を含むすべての権限を持っているため、今回の原因とは別の問題だ。まずはすべてのプラグインを停止し、テーマをデフォルトに戻して競合の有無を確認する。HPOS 互換モードを一時的に再有効化して症状が改善するかもテストする価値がある。
edit_posts を追加してもアクセスできない場合は他に何を確認すべきか
WooCommerce の注文には、edit_shop_orders や view_admin_dashboard といった権限も必要になる。後者が不足していると、管理画面自体へのアクセスが制限される可能性がある。また、キャッシュ系プラグインやセキュリティプラグインが権限チェックに干渉しているケースもあるため、これらの設定も見直す。
HPOS の互換モードを再有効化すれば解決するのか
一時的な回避策としては機能する可能性が高い。しかし、HPOS の互換モードは将来的に廃止される予定の過渡的な機能だ。根本解決のためには、ここまでに説明した権限の適切な設定を行い、HPOS を有効化した状態で動作させることが推奨される。
コードを使って権限を自動付与する方法はあるか
特定のロールに対してテーマやプラグインの有効化時に権限を追加したい場合、WP_Role クラスの add_cap() メソッドを使う。たとえば、functions.php やカスタムプラグイン内で、get_role('shop_manager')->add_cap('edit_posts') のように記述する。このコードは一度だけ実行すればよいが、権限の変更を明確にするために、プラグインのアクティベーションフックで実行することが望ましい。
この記事のポイント
- WooCommerce の更新後、注文の編集ができない原因は
edit_posts権限の不足にある - 権限管理プラグインで該当ロールに
edit_postsを割り当てるだけで問題は解決する - 不要な投稿画面へのアクセスは、Admin Menu Editor などのプラグインで個別に制限する必要がある
- 管理者権限での同様の症状は、プラグイン競合といった別の原因を疑う
- HPOS 互換モードの再有効化は一時しのぎに過ぎず、権限設定による根本解決が推奨される

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

ShopMagicで重複カラムエラーが出る原因とデータベース接頭辞の修正
ShopMagic 4.8.6以前のバージョンで、データベースアップグレード中に「カラムが重複しています(Duplicate column name ‘note_context’)」というエラーが発生する場合、原因はプラグイン内部のマイグレーションファイルでテーブル接頭辞が wp_ に固定されていることだ。バージョン4.8.7へのアップデートで修正されるが、すぐにアップデートできない場合は、データベースのオプション値を直接編集する緊急回避策でエラーを止められる。
なぜShopMagicで重複カラムエラーが発生するのか

ShopMagicには、プラグインが更新されるたびにデータベースのテーブル構造を自動調整する「マイグレーション」機能が備わっている。今回の問題は、マイグレーションファイル Version_42.php の17行目付近で発生する。このファイルは、note_context というカラムが既に存在するかどうかを確認するために SHOW COLUMNS クエリを実行するが、その際に対象テーブルを wp_shopmagic_automation_outcome_logs と決め打ちしてしまっている。
サイトのデータベース接頭辞(wp-config.php の $table_prefix)がデフォルトの wp_ であれば問題は出ない。しかし、セキュリティや複数サイト運用の都合で接頭辞を abc123_ などに変更している場合、wp_shopmagic_automation_outcome_logs というテーブルは存在しないため、SHOW COLUMNS が失敗する。その結果、プラグインは「カラムが存在しない」と誤認し、note_context を追加しようとする。しかし実際には正しい接頭辞のテーブルに既に存在するため、ALTER TABLE が「カラムが重複しています」というエラーで失敗する。
さらに深刻なのは、このエラーによってマイグレーションチェーン全体が止まってしまう点だ。Version 42が失敗として記録されないため、後続のVersion 43から48のマイグレーションがいっさい実行されない。これにより、マーケティングリストやトラッキングメール関連のテーブルが不足し、気付かないうちに一部機能が不完全になる可能性がある。また、エラーはページが読み込まれるたびに繰り返し発生し、デバッグログを大量に汚染する。
データベースエラーを解消するアップデート手順
根本的な解決策は、ShopMagicをバージョン4.8.7以降にアップデートすることだ。このバージョンでは、マイグレーションファイル内のハードコードされた wp_ が削除され、動的に正しいテーブル接頭辞を参照するように修正されている。
管理画面から自動アップデートする
WordPress管理画面の「プラグイン」→「インストール済みプラグイン」で、ShopMagicに利用可能なアップデートが表示されていれば、「今すぐ更新」をクリックする。アップデート後、データベースのアップグレードが正常に走り、エラー通知が消えていることを確認する。
手動でアップデートする
自動アップデートが利用できない場合は、公式リポジトリまたは有料版の提供元から最新のZIPファイルをダウンロードし、管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から上書きインストールする。既存の設定やデータが失われることはないが、不安な場合は事前にサイト全体のバックアップを取得しておく。
アップデートできない場合の緊急回避策

何らかの理由ですぐにプラグインをアップデートできない場合、データベースのオプション値を直接書き換えることでエラーの無限ループを止められる。この方法は、マイグレーションVersion 42が「未完了」として記録されているために毎回実行される状態を、「完了」とマークするものだ。Version 42が実際に行うべきテーブル変更(カラム追加)はエラーを起こしながらも既に成功しているため、安全性は高い。
wp_options テーブルを開く(接頭辞は環境に合わせる)option_name が shopmagic_db の行を探し、編集するoption_value を WPDesk\ShopMagic\migrations\Version_42 に変更して保存するWPDesk\ShopMagic\migrations\Version_42 とシングルバックスラッシュで入力する。保存後に LENGTH(option_value) が38(35ではない)であることを確認すれば、正しく保存されている。変更を保存して管理画面を再度読み込むと、ShopMagicはVersion 42のマイグレーションが完了したと認識し、続けてVersion 43から48の未実行マイグレーションを順次処理する。これにより、不足していたテーブルが自動的に作成され、エラー通知も消える。なお、マイグレーション44では既存のオプトインメールデータを作成済みのマーケティングリストテーブルにコピーする処理が含まれるため、データ量によってはページの読み込みに時間がかかることがある。
よくある質問
エラーが解消された後、不足していたテーブルは自動的に作られるのか
アップデートまたはオプション値の書き換え後、ページを読み込んだタイミングで自動的に不足テーブルが作成される。Version 43から48のマイグレーションが順次実行され、マーケティングリストテーブルやトラッキングメールテーブルなどが生成される。特別な操作は不要だ。
データベース接頭辞をデフォルトのwp_に変更すれば直るのか
接頭辞の変更はサイト全体に影響を与える大掛かりな作業であり、推奨しない。テーブル名の一括置換やwp-config.phpの編集、シリアライズ化データの再計算などが必要になる。このエラーはプラグイン側の問題であり、ShopMagicをアップデートするだけで解決するため、そちらを優先する。
この問題はShopMagic以外のプラグインでも起きるのか
プラグインが内部でデータベース接頭辞をwp_に決め打ちしている場合、全く同じメカニズムでエラーが発生する。ただし、多くのプラグインはWordPressの$wpdb->prefixを用いて動的に接頭辞を取得するため、一般的な問題ではない。カスタム接頭辞を使用しているサイトで特定のプラグインだけがエラーを起こす場合、同様のハードコードが原因である可能性を疑うとよい。
phpMyAdminから直接オプション値を変更するのが不安だ
WP-CLIが利用できる環境であれば、wp option update shopmagic_db 'WPDesk\ShopMagic\migrations\Version_42' --format=plain というコマンドで安全に同じ変更が行える。phpMyAdminを使う場合でも、該当行の編集後すぐに管理画面を開き、エラー通知が消えたことを確認すれば問題ない。
この記事のポイント
- エラーの直接原因は、マイグレーションファイル内でテーブル接頭辞が
wp_に固定されていること - カスタム接頭辞を使うサイトでは、毎回のページ読み込みでエラーが繰り返される
- ShopMagicをバージョン4.8.7以降にアップデートすれば根本解決する
- アップデートできない場合、
shopmagic_dbオプションを手動で進める緊急回避策がある - 回避策を取ったあと、後続のマイグレーションが自動実行され不足テーブルも作成される

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WordPressで「Duplicate entry」データベースエラーが出た時の原因と直し方
プラグイン更新後に debug.log へ「WordPress database error Duplicate entry」が大量出力される問題は、テーブルに一意キーを追加する際、既存データに空の値や重複が存在するために起きている。このエラーそのものはサイトの表示を直ちに壊すわけではないが、ログファイルが急激に肥大化してサーバーのディスク容量を圧迫するため、早期の対処が必要だ。
なぜこのエラーが発生するのか

プラグインのバージョンアップで、データベースのテーブル構造(スキーマ)が変更されることがある。今回のように wp_blc_links テーブルに url_hash カラムを追加し、さらにそのカラムへ UNIQUE KEY(一意キー制約)を設定しようとした場合、既存のレコードの中に同一のハッシュ値が重複していると「Duplicate entry」エラーが発生する。
とりわけ問題になるのが、ハッシュ値が空文字列(空の値)のまま残っているレコードだ。空文字列どうしも「同じ値」とみなされるため、一意キー制約に違反してエラーとなる。これは Broken Link Checker に限らず、データベースのスキーマ変更をともなうあらゆるプラグインで起こりうる。
エラーメッセージの後半に「for key 'wp_blc_links.url_hash'」と表示されているなら、url_hash 列の重複が原因と特定できる。この情報を手がかりに、次の対処へ進む。
まずはログの肥大化を止める

このエラーはサイトの表示に影響を与えないケースが多いが、放置すると debug.log が一晩で数百 MB に膨れ上がる。ディスク容量が尽きればサイト全体が停止するため、真っ先にログ出力を食い止める必要がある。
プラグインを前のバージョンに戻す
最も確実なのは、問題が発生しなかった旧バージョンへ差し戻す方法だ。プラグインの公式ページにある「以前のバージョン」セクションからダウンロードし、手動でアップロードして上書きする。WordPress 管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP ファイルを指定すればよい。
プラグインを一時的に無効化する
旧バージョンの入手が難しい場合や、そもそもこのプラグインがサイト運営に必須でなければ、無効化するだけでログ出力は止まる。「プラグイン」→「インストール済みプラグイン」から該当プラグインを無効化するだけだ。無効化しても、これまでに収集されたリンク切れのデータはデータベースに残るため、後で有効化すれば以前の状態から再開できる。
→ 数時間で数百 MB に肥大化
→ ログファイルは正常サイズを維持
上図は、プラグインのバージョンを戻すか無効化する前後でのログ出力の変化を表している。どちらの方法でも、エラーの無限出力はすぐに止められる。
データベースの重複を手動で修正する

プラグインの新バージョンを使い続けたい場合や、修正パッチのリリースを待たずに根本解決したい場合は、データベースを直接操作して重複レコードを削除する方法がある。ただし、操作を誤るとサイト全体に影響が出るため、必ず事前にデータベースのバックアップを取得しておく。
phpMyAdmin から重複行を特定して削除する
レンタルサーバーの管理画面から phpMyAdmin を開き、該当の WordPress データベースを選択する。wp_blc_links テーブル(接頭辞は環境により異なる)を表示し、「SQL」タブで次のクエリを実行すると、url_hash が空のレコードと重複しているレコードを確認できる。
SELECT url_hash, COUNT(*)
FROM wp_blc_links
GROUP BY url_hash
HAVING COUNT(*) > 1;このクエリで表示される行が、一意キー制約に違反する重複レコードだ。続けて、重複しているレコードのうち不要なものを削除する。url_hash が空文字列のレコードをすべて削除してしまえば、多くのケースでエラーは解消する。
DELETE FROM wp_blc_links WHERE url_hash = '';削除後、プラグインを最新バージョンにアップデートするか、一度無効化してから再度有効化すれば、テーブルのスキーマ変更が正常に完了する。エラーログへの出力も止まるはずだ。
WP-CLI が使える環境での対処
サーバーに SSH 接続でき、WP-CLI がインストールされているなら、コマンドラインからより安全に操作できる。まずは重複を確認する。
wp db query "SELECT url_hash, COUNT(*) FROM wp_blc_links GROUP BY url_hash HAVING COUNT(*) > 1;"問題が確認できたら、同様に空ハッシュのレコードを削除する。
wp db query "DELETE FROM wp_blc_links WHERE url_hash = '';"操作後はプラグインを再有効化し、debug.log からエラーが消えたことを確認する。WP-CLI を使う最大の利点は、誤って操作しても wp db export で事前にバックアップを取りやすく、復旧が容易な点だ。
再発防止と注意点

プラグインのアップデートは自動更新に任せず、可能であればステージング環境で事前にテストする運用が望ましい。とくにデータベースのスキーマ変更をともなうアップデート(変更履歴に「database」「schema」「table」「column」といった単語が見られるもの)は要注意だ。
また、debug.log が常に有効になっている環境では、定期的にログファイルのサイズを確認し、不要になったら削除する習慣をつけておくと、ディスク容量の急激な枯渇を防げる。wp-config.php で WP_DEBUG_LOG を true にしている場合は、開発やトラブル解決時以外は false に戻しておくのも有効な対策だ。
よくある質問
重複レコードを削除してもプラグインの機能に影響はないのか
空のハッシュ値を持つレコードは、もともと正常にリンクチェックが機能していないデータだ。削除しても、プラグインは次回のクロール時に改めてリンクを検査して正しいハッシュ値を再生成するため、実害はない。むしろ重複が解消されることで、後続のアップデートも正常に完了するようになる。
このエラーを放置するとどうなるのか
エラーそのものはサイトのフロントエンド表示に影響しない場合が多いが、debug.log がサーバーのディスク容量を圧迫し、最悪の場合「ディスクフル」でサイト全体がダウンする。また、プラグインのスキーマ変更が完了しないため、以降のアップデートが正常に適用されず、プラグインの一部機能が動作しない状態が続く可能性もある。
Broken Link Checker 以外のプラグインでも同じエラーは起こるのか
起こる。UNIQUE KEY を追加するデータベーススキーマの変更を行うプラグインであれば、同種のエラーが発生しうる。SEO プラグインやセキュリティプラグインの大規模アップデートでも見られるため、エラーメッセージに表示されるテーブル名とカラム名を手がかりにして、同じ手順で対処できる。
phpMyAdmin を使えない場合はどうすればよいか
「WP Data Access」や「Advanced Database Cleaner」のようなデータベース操作ができるプラグインを一時的にインストールして、SQL クエリを実行する方法がある。あるいは、サーバー会社のサポートに依頼して重複レコードの削除を代行してもらうのも一つの手だ。
修正パッチがリリースされるまでのつなぎ対策は
プラグインを旧バージョンに固定し、WordPress 管理画面の「プラグイン」→「インストール済みプラグイン」で該当プラグインの自動更新をオフにしておく。公式の変更履歴を定期的にチェックし、修正が含まれたバージョンがリリースされたら手動でアップデートすればよい。
この記事のポイント
- 「Duplicate entry」エラーは、一意キー制約の追加時に既存データの重複が原因で発生する
- 緊急対応として、プラグインを旧バージョンに戻すか一時的に無効化する
- データベースから重複レコードを削除すれば、最新バージョンでも正常動作する
- 事前のバックアップ取得と、ステージング環境でのテストが再発防止に有効

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WooCommerceチェックアウトでPayPalボタンが表示されない原因と修正手順
独自テーマを使った WooCommerce サイトのチェックアウトページで PayPal ボタンが表示されない場合、主な原因は DOM の準備完了前に async で読み込まれた JavaScript がコンテナ要素を取得できずに失敗することだ。また、PayPal JS SDK の読み込み完了後に buttons メソッドが存在しない問題は、コンストラクタの引数順序の誤りやスクリプトの初期化タイミングの競合で発生する。これらの問題を順に切り分けて修正すれば、数分でボタンが復活する。
PayPalボタンが表示されない原因を特定する

まずコンソールに出力されているエラーを把握する。大半のケースで、Error: Document is ready and element #paypal-button-container does not exist(日本語環境では同様のエラーメッセージが英語で表示される)という致命的なエラーが記録されている。これは PayPal JS SDK が #paypal-button-container という要素を DOM から見つけられず、ボタンの描画を中止したことを意味する。同時に、スクリプトがチェックアウトページではなく商品カテゴリページで動作してしまう現象や、CORS(クロスオリジンリクエスト)がブロックされたというエラーも散見される。
以下のフローで問題を切り分けると、原因に早くたどり着ける。
#paypal-button-container が実在するか確認するconsole.log でオブジェクトを確認するinit() 後の this.paypal.buttons が undefined でないか検証するこの4つのチェックポイントをもとに、次のセクションで具体的な修正を加えていく。
async読み込みによるDOM参照の競合を解決する

WordPress 7.0 では、wp_enqueue_script に 'strategy' => 'async' を指定すると、スクリプトが非同期で読み込まれる。この設定自体は高速化に有効だが、DOM の構築が完了する前に document.querySelector('#paypal-button-container') が実行されると、要素がまだ存在しないために null が返ってしまう。
解決策はシンプルだ。PayPal ボタンの初期化処理全体を DOMContentLoaded イベントの中に包み、DOM の準備完了を待つ。具体的には index.js の setupPayment() を次のように修正する。
document.addEventListener('DOMContentLoaded', async function() {
const paypalManager = new PayPalManager(
clientIdHere,
'.checkoutForm',
'#paypal-button-container',
orderEndPoint,
emailEndPoint
);
await paypalManager.init();
await paypalManager.renderButtons(paypalManager.buttonContainer);
});こうすれば、DOMContentLoaded が発火した時点でコンテナ要素が確実に存在するため、null エラーが解消する。なお、async ストラテジーはそのままでも問題ないが、より確実な制御を求めるなら defer に切り替えてもよい。ただし defer も DOM 構築の完了前に実行される可能性があるため、イベントリスナーを組み合わせるのが最も安全だ。
コンストラクタの引数順序と初期化タイミングを修正する

コンソールに出力されたオブジェクトを見ると、buttonContainer が null、orderEndPoint と emailEndPoint の値が意図したものと逆になっているケースが多い。これは PayPalManager のコンストラクタを呼び出す際の引数の順序がずれているか、引数が不足しているときに起こる。
典型的なミスは、最初の引数(clientId)を空にしてしまったり、セレクタ文字列を間違った順番で渡してしまうことだ。次のように constructor と new の呼び出し側を一致させる必要がある。
// paypal_manager.js の constructor 定義(本来の正しい順序の例)
constructor(clientId, formSelector, containerSelector, orderEndPoint, emailEndPoint) {
this.clientId = clientId;
this.formSelector = formSelector;
this.containerSelector = containerSelector;
this.buttonContainer = null;
this.orderEndPoint = orderEndPoint;
this.emailEndPoint = emailEndPoint;
this.paypal = null;
}// index.js でのインスタンス化(すべての引数を順序通りに正しく与える)
const paypalManager = new PayPalManager(
'your-client-id', // clientId
'.checkoutForm', // formSelector
'#paypal-button-container',// containerSelector
'https://api-m.sandbox.paypal.com/v2/checkout/orders', // orderEndPoint
'/wp-json/auto-parts/v3/send_order_email' // emailEndPoint
);このコードのように引数を明示的に記述すれば、プロパティの食い違いが一掃される。また、init() 内で this.paypal.buttons が undefined になる問題は、loadScript() の完了を await で待つ処理が正しく記述されていれば解決する。paypal-js パッケージの loadScript は Promise を返すので、必ず await loadScript(...) の形で使う。
チェックアウトページにだけスクリプトを読み込む方法

症状のひとつに「スクリプトが商品カテゴリページでは動くのにチェックアウトページで動かない」という現象があった。これは wp_enqueue_scripts フックがすべてのページで実行されるために、意図しないページで PayPal のコードが動き出し、逆にチェックアウトページでは何らかの理由でコンテナが存在したにもかかわらず失敗していることを示す。
第一に、スクリプトの読み込みをチェックアウトページに限定する。WordPress の条件分岐タグ is_checkout() を使い、functions.php を次のように変更する。
function mainModules() {
if ( is_checkout() && ! is_order_received_page() ) {
wp_enqueue_script(
'paypal-checkout',
get_theme_file_uri('/build/index.js'),
array(),
'1.0.0',
array( 'strategy' => 'async' )
);
}
}
add_action('wp_enqueue_scripts', 'mainModules');この条件を追加すれば、商品一覧やカテゴリページで PayPal 関連の JavaScript エラーがコンソールに表示されなくなり、意図したページだけが初期化を行う。また、キャッシュプラグインが原因で古いスクリプトが配信されている可能性があるため、修正後にキャッシュをクリアすることも忘れずに行う。
CORSエラーの対処と無視できる場合

コンソールに記録される Cross-Origin Request Blocked エラーは、PayPal のロガー API(https://www.sandbox.paypal.com/xoplatform/logger/api/logger)へ送信されるリクエストがオリジン間制限に引っかかったものだ。このエラーは、PayPal ボタンの描画が失敗した後に二次的に発生するケースがほとんどで、サイトの主要機能には影響しない。
ボタンが正しく表示されるようになれば、多くの場合この CORS エラーは自然に消える。もし修正後も CORS エラーが出続けるなら、PayPal の Sandbox アプリケーション設定で許可されたオリジンに本番ドメインが登録されているか確認する。通常は無視して問題ないが、セキュリティ上の懸念がある場合は、PayPal のビジネスサポートにオリジン制限の解除を依頼できる。
よくある質問
asyncとdeferのどちらを選ぶべきか
両者とも非同期読み込みだが、defer は HTML のパース完了後に実行順序を保ちながら実行される。PayPal ボタンのような DOM 操作が絡むスクリプトは、defer と DOMContentLoaded の組み合わせが扱いやすい。ただし、パフォーマンスを優先するなら async のままイベントリスナーで制御する形で問題ない。
PayPal SDK の読み込みに時間がかかる場合の改善策
@paypal/paypal-js の loadScript は PayPal の CDN からスクリプトを取得する。自前でキャッシュすることは難しいが、async 読み込みによってページ全体のレンダリングをブロックしないようにできる。どうしても速度が遅い場合は、チェックアウトページ遷移時にローディングスピナーを表示し、init() が完了するまでユーザーに待機を伝える UI を実装するとよい。
コンソールのCORSエラーを完全に消す方法はあるか
PayPal 側のロガーAPIのオリジンを制御することはできないため、完全に消すことは難しい。実害がないため無視するのが一般的だ。もしどうしても気になる場合は、エラーハンドリングで該当のリクエストをキャッチして無視するか、PayPal のサポートに問い合わせてロガー機能を無効化できないか相談する。
WordPressのバージョンが7.0でなくてもこの問題は起きるか
async ストラテジーは WordPress 6.6 以降で導入されたため、それ以前のバージョンでは異なる方法で非同期読み込みを行っている可能性がある。しかし、DOM の準備完了前に要素を取得できない問題は、wp_enqueue_script の設定にかかわらず生じるため、同じ修正が有効だ。
子テーマで上書きする場合の注意点
親テーマの functions.php で定義された wp_enqueue_scripts フックを子テーマで解除するには、remove_action を使うか、子テーマ側のフックで wp_dequeue_script を使って親のスクリプトを外した後、新たに読み込む。ペイパルマネージャーの JavaScript ファイルは通常、テーマのビルドフォルダにあるため、ファイル自体を子テーマにコピーして上書きする方法が確実だ。
この記事のポイント
- PayPalボタンが表示されない根本原因は、DOMの準備完了前にスクリプトがコンテナ要素を取得できないこと
- async読み込みの対策として、DOMContentLoadedイベントの内側で初期化を行う
- コンストラクタ引数の順序ずれで、buttonContainerがnullになったりエンドポイントが入れ替わる
- is_checkout() 条件を使ってチェックアウトページにだけスクリプトを読み込む
- 二次的に発生するCORSエラーはボタン描画が成功すれば消えることが多く、実害がなければ無視できる

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WordPressで投稿が突然崩れる原因と直し方(HTMLが壊れる場合の対処)
WordPressで投稿を更新した直後や新規投稿を公開した際に、レイアウトが崩れたりHTMLタグがむき出しで表示される場合、原因の大半はビジュアルエディタとテーマ・プラグインの競合、または外部からのHTMLコード貼り付け時に生じた不正なタグの混入だ。自動整形機能(wpautop)の誤作動が引き金になるケースも多い。本記事では、投稿が崩れる代表的な原因を整理し、投稿を元どおりに戻す手順を具体的に示す。
投稿のHTMLが崩れる原因はどこにあるのか

WordPressの投稿が崩れる場合、問題は大きく3つのレイヤーに分かれる。エディタ内部での表示崩れ、データベースに保存される時点での変換ミス、そしてフロントエンドでレンダリングされる際のテーマやプラグインの干渉だ。
WordやGoogleドキュメント、他のCMSからコピーしたテキストには、不要なスタイル指定や不正なHTMLタグが混入している。WordPressのエディタがこれらを正しく処理できず、表示が崩れる。
WordPressは本文の改行を自動で<p>タグや<br>タグに変換する。この機能がカスタムHTMLやショートコードと衝突し、不要なタグを挿入してレイアウトを破壊することが多い。
使用中のテーマやプラグインが、WordPressの標準機能であるTinyMCEエディタやブロックエディタの動作を妨害している。特定のプラグインがJavaScriptエラーを起こし、エディタの表示や保存処理が不完全になる。
実際のトラブルでは、これらの要因が複合的に絡み合っている。投稿が完全に壊れてしまう前に、まずはどのレイヤーで破損が起きているのかを段階的に絞り込む必要がある。
テキストエディタでHTMLを直接確認し修復する手順

最初に試すべきは、WordPress標準の「テキスト」エディタ(クラシックエディタ利用時)またはブロックエディタの「コードエディタ」モードを使って、投稿に含まれるHTMLを直接目視することだ。不正なタグやスタイル指定が混入していれば、この段階で発見できる。
<span style=”font-size: 12pt; font-family: ‘MS Gothic’;”><span lang=”EN-US”>テキストが</span></span><span lang=”EN-US”>途中で切れる</span>
<p>テキストが途中で切れずに表示される</p>
管理画面の投稿編集画面を開き、画面右上の「オプション」(縦三点リーダー)から「コードエディター」を選択する。クラシックエディタの場合は「テキスト」タブをクリックする。ここで表示されるHTMLソースに、意図しない<span>タグやインラインスタイル、閉じタグの不足がないかを確認する。
もしWordなどからの貼り付けが原因なら、「形式を選択して貼り付け」または「プレーンテキストとして貼り付け」機能を使い、装飾なしで再貼り付けを行う。ブロックエディタには貼り付け時に「ブロックとして貼り付け」「プレーンテキストとして貼り付け」などの選択肢が表示されるため、常にプレーンテキストを選ぶのが安全だ。
テーマとプラグインを切り分けて競合を特定する

HTMLに問題が見当たらない、あるいは修正しても再発するなら、次はテーマとプラグインの切り分けに進む。この作業はサイトの表示に一時的な影響を与えるため、可能であればメンテナンスモードを有効にするか、深夜帯などアクセスの少ない時間帯に実施する。
この手順で問題が解消された場合、原因は無効化したプラグインかテーマにある。問題が消えたら、プラグインを1つずつ再有効化していき、どのタイミングで投稿の崩れが再発するかを観察する。競合が見つかったプラグインは、代替プラグインを探すか、開発元にサポートを依頼する。
wpautopフィルターを停止して自動整形を無効化する

カスタムHTMLやショートコードを多用するサイトでは、WordPressの自動整形機能(wpautop)が不要な<p>タグや<br>タグを挿入し、投稿を壊してしまうことがある。この機能はfunctions.phpに1行追加するだけで停止できる。
remove_filter('the_content', 'wpautop');上記のコードを、使用中のテーマ(できれば子テーマ)のfunctions.phpの末尾、<?php タグの内側に追加する。この設定を加えると、本文全体の自動整形が無効になり、HTMLを書いたとおりに表示されるようになる。ただし、これにより通常の投稿でも改行が反映されなくなるため、本文はすべてHTMLでマークアップする必要が出てくる点に注意が必要だ。
どうしても特定の投稿だけwpautopを無効化したい場合は、専用のプラグインを利用する方法もある。たとえば「Toggle wpautop」のような軽量プラグインを使えば、投稿ごとに自動整形のオンオフを切り替えられる。
ブロックエディタの「カスタムHTMLブロック」で安全にコードを埋め込む

ブロックエディタでHTMLコードを埋め込む場合、通常の段落ブロックに直接コードを書き込むと、エディタが予期せぬ変換を行うことがある。これを回避するには、必ず「カスタムHTML」ブロックを使用する。
ブロックエディタで「+」ボタンを押し、「カスタムHTML」ブロックを追加する。その中にHTMLやショートコードを記述すれば、エディタによる自動変換の影響を受けずに済む。すでに崩れてしまった投稿も、一度このブロックにコードを移し替えることで、表示が安定することが多い。
ブラウザのキャッシュとサーバーキャッシュをクリアする

投稿を修正してもブラウザ上で崩れたままに見える場合、キャッシュが古い状態を表示し続けている可能性がある。最初にブラウザのキャッシュをクリアし、ハードリロード(Ctrl+Shift+RまたはCmd+Shift+R)を試す。
WordPress側でキャッシュ系プラグインを使用している場合は、管理画面から全キャッシュを削除する。サーバーレベルでVarnishやNginx FastCGI Cache、CloudflareなどのCDNキャッシュが有効になっている場合は、それらもパージする。特にCloudflareを使用している場合、「キャッシュ」→「キャッシュの消去」から「すべてを消去」を実行すると確実だ。
よくある質問
ブロックエディタで「コードエディタ」が見つからない
ブロックエディタの画面右上にある「オプション」アイコン(縦三点リーダー)をクリックすると、メニューの中に「コードエディター」が表示される。もし表示されない場合は、管理画面の「ユーザー」→「プロフィール」で「ビジュアルエディターを使用しない」のチェックが入っていないか確認する。
functions.phpを編集したらサイトが真っ白になった
PHPの文法ミスが原因だ。FTPやレンタルサーバーのファイルマネージャーでfunctions.phpを開き、追加したコードを削除または修正する。functions.phpの編集前には必ずバックアップを取り、できればCode Snippets系のプラグインを使うほうが安全だ。
テーマやプラグインの競合がまったく特定できない
「このサイトで重大なエラーが発生しました」というメッセージが表示されているなら、WordPressのデバッグモードを有効にして具体的なエラー内容を確認する。wp-config.phpにdefine('WP_DEBUG', true);を追加すると、エラーの詳細が画面に表示される。また、ブラウザの開発者ツール(F12キー)のConsoleタブでJavaScriptエラーが出ていないかも併せてチェックする。
特定のプラグインだけが原因だとわかったが手放せない
そのプラグインの設定画面で、エディタ関連の機能(ビジュアルエディタの拡張やカスタムボタンの追加など)を個別に無効化できるか確認する。無効化できない場合は、プラグインのバージョンを最新に更新するか、開発元のサポートフォーラムで同様の症状が報告されていないか調べる。
WordやGoogleドキュメントから毎回貼り付ける運用を安全にしたい
貼り付けの際にCtrl+Shift+V(Cmd+Shift+V)のショートカットでプレーンテキストとして貼り付ける習慣をつける。ブロックエディタでは、貼り付け直後に表示されるツールバーから「プレーンテキストとして貼り付け」を選択する。どうしても書式を保持したい場合は、「Markdownで貼り付け」や「外部ドキュメントのインポート」に対応した専用プラグインの利用を検討する。
この記事のポイント
- 投稿の崩れはHTML混入、wpautop誤作動、テーマ・プラグイン競合の3層で起きる
- コードエディタでHTMLを直視し、不要タグや不正なインラインスタイルを取り除く
- 全プラグイン無効化+標準テーマで原因を特定し、1つずつ再有効化して競合を絞り込む
- カスタムHTML埋め込みはカスタムHTMLブロックを使い、段落ブロックへの直書きを避ける
- 修正後はブラウザキャッシュ、プラグインキャッシュ、CDNキャッシュをすべてクリアする

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

プラグイン更新でテーマの色設定が消えた時の原因と戻し方
プラグインを更新した直後に、テーマのカスタマイザーやページビルダーで設定したリンク色やボタン色がデフォルトに戻る現象は、プラグインが出力する CSS の読み込み順序やスタイルの上書きルールが更新によって変わったことが主な原因だ。まずは設定パネルで該当の色をもう一度選んで保存し、サーバーキャッシュとブラウザキャッシュを完全にクリアすれば、多くのケースは即座に解決する。
更新後にテーマの色やスタイルが消えるのはなぜか

プラグインのアップデートでは新機能の追加やバグ修正だけでなく、内部で使う CSS クラス名の変更やスタイルシートの構造そのものが刷新される場合がある。とくにページビルダー系のプラグインや、テーマが提供する「グローバルカラー」機能を拡張するアドオンでは、アップデートによって優先度の高い新しいデフォルトスタイルが追加され、それまでサイトの表示に適用されていたユーザー定義の色指定が打ち消されてしまう。
管理画面の設定パネル上では、以前に選んだ紫色や緑色が「選択中」として残っているように見えるのに、実際のフロントエンドではプラグインが用意したデフォルトの青色や無指定状態に戻ってしまうのはこのためだ。設定データ自体がデータベースから消えたわけではなく、CSS の読み込み優先順位の変化によって見た目だけが元に戻っている状態と理解するとよい。
ユーザー指定の紫色(#9b59b6)が矢印やリンクに反映されている
プラグイン追加のデフォルト青(#1976d2)がユーザー指定を上書きしてしまう
上の図のように、データベースに保存された色の設定値は更新後も消えていない。プラグインが出力する CSS の層が一枚増えて、その層のデフォルト指定が手前にかぶさっているだけの状態だ。この仕組みを理解しておけば、むやみにテーマ全体を作り直す必要はないとわかる。
色設定を元に戻すための具体的な4つの手順

設定データが無事なら、原因の多くは CSS の読み込み順序の衝突とキャッシュの残留だ。小手先の修正を重ねるよりも、この4ステップを順番に試していく方が結果的に早い。
STEP 1|設定を再保存してキャッシュをすべて消す
該当のプラグイン設定画面を開き、色指定のフィールドでいったん別の色を選んでから再度目的の色に設定し直し、「変更を保存」ボタンを押す。この操作でプラグインは最新バージョンの CSS 生成ロジックを使って、現在の設定値を CSS として書き出す。
保存後は以下の3つのキャッシュを完全に削除する。どれか一つでも残っていると、古い表示のまま問題が続いているように見える。
- プラグインやサーバー側で使っているキャッシュ(WP Rocket や W3 Total Cache など)をすべて削除する
- CDN(Cloudflare など)を使っている場合は、CDN のキャッシュもパージする
- ブラウザのキャッシュを削除するか、シークレットウィンドウで表示を確認する
ここまで実施して色が戻れば、問題は一時的な読み込み順序の不整合だったことになる。これで直らない場合は、次にプラグイン同士の競合を疑う。
STEP 2|全プラグインを停止して問題の範囲を絞る
更新したプラグイン以外にも、CSS や JavaScript を操作するプラグインが複数入っていると、スタイルの打ち消し合いが起こることがある。トラブルシューティングの基本として、更新したプラグインだけを有効にし、それ以外のプラグインをすべて無効化した状態で表示を確認する。
この状態で正しい色が表示されれば、他のプラグインとの競合が原因だ。一つずつ再有効化して、問題が再発するタイミングを特定する。操作は本番環境ではなく、必ずステージング環境かローカル環境で行う。本番サイトでプラグインをまとめて停止すると、レイアウト崩れや機能停止が起こる可能性がある。
STEP 3|セーフモードでクリーンな状態を作る
WordPress 5.2 以降に搭載されたサイトヘルス機能の一部として「致命的エラーからの保護(リカバリーモード)」がある。更新後に画面が真っ白になったり「このサイトで重大なエラーが発生しました」というメッセージが出た場合は、この仕組みが自動で発動し、管理者宛てにリカバリーモード用のリンクがメールで届く。
リカバリーモードでは、問題のプラグインが無効化された状態で管理画面に入れる。ここで該当プラグインの設定を開き、色指定を再保存してからプラグインを再有効化することで、破損したキャッシュや不完全な更新ファイルが原因の不具合を解消できる場合がある。
STEP 4|プラグインを旧バージョンに戻す
STEP 1〜3 で解決しない場合や、どうしてもサイトを今すぐ正常な見た目に戻す必要がある場合は、WP Rollback などの専用プラグインを使って該当プラグインを更新前のバージョンに戻す。この方法を取れば、開発者側の修正パッチがリリースされるまでの間もサイトの見た目を維持できる。
旧バージョンへのロールバックは一時的な回避策であり、セキュリティ修正や脆弱性対策が含まれるアップデートの場合は注意が必要だ。ロールバックを実施したら、必ずプラグインの公式サポートフォーラムや変更履歴を確認し、次の安定版がリリースされたタイミングで速やかに更新すること。
修正パッチを適用する際の注意点

プラグイン開発者から修正版の ZIP ファイルが提供される場合がある。通常の管理画面から「プラグイン」→「新規追加」→「プラグインのアップロード」でインストールできるが、すでに同名のプラグインが存在する場合は「上書きインストール」を求められる。
上書きインストールの前に、必ずサイト全体のバックアップ(データベースとファイル)を取得しておく。ZIP ファイルのアップロード時に「500 Internal Server Error」が発生した場合は、サーバーの PHP メモリ不足やアップロードサイズ制限が原因の可能性が高い。サーバーのエラーログを確認し、必要に応じて `php.ini` や `.htaccess` でメモリ上限や実行時間の設定を一時的に引き上げる。
FTP が使える環境なら、管理画面からのアップロードではなく、ZIP を解凍してプラグインフォルダ(`/wp-content/plugins/プラグイン名/`)に直接アップロードする方法もある。この場合はファイルの上書きミスを防ぐため、既存フォルダをリネームして退避させてから新しいファイルを配置する方が安全だ。
よくある質問
プラグインを更新前のバージョンに戻すにはどうすればよいか
「WP Rollback」プラグインをインストールすると、プラグイン一覧画面に「Rollback」リンクが追加される。クリックすると過去のバージョン一覧が表示され、任意のバージョンにワンクリックで戻せる。手動で戻す場合は、プラグインの公式ディレクトリにある「Previous Versions」から旧バージョンの ZIP をダウンロードし、FTP で上書きアップロードする。
色設定が毎回のアップデートで消えるのを防ぐ方法はあるか
プラグインのグローバルカラー機能に頼らず、子テーマの `style.css` にカスタム CSS として直接色指定を書いておく方法が最も安定する。テーマやプラグインのアップデートでは子テーマのファイルは上書きされないため、色指定が勝手にリセットされる心配がなくなる。
キャッシュを削除しても色が戻らない場合はどうするか
ブラウザの「検証ツール(F12キー)」を開き、色が変わってしまった要素をクリックして Styles パネルを確認する。目的の色指定に打消し線が入っていて、別の CSS ルールが優先されている場合は、そのルールの出どころ(プラグイン名やファイル名)を特定できる。特定できたら、より強いセレクタ(ID セレクタや `!important`)を使って子テーマ側で上書きする。
プラグイン更新後にサイト全体が真っ白になった時の対処法は
「このサイトで重大なエラーが発生しました」と表示される場合は、FTP で `/wp-content/plugins/該当プラグインのフォルダ/` をリネームして無効化し、管理画面にアクセスできる状態を確保する。その後、`wp-config.php` に `define(‘WP_DEBUG’, true);` を追加してデバッグモードを有効にし、具体的なエラー内容を確認してから対応を進める。
自動更新を止めておくことは可能か
特定のプラグインだけ自動更新を無効化するには、`wp-config.php` に手を加えるか、Easy Updates Manager のような管理プラグインを使う。ただし自動更新を止めるとセキュリティ修正の適用も遅れるため、本番環境では更新前にステージング環境で動作確認する運用体制を整えておくことが現実的な対策になる。
この記事のポイント
- プラグイン更新で色が消えるのは、設定データの消失ではなく CSS の読み込み順序や優先度が変わったことが原因
- 設定の再保存とキャッシュ完全削除でほとんどは即座に解決する
- 直らない場合はプラグイン競合の切り分けやリカバリーモードを試す
- 恒久対策として、重要な色指定は子テーマの CSS に直接書いておくとアップデートに左右されない

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WordPressで「Duplicate entry ‘0’ for key ‘PRIMARY’」エラーが発生したときのデータベース修復手順
MailPoetなどのプラグインで「An exception occurred while executing a query: Duplicate entry ‘0’ for key ‘PRIMARY’」というエラーが発生しプラグインを再インストールしても直らない場合、原因はデータベーステーブルの主キーからAUTO_INCREMENT属性が失われていることだ。phpMyAdminでテーブル構造を直接修復すれば解決する。
なぜ再インストールではこのエラーが直らないのか

「Duplicate entry ‘0’ for key ‘PRIMARY’」は、データベースの主キー(PRIMARY KEY)に同じ値「0」を重複して挿入しようとしたときにMySQLが返すエラーだ。通常、主キーにはAUTO_INCREMENTが設定されており、新しい行が追加されるたびに自動で一意の番号(1、2、3…)が振られる。しかしテーブル構造が破損したり、何らかの操作でAUTO_INCREMENT属性が外れたりすると、WordPressやプラグインは新しい行を追加する際に主キーへ「0」や重複した値を挿入しようとして失敗する。
MailPoetを管理画面から削除して再インストールしても、プラグインが使用するカスタムテーブルは削除されずに残ることが多い。テーブルが残っていれば破損した構造もそのままだ。結果として、何度インストールし直しても同じエラーが再発するという状況に陥る。
↑ AUTO_INCREMENTが欠落
→ 新規行のidが常に0になる
↑ 自動で一意の番号が振られる
→ 正常にデータを追加できる
エラーが発生しているテーブルは、エラーメッセージに直接表示されないことも多い。MailPoetの場合、mailpoet_で始まる複数のテーブルのいずれかでこの問題が起きている可能性が高い。具体的にはmailpoet_subscribersやmailpoet_segmentsなど、データを頻繁に追加するテーブルで発生しやすい。
phpMyAdminでデータベーステーブルを修復する手順

レンタルサーバーの管理画面からphpMyAdminにアクセスし、以下の手順でテーブル構造を修復する。操作は数分で完了し、特別な技術知識は不要だ。
対象のデータベースとテーブルを特定する
phpMyAdminを開いたら、左側のデータベース一覧からWordPressサイトが使用しているデータベースをクリックする。データベース名がわからない場合は、WordPressインストールディレクトリのwp-config.phpファイルを開き、DB_NAMEの値を確認する。またはサーバー管理画面の「データベース」セクションでWordPressに関連付けられたデータベース名を探す。
データベースを選択するとテーブルの一覧が表示される。MailPoetのテーブルはmailpoet_という接頭辞で始まる(例:wp_mailpoet_subscribers、wp_mailpoet_newslettersなど)。エラーの原因となっているテーブルを特定するには、まずmailpoet_subscribersなど主要なテーブルの「構造」タブを開き、主キー(通常はidカラム)の「AUTO_INCREMENT」が有効かどうかを確認する。
主キーにAUTO_INCREMENTを再設定する具体的なSQL操作
テーブルの「構造」タブでidカラムの「変更」リンク(鉛筆アイコン)をクリックする。表示された編集画面で「A_I」(AUTO_INCREMENT)チェックボックスにチェックを入れ、「保存」をクリックする。これで主キーにAUTO_INCREMENT属性が再設定される。
もしphpMyAdminのGUI操作でエラーが出る場合は、SQLタブを開いて直接SQL文を実行する。以下のSQLを実行する(テーブル名は実際のものに置き換える)。
ALTER TABLE wp_mailpoet_subscribers MODIFY COLUMN id INT(11) NOT NULL AUTO_INCREMENT;このSQL文は、wp_mailpoet_subscribersテーブルのidカラムをAUTO_INCREMENT付きで再定義する。同じ問題が他のMailPoetテーブルでも発生している可能性があるため、mailpoet_で始まるすべてのテーブルの構造を確認し、idカラムのAUTO_INCREMENTが外れているものがあれば同様に修正する。
操作後はphpMyAdminの「操作」タブから、そのテーブルのAUTO_INCREMENTの現在値を適切な値に設定しておくとより安全だ。テーブル内の既存データの最大IDより大きい値(例:既存の最大IDが150なら151)をAUTO_INCREMENT欄に入力して「実行」をクリックする。
データベースに直接アクセスできない場合の代替手段
レンタルサーバーによってはphpMyAdminが提供されていなかったり、セキュリティ上の理由でデータベースへの直接アクセスが制限されている場合がある。その場合は以下の方法を試す。
WP-CLIが利用できる環境なら、以下のコマンドでデータベースに直接SQLを実行できる。
wp db query "ALTER TABLE wp_mailpoet_subscribers MODIFY COLUMN id INT(11) NOT NULL AUTO_INCREMENT;"WP-CLIもphpMyAdminも使えない共有サーバーの場合は、「Advanced Database Cleaner」や「WP-DBManager」のようなWordPressプラグインを使ってSQLクエリを実行する方法もある。ただし多くのレンタルサーバーにはphpMyAdminが標準で用意されているため、まずはサーバー管理画面を確認するのが確実だ。
MailPoetテーブルを完全にリセットして再インストールする方法

テーブル構造の修復が難しい場合や、破損が広範囲に及んでいる場合は、MailPoetの全テーブルを手動で削除してからプラグインを再インストールする方法もある。この方法では既存の購読者データやニュースレターの設定は失われるため、事前にバックアップがある場合のみ選択する。
テーブルを削除するには、phpMyAdminで各mailpoet_テーブルにチェックを入れ、下部の「処理」ドロップダウンから「削除(DROP)」を選択して実行する。MailPoetのテーブルは数が多いため、一つずつ選択するか、以下のようなSQLを実行して一括削除することもできる。
DROP TABLE IF EXISTS wp_mailpoet_subscribers, wp_mailpoet_segments, wp_mailpoet_newsletters;すべてのMailPoetテーブル名はphpMyAdminのテーブル一覧で確認できる。DROP TABLEは取り消せない操作のため、実行前に必ずデータベース全体のバックアップ(エクスポート)を取得する。その後WordPress管理画面からMailPoetプラグインを削除し、改めて「プラグイン」→「新規追加」からインストールすれば、正常なテーブル構造でプラグインが初期化される。
他のプラグインでも発生する同様のエラーと共通の対処法

「Duplicate entry ‘0’ for key ‘PRIMARY’」はMailPoetに限らず、WooCommerce、BuddyPress、LearnDashなど、独自のカスタムテーブルを作成するあらゆるプラグインで発生する可能性がある。根本原因は常に同じで、主キーのAUTO_INCREMENT属性が失われていることだ。
WooCommerceの場合はwp_woocommerce_order_itemsやwp_woocommerce_downloadable_product_permissionsなど、BuddyPressではwp_bp_activityやwp_bp_notificationsで発生しやすい。エラーメッセージが表示されたら、まずメッセージ内で言及されているクエリからテーブル名を特定し、そのテーブルの主キー構造をphpMyAdminで確認する手順は同じだ。
WordPressのメジャーアップデートやサーバーのMySQLバージョンアップグレード後にこのエラーが突然発生した場合は、複数のカスタムテーブルで同様の破損が起きている可能性が高い。その際は一つずつ修復するよりも、データベース全体のバックアップを取った上で、DB管理ツールの「テーブルの修復」機能を使うのが効率的だ。phpMyAdminではデータベースを選択後、全テーブルにチェックを入れて「処理」から「テーブルの修復」を選択すると、破損したテーブルを一括で修復できる。
今後の再発を防ぐための予防策
AUTO_INCREMENT属性が外れる根本原因は、MySQLの不整合やプラグインの不完全なアップデート処理にあることが多い。完全に防ぐことは難しいが、以下の対策でリスクを低減できる。
プラグインのアップデート前にデータベースのバックアップを必ず取得する習慣をつける。多くのレンタルサーバーでは管理画面からワンクリックでバックアップを取得できる。また「UpdraftPlus」などのバックアッププラグインを導入し、自動バックアップをスケジュールしておくと、問題発生時に迅速に復元できる。
プラグインのメジャーアップデート(1.xから2.xなど大幅なバージョンアップ)を適用する際は、可能であればステージング環境で事前テストを行う。これにより本番環境でテーブル破損が発生するリスクを大幅に減らせる。ステージング機能を提供しているレンタルサーバーも増えている。
よくある質問
エラーメッセージにテーブル名が表示されない場合はどうすればいいか
WordPressのデバッグモードを有効にすると、より詳細なエラー情報が表示される。wp-config.phpにdefine('WP_DEBUG', true);とdefine('WP_DEBUG_LOG', true);を追加し、wp-content/debug.logに出力されるエラーログを確認する。ログにはクエリ全体が記録されるため、テーブル名が特定できる。
phpMyAdminでAUTO_INCREMENTのチェックボックスがグレーアウトして変更できない
主キーが正しく設定されていない可能性がある。まず「構造」タブでidカラムが「PRIMARY」と表示されているか確認する。表示されていない場合は、そのテーブルのSQLタブでALTER TABLE テーブル名 ADD PRIMARY KEY (id);を実行してから再度AUTO_INCREMENTの設定を試す。
テーブルを修復したが同じエラーが別のテーブルで発生する
プラグインが使用する全テーブルを確認する必要がある。MailPoetは40以上のテーブルを使用しており、idカラムを持つテーブルすべてで同様の問題が起きている可能性がある。phpMyAdminの検索機能で「id」を含むテーブル構造を横断的に確認するか、前述の全テーブル削除と再インストールを検討する。
データベース操作に不慣れでSQLの実行が不安な場合の安全な方法はあるか
レンタルサーバーのサポートに依頼するのが最も安全だ。「WordPressプラグインのデータベーステーブルでAUTO_INCREMENTが破損しているため修復してほしい」と伝えれば、多くのサーバー会社では技術サポートが対応してくれる。またphpMyAdminの「エクスポート」で事前にSQLバックアップを取得しておけば、操作ミスがあっても復元できる。
この記事のポイント
- 「Duplicate entry ‘0’ for key ‘PRIMARY’」は主キーのAUTO_INCREMENT属性欠落が原因
- プラグイン再インストールだけではテーブル構造は修復されない
- phpMyAdminで対象テーブルのidカラムにAUTO_INCREMENTを再設定すれば解決する
- MailPoet以外のプラグイン(WooCommerce、BuddyPress等)でも同じ対処法が有効
- 事前のデータベースバックアップとデバッグモード活用で早期発見と安全な修復が可能

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WC Vendors 2.7.0アップグレードでfatal errorが出た時の対処法
WC Vendors 2.7.0 にアップグレードした直後、サイト全体が「このサイトで重大なエラーが発生しました」の表示になり管理画面にもアクセスできなくなった場合、wcvendors_capability_product_types オプションの値が配列ではなく文字列で保存されていることが原因だ。WP-CLI を使えるかどうかで復旧手順を分けて対処する。
WC Vendors 2.7.0で管理画面にすら入れなくなる原因は何か

この問題は、プラグイン内部の関数 wcv_is_all_product_types_hidden() が array_diff() を呼び出す際、引数として文字列を渡してしまうことで発生する。PHP 8 環境では型宣言が厳密になったため、ここで TypeError(致命的エラー)が起こり、サイト全体が HTTP 500 エラーで停止する。
関数に渡されるのは wcvendors_capability_product_types というオプションの値だ。このオプションは本来、商品タイプの配列(['simple', 'variable'] など)を保持すべきだが、古いバージョンの WC Vendors(特に 1.x 系)から移行してきたサイトでは、内部的に「simple」のような文字列のまま残っているケースがある。2.7.0 で追加された新しい関数には配列へのキャスト処理が含まれておらず、長期間眠っていた不正なデータが一気に致命的エラーとして表面化した。
(array) によるキャストがあり、文字列でも配列として扱われていたarray_diff() に文字列が直接渡され、PHP 8 で TypeErrorエラーのトリガーは wp_loaded フックで、これは WordPress の読み込みのかなり早い段階で実行される。そのため管理画面もフロントエンドも一切表示されず、ダッシュボードからプラグインを無効化するという通常の復旧手段が使えなくなってしまう。
管理画面にログインできない場合の応急処置(WP-CLI を使う)

サーバーに SSH でアクセスできる環境であれば、WP-CLI を使って不正なオプション値を直接修正するのが最も確実な回復方法だ。管理画面に入れなくても、この操作でサイトは即座に復旧する。
wp option update wcvendors_capability_product_types '["simple"]' --format=json上記コマンドは wcvendors_capability_product_types オプションの値を強制的に JSON 配列として上書きする。["simple"] の部分は、自サイトで実際に有効にしていた商品タイプのスラッグに置き換える。可変商品や外部商品を使っていた場合は、["simple","variable","external"] のようにカンマ区切りで列挙する。値は連想配列ではなく、単純なリスト形式でなければならない。
WP-CLI を使えない場合のエラー復旧手順(FTP/ファイルマネージャー)

レンタルサーバーでは SSH が利用できず、WP-CLI も使えないケースが多い。その場合は FTP またはサーバー付属のファイルマネージャーを使ってプラグインを一時的に無効化し、管理画面にアクセスできる状態に戻す。
- FTP クライアントまたはファイルマネージャーで
/wp-content/plugins/ディレクトリにアクセスする wc-vendorsディレクトリを探し、名前をwc-vendors-disabledに変更する- ブラウザで管理画面の URL(
yourdomain.com/wp-admin/)を開く - 管理画面にログインできたら、
wc-vendors-disabledをもとのwc-vendorsに戻す(ただし有効化はしない) - 管理画面の「プラグイン」で WC Vendors が「無効」になっていることを確認し、データベースの該当オプションを修正する手順に進む
ディレクトリ名の変更によってプラグインが強制的に無効化される仕組みを利用している。ファイル自体は削除せず、リネームするだけなので元に戻せる。管理画面に戻ったら、次のセクションで説明する根本的なオプション修正を行う。現時点で WC Vendors を再度有効化すると、同じエラーが再発するので有効化してはいけない。
根本的な修正をプラグインのアップデート前に済ませておく

WC Vendors の開発チームはこの問題を認識しており、将来のリリースで修正が反映される見込みだ。しかしアップデートを待つだけでは、同じサイトで別の箇所が再び同様のエラーを起こす可能性を抱えたままになる。管理画面にログインできる状態にしたら、データベース上のオプション値を正規化してしまおう。
最も簡便な方法は、先ほど WP-CLI で実行したコマンドと同じ操作を、データベース管理ツール(phpMyAdmin など)やカスタムスクリプトで行うことだ。具体的には wp_options テーブルを開き、option_name が wcvendors_capability_product_types の行を探す。option_value カラムが文字列(例 simple)になっている場合、a:1:{i:0;s:6:"simple";} のようにシリアライズされた配列表現に書き換える。
PHP のシリアライズ形式を手書きするのはミスが怖い場合は、次のような安心な手順をとる。
- WC Vendors が無効化されていることを確認する
- 管理画面の「設定」→「WC Vendors」→「販売」→「商品タイプ」に進み、チェックボックスで適切な商品タイプを選んで保存する(これで正常な配列としてオプションが上書きされる)
- WC Vendors を有効化する
この方法は管理画面を使うため、データベースを直接触る必要がなく安全だ。ただしバージョン 2.7.0 では有効化した瞬間に wp_loaded フックのエラーが再発する可能性があるため、あらかじめプラグインファイルの該当行を一時的に修正するか、前述のキャストを適用しておくと確実だ。
よくある質問
エラーログを確認するにはどうすればよいか
サーバーのエラーログには wp-content/debug.log(WordPress のデバッグログ)や、Apache/Nginx のエラーログがある。WP-CLI が使えれば wp config set WP_DEBUG true --raw と wp config set WP_DEBUG_LOG true --raw でログ出力を有効にした上で、エラーを再現させて wp-content/debug.log を確認する。共有サーバーではホスティングの管理画面からエラーログが見られることも多い。
WC Vendors をアップグレードする前に何か注意すべきことはあるか
メジャーバージョンアップを行う場合は、本番サイトに適用する前に必ずステージング環境でテストする。どうしても本番で行うなら、事前にデータベースのバックアップを取り、wcvendors_capability_product_types オプションの現在の値を確認しておく。WP-CLI で wp option get wcvendors_capability_product_types --format=json を実行し、値が配列形式になっていることを確かめればリスクを大幅に減らせる。
PHP のバージョンが 7.x 系ならこの問題は起きないか
PHP 7.x では array_diff() に文字列を渡しても Warning は出るが Fatal Error にはならないため、サイトが完全停止することはない。ただしエラー自体の根本原因は同じであり、動作は予期しない結果になる可能性が高い。推奨される PHP のバージョンは 8.x 系へ移行することであり、その前に対処しておくことが望ましい。
WC Vendors Free と Pro のどちらでも発生するのか
この問題は WC Vendors の無料版(Free)のコア機能部分で発生している。Pro 版を併用している場合でも、同じオプション値を読み込むため影響を受ける可能性が高い。特に 1.x 系からバージョンを重ねてきたサイトは要注意だ。
この記事のポイント
- WC Vendors 2.7.0 へのアップグレードでサイトが停止するのは
array_diff()の型不一致が原因 - 古いサイトでは
wcvendors_capability_product_typesが文字列で残っているケースがある - WP-CLI を使えるなら
wp option updateで即座に復旧できる - WP-CLI が使えない場合はプラグインディレクトリをリネームして管理画面に復帰する
- 根本的には設定画面で商品タイプを保存し直すか、データベースの値を配列に正規化する

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WordPress 7.0 ブロックエディターで多言語プラグイン Bogo 有効時に REST API 500 エラーが出る原因と対処
WordPress の多言語プラグイン Bogo を有効化した状態でブロックエディターを開くと、カテゴリーなどのタクソノミーパネルが空になり、REST API が 500 Internal Server Error を返す症状は、Bogo が REST API に付与する lang パラメータと WordPress 7.0 のブロックエディター側のリクエスト処理が競合していることが主な原因だ。
なぜ Bogo とブロックエディターの組み合わせで REST API が 500 エラーを返すのか

この問題の核心は、ブロックエディターが内部で使用する REST API エンドポイントに対するリクエストにある。ブロックエディターは編集画面を表示する際、/wp-json/wp/v2/taxonomies や /wp-json/wp/v2/users/〜 といった複数のエンドポイントに同時にリクエストを送信し、カテゴリー一覧や投稿者情報を取得している。
Bogo は多言語対応のために、これらの REST API リクエストに対して自動的に lang クエリパラメータを付与する。たとえば ?lang=en や ?lang=ja といった具合だ。このパラメータ追加の処理が、ブロックエディターの特定の内部リクエストと組み合わさった際に、サーバー側で PHP の致命的エラーを引き起こしている。
データベースから要求された言語のデータを取得しようとするが、ブロックエディターのコンテキストでは想定外の引数が渡され、結果として WP_Query やタクソノミー取得関数が WP_Error オブジェクトを返す。これが REST API のレスポンス生成時に適切にハンドリングされず、500 エラーとして表面化する。
エラーの切り分けと原因特定の手順

まずは問題が本当に Bogo とブロックエディターの組み合わせに限定されているのかを確認する。以下のフローに沿ってテストを進めると、原因の特定がスムーズになる。
上記の最小構成でもエラーが再現する場合、Bogo とブロックエディターの直接的な競合と判断できる。なお、クラシックエディタープラグインをインストールして同じ操作を行った際に問題が発生しないことも、ブロックエディター固有の問題であることの強い証拠になる。
実用的な回避策と当面の対応

根本的な修正は Bogo プラグイン側のアップデートを待つ必要があるが、運用を止めずにしのぐ方法はいくつか存在する。状況に応じて以下を使い分ける。
クラシックエディターへの一時的な切り替え
最も確実で即効性のある回避策は、クラシックエディタープラグインをインストールして旧来の編集画面を使うことだ。クラシックエディターは REST API に依存したデータ取得を行わないため、Bogo の lang パラメータ付与が問題を引き起こす余地がない。
→ ブロックエディターの内部リクエストが lang パラメータと競合
→ REST API 非依存のため競合が発生しない
クラシックエディターは WordPress の公式プラグインディレクトリから無料でインストールできる。インストール後は「設定」→「投稿設定」からデフォルトのエディターを切り替えられる。
REST API への lang パラメータ付与をフィルターフックで制限する
Bogo は REST API リクエストに言語パラメータを付与する際、rest_dispatch_request や rest_pre_dispatch といったフィルターフックを経由している。子テーマの functions.php に以下のようなコードを追加することで、管理画面からのリクエストに対して言語パラメータの付与を抑制できる。
add_filter( 'rest_dispatch_request', function( $dispatch_result, $request, $route, $handler ) {
// 管理画面からの REST API リクエストの場合、Bogo の言語処理をスキップ
if ( is_admin() || ( defined( 'REST_REQUEST' ) && REST_REQUEST && strpos( $route, '/wp/v2/' ) === 0 ) ) {
remove_filter( 'rest_dispatch_request', 'bogo_rest_dispatch_request', 10 );
}
return $dispatch_result;
}, 5, 4 );このコードは、/wp/v2/ から始まる REST API ルート(ブロックエディターが使用する主要なエンドポイント)に対して、Bogo が持つ bogo_rest_dispatch_request フィルターを一時的に除去する。ただし、この方法は Bogo の内部実装に依存しているため、プラグインのバージョンアップによって動作が変わる可能性がある点に注意が必要だ。
プラグインのダウングレードまたはフォーク版の利用を検討する
Bogo 3.9.2 で問題が顕在化したのであれば、1つ前のバージョンである 3.9.1 にダウングレードすることで問題が回避できる可能性がある。ただし、ダウングレードはセキュリティ上のリスクを伴うため、あくまで開発者側の対応を待つ間の暫定策と位置づける。
代替の多言語プラグインへの移行を検討する
Bogo はシンプルな多言語化プラグインとして長く使われているが、ブロックエディターとの相性問題が続くようであれば、Polylang や WPML、TranslatePress といった代替プラグインへの移行も選択肢に入る。これらのプラグインはブロックエディターとの互換性テストがより積極的に行われており、多言語サイトの構築で実績も豊富だ。
デバッグモードで詳細なエラー情報を取得する

REST API の 500 エラーは、通常の PHP エラーとは異なり debug.log に記録されない場合がある。そのため、wp-config.php に以下の定数を追加して、より詳細なエラー情報を取得する。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SAVEQUERIES', true );さらに、ブラウザの開発者ツールで「ネットワーク」タブを開き、500 エラーを返している REST API リクエストを特定する。該当するリクエストの「レスポンス」タブを確認すると、サーバーから返された HTML のエラーページや JSON エラーオブジェクトが表示される。WordPress 7.0 では「このサイトで重大なエラーが発生しました」というメッセージが返ってくることが多い。
どうしてもエラーの詳細が取得できない場合は、wp-config.php に以下のコードを追加し、REST API エラー専用のログファイルを作成する方法もある。
add_action( 'rest_api_init', function() {
set_error_handler( function( $errno, $errstr, $errfile, $errline ) {
$log = sprintf( '[%s] %s:%d %s', date( 'Y-m-d H:i:s' ), $errfile, $errline, $errstr );
file_put_contents( WP_CONTENT_DIR . '/rest-api-errors.log', $log . PHP_EOL, FILE_APPEND );
});
}, 1 );このコードは REST API の初期化時にカスタムエラーハンドラを登録し、発生したエラーをすべて wp-content/rest-api-errors.log に記録する。問題が解決したら必ず削除すること。
よくある質問
Bogo の代わりに Polylang を使っても同様のエラーは出るか
Polylang は REST API との統合が設計段階から考慮されており、ブロックエディターとの組み合わせでも同様の 500 エラーが発生する可能性は極めて低い。実際に多くの多言語サイトで Polylang とブロックエディターの組み合わせが問題なく運用されている。移行を検討する価値は十分にある。
この問題は WordPress 7.0 以前のバージョンでも発生するのか
WordPress 6.x 系では報告が少なく、7.0 へのアップデート後に顕在化したケースが多い。ブロックエディターの内部実装が 7.0 で変更され、特定の REST API エンドポイントに対するリクエストのタイミングやパラメータの扱いが変わったことが影響していると考えられる。
クラシックエディターに切り替えた後、再びブロックエディターに戻せるのか
問題なく戻せる。クラシックエディターで作成した投稿は、ブロックエディターに戻した際に自動的にクラシックブロックとして読み込まれる。Bogo プラグイン側のアップデートで問題が修正されたら、クラシックエディタープラグインを無効化してブロックエディターに戻せばよい。
REST API のエラーはフロントエンドの表示にも影響するのか
今回の問題は管理画面のブロックエディター内に限定されており、公開済みサイトのフロントエンド表示には影響しない。カテゴリー一覧や投稿一覧の表示、多言語切り替え機能は通常どおり動作する。ただし、ブロックエディターでカテゴリーを選択・編集できないため、投稿の作成や編集作業に支障が出る。
functions.php にフィルターフックを追加する方法がわからない場合はどうすればよいか
最も安全な方法は、FTP クライアントまたはレンタルサーバーのファイルマネージャーを使い、子テーマの functions.php ファイルを編集することだ。操作に不安がある場合は、Code Snippets プラグインを利用して管理画面からコードを追加する方法もある。誤ったコードの追加はサイト全体に影響するため、必ず事前にバックアップを取得してから作業すること。
この記事のポイント
- Bogo 有効時にブロックエディターのカテゴリーパネルが空になるのは、REST API への lang パラメータ付与が競合を起こすため
- クラシックエディターに一時的に切り替えることで、即座に問題を回避できる
- functions.php にフィルターフックを追加し、管理画面からの REST API リクエストに対して Bogo の言語処理を抑制する方法もある
- 根本解決には Bogo プラグイン側のアップデートが必要で、状況によっては代替プラグインへの移行も検討する
- REST API の 500 エラーは debug.log に記録されないことがあるため、専用のエラーログ取得を設定すると原因特定が早まる

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
