タグアーカイブ WordPress

Diviビルダーでカスタムパーマリンクのページが404になる原因と直し方

Diviビルダーでカスタムパーマリンクのページが404になる原因と直し方

Diviビルダーでカスタムパーマリンクを設定した固定ページを編集しようとしたとき、編集画面が404エラーになる現象は、パーマリンク管理プラグインがビルダー専用のクエリパラメータを不正に処理しているために起こる。多くの場合、プラグインの詳細設定で特定のクエリ文字列を除外するだけで解決する。

なぜDiviビルダーがカスタムパーマリンクのページで404エラーを起こすのか

Diviのビジュアルビルダー(フロントエンド編集)は、管理画面から対象ページのURLに「?et_fb=1」といったクエリパラメータを付与し、そのページをiframe内で読み込んで動作する。このとき、パーマリンク管理プラグイン(Permalink Manager Lite など)が設定したカスタムパーマリンクのリダイレクトルールが厳しすぎると、「?et_fb」がついたURLを本来とは別の場所に転送したり、存在しないページとみなして404ステータスを返してしまう。ページ自体は正常に表示されていても、ビルダーという編集専用のアクセスだけがブロックされるかたちになる。

具体的には、パーマリンク管理プラグインの「リダイレクト設定」や「正規化」機能が、付加されたクエリ文字列を除去してしまったり、ビルダー用のパラメータを含むURLをリダイレクト対象から外す設定になっていないことが原因だ。また、一部のキャッシュ設定が影響して、ビルダーがキャッシュ済みの不完全なページを読み込んで404を返すケースもある。

Permalink Manager Lite の設定を調整して404を解消する

カスタムパーマリンクで運用している環境でDiviビルダーが使えなくなったら、まずパーマリンク管理プラグインの詳細設定を見直す。ここでは日本語環境でも多く使われている「Permalink Manager Lite」を例に手順を示すが、他のパーマリンク系プラグインでも同様の考え方で対処できる。

STEP 1 管理画面の「ツール」→「Permalink Manager」→「設定」を開く
STEP 2 「詳細設定」タブをクリックする
STEP 3 「除外するクエリパラメータ」欄に「et_fb」を追加して保存する
設定画面の移動 タブの切り替え 除外指定の追加

上記の「除外するクエリパラメータ」には「et_fb」とだけ入力すればよい。クエリキー名のみをカンマ区切りで列挙する仕様のため、値や「?」を含める必要はない。保存後にDiviビルダーでカスタムパーマリンクのページを開き直し、編集画面が正しく表示されるか確認する。

リダイレクト無効化で管理者の編集を保護する

もう一つの有効な方法は、特定のユーザーに対してリダイレクト機能を一時的に無効化する設定だ。「詳細設定」画面の「リダイレクトを無効化するユーザー」で「管理者」にチェックを入れて保存する。こうすると管理画面からビルダーを開く管理者のリクエストにはリダイレクトルールが適用されず、クエリパラメータがそのまま残るため404が発生しなくなる。ただし、この設定は公開側のパーマリンク動作には影響しない。

デバッグモードで原因を可視化する

設定を変更しても改善しない場合は、「ツール」→「Permalink Manager」→「設定」→「詳細設定」にある「デバッグモード」を有効にしてみる。デバッグモードをオンにすると、ビルダーで404になった際にプラグインがどのURLを解決しようとして失敗したか、詳細なログが記録される。これを見ることで「et_fb」以外に必要な除外パラメータが見つかったり、リダイレクトルールの競合を特定できる。

キャッシュプラグインの影響を切り分ける

キャッシュプラグインの影響を切り分ける

パーマリンク管理プラグインの設定を見直しても直らないときは、サーバーキャッシュやWordPressのキャッシュプラグインの影響を疑う。ビルダー読み込み時の動的URLがキャッシュから誤ったレスポンスを返す場合があるため、以下の手順で一時的にキャッシュを無効化し、症状が消えるか確認する。

  • 使用しているキャッシュプラグイン(WP Super CacheやW3 Total Cacheなど)を一時停止する
  • サーバー側でNginxのfastcgi_cacheやApacheのmod_cacheを使っているなら、管理画面経由でキャッシュをクリアするか、一時的に無効にする
  • ブラウザのキャッシュもクリアしてからビルダーを再読込する

キャッシュを切った状態で編集が成功したなら、キャッシュプラグインの「除外するURLパターン」に「?et_fb」を含む設定を追加する。たとえば、et_fb というクエリ文字列がついたリクエストはキャッシュしないように設定すれば、運用を続けながら編集機能を維持できる。

どうしても直らないときの代替手段

どうしても直らないときの代替手段

上記すべてを試してもビルダーが404を返す場合、根本的にプラグインの仕組みがDiviビルダーと相性が悪い可能性がある。以下の対策を順に検討する。

Before:ビルダー404
カスタムパーマリンク + Permalink Manager Lite → 編集不可
After:編集可能に
クエリパラメータ除外 or プラグイン一時停止でビルダー起動
404エラー状態 編集復旧

パーマリンクプラグインを別のものに切り替える

カスタムパーマリンク機能自体は別のプラグインでも実現できる。「Custom Permalinks」や「WP Permalink」など、Diviとの競合報告が少ないプラグインを試すことで、リダイレクトの挙動を根本から変えられる。ただし、移行時には既存のURL構造を維持できるか事前にテスト環境で確認する必要がある。

ページ編集時だけパーマリンクを一時的にデフォルトに戻す

最終手段として、編集したい固定ページのパーマリンク設定を一時的に「デフォルト(?p=123)」に変更してビルダーで作業し、公開直前にカスタムパーマリンクに戻す方法もある。ただし、編集のたびに手作業が発生するため、恒常的な運用には向かない。

よくある質問

エラーは「このサイトで重大なエラーが発生しました」ではなく「404 Not Found」と表示されるのはなぜか

Diviビルダーはページをiframeで読み込む際に、サーバーに実際のHTTPリクエストを送る。カスタムパーマリンクのルールがリクエストを処理できないと、WordPressのルーティングが失敗し「ページが見つかりません」という404ステータスが返る。これはPHPの致命的エラーではなく、あくまでもURL解決の失敗が原因だ。

特定の固定ページだけ編集できず、他のカスタムパーマリンクページは問題ないのはなぜか

スラッグの重複やリダイレクトルールの複雑さによって、一部のURLだけ誤って別のルールにマッチしてしまうことがある。全ページに同じカスタム構造を割り当てていても、個別に手動で追加したリダイレクト設定が干渉している場合もあるため、プラグインの「重複チェック」や「リダイレクトリスト」を確認する必要がある。

除外するクエリパラメータに「et_fb」を追加しても直らない場合はどうすればよいか

その場合は、ビルダーが使用する可能性のあるすべてのクエリパラメータを確認する。たとえば「et_fb」「et_pb_preview」「et_fb_iframe」「preview」「preview_id」などが考えられる。開発者ツールのネットワークタブでビルダー起動時に送信されるリクエストを調べ、404になっているURLに含まれるパラメータをすべて除外リストに追加する。

キャッシュプラグインを停止しても404が消えない

サーバーレベルのキャッシュ(VarnishやNginx FastCGI)が影響している可能性がある。レンタルサーバーの管理パネルからキャッシュを手動でクリアするか、サーバー会社のサポートに一時的なキャッシュ停止を依頼して切り分ける。WordPressのキャッシュプラグインだけでは制御できない層があるためだ。

この記事のポイント

  • パーマリンク管理プラグインの除外設定に「et_fb」を追加すれば大半のケースで解決する
  • 管理者向けのリダイレクト無効化も有効な回避策になる
  • キャッシュプラグインやサーバーキャッシュが404を悪化させることがあるため、一時停止して切り分ける
  • デバッグモードで詳細なログを確認すれば、除外すべき追加パラメータを特定できる
  • 根本的に相性が悪い場合は、パーマリンクプラグインの変更も選択肢に入る
プラグイン更新後にログイン不可「ユーザー名またはパスワードが間違っています」と表示される原因と直し方

プラグイン更新後にログイン不可「ユーザー名またはパスワードが間違っています」と表示される原因と直し方

プラグインの更新後、正しいユーザー名とパスワードを入力しているにもかかわらずログインできず「ユーザー名またはパスワードが間違っています」というエラーが表示されるなら、その原因は特定のプラグインが認証フローに干渉したことによる競合だ。特にログインフォームをカスタマイズするプラグインと、追加のセキュリティ認証(Cloudflare Turnstileなど)を組み合わせている場合に発生しやすい。

なぜ正しいパスワードなのに「間違っています」と表示されるのか

なぜ正しいパスワードなのに「間違っています」と表示されるのか

WordPressは通常、ログイン認証を「wp-login.php」を通じて処理している。ここにプラグインが独自のログインフォームを追加したり、認証前にCAPTCHAや追加認証を挟むと、データの送信順序や検証の流れが変わる。プラグインのバージョンアップでこの処理順序が微妙に変わった結果、正しい認証情報がバックエンドの判定に渡る前に「誤り」と判定されるケースが起きる。

典型的なパターンとして、会員制サイト用のプラグイン(Ultimate Memberなど)が生成する独自ログインページと、追加のボット対策機能(Cloudflare TurnstileやreCAPTCHA)が衝突する問題が挙げられる。どちらか一方が先にフォームの値を検証し、もう一方に正しい情報を渡せなくなることが原因だ。

■ エラー発生時の処理の流れ(競合)
ログインフォーム セキュリティ認証(Turnstile) WordPress認証
認証トークンの不一致や情報の欠落が発生 → WordPressが「ユーザー名またはパスワードが間違っています」と誤判定する

まず試す緊急回避策 管理画面に入れない場合の対処

まず試す緊急回避策 管理画面に入れない場合の対処

ログインできない状態では管理画面からプラグインを停止できない。次のいずれかの方法でプラグインを一時的に無効化し、管理画面に再アクセスできるようにする。

FTPやファイルマネージャーでプラグインフォルダの名前を変更する

レンタルサーバーのファイルマネージャーやFTPソフトでサイトのファイルにアクセスし、「/wp-content/plugins/」ディレクトリを開く。問題を起こしているプラグインのフォルダ名を一時的に「_(アンダースコア)」を付けるなどして変更する。WordPressは存在しないプラグインディレクトリを無効化するため、余分な認証処理が外れて本来のログインフローが復活する。

具体的な対象は、直近で更新したプラグインか、ログインフォームをカスタマイズしているプラグインだ。Ultimate Memberのような会員制プラグインや、Cloudflare Turnstileを追加しているプラグインが該当する。

wp-config.phpでプラグインを一括無効化する

FTPでWordPressのルートディレクトリにある「wp-config.php」をダウンロードし、次の一行を「/* 編集が必要なのはここまでです ! */」の直前に追加する。

define('DISABLE_PLUGINS', true);

この状態でファイルを上書きアップロードすると、すべてのプラグインが一時的に無効化される。管理画面にログインできたらこの行を削除し、原因のプラグインだけを停止してから他のプラグインを再有効化する。ただし、この定数は非公式の回避策で、すべての環境で動作するとは限らない点に注意する。

原因となったプラグインの特定と恒久対応

原因となったプラグインの特定と恒久対応

管理画面にログインできたら、プラグイン一覧画面で「直近更新されたプラグイン」を順に停止し、問題が再現するか確認する。特に次の組み合わせに心当たりがあれば、真っ先に疑うべきだ。

  • 独自のログインフォームを提供するプラグイン(Ultimate Memberなど)
  • Cloudflare TurnstileやreCAPTCHAなどの認証機能をログイン画面に追加するプラグイン
STEP 1 プラグイン一覧で更新日時を確認し、直近更新されたプラグインを特定する
STEP 2 そのプラグインの追加認証機能(Turnstileなど)を設定画面で一時的に「無効」にする
STEP 3 シークレットウィンドウでログイン画面を開き、正しくログインできるかテストする
STEP 4 問題が解決したら、プラグインを旧バージョンに戻すか、開発元に不具合を報告する

旧バージョンに戻す方法

プラグインの以前のバージョンは、WordPress公式プラグインディレクトリの「以前のバージョン」セクションからダウンロードできる。プラグインページの下部にある「詳細を見る」→「開発」→「以前のバージョン」の順に進むと、過去のすべての安定版がzipで入手可能だ。管理画面のプラグイン新規追加から手動でアップロードし直すか、FTPで「/wp-content/plugins/」に解凍して上書きすれば戻せる。

Cloudflare Turnstileをそのまま使いたい場合の設定見直し

TurnstileのWidget Modeを「Managed」から「Non-interactive」に変更するか、ログインページだけ設定を除外する方法を試すと競合が緩和されることがある。Cloudflareのダッシュボード側で該当サイトの「Security → Bots → Turnstile」から、Fail-open動作(認証失敗時にアクセスを通す)を有効にするのも有効な回避策だ。

根本原因を理解して今後の更新に備える

根本原因を理解して今後の更新に備える

この問題の本質は、WordPressの認証フック(authenticateフィルター)に対して複数のプラグインが非標準的な順序で割り込んだことにある。WordPressのコア認証は、ユーザー名とパスワードが一致したらWP_Userオブジェクトを返す。しかし追加認証を挟むプラグインは、認証が成功しても「null」を返したり、エラーオブジェクト(WP_Error)に差し替えたりする。バージョンアップでこのフィルターの優先度(priority)が変わると、突然認証が通らなくなるというわけだ。

将来的に同様のトラブルを避けるには、本番環境の更新前にステージング環境で動作確認することが最も確実な対策になる。また、会員制プラグインとセキュリティ認証プラグインの両方を使用している場合は、片方のログイン機能をオフにしてWordPress標準のログインページに一本化するのも安定性を高める選択肢だ。

よくある質問

Ultimate Memberのログインフォームだけエラーになるのはなぜか

Ultimate MemberはWordPress標準の認証処理を大きくカスタマイズし、独自の認証フックを追加している。ここにCloudflare Turnstileのような外部検証が割り込むと、UM側で生成したnonce(ワンタイムトークン)やセッション情報が検証前に消費されたり、書き換えられてしまう。UMはバリデーションが1つでも失敗すると「認証情報が間違っている」と一般化して表示する設計のため、実際のパスワードは合っていてもエラーになる。

プラグインを旧バージョンに戻したがサイトが脆弱にならないか

旧バージョンに戻すことは一時的な対処であり、修正が適用された最新版に更新できるまでの猶予と考えるべきだ。緊急回避の間は、WAF(Webアプリケーションファイアウォール)のルールを厳しくする、ログイン試行回数の制限をかける、IP制限を追加するなど、他の手段で防御を補強しておく。該当プラグインのサポートフォーラムで同様の報告がないか確認し、解決パッチを待つか、開発元に直接報告するのが安全な進め方だ。

Cloudflare Turnstileを完全に外す以外の選択肢はあるか

Cloudflare側の設定で「アクション」を「管理モード」から「監視モード」に変更し、認証を可視化せず裏側でリスク評価だけさせる手がある。また、一部のプラグインでは特定のページ(wp-login.phpなど)だけ検証をスキップするフックが用意されている場合がある。プラグインのドキュメントやフックリファレンスに「bypass turnstile on specific page」の情報がないか探してみるとよい。

管理画面にすら入れない場合、データベースから直接プラグインを無効化できるか

可能だ。phpMyAdminなどでWordPressのデータベースにアクセスし、「wp_options」テーブルの「active_plugins」レコードを編集する。このレコードには有効化されているプラグインの一覧がシリアライズされた配列で保存されている。該当プラグインのパスを削除して保存すれば、そのプラグインだけが無効化される。ただしシリアライズされたデータの文字数カウントを修正する必要があるため、FTPでのフォルダ名変更のほうが手軽で安全だ。

この記事のポイント

  • 正しいパスワードでログインエラーになるのは、認証フックに割り込むプラグインの競合が原因
  • FTPで問題のプラグインフォルダをリネームするか、wp-config.phpで全プラグインを一時停止して管理画面に入る
  • Cloudflare TurnstileやreCAPTCHAの設定をオフにするか、旧バージョンへのダウングレードで即座に解決する
  • 恒久対応は、開発元への不具合報告と、ステージング環境での更新前検証の徹底
  • 同種のプラグインを併用する場合は、WordPress標準ログインページへの統一も検討する
PHP Parse Error unexpected クエスチョンでWordPressが真っ白になる原因と直し方

PHP Parse Error unexpected クエスチョンでWordPressが真っ白になる原因と直し方

「PHP Parse error: syntax error, unexpected ‘?’」が error_log に記録され、WordPress の管理画面を含むサイト全体が真っ白になる症状は、実行環境の PHP バージョンが古すぎて、WordPress コアファイルが記述する構文を解釈できないことが原因だ。とくに wp-includes/compat-utf8.php の 47 行目でエラーになるケースでは、PHP 5.x 系で動作している可能性が高い。サーバーの PHP を 7.4 以上(WordPress 7.0 の動作要件には 8.0 以上が推奨)に切り替えれば、このエラーは即座に解消する。

なぜ compat-utf8.php で unexpected ‘?’ が発生するのか

なぜ compat-utf8.php で unexpected ‘?’ が発生するのか

WordPress のコアファイル compat-utf8.php は、マルチバイト文字列を安全に扱うための互換関数群を収めている。中では null 合体演算子(??)やシンプルな三項演算子が使われる場面があり、これらは PHP 7.0 以降で導入された構文だ。もしサーバーが PHP 5.6 以前のバージョンで動作していると、「?’」の部分で構文エラーが発生し「unexpected ‘?’」というメッセージを吐く。つまり PHP バージョン不足が根本原因になる。

エラーの「expecting variable (T_VARIABLE)」は、処理系が疑問符を見て、本来そこに変数が来るはずの三項演算子の前半部分と誤解したことを示す。古い PHP は「??」を認識できずに文法的に未知のトークンとしてパースエラーを起こす。WordPress 7.0 が標準で要求する PHP バージョンはさらに高く、8.0 以降を推奨するケースも多い。

Before PHP 5.6 で実行
compat-utf8.php で「unexpected ‘?’」
サイト全体が真っ白
After PHP 8.0 に切り替え
エラー消滅、サイトが正常に表示
エラー状態  復旧後

上図のように PHP バージョンが低いとコアファイルの構文エラーで画面が真っ白になり、適切なバージョンにすると何も修正しなくてもその場で直る。

PHP バージョンを確認してサーバーで変更する手順

PHP バージョンを確認してサーバーで変更する手順

最初にサーバーが現在どの PHP バージョンで動いているかを調べ、続いて管理画面からバージョンを切り替える。操作性はレンタルサーバーによって異なるが、多くの場合 cPanel か独自コントロールパネルに PHP セレクターが用意されている。

STEP 1 phpinfo() ファイルで現在の PHP バージョンを調べる
STEP 2 サーバー管理画面の「PHP バージョン選択」で PHP 7.4 以上に切り替える
STEP 3 サイトを再読み込みしてエラーが消えたことを確認する

phpinfo() で現在の PHP バージョンを調べる

サーバーの公開ディレクトリに info.php などのファイルを作り、内容を <?php phpinfo(); ?> にしてブラウザで開く。表示されるページの最上部に「PHP Version」として現在のマイナーバージョンまで確認できる。この値が 5.6 や 7.0 であれば、まさにこの構文エラーを引き起こす原因になっている。

コントロールパネルで PHP バージョンを変更する

cPanel の場合は「Select PHP Version」または「マルチPHP マネージャー」といった項目からドロップダウンで選択し、その場で切り替えが可能だ。PHP 7.4 や 8.0 が用意されていないときは、ホスティング会社のサポートに「PHP のバージョンアップグレードをお願いします」と連絡して対応を依頼する。

WordPress が推奨する動作環境は年々上がっている。WordPress 7.0 であれば PHP 8.0 以降を選択するほうが安全で、プラグインの互換性も考慮してなるべく新しい安定バージョン(8.1 や 8.2)を選ぶとよい。

変更後にサイトが復旧したかどうか確認する

PHP バージョンを切り替えたら、キャッシュが残らないようシークレットウィンドウで管理画面とトップページを開く。真っ白だった画面が正常に表示されれば解決だ。もし引き続きエラーが出る場合は、次節のチェックポイントを試す。

PHP をアップグレードしても直らないときの確認ポイント

PHP をアップグレードしても直らないときの確認ポイント

PHP バージョンが適切でも compat-utf8.php で同じエラーが出るなら、コアファイルの破損や、別の場所から読み込まれた古い互換コードが原因の可能性が残る。

コアファイルを再アップロードして整合性を確かめる

wp-admin と wp-includes ディレクトリ、およびルートのファイルを公式アーカイブからダウンロードし、FTP で上書きする。このとき wp-content は触らない。アップロード後もエラーが出るなら、WP-CLI が使える環境では「wp core verify-checksums」コマンドでファイルの改ざんや破損を検出できる。

wp-content 内のカスタムコードを調査する

まれに mu-plugins(Must Use プラグイン)やテーマの functions.php に記述された互換用のオーバーライドが、古い PHP 構文を含んでいるケースがある。wp-content/mu-plugins を一時的に空にし、子テーマを標準テーマに切り替えてアクセスしてみる。これでエラーが消えたら、該当ファイル内の記述を新しい書き方に書き換える必要がある。

サーバーの .htaccess や php.ini を確認する

特定のディレクトリだけ古い PHP ハンドラが割り当てられている場合、.htaccess に AddHandler や SetHandler で別バージョンが指定されていることがある。推測されるハンドラ名があればコメントアウトして様子を見る。また、php.ini に意図しない設定でバージョン互換モードが指定されていないかも確認する。

よくある質問

エラーメッセージの unexpected ‘?’ と expecting variable は何を意味しているのか

PHP がソースコードを解析する際に、予期しない「?」を見つけて構文エラーを起こしたという意味だ。古い PHP では null 合体演算子(??)が文法として認識されず、単独の疑問符として解釈され「ここには変数が来るべきだ」と報告される。PHP 5.6 以下でしか発生しない典型的なエラーパターンである。

WordPress 7.0 にアップグレードしたらこのエラーが出るのはなぜか

WordPress 7.0 のコアが新たに PHP 7.4 や 8.0 の構文を使い始めたためだ。以前のバージョンでは問題なく動いていても、最新のコアに置き換えた途端に PHP のバージョン要件が上がり、サーバー側が追いついていないと構文エラーが発生する。

レンタルサーバーで PHP バージョンが変更できない場合の対処法は

低スペックの格安プランや古い共用サーバーでは PHP セレクターが提供されていないこともある。その場合はホスティング会社のサポートへ「PHP のバージョンを 7.4 以上に変更してほしい」と申請する。対応してもらえなければ、別のサーバーへの移転も検討する必要がある。

compat-utf8.php 以外のファイルで同じ構文エラーが出た場合も同じ対処でいいのか

はい。ファイル名が異なっていても、unexpected ‘?’ という構文エラーは PHP バージョン不足が原因である可能性が極めて高い。ただ、プラグインやテーマが原因の場合もあるため、エラーが wp-content 配下のファイルで出るならそのプラグインを無効化するか、開発元に PHP バージョン要件を問い合わせるのが早い。

この記事のポイント

  • 画面真っ白と unexpected ‘?’ 構文エラーは PHP 5.x 系で発生しやすい
  • まず phpinfo() で現在の PHP バージョンを調べ、7.4 以上に切り替える
  • サーバー管理画面の PHP セレクターかサポート依頼でバージョンを上げる
  • 切り替え後も直らなければコアファイルの再アップロードと mu-plugins の調査を
  • WordPress 7.0 なら PHP 8.0 以降の利用が推奨される
WordPressでショートコードが表示されず文字列だけ出る時の直し方

WordPressでショートコードが表示されず文字列だけ出る時の直し方

WordPress 7.0 でショートコードが表示されず、角括弧付きの文字列がそのまま画面に出る場合、プラグインの停止・テーマの出力フィルタ不足・ブロックエディタとの相性が主な原因だ。直すにはプラグインの更新や有効化確認から始め、テーマ側で処理されていないときは強制実行のコードを functions.php に追加する。

なぜショートコードが表示されず文字列だけ出るのか

なぜショートコードが表示されず文字列だけ出るのか

ショートコードは [example] のような角括弧で囲まれた短い文字列で、WordPress が表示の瞬間に対応する PHP 処理や HTML に置き換える仕組みだ。この置き換えが行われず、角括弧付きのまま表示される場合、大きく分けて三つの原因が考えられる。

原因1 ショートコードを登録しているプラグインが停止している

プラグインが無効化されているか、WordPress 7.0 への更新後に互換性の問題で停止しているケースが最も多い。更新直後にサイトが「このサイトで重大なエラーが発生しました」という表示になった場合、WordPress は自動で問題のプラグインを停止する。この自動停止によってショートコードの登録処理が丸ごと抜け落ち、文字列だけが残る。

また、プラグインは有効に見えても、特定のページタイプ(固定ページ・投稿・カスタム投稿タイプ)で意図的にショートコードの置換を制限している設計もある。管理画面のプラグイン一覧で有効化状態を確認しても原因がわからないときは、プラグインの内部ロジックまで疑う必要がある。

原因2 テーマが本文中のショートコードを処理していない

ショートコードの置換は do_shortcode() という関数を通じて実行される。WordPress の標準ループやウィジェットエリアでは自動で処理されるが、テーマがカスタマイズされたテンプレートで直接 get_post_meta()the_content() を独自に加工している場合、この関数が呼ばれずショートコードが展開されない。とくに自作テーマや子テーマでカスタムフィールドの値を表示する箇所で起きやすい。

原因3 ブロックエディタの「ショートコードブロック」未使用

WordPress のブロックエディタ(Gutenberg)でショートコードを機能させるには、専用の「ショートコード」ブロックの中に記述する必要がある。段落ブロックや見出しブロックに直接 [example] と打ち込んだ場合、ブロックの保存・出力の仕様によってはテキストとしてそのまま表示されることがある。クラシックエディタに慣れていると見落としがちなポイントだ。

ショートコードが表示されないときの原因3分類
原因 A プラグインが無効化または停止している
原因 B テーマが do_shortcode() を呼んでいない
原因 C ブロックエディタでショートコードブロックを使っていない
プラグイン停止  テーマ側の処理不足  ブロック種別の選択ミス

上図の三方向から原因を絞り込めば、ほとんどのケースで該当箇所が見つかる。次項からは実際の対処手順を具体的に解説する。

ショートコードが機能しないときの具体的な対処手順

ショートコードが機能しないときの具体的な対処手順

手順1 プラグインの有効化と更新を確認する

管理画面の「プラグイン」→「インストール済みプラグイン」を開き、該当プラグインが有効化されているかを確認する。無効化されていれば「有効化」をクリックするだけで解決することが多い。有効化されているのに直らない場合は、プラグインの最新バージョンがリリースされていないか更新画面を確認する。WordPress 7.0 へのメジャーアップデート直後は、プラグイン開発者が緊急の互換性アップデートを出している可能性が高い。

管理画面にアクセスできないほどサイトが壊れている場合は、WordPress の「リカバリモード」を利用する。サイトで致命的エラーが発生すると、管理者メールアドレス宛に「このサイトで重大なエラーが発生しました」という件名のメールが届き、その中にリカバリモード用の特別なログインリンクが記載されている。このリンクからログインすると、問題のプラグインだけが停止した状態で管理画面に入れる。

手順2 テーマ側で do_shortcode() を明示的に実行する

プラグインが正常に動作しているのにショートコードが展開されない場合、テーマのテンプレートが原因だ。該当のショートコードを表示したい箇所がカスタムフィールドやウィジェットエリア内であれば、テンプレートファイル内の出力部分に do_shortcode() を追加する。

// カスタムフィールドの値をショートコード展開して出力
echo do_shortcode( get_post_meta( get_the_ID(), 'my_custom_field', true ) );

// 本文中のショートコードを意図的に再実行(通常は不要だが保険として)
echo do_shortcode( get_the_content() );

上記は functions.php ではなく、該当のテンプレート(single.phppage.php など)の出力箇所に追記するコードだ。子テーマを使っていない場合は必ず子テーマを用意してから編集し、テーマのアップデートで変更が失われないようにする。子テーマの作り方は後述の FAQ で扱う。

手順3 ブロックエディタで「ショートコード」ブロックを使う

ブロックエディタでページを編集している場合、ブロック挿入ツール(+ボタン)から「ショートコード」ブロックを検索して追加する。既存の段落ブロックに直接ショートコードを打ち込んでいる場合は、そのブロックを削除して新しくショートコードブロックを追加し、中にショートコード文字列だけを入力する。

STEP 1 ブロック挿入ツール(+)をクリック
STEP 2 「ショートコード」ブロックを検索して追加
STEP 3 ブロック内にショートコード(例: [example])を入力
STEP 4 プレビューまたは公開して表示を確認

この手順でブロックエディタ上の問題は解決するが、テーマ側の出力処理に起因する問題はこれだけでは直らない。手順2も併せて確認するのが確実だ。

WordPress 7.0 特有の注意点と想定外のエラーへの備え

WordPress 7.0 特有の注意点と想定外のエラーへの備え

WordPress 7.0 は内部のエラーハンドリングが強化され、従来は警告レベルで済んでいた処理が致命的エラーとして扱われるケースが増えている。プラグインが最新でも、内部の非推奨関数の呼び出しや PHP バージョンとの不一致があると、サイト全体がダウンし管理画面からも締め出される。

こうした状況では、FTP またはサーバーのファイルマネージャーで /wp-content/plugins/問題のプラグインフォルダ/ を一時的にリネームする方法が最も確実な緊急回避策になる。フォルダ名を「custom-profile-picture」から「custom-profile-picture_temp」などに変更すれば、WordPress はそのプラグインを検出できなくなり、サイトが正常に表示される状態まで復帰する。その後、プラグインの互換性情報を確認してから正式な対処を取る。

よくある質問

ショートコードを使うプラグインをアップデートしたらサイトが真っ白になった

WordPress 7.0 とプラグインの互換性が取れていない可能性が高い。リカバリモードのリンクがメールで届いていればそこからログインし、問題のプラグインを停止する。メールが届いていない場合は FTP で対象プラグインのフォルダをリネームし、管理画面にアクセスできる状態に戻してから代替プラグインを検討する。

子テーマの functions.php に追記する方法がわからない

子テーマとは、親テーマの機能を引き継ぎつつ安全にカスタマイズするための仕組みだ。まず親テーマと同じディレクトリに子テーマ用フォルダを作成し、style.cssfunctions.php の2ファイルを設置する。functions.php には親テーマのスタイルを読み込むコードと、do_shortcode() を含むカスタマイズコードを記述する。詳細な手順は WordPress 公式の子テーマ作成ガイドが役立つ。

ショートコードブロックを使っても特定のページだけ表示されない

キャッシュ系プラグインや CDN が原因のことが多い。キャッシュを全削除し、CDN を使用している場合は一時的に開発モードにしてから表示を確認する。また、該当ページがカスタム投稿タイプで、テンプレートが専用の出力処理をしている場合も同様に do_shortcode() の追加が必要になる。

プラグインを更新したが問題が再発した

更新で一度直っても、WordPress の自動エラーハンドリングが再度働いて同じプラグインを停止することがある。サーバーのエラーログを確認し、PHP のメモリ不足や実行時間制限が原因であれば、wp-config.phpWP_MEMORY_LIMIT を 256M 以上に設定する。根本的にはプラグイン開発者の対応を待つ必要があるケースもある。

この記事のポイント

  • ショートコードが文字列のまま表示される主因はプラグイン停止・テーマの処理不足・ブロック選択ミスの3つ
  • 管理画面に入れない場合はリカバリモードか FTP でプラグインフォルダをリネームして復旧させる
  • テーマ側で do_shortcode() が呼ばれていない箇所は子テーマのテンプレートに追記する
  • ブロックエディタでは必ず「ショートコード」専用ブロックの中に記述する
  • WordPress 7.0 はエラーハンドリングが強化され互換性問題が表面化しやすい
WP All Importで物件画像が混ざる原因とファイル名の一意化による解決方法

WP All Importで物件画像が混ざる原因とファイル名の一意化による解決方法

WP All Import で物件情報をインポートした際、他の物件の画像が表示される不具合は、画像ファイル名の重複と画像マッチング設定の不備が主な原因だ。この問題は、WP All Import のファイル名指定で一意の名前を生成し、画像マッチングルールを適切に設定することで解決できる。

WP All Import でインポートした画像が混ざる原因は何か

WP All Import でインポートした画像が混ざる原因は何か

WP All Import は XML フィードから画像をダウンロードし、メディアライブラリに追加する。ここで「すでに同じファイル名の画像がメディアライブラリに存在する」と、意図せず既存の画像を参照してしまうことがある。特に検索やマッチングをすべてオフにしていても、ファイル名の衝突が発生すると新規ダウンロードをスキップして既存画像にリンクを張る挙動が起こりうる。これが、異なる物件で同じ画像が表示される最大の原因だ。

もう一つの原因は、Houzez テーマやそのアドオンがインポート後に画像ギャラリーを再構築する際、メディアライブラリ内の添付ファイルの親子関係やメタデータを誤って上書きしてしまうケースだ。プレビュー段階では正しいのに、インポート完了後に別の物件の画像に差し替わるのは、インポート後のテーマ側の処理タイミングで画像の紐付けがずれるために起こる。

画像ファイル名を一意にして他物件との画像混入を防ぐ方法

画像ファイル名を一意にして他物件との画像混入を防ぐ方法

WP All Import では、インポートテンプレートの「画像」セクションで、保存時のファイル名をカスタマイズできる。ここで物件ごとに絶対に重複しない名前を付けるのが最も確実な対策だ。具体的には、物件 ID や MLS 番号、住所の一部など、XML 内のユニークな要素をファイル名に組み込む。

Before 重複しやすい設定
ファイル名指定 {filename}.jpg
↓ XML に「1.jpg」「1.jpg」… 重複発生
After 一意になる設定
ファイル名指定 {mls_id[1]}_{typename[1]}_{index}.jpg
↓ 物件ごとに絶対衝突しない
重複危険  一意保証

上のデモのように、{mls_id} や {property_id} といった絶対に重複しないフィールドをファイル名に含める。インポート時に「既存画像を保持」の設定をオフにしていても、ファイル名が重複すると WordPress 本体側で「ファイル名-1」「ファイル名-2」のように連番サフィックスが付与されることがあり、このサフィックス付きファイル名を Houzez アドオンが正しく追跡できない場合もある。ファイル名の段階で完全にユニークにしておけば、そのリスクも回避できる。

WP All Import の画像マッチング設定を適切に構成する

WP All Import の画像マッチング設定を適切に構成する

現在「すべてオフ」の状態は、一見すると毎回新規ダウンロードされそうに見えるが、実際にはファイル名の重複や WordPress の内部キャッシュによって想定外のマッチが起こりうる。以下の設定を見直す。

画像 URL またはファイル名でのマッチを有効にする

「Match image by URL」をオンにすると、WP All Import は XML 内の画像 URL とメディアライブラリ内の元 URL メタデータを照合し、すでに同じ URL からダウンロードされた画像があれば再利用し、なければ新規ダウンロードするという明確な挙動になる。「すべてオフ」よりも意図が明確で、混入が防ぎやすい。

Search Media Library for existing images の使い所

この設定は、ファイル名やタイトルで既存画像を検索する。ファイル名が重複しがちな構成ではオフのままが安全だが、ファイル名を一意にしたうえでオンにすれば、再インポート時の二重ダウンロードを防ぎつつ正確にマッチできる。画像ファイル名の一意化が完了しているなら、ここをオンにして「既存画像の検索」に任せるのも選択肢になる。

First image set as Featured Image の副作用に注意する

この設定がオンの場合、WP All Import と Houzez アドオンがそれぞれ「アイキャッチ画像」を設定しようとして、2つの処理が干渉することがある。画像の入れ替わりが激しいなら、いったんこの設定をオフにして、Houzez アドオン側にアイキャッチ設定を任せてみる。それで安定するなら、アドオン側の処理が優先される構成に統一する。

Houzez アドオンとテーマ側の画像処理を確認する

Houzez アドオンとテーマ側の画像処理を確認する

Houzez アドオンはインポート後に物件ギャラリーやアイキャッチ画像を再構成する独自の処理を行う。この処理が WP All Import のメディアライブラリ操作と競合し、別の物件の画像を拾ってしまうことがある。特に再インポート時に、アドオンが「物件に紐づく既存画像」を誤ったロジックで上書きするパターンが報告されている。

アドオンの画像処理フックを一時停止して検証する

子テーマの functions.php に以下のコードを一時的に追加し、Houzez アドオンの画像処理をスキップしてインポート結果が正しくなるかテストする(テスト後は必ず削除する)。

// テスト用 インポート後の Houzez 画像処理を無効化
add_action('init', function() {
    if (class_exists('Houzez_Property_Feed')) {
        remove_all_actions('pmxi_after_xml_import');
        remove_all_actions('pmxi_saved_post');
    }
}, 99);

これで画像の混入が止まるなら、Houzez アドオン側の処理が原因だ。その場合、アドオンの最新バージョンへのアップデート、または Houzez 公式サポートに「WP All Import インポート後の画像上書き」の修正を依頼する。アドオンのバージョンが古いと、WP All Import の最新 API との互換性が崩れていることがある。

再インポート前にメディアライブラリの紐付けをリセットする

WP All Import で「既存の投稿を更新」する形で再インポートする場合、過去のインポートで作られたメディアの紐付け(post_parent やメタデータ)が残っていると、新しい画像が正しく割り当てられない。この場合は、一度該当の物件投稿と画像の紐付けを手動で外すか、WP All Import 実行前に該当物件の画像をメディアライブラリから削除してから再インポートすると、クリーンな状態で画像が再構築される。

Amazon S3 Offload 使用時の画像混入を防ぐ

Amazon S3 Offload 使用時の画像混入を防ぐ

Amazon S3 Offload(WP Offload Media 等)を使用している場合、メディアライブラリの画像実体は S3 に移動され、ローカルにはメタデータだけが残る。この状態で WP All Import が「同じファイル名」の画像を処理しようとすると、S3 上の URL とメディアライブラリのメタデータに不整合が生じ、参照がずれることがある。

S3 Offload の URL 書き換えタイミングを確認する

WP Offload Media はアップロード後に URL を書き換えるが、このタイミングが WP All Import のインポート後処理や Houzez アドオンのギャラリー構築タイミングと重なると、書き換え前のローカル URL が一時的に保存されてしまう。S3 Offload プラグインが「非同期処理」や「スケジュール処理」で URL を更新する設定になっているなら、同期処理に切り替えて、インポート完了までにすべての URL が書き換わるようにする。

インポート中は S3 Offload を一時停止する

大量インポート時は、WP Offload Media のアップロードフックを一時的に停止して、WP All Import のインポートが完全に終わったあとに手動で一括オフロードする方法も有効だ。インポートスクリプトの先頭でオフロードを無効化し、完了後に再有効化するワークフローにすると、混入リスクをほぼゼロにできる。

よくある質問

Preview では正しいのに本番インポートで画像が混ざるのはなぜか

Preview は実際のダウンロードとメディアライブラリ登録をスキップし、XML の URL だけを表示する仕組みだ。本番インポートではメディアライブラリへの保存が行われ、このときにファイル名衝突やテーマの後処理が発動して画像が入れ替わる。この違いが「Preview では正しいのに本番で壊れる」現象の正体だ。

画像が混ざった物件を一括で修正できるか

WP All Import の「既存の投稿を更新」機能を使い、画像フィールドだけを再インポートすることで一括修正できる。その際、ファイル名の一意化とマッチング設定の見直しを事前に済ませておく必要がある。メディアライブラリに重複画像が大量にある場合は、一度不要画像を一括削除してから再インポートすると確実だ。

Houzez テーマ以外でも同じ問題は起こるか

起こる。WP All Import とテーマ付属の独自インポートアドオンが競合する構図は、不動産テーマ(HomePress、RealHomes 等)や EC(WooCommerce の WP All Import アドオン)でも報告されている。基本的な対策であるファイル名の一意化とマッチング設定の見直しは、どのテーマでも有効だ。

画像 URL にクエリパラメータが付いている場合の注意点はあるか

URL の末尾に ?w=800&h=600 のようなパラメータが付いていると、WP All Import が「別の画像」として認識せず、パラメータ部分を無視してファイル名を生成するため重複が起きやすい。URL マッチングを使用する場合も、パラメータ除去後のベース URL で照合されるため、意図したマッチが働かないことがある。可能なら XML 側でクエリパラメータのないクリーンな URL を用意するのが望ましい。

メディアライブラリの画像が増えすぎないか心配だ

ファイル名の一意化と画像 URL マッチングを適切に設定すれば、同じ URL の画像はメディアライブラリに一度だけ保存されて再利用される。重複ダウンロードが起きていたのは、ファイル名衝突によって新規保存と既存参照が混在していたためで、設定を見直せばメディアライブラリの肥大化も抑えられる。

この記事のポイント

  • 画像混入の主因はファイル名重複とマッチング設定の不備
  • XML 内のユニーク ID をファイル名に組み込む
  • 画像 URL マッチングをオンにして明確な挙動にする
  • Houzez アドオンの画像処理競合はフック停止で検証
  • S3 Offload 使用時は同期処理への切り替えが安全
WP Extendedのスニペット一覧が真っ白になった時のファイル復旧方法

WP Extendedのスニペット一覧が真っ白になった時のファイル復旧方法

WP Extended の管理画面でコードスニペットの一覧が突然真っ白になり、まったくアクセスできなくなっても、作成したスニペット本体はサーバー上に PHP ファイルとして残っている。慌てずに /wp-content/wpextended-snippets ディレクトリを開き、必要なコードを取り出せばよい。本記事ではファイルの所在確認からコードの復旧、別環境への移し替えまでを具体的に示す。

なぜ WP Extended のスニペット一覧が表示されなくなったのか

なぜ WP Extended のスニペット一覧が表示されなくなったのか

WP Extended のようなコードスニペット管理プラグインで一覧画面が機能しなくなる原因は、プラグイン自体の不具合というより、特定の環境下での PHP エラーやデータベースの不整合によるところが大きい。特に有効化したスニペットに文法エラーがあると、管理画面全体が「このサイトで重大なエラーが発生しました」といった真っ白な画面に陥るケースもある。実際の管理画面が表示されなくなった時の典型的な引き金は次のとおりだ。

  • 直前に有効化したスニペット内の PHP コードに誤りがある
  • プラグイン本体の更新と WordPress 本体または PHP バージョンとの相性問題
  • 他のプラグインとの競合で管理画面の読み込みが途中で止まる
  • サーバーのメモリ制限やファイル権限の問題でスニペットディレクトリを読み取れない

いずれにしても、スニペット一覧が見えなくなったからといって、作成したコードが消えたわけではない。WP Extended は各スニペットを wp-content ディレクトリ内に実ファイルとして保存しているため、管理画面が動作しなくてもサーバー側から直接回収できる。

スニペットの実体はどこに保存されているのか

スニペットの実体はどこに保存されているのか

WP Extended が保存するスニペットの実ファイルは、WordPress インストール先の wp-content/wpextended-snippets ディレクトリに置かれている。個々のスニペットは snippet-XX.php といった名前の独立した PHP ファイルになっており、コード本体のほかスニペット名や優先度などのメタ情報がコメントとして残っていることも多い。

↓ よくあるディレクトリ構成
/wp-content/
└─ wpextended-snippets/
    ├─ snippet-1.php
    ├─ snippet-2.php
    └─ snippet-3.php
※ 管理画面からアクセスできなくても、この場所をサーバー上で直接開けばスニペットのコードを取り出せる

サーバー上の PHP ファイルからスニペットのコードを回収する手順

サーバー上の PHP ファイルからスニペットのコードを回収する手順

管理画面が使えなくても、レンタルサーバーのファイルマネージャーか SFTP クライアントを使えばスニペットの実体にアクセスできる。全体の流れは以下のデモのとおりだ。

STEP 1 SFTP またはファイルマネージャーでサーバーにログインする
STEP 2 wp-content/wpextended-snippets ディレクトリを開く
STEP 3 スニペットの PHP ファイルをローカルにダウンロードする
STEP 4 エディタでファイルを開き、中身の PHP コードをコピーする

ファイルマネージャーを使う場合

多くの国内レンタルサーバーが提供しているブラウザ上のファイルマネージャーを開き、wp-content フォルダへ移動して wpextended-snippets を探す。目的のスニペットがどれかわからない場合は、すべての PHP ファイルを一旦ダウンロードし、ローカルで中身を確認すればよい。

SFTP クライアントでアクセスする場合

FileZilla などの SFTP クライアントを使い、ホスト名・ユーザー名・パスワード(または SSH 鍵)で接続する。接続後、リモートサイト側のディレクトリツリーから wp-content/wpextended-snippets へ進み、ファイルを一括ダウンロードする。権限不足で開けない場合は、サーバー管理画面からファイルのパーミッションを 755 に修正する。

取り出した PHP コードを別のスニペット管理プラグインへ移す

取り出した PHP コードを別のスニペット管理プラグインへ移す

ダウンロードしたファイルをテキストエディタで開くと、WP Extended が自動生成したヘッダコメントに続いて実際の PHP コードが記述されている。スニペットの中身だけをコピーし、別のコードスニペット管理プラグイン(例: 無料の Code Snippets プラグイン)に貼り付ければすぐに再利用できる。

Before
WP Extended の管理画面でスニペット一覧が空白のまま操作不能
After
サーバーから回収したコードを別のスニペット管理画面に登録し、正常に動作中
Before(問題発生時)  After(復旧後)

スニペットを Code Snippets に移す場合の注意点

Code Snippets のような別のプラグインに移すときは、コピーした PHP コードをそのまま新規スニペットとして貼り付ける。ただし、WP Extended では「フロントエンドのみ実行」「管理画面のみ実行」といった実行条件を設定している場合、それらを移行先プラグイン側で改めて指定し直す必要がある。条件が無く単純な functions.php 的コードであれば、貼り付けて保存するだけですぐに動く。

子テーマの functions.php に直接書く方法

スニペットの数が少なく、なおかつテーマの関数として常時読み込ませて構わない場合は、子テーマの functions.php に直接コードを転記するという手もある。ただし、テーマを切り替えると動作しなくなるため、サイト全体で使うコードは専用プラグインとしてまとめるほうが管理しやすい。

同じ問題が再発しないようにするための対策

同じ問題が再発しないようにするための対策

WP Extended の管理画面が再び使えなくなる事態を防ぐには、以下の点を普段から意識しておくことが重要だ。

  • スニペットを新規追加・有効化する直前は、必ずローカルやステージング環境で動作確認する
  • プラグイン本体や WordPress 本体を更新する前に、スニペットのバックアップ(ディレクトリごとダウンロード)を取る
  • PHP エラーログを定期的に確認し、構文エラーが残っていないか点検する
  • 別のコード管理プラグインへの移行を検討する場合、スニペットのエクスポート機能が無いか事前に調べる

よくある質問

管理画面が真っ白で wpextended-snippets ディレクトリも見つからない

WordPress のインストール先がサブディレクトリになっている可能性がある。サーバールートではなく、WordPress を設置したフォルダ(例: public_html/wp/)の中を確認する。また、何らかの理由でプラグインが削除されているとディレクトリごと消えている場合があるため、事前にバックアップが無いかレンタルサーバーの管理画面を調べる。

PHP ファイルの中身をコピーしても新しいプラグインで動作しない

多くの場合、スニペットが <?php 開始タグなしで保存されているか、WP Extended 独自の定数やフィルターフックに依存していることが原因だ。コードの先頭に <?php を付け、必要なフック(add_actionadd_filter)が正しく記述されているか見直す。

WP Extended を再インストールしたらスニペットは戻るのか

プラグインを一度アンインストールすると、wpextended-snippets ディレクトリやデータベースの情報が削除される可能性がある。そのため、再インストール前に必ずスニペットファイルのバックアップを取っておく。バックアップが無ければ、サーバーのバックアップサービスからの復元が必要になる。

スニペットが複数あり、どれが目的のコードかわからない

ファイル名だけでは判別が難しいため、全ての PHP ファイルを一度ローカルにダウンロードし、エディタで内容を確認する。WP Extended のヘッダ部分にスニペット名が書かれていることが多いので、それを手がかりに必要なファイルを特定する。

この記事のポイント

  • WP Extended のスニペット一覧が見えなくなっても、ファイルは wp-content/wpextended-snippets に残っている
  • サーバーのファイルマネージャーまたは SFTP で PHP ファイルを回収できる
  • 回収したコードは別のスニペット管理プラグインや子テーマに移せる
  • 事前のバックアップとテストで同じトラブルを防げる
メガメニューのスタイルが崩れた時の原因と直し方

メガメニューのスタイルが崩れた時の原因と直し方

プラグイン更新後にメガメニューのスタイルが崩れ、一部のナビゲーション項目が表示されなくなった場合、まずは以前のバージョンへの巻き戻しと全キャッシュの削除を試みる。この2つで多くのケースは即座に復旧する。

なぜプラグイン更新後にメガメニューのスタイルが崩れるのか

なぜプラグイン更新後にメガメニューのスタイルが崩れるのか

メガメニュープラグインは、独自の CSS と JavaScript を読み込んでスタイルを適用している。アップデートによってこれらのファイル構成が変更されると、ブラウザやサーバーに残った旧バージョンのキャッシュが新バージョンのスタイルと衝突し、見た目が崩れることがある。

また、プラグイン内部で HTML 構造が変更された場合、テーマ側で追加したカスタム CSS のセレクタが合わなくなり、スタイルが外れてしまうケースも少なくない。これが「項目が完全に見えなくなる」原因になることもある。具体的には、項目を非表示にする CSS ルール(display:none など)が誤って適用されたり、z-index の競合で他の要素の裏に隠れたりする。

メガメニューの崩れを直す緊急対処の流れ

メガメニューの崩れを直す緊急対処の流れ

まずはサイトの表示に直接影響するキャッシュをすべて取り除き、それでも直らなければプラグインを以前のバージョンに戻す。この順序で作業すると、無駄な切り分けを減らせる。

STEP 1 ブラウザキャッシュとサーバーキャッシュを完全に削除する
STEP 2 キャッシュ系プラグインで CSS と JS を再生成する
STEP 3 改善しなければプラグインを旧バージョンに巻き戻す
STEP 4 自動更新を一時停止して修正版のリリースを待つ

キャッシュを完全に除去する手順

まず Chrome や Firefox のデベロッパーツールを開き、ネットワークタブで「キャッシュを無効化」にチェックを入れた状態で再読み込みする。これでブラウザキャッシュ由来の崩れかどうかをすぐに確認できる。改善したらブラウザキャッシュが原因だ。

次に WordPress の管理画面から、使用しているキャッシュ系プラグイン(WP Rocket や W3 Total Cache など)の設定画面を開き、「キャッシュをすべて削除」を実行する。さらに「CSS の最適化」や「JavaScript の結合」機能が有効なら、一度無効化してからキャッシュを再生成する。結合・最適化の過程で生まれた旧ファイルが新バージョンと衝突している可能性があるためだ。

サーバーレベルで Nginx や Varnish を使っている場合は、ホスティングのコントロールパネルからサーバーキャッシュもフラッシュする。

プラグインを以前のバージョンに巻き戻す

キャッシュの完全削除でも直らないときは、アップデートそのものに互換性の問題があると判断してよい。メガメニュープラグインを無効化し、旧バージョンの ZIP ファイルを入手して手動で上書きする。

旧バージョンはプラグインの公式ページにある「以前のバージョン」セクションや、開発者向けの SVN リポジトリからダウンロードできる。管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP を選び、「既存のものを置き換える」形でインストールする。上書き後、管理画面でバージョン表記が古くなっていれば成功だ。

この作業でメガメニューが復旧したら、一時的に自動更新を停止しておく。プラグイン一覧画面や wp-config.php に define('WP_AUTO_UPDATE_CORE', false); を追加する方法もあるが、該当プラグインだけを止めるにはプラグイン単位の自動更新を無効化するコードを functions.php に書くか、管理プラグインを使う。

項目がまるごと消える問題の原因を切り分ける

項目がまるごと消える問題の原因を切り分ける

スタイル崩れだけでなく、メニュー項目のひとつが完全に非表示になるケースでは、CSS の display プロパティや visibility プロパティが悪さをしていることが多い。HTML 構造が変わった結果、テーマ側で追加したカスタム CSS が意図しない要素を非表示にしている可能性がある。

デベロッパーツールで非表示の原因を特定する

Chrome の検証機能で消えたメニュー項目の HTML 要素を探す。要素が見つかるのに画面に出ていない場合は、右側の「スタイル」パネルで display:nonevisibility:hidden が適用されていないか確認する。該当プロパティがあれば、打ち消し線が入っているか、どの CSS ファイルの何行目から来ているかが表示される。

もしテーマの style.css や追加 CSS に身に覚えのないルールがあれば、そのセレクタがアップデート後の HTML に誤ってマッチしている可能性が高い。一時的にそのルールをコメントアウトして表示が復活するかを試すと、原因の特定が早い。

テーマとプラグインの競合を調べる

メガメニュープラグインのアップデート後に問題が起きた場合、テーマ側のメニュー処理と競合していることも考えられる。一時的に標準テーマ(Twenty Twenty-Five など)に切り替えて、メニューが正常に表示されるか確認する。標準テーマで問題なければ、テーマ側のカスタマイズや専用のメニュー関数が干渉していると判断できる。

Before(エラー状態)
メニュー項目「会社概要」が表示されず、他の項目もスタイルが崩れている
After(標準テーマで検証後)
全項目が正しく表示され、スタイルも元に戻る。テーマ側の干渉と特定
エラー状態  標準テーマで正常化

再発を防ぐためのアップデート前チェックリスト

再発を防ぐためのアップデート前チェックリスト

メガメニューのようなサイト全体の導線を担うプラグインは、更新ひとつで売上や問い合わせに影響が出る。以下の手順を踏んでおけば、今回のようなスタイル崩れを未然に防げる。

  • ステージング環境で事前にアップデートを検証する
  • テーマのカスタム CSS はメガメニューのクラス名に依存しすぎない
  • 更新前に必ずサイト全体のバックアップを取る
  • キャッシュ系プラグインの設定を更新後に見直す習慣をつける

特に、ステージング環境での事前検証は手間に見えて最も確実な安全策だ。多くの国内レンタルサーバーはワンクリックでステージングを作れる機能を備えている。更新後、メニューの表示やモバイルでの開閉動作を一通りチェックしてから本番に反映すれば、今回のような急なスタイル崩れでサイトが長時間壊れる事態を回避できる。

よくある質問

旧バージョンの ZIP が見つからない場合はどうする?

プラグインの公式ディレクトリページ下部にある「以前のバージョン」からダウンロードできないケースでは、開発者の公式サイトや GitHub リポジトリを探す。WP Rollback のようなプラグインを使えば、管理画面から直接過去のバージョンに切り替えられる場合もある。

キャッシュを削除しても直らないのはなぜ?

サーバー側のキャッシュに加え、CDN を使用している場合は CDN のキャッシュもパージする必要がある。また、ブラウザの Service Worker が古いファイルを保持していることもあるので、シークレットウィンドウで確認するか、デベロッパーツールから Service Worker の登録を解除する。

アップデートを戻したのに一部のスタイルが直らない

旧バージョンに戻した後も、キャッシュ系プラグインが生成した最適化済み CSS ファイルが残っている可能性がある。「CSS の再生成」や「クリティカル CSS の削除」も実行する。さらに、テーマ側のカスタマイザーで追加した CSS が悪さをしていないか、追加 CSS 欄を一時的に空にして確認する。

修正版がリリースされるまでどう運用すればよい?

プラグインの自動更新を停止し、旧バージョンのままサイトを運用する。管理画面の「更新」通知は無視して問題ない。修正版が公開されたら、最初にステージング環境でテストし、スタイルや項目の表示に問題がないことを確認してから本番に適用する。

この記事のポイント

  • プラグイン更新後のメガメニュー崩れはキャッシュの完全削除から試す
  • 改善しなければ旧バージョンに巻き戻し、自動更新を一時停止する
  • 項目消失は CSS の意図しない適用が原因になりやすい
  • テーマとの競合を疑う場合は標準テーマで切り分ける
  • 再発防止にはステージング環境での事前検証が最も有効
Kadence BlocksのナビゲーションAdvブロックでフォント設定が効かない時の直し方

Kadence BlocksのナビゲーションAdvブロックでフォント設定が効かない時の直し方

Kadence Blocks のナビゲーション(Adv)ブロックでフォントサイズや太字の設定が反映されず、文字が意図したスタイルにならない現象の原因は、プラグイン側のバグだ。Kadence Blocks 7.3.3 以降のバージョンでは、ブロックが出力するインライン CSS に {{ のような余分な二重括弧が混入し、ブラウザが CSS のパースに失敗して該当の装飾が丸ごと無効になる。この問題はカスタマイズを台無しにするが、Kadence Blocks を 7.3.2 以前の安定版に戻せば即座に直る

なぜナビゲーションAdvブロックのフォント設定だけが消えるのか

なぜナビゲーションAdvブロックのフォント設定だけが消えるのか

ブロックエディター上や公開サイトで、ナビゲーションメニューの文字サイズが指定したとおりに表示されず、標準テーマのデフォルト値に戻ってしまう。検証ツールで要素に付与されているインラインスタイルを見ると、次のような壊れた CSS が埋め込まれていることが確認できる。

Before(エラー状態)
.kb-nav-link-319_9f80b8-fd > /*…*/ .kb-nav-link-content{{font-size:var(–global-kb-font-size-md, 1.25rem);}}
二重に重なった中括弧があるため、ブラウザがこの行全体を正しいCSSとして認識できない
After(修正後)
.kb-nav-link-319_9f80b8-fd > /*…*/ .kb-nav-link-content{font-size:var(–global-kb-font-size-md, 1.25rem);}
正規の中括弧だけになるので、フォントの装飾が有効に戻る
エラー状態  正しいCSS

このデモで示したとおり、本来は {…} であるべきブロックのスタイル指定が、バグにより {{…}} と出力されてしまう。この形式はブラウザの構文解析でエラー扱いされ、font-size や font-weight がまったく適用されなくなる。Kadence ナビゲーション(Adv)ブロックを使っているメニューすべてで発生し、管理画面のブロックエディター上でもプレビューが崩れてしまうのが典型的な兆候だ。

ナビゲーションAdvブロックの表示崩れを直す手順

ナビゲーションAdvブロックの表示崩れを直す手順

根本原因は Kadence Blocks 7.3.3 以降のコードにある。修正アップデートがリリースされるまで、自力で解決するには古い安定バージョンにプラグインを差し戻すのが確実かつ短時間で終わる方法だ。サーバーをいじる必要はなく、WordPress 管理画面の操作だけで完了する。

現在の Kadence Blocks のバージョンを確認する

「プラグイン」→「インストール済みプラグイン」で Kadence Blocks 、 Gutenberg Blocks for Page Builder Features を探す。バージョン番号が 7.3.3 以上であれば、この不具合の影響を受けている可能性が高い。日本語環境では「Kadence Blocks(旧 Kadence Gutenberg Blocks)」と表記される場合もある。

一度 Kadence Blocks を削除せずにダウングレードするための準備

WordPress の仕様上、管理画面から直接古いバージョンを上書きインストールすることはできない。必ず一度無効化と削除を行い、その後 7.3.2 以前の ZIP ファイルを手動でアップロードする流れになる。ただし、削除してもデータベースに保存されているブロックの設定は消えないため、再度同じプラグインを導入すれば以前のデザインは保持される。

STEP 1 Kadence Blocks をライブラリから削除する
STEP 2 旧バージョンのZIPを入手し、アップロードしてインストール
STEP 3 有効化してサイトキャッシュを削除すれば完了

STEP 1:Kadence Blocks を無効化して削除する

「プラグイン」画面で Kadence Blocks を無効化し、続けて削除を実行する。「本当に削除してもよいか」という確認画面では、そのまま操作を進めて問題ない。削除によってブロックのレイアウトデータが消えることはなく、再度インストールすれば以前の状態に復元される。

STEP 2:7.3.2 以前のバージョンを手動でインストールする

WordPress.org の Kadence Blocks プラグインページにアクセスし、「アドバンスビュー」から「バージョンを選択」のドロップダウンで 7.3.2 を選び、ZIP ファイルをダウンロードする。バージョン一覧のURLは https://wordpress.org/plugins/kadence-blocks/advanced/ の末尾からアクセスできる。ダウンロードしたら「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP を選択し、「今すぐインストール」を実行する。

STEP 3:有効化してキャッシュをクリアする

インストール完了後、忘れずに Kadence Blocks を有効化する。続いて、サイトのキャッシュ系プラグイン(W3 Total Cache や WP Super Cache など)で全キャッシュを削除し、ブラウザのキャッシュもリロードして最新の状態を確認する。これでナビゲーションAdvブロックのフォント設定が元どおり反映されるはずだ。

ダウングレードが難しい場合の応急策と今後の注意点

WordPress の自動更新を一時的に停止しておく

Kadence Blocks に限らず、プラグインの自動更新が有効になっていると知らないうちにバグのあるバージョンに上がってしまい、同じ現象が再発する。とくに本番サイトでは「プラグイン」→「インストール済みプラグイン」の各プラグインに表示される「自動更新を有効化」のチェックが外れている状態を推奨し、アップデートはステージング環境で検証してから手動で行う習慣が安心だ。

プラグイン側の修正パッチを追う

この二重括弧の不具合は Kadence Blocks の無料版でも再現する純粋なバグのため、開発者のもとですでに修正が進められている可能性が高い。公式の変更履歴(Changelog)を定期的に確認し、次の安定版リリースがあれば速やかに導入することが基本となる。

よくある質問

ダウングレードしたがまだフォントが反映されない

ブラウザキャッシュや CDN のキャッシュに古いスタイルシートが残っているケースだ。シークレットウィンドウで表示確認するか、管理画面の「外観」→「カスタマイズ」で該当のナビゲーションブロックの設定を一度開いて「公開」を押し直すと、強制的に新しい CSS が生成されて直ることが多い。

ほかの Kadence ブロックも同じ現象が起こるのか

今のところ報告が集中しているのはナビゲーション(Adv)ブロックのみだ。ただし Kadence の高度なブロック群で似たような CSS 生成の仕組みを使っている可能性はゼロではないため、別のブロックで表示の異常を見つけた場合は同じ手順でバージョンを戻してみると切り分けになる。

Pro 版の Kadence Blocks でも同じバグは起こるのか

今回の不具合は無料版のコア機能に起因しており、Pro 版を併用している環境でも 7.3.3 以降に更新すればまったく同じように発生する。ダウングレードの手順も無料版と変わらない。

プラグインを削除せずに直す方法はないのか

functions.php などでフィルターフックを使い、動的に二重括弧を除去するコードを書くことは理論上可能だが、すべてのブロックに干渉するためリスクが高い。安全をとって旧バージョンに戻す方が現実的だ。

この記事のポイント

  • Kadence Blocks 7.3.3 以上でナビゲーションAdvブロックのフォント設定が消えるのは、インラインCSSの二重括弧が原因
  • 解決の最短手段は 7.3.2 以前へのダウングレードとキャッシュクリア
  • プラグインの削除・再インストールでデータは消えず、設定も維持される
  • 自動更新を止めて、本番適用前に検証する運用が望ましい
  • 公式の修正パッチがリリースされ次第、最新版に戻して問題ない
Contact Form 7 PayPal Stripe Add-onの脆弱性と最新版への更新手順

Contact Form 7 PayPal Stripe Add-onの脆弱性と最新版への更新手順

Contact Form 7 PayPal & Stripe Add-on のバージョン 2.4.9 以前には、PayPal 決済を本来の支払い金額や通貨と無関係に「支払い完了」として通過させてしまう脆弱性がある。最新版へ更新すれば対処でき、放置すると注文だけが成立して金銭が回収できない重大なリスクを抱えるため、至急確認する必要がある。

Contact Form 7 用 PayPal & Stripe Add-on にどんな脆弱性があるのか

Contact Form 7 用 PayPal & Stripe Add-on にどんな脆弱性があるのか

この脆弱性は CVE-2026-9189 として採番されており、攻撃者が PayPal の正当な通知(IPN)に見せかけたリクエストを送信することで、実際の支払い金額や通貨、受取人の一致をまったく検証せずに「支払い済み」とマークできてしまう。プラグインは PayPal からの通知の署名検証は行っていたものの、肝心の取引金額・通貨コード・受取人メールアドレスの突き合わせを実装していなかったため、ゼロまたは極端に低い金額の注文が成立してしまう。

具体的には、フォーム送信時に生成される注文レコードに対して、PayPal のトランザクション ID と支払いステータスのみが照合され、注文時に設定された金額と実際に PayPal 上で決済された金額の比較が行われない。このため、正規のトランザクション ID を悪用、あるいは偽装した通知に対してプラグインが「正当な支払い」と誤認する状況が生まれていた。

Before(脆弱な状態)

PayPal 通知の受信 → 署名検証のみ実施 → 金額・通貨・受取人の検証なし → 0円でも「支払い完了」

After(修正後)

PayPal 通知の受信 → 署名検証 → 金額・通貨・受取人を注文情報と突合 → 一致時のみ「支払い完了」

脆弱な状態  修正後の状態

上の図が示す通り、修正後は金額・通貨・受取人の3点を必ず比較するロジックが追加されている。この検証が欠けていたことが、支払いバイパスを成立させる根本原因だった。

どのバージョンが影響を受けるのか

どのバージョンが影響を受けるのか

Contact Form 7 PayPal & Stripe Add-on のバージョン 2.4.9 以下が影響を受ける。2026年6月中旬時点で修正済みのバージョンがリリースされており、2.5.0 以降に更新すればこの脆弱性は解消される。

自分のサイトでどのバージョンを使用しているかは、WordPress 管理画面の「プラグイン」→「インストール済みプラグイン」一覧で確認できる。該当プラグインが有効化されている場合は、バージョン番号を直ちにチェックしておきたい。

最新版へ更新する具体的な手順

最新版へ更新する具体的な手順
STEP 1 管理画面「ダッシュボード」→「更新」を開く
STEP 2 該当プラグインの更新チェックボックスをオンにする
STEP 3 「プラグインを更新」をクリックして完了

更新前にサイト全体のバックアップを取得しておくとなお安心だ。更新が完了したら、プラグイン一覧でバージョンが 2.5.0 以降に切り替わっていることを必ず確認する。

更新がすぐに実行できない場合の対処

更新がすぐに実行できない場合の対処

何らかの理由で即時更新が難しい場合は、一時的に PayPal 決済機能を停止し、フォームそのものを別の決済手段に切り替えるなどの対策が有効だ。とはいえ、あくまで暫定的な措置であり、根本対策は最新版への更新以外にない。

プラグインを無効化すれば脆弱性は発動しなくなるが、フォーム経由の PayPal 決済も一切使えなくなる。その間に代替として WooCommerce の標準決済や別のフォームプラグインへ移行する判断も必要になるだろう。

よくある質問

Stripe 決済にも同じ問題はあるのか

この脆弱性は PayPal の通知処理に起因する問題であり、Stripe 側の処理ロジックには同様の不備は確認されていない。ただし、セキュリティ修正の一環で Stripe 関連のコードにも改善が加えられているため、プラグイン全体を最新に保つのが賢明だ。

すでに不正な取引が行われていないか調べる方法はあるか

PayPal の取引履歴と Contact Form 7 の送信ログを突き合わせ、注文金額と実際の決済金額が一致しているかを手動で検証する必要がある。プラグイン自体に取引監査の機能はないため、自社の売上レポートと PayPal の管理画面を定期的に照合する習慣をつけることを推奨する。

自動更新を有効にしていれば問題は起きなかったのか

自動更新が有効でも、WordPress.org のプラグインディレクトリに修正版が配信されるタイミング次第では数時間から数日のラグが生じる。さらに、サイトの更新設定によってはメジャーアップデートが自動適用されないケースもあるため、手動での確認を怠らないほうが安全だ。

このプラグインを使い続けるリスクは他にもあるか

Contact Form 7 のアドオンは多数の開発者によって提供されており、サポートや更新の頻度はプラグインごとにまちまちだ。決済を扱う以上、常に開発が継続され、すみやかにセキュリティパッチが提供されるプラグインを選ぶことが大前提となる。

この記事のポイント

  • Contact Form 7 PayPal & Stripe Add-on 2.4.9 以前に支払いバイパスの脆弱性がある
  • PayPal 通知の金額・通貨・受取人を検証しないため 0 円でも「支払い完了」になる
  • 修正済みの最新版(2.5.0 以降)に更新すれば問題は解消される
  • 更新前にバックアップを取り、バージョン番号を必ず確認する
  • 決済系プラグインは常に最新を保ち、定期的なログ照合を習慣化する
Relevanssiで日本語検索クエリが原因のテーブルフルスキャンを防ぐ

Relevanssiで日本語検索クエリが原因のテーブルフルスキャンを防ぐ

Relevanssiで日本語だけの検索クエリがデータベースの全テーブルスキャンを引き起こす問題は、トークナイズ結果が空文字になるケースをカスタムコードで事前に検知し、SQLを発行せずに空の結果を返すことで根本的に回避できる。設定のチューニングと併用すれば、サイト全体の検索パフォーマンスを維持できる。

なぜ日本語の検索クエリでRelevanssiがテーブル全体を読み込むのか

なぜ日本語の検索クエリでRelevanssiがテーブル全体を読み込むのか

Relevanssiは登録された投稿のタイトルや本文を分解し、単語単位でインデックスを作る全文検索プラグインだ。英語などスペースで区切られた言語では問題なく機能するが、日本語や中国語、韓国語といったCJK(中国語・日本語・韓国語)テキストでは事情が異なる。

CJKの文字列は単語境界の空白が存在しないため、Relevanssiが検索クエリを受け取ると、内部のトークナイザ(単語への分割処理)で適切な単位に区切れないことがある。特に、形態素解析エンジンがインストールされていない標準環境では、クエリが解析不能と見なされ、トークンがゼロ個、つまり空の状態になりやすい。

この「空のクエリ」が問題の本質だ。Relevanssiの検索SQLでは、本来なら検索語に基づいてWHERE term = '検索語'のように絞り込む。しかしトークンが空になると、検索語を表す変数に何も入らず、SQLがWHERE term = termという常に真になる条件へと崩れる。結果としてwp_relevanssiテーブルの何百万行という全レコードを走査するフルスキャンに陥り、応答に数十秒かかる事態を引き起こす。

これはバグではなく、空のクエリに対するフォールバック(予備動作)が設計上考慮されていないために発生する。本来なら検索語が存在しないと判断された時点で、データベースに問い合わせず「該当なし」を返すのが望ましい。

検索クエリが空になるのをコードで検出し早期リターンする

検索クエリが空になるのをコードで検出し早期リターンする

最も確実な解決策は、RelevanssiがSQLを構築する前に検索クエリの内容をチェックし、有効なトークンがなければ検索処理を打ち切る仕組みをテーマのfunctions.phpに組み込むことだ。Relevanssiは複数のフィルターフックを提供しており、そのうちrelevanssi_search_okまたはrelevanssi_modify_wp_queryを利用する。

具体的な実装コードと設置手順

STEP 1 子テーマまたはカスタムプラグインの準備
STEP 2 functions.php にフィルターフックを追加
STEP 3 検索クエリのトークン有無を判定する条件を記述
STEP 4 空の場合は検索をキャンセルし空結果を返す

このデモが示す流れで、コードを追加する。以下は実際に利用できる実装例だ。

add_filter( 'relevanssi_search_ok', function( $ok, $query ) {
    // 検索クエリが文字列であり、内容が空でないか確認する
    if ( ! is_string( $query->query_vars['s'] ) || '' === trim( $query->query_vars['s'] ) ) {
        return false; // 検索を実行せず早期リターン
    }

    // スペースを除いたテキストがCJK文字だけで構成されているか簡易チェック
    $search_term = trim( $query->query_vars['s'] );
    // CJK統合漢字・ひらがな・カタカナ・ハングルの正規表現
    $cjk_pattern = '/[\x{4e00}-\x{9faf}\x{3040}-\x{309f}\x{30a0}-\x{30ff}\x{ac00}-\x{d7af}]+/u';
    preg_match_all( $cjk_pattern, $search_term, $matches );

    // マッチしたCJK文字列が存在するかを確認
    if ( empty( $matches[0] ) ) {
        // CJK文字がなければ通常の検索を続行
        return $ok;
    }

    // 簡易的なトークン判定: Relevanssiが実際に使うトークナイザを再現
    // ここではCJKクエリが本当にインデックス可能か簡易判定する
    $tokens = relevanssi_tokenize( $search_term, true );
    if ( empty( $tokens[0] ) ) {
        return false; // 有効なトークンがないため検索中止
    }

    return $ok;
}, 10, 2 );

このコードでは、Relevanssiの内部関数relevanssi_tokenize()を呼び出し、実際に検索に使われるトークンが生成されるかどうかを見ている。もし空の配列が返ってきたら、それは全テーブルスキャンを引き起こす危険な状態だと判断し、falseを返すことで検索SQLの実行そのものをブロックする。

もうひとつ重要なのは、relevanssi_search_okフィルターがSQL構築の直前で動作するため、無駄なクエリがデータベースに発行される前に検索を止められる点だ。サイトの規模が大きく、wp_relevanssiテーブルが数百万行を超える場合でも、安全に空の結果を返せるようになる。

テーマの functions.php に追加する際の注意点

コードは必ず子テーマのfunctions.phpまたは専用のカスタムプラグインに記述する。親テーマのfunctions.phpを直接編集すると、テーマのアップデートで変更が失われる。また、PHPのバージョンが7.4以上であることをあらかじめ確認しておく。

コードを追加したら、日本語だけで構成された検索クエリを実際に投げてみる。検索結果がゼロ件で返ってくることを確認し、同時にMySQLのスロークエリログやQuery Monitorプラグインで、フルスキャンが発生していないかチェックすると確実だ。

データベースの負荷を根本的に下げるRelevanssiの設定

データベースの負荷を根本的に下げるRelevanssiの設定

コードによる早期リターンと並行して、インデックスと検索設定そのものを見直すことで、CJKクエリ以外の場面でもパフォーマンスを向上させられる。

最小文字数制限をCJKに合わせて調整する

Relevanssiの管理画面には「インデックスを作成する最小文字数」という設定がある。デフォルトでは2文字程度に設定されていることが多いが、CJK環境では1文字でも意味を持つ(例: 「本」「水」など)ため、1に下げるのが基本だ。ただし、1文字にするとインデックスサイズが膨張しやすいため、サイトの投稿規模に応じて2以上にするか、あるいは後述の文字種フィルタリングと組み合わせる。

検索から除外する投稿タイプやステータスを絞る

wp_relevanssiテーブルが肥大化する大きな要因は、リビジョンや自動下書き、非公開のカスタム投稿タイプまでインデックスに含めているケースだ。設定画面の「インデックスを作成する投稿タイプ」で、実際にサイトのフロントエンド検索で必要になる投稿タイプと公開済みのものだけに限定する。リビジョンが無駄に行を占有しているだけで、テーブルサイズが数割変わることもある。

MySQL / MariaDB のバッファ設定を最適化する

13万投稿、1300万行のインデックスを持つ規模では、サーバーのデータベース設定そのものがボトルネックになる。特にinnodb_buffer_pool_sizeをサーバーの物理メモリの70%程度に設定し、Relevanssiのテーブル全体がメモリに収まるようにすると、たとえスキャンが発生してもディスクI/Oを避けられる。設定変更は必ず本番環境でテストした後に適用する。

よくある質問

コードを追加した後、通常の英語検索に影響はないか

上記のコードは、トークンが空になる場合にのみ検索を中止する。英語のスペース区切りクエリや、英数字が混在する日本語クエリでは通常どおりRelevanssiのインデックスが使われるため、影響はない。万が一、正常な検索がブロックされていると感じたら、relevanssi_tokenize()の結果をエラーログに出力して確認する。

Relevanssi以外の全文検索プラグインでもこの問題は起こるのか

起こりうる。特にPHPベースのトークナイザに依存するプラグインでは、CJK文字の分割に失敗すると同様の空クエリ問題が発生する可能性がある。検索プラグインを選定する際は、形態素解析(MeCabなど)に対応しているか、もしくは外部の検索エンジン(Elasticsearch、Algoliaなど)と統合できるかを基準にするとよい。

大量のクローラーからCJKクエリを繰り返し受けている場合の対策は

検索クエリが空になるパターンは、ボットがランダムな文字列や日本語の記事タイトルを検索ボックスに投げ込むことで頻発する。コードによる早期リターンでサーバー負荷は防げるが、さらにCloudflareやWAFのレート制限で同一IPからの過剰な検索リクエストを制限すると、クローラー起因のリソース浪費全体を抑えられる。

functions.php を触れない環境で他にできることはあるか

管理画面のRelevanssi設定で「検索を許可する最低文字数」を意図的に上げる(例: 3文字)方法がある。ただし、これは短い日本語の単語が検索できなくなる副作用を伴う。根本解決にはならないが、緊急のパフォーマンス低下を抑える応急処置としては有効だ。

この記事のポイント

  • 日本語のみの検索クエリでRelevanssiが全テーブルスキャンに陥る根本原因は、トークナイズ結果が空になりSQLが常に真になるため
  • カスタムコードでSQL実行前に空トークンを検出し、早期リターンさせることでデータベース負荷を回避できる
  • インデックスの最小文字数制限や対象投稿タイプの絞り込みをCJK向けに最適化すると、さらなるパフォーマンス改善につながる
  • コード追加後も通常の英数字検索には影響を与えず、安全に運用できる
  • クローラーからの大量アクセスに対してはWAFやレート制限との併用が効果的