Redis Object Cache有効時にPHP-FPMがクラッシュして503エラーが頻発する原因と対処法
Redis Object Cacheプラグインのドロップインを有効にしたWordPressサイトで、PHP-FPMのワーカープロセスがSIGSEGV（セグメンテーション違反）を起こし断続的に503エラーが発生する現象は、PHP本体のコア（Zend Engine）領域におけるメモリ破壊が根本原因だ。まずはオブジェクトキャッシュを無効化してサイトを安定させ、PHPのビルドバージョンやRedis拡張の状態を確認するのが最初の一手になる。
なぜRedis Object Cacheを使うとPHP-FPMが落ちるのか
障害の直接的な引き金は、Zend Engine VM の命令ハンドラ内で発生するSIGSEGVシグナルだ。これはPHP本体のコア実行エンジンが、本来アクセスできないメモリ領域に誤って触れたときにOSがプロセスを強制終了させる。エラーが発生する場所は拡張機能のコードではなく、PHP 8.5.9が持つVMの基本命令を処理する部分であるため、PhpRedisのような特定の拡張機能が直接のバグを抱えている可能性は低い。
クラッシュはリクエスト処理の初期には起こらず、PHP-FPM のワーカーが起動してから700～1,600秒以上経過したタイミングで突如発生する。この時間差は、徐々に進行するヒープの破壊（メモリの二重解放、解放後の使用、境界外書き込みなど）を示唆している。リクエストの処理中にどこかでメモリが不正に操作され、その結果として破壊された領域を後続のVM命令が触れたときにSIGSEGVが起こる流れだ。
Redis Object Cacheのドロップインが有効な場合にのみ再現するのは、オブジェクトキャッシュが大量の一時データをPHPのメモリ空間に出し入れすることで、潜在的なメモリ破壊の発生確率を高めているからだと考えられる。また、キャッシュ操作自体の頻度やデータ構造の複雑さが、PHP 8.5.9固有のレアな境界条件を偶然踏み抜いている可能性もある。
クラッシュが発生した場合、PHP-FPM マスタープロセスは該当の子プロセスを再起動するが、その間は該当ワーカーが応答できないため、Webサーバー（nginxやApache）がバックエンドのFPMに接続できず、フロントエンドに503エラーが断続的に現れる。
実際のクラッシュ発生箇所は次のバックトレースで特定されており、coreで発生していることはほぼ間違いない。
0 ZEND_SEND_VAL_EX_SIMPLE_SPEC_CONST_HANDLER (execute_data=…, opline=…)
at Zend/zend_vm_execute.h:6227Redis Object Cacheを安全に無効化する手順
サイトの安定が最優先だ。根本原因の調査は時間がかかるため、まずはオブジェクトキャッシュのドロップインを無効化し、クラッシュが起きない状態に戻す。無効化してもフロントエンドの表示が著しく遅くなるわけではないケースが大半だが、ショートコードやDBクエリの多い動的ページでは表示速度が一時的に落ちる可能性があることは把握しておく。
管理画面にログインできる状態なら、以下の手順で無効化する。もし503エラーの影響で管理画面にアクセスできない場合は、FTPやSSH経由で直接ファイルを削除する手順に進む。
プラグイン自体を停止するとドロップイン（wp-content/object-cache.php）も無効化される。プラグインを停止したあと、念のためFTPやSSHでwp-content/object-cache.phpが削除されていることを確認するほうが確実だ。このファイルが残っていると、プラグインが無効でもキャッシュ機構だけが動き続ける。
管理画面にアクセスできない場合は、以下のいずれかの方法でobject-cache.phpを直接削除する。
- FTPクライアントで
wp-content/object-cache.phpを削除（または拡張子を.bakに変更） - SSHで
rm wp-content/object-cache.phpを実行 - wp-cliが使えるなら
wp redis disableを実行
いずれの操作のあとも、サイトが正常に表示され503が発生しなくなったことを確認する。これで一時的な安定化は完了だ。
PHP 8.5.9でのSIGSEGVを根本的に調査する方法
オブジェクトキャッシュを無効にしてサイトが安定したら、根本原因の調査に移る。クラッシュの位置がZend Engineコアである以上、PHPランタイムそのものの再ビルドや、利用しているPHPビルドの変更が最も確実な対策になる。
PHPのビルドを更新または再コンパイルする
この問題は特定のPleskビルド（plesk-php85-8.5.9-0redhat.9.260731.1229）で確認されている。Plesk環境であれば、PHPのコンポーネント更新を実行し、最新のマイナーパッチが適用されたビルドに差し替える。ビルド番号が異なるだけでZend Engineの挙動が変わる可能性があるからだ。Pleskの「ツールと設定」→「更新とアップグレード」から「PHP 8.5」のコンポーネント更新をチェックする。
ソースから自前でPHPをビルドしている場合は、configureオプションに--enable-debugを付けてビルドしたPHPをまずは検証環境にデプロイし、デバッグシンボル付きでクラッシュ時の詳細なコールスタックを取得する。商用サイトでデバッグビルドを使うとパフォーマンスが落ちるため、あくまでテスト用のステージング環境で行うこと。
PHPのセッションハンドラを確認する
Redis Object Cacheのドロップインが、意図せずセッションハンドラとしても機能しているケースがある。セッションデータがPHPの内部メモリ管理と衝突し、クラッシュを誘発している可能性も考えられるため、php.iniのsession.save_handlerがfilesまたは意図した値になっているかを確認する。redisが指定されていた場合は、セッションとキャッシュの分離を検討する。
Redisサーバー側のチューニングと接続方式を再検討する
今回の環境ではRedisとの接続にUnixソケットが使われている。UnixソケットはTCP接続より高速だが、カーネルのソケットバッファやパーミッションの問題が間接的にPHP-FPMのメモリ状態を不安定にすることもありうる。いったんWP_REDIS_SCHEMEをtcpに切り替えてしばらく様子を見るという切り分けも有効だ。
また、Redis側のmaxmemory-policyがnoevictionだと、メモリ上限に達したときに書き込みエラーが発生する。直接SIGSEGVを起こすわけではないが、エラー処理の過程でPHP内部の状態が破壊される可能性を完全には否定できない。allkeys-lruなど適切な追い出しポリシーを設定し、Redis自体のメモリ使用率にも注意を払う。
代替のオブジェクトキャッシュバックエンドを試す
Redis Object Cacheプラグインをどうしても使い続けたい場合は、PhpRedisとPredisのどちらのクライアントバックエンドを使ってもクラッシュが再現する以上、Redis以外のバックエンドをテストする価値がある。たとえばMemcachedをバックエンドとするObject Cache Proや、ファイルベースのキャッシュに一時的に切り替えて様子を見る。
とはいえ、Zend Engineコアでのクラッシュである以上、バックエンドを変えても根本解決には結びつかない可能性が高い。もしMemcachedやファイルキャッシュに切り替えても同じタイミングでクラッシュするなら、PHPビルドそのものの問題である確度がさらに上がる。
よくある質問
503エラーはRedis Object Cacheをやめれば必ず直るのか
PHP-FPMのワーカークラッシュが原因で起こっている503エラーであれば、ドロップインを無効化してクラッシュが発生しなくなれば解消する。ただしサーバーの同時接続数超過や他のPHP拡張の不具合など、別の原因で503が発生しているケースもあるため、エラーログを必ず確認する。
PHP 8.5系以外でも同じ現象は起こるのか
今回のクラッシュ位置（Zend Engineの特定の命令ハンドラ）がトリガーになっていることから、PHP 8.5の特定ビルドに限定される可能性が高い。ただしPHP 8.4や8.3の一部のビルドでも、メモリ安全性に関する潜在バグが残っていることはありうる。まずは該当のPHPマイナーバージョンにパッチが提供されていないか公式のバグトラッカーを確認する。
PHP-FPMのワーカー数を増やせば503は減るのか
クラッシュが断続的に発生しているだけなら、ワーカー数を一時的に増やすことで503の発生頻度を下げられる場合がある。ただし本質的には問題を隠しているだけであり、クラッシュが多発すると結局は全ワーカーが落ちてサイト全体が応答不能になるリスクは残る。根本対策にはならない点に注意が必要だ。
ドロップインを削除してもRedisは自動起動したままでいいのか
ドロップインを削除しただけではRedisサーバープロセスは稼働し続ける。メモリやCPUリソースをわずかに消費するが、WordPressが接続しなければ実害はほとんどない。必要に応じてRedis自体を停止しても構わないが、他のアプリケーションが同じRedisインスタンスを使っている場合は影響範囲を確認してから停止する。
PHPのバグ報告はどこに出せばいいのか
再現手順が明確で、デバッグシンボル付きのバックトレースが取得できているなら、PHPの公式バグトラッカー（bugs.php.net）に報告する。Plesk環境固有のビルドに問題がありそうな場合は、Pleskサポートにも並行してチケットを発行するとよい。報告時はPHPのビルド番号と再現手順をできるだけ具体的に記載する。
この記事のポイント
- PHP 8.5.9の特定ビルドでRedis Object Cacheのドロップインが有効だと、Zend EngineコアでSIGSEGVが発生し503エラーが断続的に起こる
- クラッシュはワーカー起動後700秒以上経過してから発生し、PhpRedisとPredisの両方で再現するため拡張機能固有のバグではない
- 応急処置としてobject-cache.phpを削除しオブジェクトキャッシュを無効化すればサイトは安定する
- PHPのビルド更新、セッションハンドラの確認、Redis接続方式の変更などでPHP本体の潜在バグを回避できる可能性がある
- 根本解決にはPHPのバグ報告またはビルド差し替えが必要で、再発リスクを下げるにはステージング環境での検証が欠かせない
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
ManageWP でサイトがオフラインエラーになる All-In-One Intranet 競合の直し方
ManageWP のダッシュボードでサイトが「オフライン」表示になり Worker プラグインの再接続に失敗するエラーが出る場合、All-In-One Intranet プラグインの強制ログイン機能が外部通信をブロックしている可能性が高い。プラグインを最新版にアップデートするか、提供されているフィルターフックで ManageWP のアクセスだけを許可すれば直ちに解決する。
なぜ ManageWP が All-In-One Intranet 導入後に接続不能になるのか
All-In-One Intranet は WordPress サイト全体を非公開化するプライバシー保護プラグインだ。設定を有効にすると、訪問者がログインしていない限り、あらゆるページへのアクセスを遮断する。この制御は WordPress のリクエスト処理そのものにかかり、人間のブラウザアクセスだけでなく、バックグラウンドで動作する管理ツールの通信も一律に弾いてしまう。
ManageWP はサイトで ManageWP Worker プラグインを経由して、ダッシュボードからの一括更新や監視を実現している。この通信は非ログイン状態の外部リクエストとして届くため、All-In-One Intranet の「未ログインユーザーをブロック」のルールに引っかかり、結果として「Worker プラグインがアクティブでない」という誤ったエラーを ManageWP 側に返してしまう。
このデモは、All-In-One Intranet が ManageWP の通信を遮断する流れと、除外設定後の正常な通信を示している。
アップデートで競合を根本解決する
プラグイン開発元がこの競合を把握しており、バージョン 1.10.0 で ManageWP をはじめとする外部管理ツール（MainWP、WP Umbrella など）との通信が復旧する修正が行われた。古いバージョンを使い続けているなら、まずは All-In-One Intranet を最新にアップデートするだけで問題が解消する。
アップデート前のキャッシュとバックアップ
プラグインの更新前に、サイト全体のバックアップを取得しておく。管理画面から「ダッシュボード」→「更新」を開き、「プラグイン」セクションで All-In-One Intranet の新しいバージョンの有無を確認する。
更新が完了したら、サーバーキャッシュや CDN キャッシュをすべてクリアする。ManageWP 側のキャッシュもリセットするために、対象サイトの「サイトを再接続」を一度だけ実行し、オフライン表示が消えるか確認する。
フィルターフックで ManageWP を手動除外する
プラグインを何らかの理由で最新版にできない場合や、最新版でも何かしらの要因で競合が続くなら、All-In-One Intranet が用意している aioi_allow_public_access フィルターフックで ManageWP Worker のアクセスだけ許可する方法がある。このフックを使うと、サイトの他のプライバシー設定を維持したまま、特定のエンドポイントやリクエストを認証不要で通過させられる。
子テーマの functions.php にコードを追加する
フィルターフックは、利用している子テーマの functions.php にコードを追記して適用する。FTP やホスティングのファイルマネージャーで直接編集するか、管理画面の「外観」→「テーマファイルエディター」から functions.php を開く。
add_filter( 'aioi_allow_public_access', function( $allow ) {
// ManageWP Worker の要求を常に許可する
if ( defined( 'MWP_ACTION' ) || isset( $_GET['mwp_action'] ) ) {
return true;
}
return $allow;
});上記のコードは、ManageWP Worker プラグインがリクエストの際に内部でセットする定数やクエリパラメータを目印にしている。もし Worker プラグインが異なるパターンのリクエストを送っていたとしても、フック内の条件を適宜拡張すればよい。
コードを追加したらファイルを保存し、ManageWP ダッシュボードで対象サイトを再接続する。このタイミングでオフラインエラーが出なくなり、正常に一覧に戻ってくるはずだ。
この STEP 図は、フィルターフックでアクセスを許可し、ManageWP の接続を復旧するまでの一連の流れを視覚化したものだ。
回避策が効かない場合の追加切り分け
ごく稀に、All-In-One Intranet のバージョンアップやフィルター適用後もエラーが消えないケースがある。その場合は、他のセキュリティプラグインが重複して通信を遮断していないか確認する。
プラグインの競合を最小構成で検証する
一時的に全プラグインを無効化し、All-In-One Intranet と ManageWP Worker だけを有効化する。この状態で ManageWP が接続できるなら、ほかのプラグインに問題を起こしているものがあると判断できる。1つずつ有効化していき、再発タイミングを特定する。
ファイアウォールとサーバー設定の二重ブロックに注意する
Wordfence などの WAF（ウェブアプリケーションファイアウォール）が ManageWP の IP アドレスをブロックしている可能性もある。プラグインの設定や cPanel の IP ブロック機能で、ManageWP の公式 IP アドレス帯域が許可リストに入っているか確認する。また .htaccess にリダイレクトや BASIC 認証をかけている場合、一時的に解除して影響を切り分ける。
よくある質問
All-In-One Intranet を無効化したくないが、セキュリティは維持できるか
フィルターフックによる除外は、ManageWP Worker が利用する特定のリクエストに絞って施せる。サイトの他の全ページは引き続きログイン必須の状態を保つため、セキュリティレベルを落とすことなく管理だけを外部から行える。コードの条件式を Worker 限定にすることで、意図しない一般リクエストの流入は防がれる。
ManageWP 以外の管理ツールでも同じ問題は起きるのか
MainWP、WP Umbrella など、サイトに Worker 的なプラグインを入れて外部から操作する仕組みの管理ツール全般で発生する可能性がある。All-In-One Intranet のバージョン 1.10.0 ではこれらツールとの互換性も修正されているため、最新版で問題が起きることはほぼない。
アップデート後に ManageWP がまだオフライン表示のままだがどうすればいいか
まず ManageWP のダッシュボードで該当サイトを明示的に「再接続」させる。続いてサーバー側のキャッシュ（プラグインベースのキャッシュやホスティングのサーバキャッシュ）を完全にクリアする。それでも反映されない場合、Worker プラグイン自身をいったん削除し、ManageWP ダッシュボードから新規にインストールし直すと設定がリフレッシュされる。
functions.php を直接編集するのに抵抗がある。安全な方法はあるか
必ず親テーマではなく子テーマの functions.php を編集する。編集前にファイルをダウンロードしてバックアップし、テーマファイルエディターを使う場合は保存前にコードの誤字を確認する。それでも不安なら、Code Snippets プラグインを導入し、管理画面からスニペットとして同じコードを追加する方法もある。
数か月前から Worker の再接続に失敗していたが、データは失われるか
ManageWP 側の管理データ（サイトの追加設定や監視ログなど）は失われない。再接続が成功すれば、プラグインやテーマの更新状況はそのまま引き継がれる。ただし、オフライン期間中にあったサイト側の変更は、再接続後に初めて ManageWP 側で認識される。
この記事のポイント
- ManageWP のオフラインエラーは All-In-One Intranet のプライバシー保護が原因
- プラグインの 1.10.0 へのアップデートで競合は根本的に解決する
- すぐ対応したい場合は
aioi_allow_public_accessフィルターで手動除外 - コード追加は子テーマの functions.php に限定しバックアップを取る
- キャッシュクリアと再接続の実行を必ず忘れずに行う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
決済手数料プラグイン更新後に商品ページがエラーで崩れる場合の対処法
WooCommerce サイトで Payment Gateway Based Fees and Discounts といった決済手数料プラグインをバージョン 3.2.0 に更新した直後から、商品ページを開くと「このサイトで重大なエラーが発生しました」と表示され、レイアウトが中央に縮まってしまう症状が起きた。このケースはプラグイン内部のクラス読み込み不具合が原因であり、該当プラグインを安全な旧バージョンにロールバックすれば即座に解決する。
なぜプラグイン更新後に商品ページが重大エラーになるのか
エラーログには「Uncaught Error: Class “TycheSoftwares\PaymentGatewayFees\Lite\WC_Tax” not found」というメッセージが記録されている。これは、プラグインのアップデートで参照している PHP クラスが適切に読み込まれていないことを示す。WooCommerce 本体やほかのプラグインとの同時アップデートが引き金になることもあるが、切り分けテストで当該プラグインを無効化すると正常に戻るなら、原因はそのプラグインの新バージョンにあると断定できる。
エラーを安全に切り分ける手順
問題が発生したら、むやみに設定を触らず、まず以下の手順で原因を特定する。同時にアップデートしたプラグインが複数ある場合も、この順序で一つずつ無効化していくと確実だ。
上記の操作は管理画面にアクセスできない場合でも使える。プラグインを無効化するだけなら、PHP の動作を変更しないため、エラーが解消された後に管理画面から安全にアンインストールや再インストールが可能だ。
旧バージョンにロールバックしてサイトを元に戻す
原因が特定できたら、問題のない旧バージョンに置き換える。ロールバックの方法は大きく分けて3つある。状況に応じて選ぶとよい。
プラグイン「WP Rollback」を使って管理画面から戻す
WordPress 管理画面にアクセスできる状態なら、無料プラグインの WP Rollback をインストールすると、プラグイン一覧から直接任意の旧バージョンに切り替えられる。操作は数クリックで完了し、面倒なファイル操作が不要なため最も簡単だ。ロールバック後は念のためキャッシュを全削除し、エラーが出なくなったことを確認する。
公式 ZIP ファイルを手動でアップロードする
管理画面に入れない場合は、WordPress 公式プラグインディレクトリの旧バージョン ZIP を直接ダウンロードし、FTP やサーバーのファイルマネージャーで上書きする。対象プラグインの開発者ページにアクセスし、右下の「Advanced View（詳細を表示）」から目的のバージョンを選んで ZIP を取得する。その後、/wp-content/plugins/ ディレクトリに解凍して配置すれば完了だ。このとき、既存のプラグインフォルダは必ずリネームしてから新しく解凍するか、上書きする前にバックアップを取っておく。
WP-CLI でコマンド操作する
サーバーに SSH 接続できる上級者向けの方法だ。WP-CLI が使える環境であれば、以下のようなコマンドでプラグインをダウングレードできる。公式 ZIP の URL を指定してインストールし、有効化するだけだ。
wp plugin install https://downloads.wordpress.org/plugin/checkout-fees-for-woocommerce.3.1.0.zip --activateロールバック後は自動更新を一時的に停止し、修正版がリリースされるまでバージョンを固定することを推奨する。 具体的には、プラグイン編集画面か wp-config.php で該当プラグインの自動更新フィルターを無効化するか、プラグイン一覧から手動更新に切り替えておく。
開発者が修正するまでに取るべき応急処置
問題のバージョンに致命的な不具合がある場合、修正版がリリースされるまでは旧バージョンでの運用が必須だ。その間、以下の点に気をつける。
- サポートフォーラムや公式リポジトリを定期チェックする。 同じ不具合が報告され、ベータ版や修正版が先に出ることがある。
- ステージング環境で新バージョンを検証する。 いきなり本番環境に適用せず、テストサイトで動作確認してから更新する習慣をつける。
- WooCommerce 本体と関連プラグインの同時更新を避ける。 依存関係の競合を避けるため、数日ずらして様子を見ながら更新するのが安全だ。
よくある質問
エラーログの確認方法がわからない
サーバーコントロールパネルのエラーログ機能を使うか、wp-config.php に define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); を追記すると、/wp-content/debug.log にエラーが記録される。本番環境ではデバッグ表示を無効にしておき、ログだけ有効にする設定が推奨される。
ロールバック中に「インストールに失敗しました」と出る
多くの場合、既存のプラグインフォルダが残っていることが原因だ。FTP で対象フォルダを削除またはリネームし、空の状態にしてから ZIP を解凍するか、WP Rollback が自動で処理するのを待つ。
プラグインを無効化すると手数料計算が狂わないか
決済手数料を動的に追加しているサイトでは、プラグインを無効化すると手数料が適用されなくなる。ロールバックが完了するまでの間は手数料の表示が消えることを顧客に通知するか、保守モードを有効にして注文自体を一時停止する判断も必要だ。
今後同じようなアップデート事故を防ぐには
WooCommerce サイトでは、本番適用前にステージング環境でプラグインの更新テストを行うのが最も確実な防止策だ。また、更新前に必ずサイト全体のバックアップを取得し、自動更新設定を重要なプラグインでは「手動」に切り替えておくことも有効である。
この記事のポイント
- Payment Gateway Based Fees and Discounts 3.2.0 の更新後、クラス未定義エラーで商品ページが崩れる
- 原因はプラグイン内部のクラス読み込み不具合で、同プラグインを旧バージョン（3.1.0）に戻せば直る
- ロールバックには WP Rollback プラグインか、公式 ZIP を手動アップロードする方法が使える
- 修正版が配布されるまでは自動更新を停止し、本番環境での同時更新を避ける
- 更新前のステージング環境テストとサイト全体のバックアップが最も有効な予防策
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
GS Team Membersアップデート後にDiviサイトが壊れた場合の復旧と修正手順
GS Team Membersプラグインのバージョン2.7.17へのアップデート後にDiviサイトが壊れ「このサイトで重大なエラーが発生しました」と表示された場合、開発者が公開した修正版2.7.18へアップデートすれば解決する。リカバリーモードで管理画面に入りプラグインを一時停止したあと、最新版へ更新するだけでサイトは復旧する。
どんなエラーが発生しているのか
GS Team Members 2.7.17では、Diviテーマ向けの統合モジュールに含まれるファイル「TeamMembersModule.php」の25行目で、必要なインターフェースが見つからないという致命的なエラー（E_ERROR）が発生する。PHPが「インターフェースが存在しない」と判断し処理を停止するため、サイト全体が表示不能になる。
エラーメッセージの要点は次の通りだ。「Interface "ET\Builder\Framework\DependencyManagement\Interfaces\DependencyInterface" not found」という内容で、Diviのビルダーフレームワークが提供するDependencyInterfaceというインターフェースを読み込もうとしたが見つからなかったことを示している。
このエラーは管理画面にもフロントエンドにも影響し、WordPress本体が自動的にリカバリーモードへ移行させる。スタックトレースにはGoogle Site Kitも登場するが、これはエラーの連鎖で巻き込まれただけで、根本原因ではない。
なぜアップデートでサイトが壊れたのか
原因はGS Team Members側のコード不備だ。バージョン2.7.17でDivi向けの統合コードを更新した際、Divi本体のバージョンによっては存在しないインターフェースを参照してしまった。PHPでは存在しないクラスやインターフェースを使おうとすると即座に致命的エラーを投げるため、その瞬間にサイト全体の処理が停止する。
スタックトレースを見ると、DependencyInterfaceを読み込もうとした箇所からエラーが始まり、REST APIの初期化処理へ飛び火している。管理画面のダッシュボードでは複数のプラグインがREST API経由でデータを取得するため、Google Site Kitや他のプラグインの処理が次々にエラーに巻き込まれているが、これらは二次的なものだ。
根本的な問題はGS Team Members 2.7.17のコードにあるため、Diviを使っているユーザーだけがこのエラーに遭遇する。他のテーマやページビルダーを使っている場合は問題が起きない。
リカバリーモードで管理画面にアクセスする手順
サイトが壊れて管理画面にもアクセスできなくなった場合、WordPressは自動的にリカバリーモードへのリンクを記載したメールを管理者アドレスに送信する。このメールを使って管理画面へ入り、問題のプラグインを停止するのが最初の復旧手順だ。
リカバリーモードのリンクは24時間の有効期限が設定されている。メールが届かない場合は迷惑メールフォルダを確認し、それでも見つからなければFTPやサーバー管理ツールでプラグインフォルダの名前を変更して強制的に無効化する手段も取れる。
GS Team Membersを最新版へアップデートする
GS Team Membersの開発者はバージョン2.7.18でこの問題を修正している。アップデート内容は「Uncaught Error: Dependency Interface」への対応で、Diviテーマとの統合コードを修正したものだ。プラグインを停止した状態で管理画面の「プラグイン」ページを開き、「GS Team Members」が更新可能になっていればそのままアップデートを実行する。
更新が完了したらプラグインを再度有効化し、サイトのフロントエンドと管理画面の両方が正常に表示されることを確認する。この時点でプラグインのキャッシュが残っている可能性があるため、ブラウザキャッシュの削除も忘れずに行う。
もし更新通知が表示されない場合は、プラグインを一度削除してから新規インストールし直す方法もある。この場合、プラグインの設定や登録済みのチームメンバーデータが保持されるかどうかを事前に確認しておく必要がある。
FTPから手動でプラグインを停止する方法
リカバリーメールが届かない、あるいはメールアドレスが古くなっているなどで管理画面に入れないケースでは、FTPやサーバーのファイルマネージャーを使ってプラグインを一時停止する。手順は単純で、対象プラグインのフォルダ名を変更するだけだ。
サーバーに接続し「wp-content/plugins/」ディレクトリへ移動する。その中にある「gs-team-members」フォルダを「gs-team-members-backup」などにリネームする。WordPressはフォルダ名でプラグインを認識するため、名前が変わると自動的にプラグインが無効化される。
これでサイトが正常に表示されるようになったら管理画面へログインし、「プラグイン」ページでGS Team Membersが解除扱いになっていることを確認する。そのまま管理画面から最新版をインストールし、フォルダ名を変更した古いバージョンは削除しておく。
再発を防ぐためのアップデート前確認事項
プラグインのアップデートでサイトが壊れるリスクを減らすには、いくつかの事前対策が有効だ。第一に、本番サイトで直接アップデートを実行するのではなく、ステージング環境で事前にテストする方法が最も安全だ。国内のレンタルサーバーの多くは管理画面からワンクリックでステージング環境を作成できる機能を提供している。
第二に、WordPressにはプラグインの自動更新機能があるが、ビジネス用途で使っているサイトではこれをオフにし、すべてのアップデートを手動で確認する運用が推奨される。プラグイン一覧で更新通知を受け取ったら、そのプラグインの変更履歴（changelog）を読み、自分の環境に影響がありそうかを判断してから実行する。
第三に、バックアッププラグインを必ず導入し、アップデート前の状態をまるごと保存する習慣をつける。もし何か起きても数分で元に戻せる安心感が、トラブル時の心理的負荷を大きく下げる。
よくある質問
GS Team Members以外のプラグインでも同じようなエラーは起きるのか
起きる可能性は十分ある。特にDiviやElementorのようなページビルダー向けのアドオンを提供するプラグインは、テーマ側のバージョンと整合性が取れていないアップデートをリリースしてしまうことがある。致命的エラーに遭遇したら、まず該当プラグインを停止し、最新バージョンの有無を確認するのが基本だ。
リカバリーモードのメールが届かない場合はどうする
サーバーのメール送信設定が正しくない、管理者メールアドレスが古い、または迷惑メールに振り分けられている可能性がある。FTPで問題のプラグインを停止してから、WordPressの「設定」→「一般」で管理者メールアドレスを最新のものに更新し、SMTPプラグインを導入してメール送信を安定させるのが長期的な解決策になる。
Diviを使っていなければこのエラーは起きないのか
その通りだ。今回のエラーはGS Team MembersのDivi統合用コードに起因するため、他のテーマを使っているサイトでは発生しない。ただし、プラグインのアップデートで別のテーマとの組み合わせに問題が生じるケースは常にあり得るため、油断は禁物だ。
プラグインの更新前に毎回ステージングテストは必要なのか
小規模なサイトや個人ブログであれば必須ではないが、ECサイトや企業サイトなどビジネス用途では強く推奨される。数分のテストで数時間のダウンタイムを防げるなら、手間をかける価値は十分にある。最近の国内レンタルサーバーはステージング機能を標準搭載しているところも多い。
Google Site Kitは関係しているのか
関係していない。エラーのスタックトレースにGoogle Site Kitが登場するのは、REST APIの初期化時にたまたま処理が巻き込まれたためだ。GS Team Members単体の問題であり、Google Site Kit側での対応は不要だ。
この記事のポイント
- GS Team Members 2.7.17はDivi環境で致命的エラーを引き起こす
- リカバリーモードで管理画面に入りプラグインを停止すればサイトは復旧する
- 開発者が公開した修正版2.7.18へアップデートすれば根本解決する
- FTPでの手動停止も有効な代替手段だ
- 重要なサイトではステージング環境での事前テストが再発防止に効く
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce決済が「処理中」で止まりサンクスページに遷移しない場合の対処法
WooCommerceでRazorpay決済を利用しているサイトで、支払い自体は成功しているのにチェックアウト画面が「処理中です。しばらくお待ちください」と表示されたまま止まり、注文完了ページへ遷移しない問題は、RazorpayのJavaScript SDKが正常に読み込まれていないか、他のプラグインとの競合によってフォーム送信処理が破損している場合に起こる。
特にサンドボックスモードでは正常に動作するのに本番環境でのみ発生する場合、APIキーの設定ミスや決済スクリプトのパス解決エラーが根本原因である可能性が高い。ブラウザの開発者コンソールを開くと GET .../build/undefined 403 や document.razorpayform.submit is not a function といったエラーが記録されているはずだ。以下では原因の特定から具体的な修正手順までを順に解説する。
ブラウザコンソールでエラーの全体像を把握する
まず最初に行うべきは、問題が起きているページで開発者ツールを開き、コンソールタブとネットワークタブに出力されているエラーを確認することだ。Razorpayの処理フローはほぼすべてフロントエンドのJavaScriptで制御されているため、バックエンドのログだけでは見えない問題がここに集中して現れる。
Chromeの場合、決済画面で F12 を押してDevToolsを開き、以下の手順で記録を取る。
記録した中で特に注目すべきは以下の2種類のエラーだ。
GET https://checkout-static-next.razorpay.com/build/undefined 403というリクエストが発生している場合、Razorpay SDKのビルドパスが正しく解決されていない。末尾が/undefinedになっているのが最大の手がかりだ。Uncaught TypeError: document.razorpayform.submit is not a functionは、決済フォームの送信メソッドが何らかの理由で失われていることを示す。他のJavaScriptによって上書きされているか、Razorpayのスクリプト自体が最後まで読み込まれていない可能性が高い。
GET …/build/undefined 403 エラーが示す根本原因
Razorpayのチェックアウトスクリプトは、プラグインが動的に生成するパスに基づいて checkout-static-next.razorpay.com/build/【バージョン番号】 というURLから読み込まれる。このバージョン番号が何らかの理由で空になると /build/undefined という不正なURLが生成され、当然ながら403 Forbiddenで拒否される。
この現象は主に次の3つの状況で起こる。
本番用APIキーが未設定または誤ったキーが入力されている
Razorpayプラグインの設定画面（WooCommerce → 設定 → 決済 → Razorpay）を開き「本番用キーID」と「本番用キーシークレット」の両方が 本番環境用の正しい値 になっているか確認する。サンドボックス用のキーが誤って本番フィールドに入力されていると、スクリプトパスの生成に失敗する。キーはRazorpayダッシュボードの「Settings → API Keys」から再発行できる。
プラグインのバージョンが古いか不完全に更新されている
公式の「Razorpay for WooCommerce」プラグインが最新版かどうかを確認する。過去のバージョンには、特定の条件下でSDKバージョン文字列が空になる不具合が報告されている。wp-adminのプラグイン一覧で更新があれば適用し、問題が継続する場合は一度プラグインを完全に削除してから再インストールする。削除前に必ずAPIキーをメモしておくこと。
マルチカレンシープラグインがRazorpayの設定を上書きしている
WooCommerce Currency Switcher（FOXやAeliaなど）を使用している場合、通貨切り替えの過程でRazorpayの決済スクリプトに渡すパラメータが改変されることがある。特にジオベースで通貨を自動切り替えしている環境では、チェックアウトページ読み込み時に想定外の通貨コードがRazorpayに渡され、SDKの初期化に失敗するケースが確認されている。
通貨スイッチャー側の設定で、チェックアウトページと決済完了ページを通貨切り替えの対象外にするルールを追加しても改善しない場合、以下の方法で問題の所在を明確にできる。
undefined になり、スクリプトパスが /build/undefined に/build/v3.45.0 など正常にdocument.razorpayform.submit is not a function を解消する
このTypeErrorは、決済フォームを送信するタイミングで razorpayform オブジェクトの submit メソッドが存在しないことを意味する。原因は主に2つに絞られる。
JavaScriptの最適化や結合によるメソッド破損
LiteSpeed CacheやAutoptimizeなどのキャッシュ・最適化プラグインがJavaScriptを結合（Combine）したり、圧縮（Minify）したり、遅延読み込み（Defer）したりする設定が有効だと、Razorpayのフォームオブジェクトが初期化される前に他のスクリプトが実行され、document.razorpayform が不完全な状態になる。
JavaScriptの最適化機能をすべてオフにしても改善しない場合でも、LiteSpeed Cacheにはページ単位の最適化設定や「ゲストモード」など追加の最適化機能が存在する。プラグインを完全に無効化してテストした上で、それでも直らなければキャッシュ以外の競合を疑う。
サンクスページカスタマイズプラグインによるリダイレクト干渉
「WooCommerce Thank You Page」のような注文完了ページをカスタマイズするプラグインは、通常のリダイレクトフックを上書きする。Razorpayが決済完了後に実行する razorpayform.submit() が、この上書きされたフローと衝突し、メソッド呼び出し自体が失敗するケースがある。
サンクスページプラグインを無効化してテストした結果、問題が解消するのであれば、そのプラグインが原因だ。Razorpayとの互換性をプラグイン開発者に確認するか、よりシンプルなフックベースのカスタマイズ（テーマのfunctions.phpで制御）に切り替える。
プラグインの競合を段階的に切り分ける手順
エラーのパターンから明らかな原因を特定できない場合は、標準的なトラブルシューティングの手順で競合を絞り込む。本番サイトで作業する前に、必ずステージング環境を用意するか、メンテナンスモードを有効にしてから行う。
STEP 4では、まず通貨スイッチャーとキャッシュ系プラグインを最初に有効化してテストする。この2つが最も競合を起こしやすい。次にPixelYourSiteなどの外部スクリプトを注入するプラグインをテストし、最後にサンクスページプラグインを検証する。
RazorpayのWebhook設定も再確認する
フロントエンドのJavaScriptエラーに加えて、バックエンドのWebhookが正しく設定されていないと、決済完了後に注文ステータスが更新されない。Razorpayダッシュボードの「Settings → Webhooks」で以下を確認する。
- Webhook URLが
https://あなたのサイトURL/wc-api/razorpay_webhook/になっている。 - イベントに
payment.authorizedとrefund.createdが最低限含まれている。 - WebhookシークレットがWooCommerce側のRazorpay設定に入力した値と完全に一致している。
- 重複したWebhook登録がない（過去のテストで作成した古いWebhookが残っていると競合する）。
よくある質問
サンドボックスでは正常なのに本番だけで止まるのはなぜですか？
本番用のAPIキー設定ミスか、本番環境専用のプラグイン（セキュリティや最適化）がRazorpayのスクリプトに干渉している可能性が高い。サンドボックスと本番で異なるキーを使っていることを再確認し、本番環境にのみ有効なプラグインを一時停止して切り分ける。
Razorpay以外の決済ゲートウェイでも同じ現象は起こりますか？
StripeやPayPalなど他の決済プラグインでも、JavaScriptの競合やリダイレクトフックの干渉によって同様の「処理中」ループが発生することがある。原因の切り分け手順はほぼ共通しているため、本記事のSTEPを他のゲートウェイにも応用できる。
コンソールにエラーが出ていないのに処理が止まる場合は？
PHPのメモリ不足や実行時間制限が原因で、決済完了後のサーバーサイド処理が途中で止まっている可能性がある。WooCommerceのステータスレポートでPHPのメモリ制限が256MB以上、最大実行時間が300秒以上あるか確認する。サーバーのエラーログも併せて調査する。
Razorpayプラグインを最新にしても直らない場合は？
プラグインの公式GitHubリポジトリで同様のIssueが報告されていないか確認する。解決策としてパッチが提供されていることもある。また、Razorpayのカスタマーサポートに本番環境のドメインとエラーの詳細を伝えて調査を依頼する方法も有効だ。APIキーの発行元アカウントに制限がかかっていないかも合わせて確認してもらえる。
PixelYourSiteを無効化せずに共存させる方法はありますか？
PixelYourSiteの設定で「チェックアウトページでのスクリプト実行を遅延させる」オプションをオフにするか、カスタムコードでRazorpayのスクリプトがPixelYourSiteより先に読み込まれるよう wp_enqueue_scripts の優先度を調整する。functions.phpに以下のようなコードを追加する方法もある。
add_action('wp_enqueue_scripts', function() {
if (is_checkout()) {
wp_dequeue_script('pys');
wp_enqueue_script('pys', 'path/to/pys.js', array('razorpay'), null, true);
}
}, 100);このコードはあくまで概念を示すもので、実際のハンドル名やパスはプラグインのソースを確認して書き換える必要がある。
この記事のポイント
- ブラウザコンソールで
/build/undefined403エラーやrazorpayform.submitTypeErrorを確認する - 本番用APIキーが正しく入力されているか、Razorpayダッシュボードで再確認する
- 通貨スイッチャーがチェックアウトページで干渉していないか検証する
- JavaScript最適化プラグインを完全無効化し、サンクスページカスタマイズプラグインを停止してテストする
- 全プラグイン無効化と標準テーマ切り替えで競合を段階的に切り分ける
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
AutoptimizeのJavaScript最適化でドロップダウンメニューが動かない時の除外設定
Autoptimize の「JavaScript コードを最適化」を有効にすると、ヘッダーのドロップダウンメニューが開かなくなる問題は、最適化処理がメニューを動かす JavaScript と競合するために起こる。ブラウザの開発者ツールで原因となるスクリプトを特定し、Autoptimize の「除外するスクリプト」欄にファイル名を追加すれば、最適化を維持したままメニューを正常に動作させられる。
なぜ JavaScript 最適化でメニューが動かなくなるのか
Autoptimize の「JavaScript コードを最適化」は、複数の JavaScript ファイルを1つに集約し、不要な空白やコメントを削除する「縮小（ミニファイ）」を施す機能だ。加えて、読み込みタイミングをずらす「遅延読み込み」や「非同期読み込み」も合わせて適用される。
ドロップダウンメニューは、マウスのホバーやクリックを検知してサブメニューを表示する仕組みで、内部では jQuery やテーマ独自の JavaScript が複数連携して動作する。最適化によってこれらのスクリプトの実行順序が入れ替わったり、縮小処理中に特定の構文が破損したりすると、メニューを開くイベントが発火しなくなる。
特定のページだけで発生する仕組み
トップページや一部の内部ページでは正常に動き、キャリアページや特定の投稿ページだけでメニューが壊れる場合、落ちているのは集約後の順序問題であることが多い。ページごとに読み込まれるスクリプトの組み合わせが微妙に異なるため、特定の構成でのみ実行順序の破綻が表面化する。
jQuery 依存のメニューは特に影響を受けやすい
多くの WordPress テーマはメニューの開閉に jQuery を使う。Autoptimize の標準設定では jQuery も他のスクリプトと一緒に集約されるが、jQuery は他のスクリプトより先に読み込まれなければならない。集約順序が変わって jQuery が後回しになると、$ is not defined や jQuery is not defined といったエラーが発生し、メニュー全体が沈黙する。
原因となる JavaScript ファイルを特定する手順
闇雲に除外設定を増やすのは避けたい。まずはブラウザの開発者ツールでエラーの出どころを確認し、ピンポイントで除外するファイルを決める。
autoptimize_xxxxx.js やテーマの navigation.js）を記録するwp-content/themes/テーマ名/js/... 等）を特定するエラーメッセージが「jQuery is not defined」であれば、jQuery の読み込み順がずれている。テーマ名や「navigation」「menu」を含むファイル名が表示されたら、そのファイルが縮小によって破損している可能性が高い。
エラーが出ない場合の切り分け方
コンソールにエラーが出ていないのにメニューが動かないケースもある。この場合は「Network」タブで autoptimize_xxxxx.js のレスポンスを確認し、途中で切れていないか、スクリプトの末尾が正常かを調べる。また、Autoptimize の設定で「JavaScript コードを最適化」だけをオンにし、「JavaScript を集約する」をオフにして症状が変わるかも試すと、問題の絞り込みが進む。
Autoptimize の除外設定でメニューを修復する
原因ファイルが特定できたら、Autoptimize の設定画面で除外リストに追加する。除外されたファイルは最適化の対象外となり、元の順序で単独で読み込まれるため、競合が解消する。
navigation.js と jquery.js を追加除外設定の具体的な入力方法
WordPress 管理画面の「設定」→「Autoptimize」→「JavaScript オプション」を開く。「JavaScript コードを最適化」が有効になっている状態で、その直下にある「除外するスクリプト」欄に、カンマ区切りでファイル名を入力する。
入力例を以下に示す。実際のファイル名は、サイトのテーマやプラグイン構成によって異なる。
jquery.js、 jQuery 本体jquery.min.js、 縮小版の jQuerynavigation.js、 テーマのメニュー制御スクリプトtheme-menu.min.js、 テーマが提供する縮小済みメニュー制御js_composer_front、 WPBakery 等のビルダーが出力するスクリプト
部分一致で指定できるため、jquery とだけ書けば、ファイル名に「jquery」を含むすべてのスクリプトが除外される。同様に navigation や menu といったキーワードでもよい。
「jQuery を集約しない」オプションの活用
Autoptimize の「JavaScript オプション」内には「jQuery を集約しない」というチェックボックスも用意されている。jQuery 依存のエラーが出ている場合は、個別のファイル名を書く前にまずこのチェックを入れてみると、まとめて解決することが多い。
どうしても直らない時の応用設定
除外設定を丁寧に行ってもメニューが復活しない場合、最適化モードそのものを調整する手がある。「JavaScript コードを最適化」の中には「縮小のみ（集約しない）」といった選択肢もあり、集約をやめて縮小だけに留めれば、多くの競合が回避される。
スクリプトの読み込み位置を変える
「JavaScript をフッターに移動する」や「Async（非同期）にする」といった項目も、メニューの動作に影響を与えうる。メニューはページの初期表示時に即座に動作する必要があるため、非同期読み込みにしてしまうと DOM 構築が完了する前にメニューのイベント登録が走ってしまい、動作しなくなる。まずはこれらのチェックを外して試す。
プラグイン単位での競合を疑う
まれに、Autoptimize と特定のキャッシュ系プラグインやテーマ付属の最適化機能が二重に働いて競合することがある。W3 Total Cache や WP Rocket に組み込まれた最適化と同時に使わず、いずれか一方に統一する。また、テーマの「パフォーマンス」設定内に JavaScript の最適化機能がある場合は、そちらを無効にして Autoptimize に一本化する。
よくある質問
除外設定を追加したのにメニューが直らない
Autoptimize のキャッシュが残っていると、除外設定が反映されずに古い最適化済みスクリプトが使われ続ける。管理画面の Autoptimize 設定画面で「キャッシュをクリア」ボタンを押し、さらにブラウザのキャッシュもスーパーリロード（Ctrl+F5）で破棄する。サーバーによっては CDN やサーバー側キャッシュもクリアする必要がある。
ファイル名がわからない時はどうするのか
ブラウザの開発者ツール「Network」タブで、JS ファイルの一覧を名前順に並べ、「theme」「menu」「nav」「dropdown」を含むファイルを探す。該当ファイルが見つからない場合は、テーマの開発者に「メニュー制御に使っている JavaScript ファイル名」を問い合わせるか、Autoptimize の「縮小のみ（集約しない）」モードで一旦回避する。
一部のページだけメニューが壊れるのはなぜか
ページによって読み込まれるプラグインやウィジェットのスクリプトが異なるため、集約後のファイルの構成が変わる。特定のページにだけ表示される「お問い合わせフォーム」や「求人一覧」のスクリプトが混ざると、集約後の全体の実行順序が崩れて、たまたまメニュー制御に影響が出ることがある。
Autoptimize を無効にするとサイトが遅くなるのが心配だ
JavaScript 最適化を完全に切る必要はない。問題のスクリプトだけをピンポイントで除外すれば、大部分のスクリプトは最適化されたまま配信される。PageSpeed Insights 等でスコアを確認しながら除外範囲を最小限に絞れば、速度と機能の両立は十分に可能だ。
この記事のポイント
- JavaScript 最適化によるドロップダウンメニュー不具合は、スクリプトの順序破綻や縮小破損が原因
- 開発者ツールの「Console」でエラーを特定し、原因ファイルを Autoptimize の除外リストに追加する
- 「jQuery を集約しない」オプションが有効なケースも多い
- 除外設定後は必ず Autoptimize キャッシュとブラウザキャッシュをクリアする
- 「縮小のみ」「非同期読み込みオフ」など、最適化の段階を調整することでも解決できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressのアコーディオンブロックが開かない原因と直し方
WordPress 6.9のアコーディオンブロックをクリックしても展開しない場合は、ページ読み込み時にブロックのJavaScriptが正しく初期化されていないことが原因だ。キャッシュを完全に削除し、プラグインの競合を確認することで大半のケースは解決する。改善しない場合はテーマの読み込み順を調整する。
なぜアコーディオンブロックが展開しないのか
この現象は、アコーディオンブロックの内部で使われる view.min.js が、ページの読み込み完了前にクリックイベントを受け取ってしまうことで起きる。具体的には、ブロックの状態（開閉のデータ）がまだ存在しないタイミングで「開く」処理が実行され、「未定義のプロパティを読めない」というTypeErrorが発生するという仕組みだ。
読み込み速度が極端に速い場合も、逆に特定のスクリプトが遅延して遅くなった場合も、内部のタイミングがずれて初期化が完了しないまま操作できてしまう。Twenty Twenty-Fiveテーマに限らず、他のテーマやプラグインがページの読み込み順を変えていると同様の症状が出ることがある。
c が undefined → エラーJavaScriptエラーの原因を開発者ツールで確認する方法
まずエラーが出ているか正確に把握する。ChromeやEdgeのデベロッパーツール（F12キー）を開き、Consoleタブを確認する。該当ページでアコーディオンをクリックした瞬間に赤いエラーメッセージが出ていれば、今回の症状に合致する。
エラー文は日本語環境でも英語で「Uncaught TypeError: Cannot read properties of undefined (reading ‘isOpen’)」と表示される。ファイル名に view.min.js が含まれていれば、WordPress 6.9の標準アコーディオンブロックの初期化問題だと特定できる。
アコーディオンが開かない場合の5つの対処法
以下の手順は、簡単で効果が高いものから順に並べている。1つずつ試し、改善した時点で後続の手順は不要だ。
サイト全体のキャッシュを完全に削除する
キャッシュ系プラグイン（W3 Total CacheやWP Super Cacheなど）を導入している場合は、管理画面から全キャッシュを削除する。加えてサーバー側のキャッシュ（NGINX FastCGI CacheやLiteSpeed Cache）もクリアする。ブラウザキャッシュを個別に消すよりも、プラグインやサーバー管理パネルからの一括削除のほうが確実だ。
全プラグインを無効化して原因を特定する
プラグインのいずれかがJavaScriptの読み込み順やタイミングに干渉している可能性がある。「プラグイン」→「インストール済みプラグイン」からすべてのプラグインを一時的に無効化し、アコーディオンブロックの動作を確認する。問題が解消したら、1つずつ有効に戻していき、再発するプラグインを特定する。
この方法で原因プラグインが判明した場合、そのプラグインの代替を探すか、開発元に修正を依頼するのが現実的だ。特にJavaScriptを多用するページビルダーや最適化系プラグインは干渉しやすいので注意する。
テーマの状態をリセットする
子テーマやカスタマイズを行っている場合は、一時的に親テーマのTwenty Twenty-Fiveに直接切り替える。必要に応じて「外観」→「テーマ」から親テーマを有効化し、カスタマイザーで追加した独自のCSSやJavaScriptが干渉していないか切り分ける。
functions.phpでスクリプト読み込み順を調整する
上記の手順で解決しない場合、テーマやプラグインの読み込み順が影響している可能性が高い。子テーマの functions.php に以下のコードを追加し、WordPress標準のスクリプトをより早い段階で読み込ませる方法が有効だ。
<?php
function force_accordion_script_priority() {
if ( has_block( 'core/accordion' ) ) {
wp_enqueue_script( 'wp-block-library' );
// モジュールスクリプトの読み込みを優先
add_filter( 'script_loader_tag', function( $tag, $handle ) {
if ( false !== strpos( $handle, 'accordion' ) ) {
$tag = str_replace( 'defer', '', $tag );
}
return $tag;
}, 10, 2 );
}
}
add_action( 'wp_enqueue_scripts', 'force_accordion_script_priority', 5 );
このコードは、アコーディオンブロックがページ内に存在する場合にだけ動作し、defer 属性を除去して読み込みの優先度を上げる。極端な遅延読み込みが原因でエラーが起きている場合に効果を発揮する。
そもそもこのエラーが起きる条件とは
このエラーはWordPress 6.9の標準ブロックに含まれる view.min.js のタイミング依存が直接の原因だ。以下のような条件が重なると発生しやすい。
- 高速なサーバー環境やCDNによってHTMLの描画が極端に速い
- 最適化プラグインがスクリプトに
deferやasyncを追加している - ページビルダーが独自の方法でスクリプトを結合・遅延読み込みしている
- カスタムテーマが
wp_head()やwp_footer()を正しく呼び出していない
いずれも、WordPressが想定するスクリプトの読み込み順序が変更されることで、ブロックの状態管理オブジェクトが生成される前にクリックイベントのリスナーが機能し始めてしまう点で共通している。
再発を防ぐための設定ポイント
この問題を恒久的に避けるには、スクリプト最適化の設定を見直すのが最も効果的だ。キャッシュプラグインや高速化プラグインの「JavaScriptの遅延読み込み」「結合」「minify」などの機能を無効化するか、該当ブロックだけ除外設定を追加する。
具体的には、プラグインの設定画面で「遅延読み込みの除外」に view.min.js または accordion を含むパスを指定する。多くの高速化プラグインでは、特定のスクリプトハンドルやファイル名を除外リストに登録できる。
また、WordPressのアップデートによってコア側の修正が入る可能性も高い。そのため、WordPress本体とテーマは常に最新の状態を維持し、修正が公式にリリースされ次第適用することも大切だ。
よくある質問
特定のブラウザだけで起きるのか
いいや、ブラウザの種類よりもページの読み込み速度やスクリプトの実行順序に左右される。Chrome、Edge、Firefox、Safariのいずれでも発生しうる。特定のブラウザだけで再現する場合は、ブラウザ拡張機能の影響も疑うとよい。
プラグインをすべて無効にしても直らない場合は
テーマに原因がある可能性が高い。一度Twenty Twenty-Fiveの親テーマを直接有効化し、それでも改善しなければサーバー側のキャッシュ機構やCDNの設定を見直す。functions.phpに追加したカスタムコードが干渉しているケースもある。
キャッシュをクリアしても改善しないときの次の手順は
ブラウザのシークレットウィンドウでテストし、ブラウザキャッシュを完全に排除した状態で確認する。それでも同じエラーが出るなら、上記のSTEP 4のコード追加を試すか、WordPress本体の再インストールを検討する。
このエラーはWordPressのバグなのか
厳密にはタイミング依存のバグであり、WordPress 6.9に標準で含まれる view.min.js に起因する。今後のアップデートで修正される見込みだが、現時点ではサーバー環境やプラグイン構成によって発生が左右されるため、回避策を講じるのが現実的だ。
テーマ側で何かできることはあるか
ある。先述のfunctions.phpによる defer 属性の除去のほか、テーマが wp_footer() の直前に不要なスクリプトを挿入していないか確認することも有効だ。シンプルなテーマほどこの問題は起こりにくい。
この記事のポイント
- アコーディオンが開かない原因はJavaScript初期化のタイミングずれ
- キャッシュの全削除とプラグイン全無効化でほぼ修正できる
- 改善しなければfunctions.phpでスクリプト優先度を上げる
- 最適化プラグインの設定で
view.min.jsを除外登録する - WordPress本体とテーマは常に最新版を保つ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
プラグイン更新後にログイン不可「ユーザー名またはパスワードが間違っています」と表示される原因と直し方
プラグインの更新後、正しいユーザー名とパスワードを入力しているにもかかわらずログインできず「ユーザー名またはパスワードが間違っています」というエラーが表示されるなら、その原因は特定のプラグインが認証フローに干渉したことによる競合だ。特にログインフォームをカスタマイズするプラグインと、追加のセキュリティ認証（Cloudflare Turnstileなど）を組み合わせている場合に発生しやすい。
なぜ正しいパスワードなのに「間違っています」と表示されるのか
WordPressは通常、ログイン認証を「wp-login.php」を通じて処理している。ここにプラグインが独自のログインフォームを追加したり、認証前にCAPTCHAや追加認証を挟むと、データの送信順序や検証の流れが変わる。プラグインのバージョンアップでこの処理順序が微妙に変わった結果、正しい認証情報がバックエンドの判定に渡る前に「誤り」と判定されるケースが起きる。
典型的なパターンとして、会員制サイト用のプラグイン（Ultimate Memberなど）が生成する独自ログインページと、追加のボット対策機能（Cloudflare TurnstileやreCAPTCHA）が衝突する問題が挙げられる。どちらか一方が先にフォームの値を検証し、もう一方に正しい情報を渡せなくなることが原因だ。
まず試す緊急回避策 管理画面に入れない場合の対処
ログインできない状態では管理画面からプラグインを停止できない。次のいずれかの方法でプラグインを一時的に無効化し、管理画面に再アクセスできるようにする。
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などの認証機能をログイン画面に追加するプラグイン
旧バージョンに戻す方法
プラグインの以前のバージョンは、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標準ログインページへの統一も検討する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Relevanssiで日本語検索クエリが原因のテーブルフルスキャンを防ぐ
—
Relevanssiで日本語だけの検索クエリがデータベースの全テーブルスキャンを引き起こす問題は、トークナイズ結果が空文字になるケースをカスタムコードで事前に検知し、SQLを発行せずに空の結果を返すことで根本的に回避できる。設定のチューニングと併用すれば、サイト全体の検索パフォーマンスを維持できる。
なぜ日本語の検索クエリで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を利用する。
具体的な実装コードと設置手順
このデモが示す流れで、コードを追加する。以下は実際に利用できる実装例だ。
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の設定
コードによる早期リターンと並行して、インデックスと検索設定そのものを見直すことで、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やレート制限との併用が効果的
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Contact Form 7のPDF出力で条件分岐ショートコードが効かない時の直し方
Contact Form 7 から出力する PDF に条件分岐のショートコード（[if] や [hide-*] など）が反映されないとき、最も多い原因は Send PDF for Contact Form 7 プラグインが、Conditional Fields のような他プラグインのショートコードを PDF 生成時に評価しないことだ。この問題は、PDF テンプレート内で直接条件分岐を記述する代わりに [_mail_body] タグを使ってメール本文を丸ごと流し込むか、出力直前にショートコードを再評価するフィルターフックで解決できる
なぜ PDF 出力で条件分岐ショートコードが効かなくなるのか
Send PDF for Contact Form 7 は、フォーム送信時に生成されたデータを PDF テンプレートに差し込んで出力する。このとき、[text-123] のような Contact Form 7 の標準タグは正しく展開されるが、Conditional Fields が提供する [group] や [if] といった条件分岐用のショートコードは、PDF 生成のコンテキストでは実行されないことが多い
理由は主に2つある。ひとつは、これらのショートコードが WordPress の do_shortcode フックに登録されていても、PDF プラグインがテンプレートを処理する段階では、フォームの送信データや条件判定に必要なコンテキストが不足しているケースだ。もうひとつは、Conditional Fields のショートコードが「メール送信時」にのみ動作するように設計されており、PDF 作成時にはそもそも処理の対象外になっているパターンだ
[if kosten-an-arbeitgeber]この見積は雇用主向けです[/if]
※条件にかかわらずショートコードがそのまま表示される
この見積は雇用主向けです
※条件に合致したテキストだけが PDF に出力される
このデモのように、PDF テンプレート内に [if] や [hide-*] を直書きしても、Send PDF 側で解釈されずに終わってしまう。以前は偶然動いていたとしても、プラグインのバージョンアップで処理順序が変わると即座に壊れる原因になる
プラグイン更新後に突然動かなくなったのはなぜか
「以前は PDF で条件分岐が効いていたのに、更新したら動かなくなった」という声は非常に多い。これは、Send PDF for Contact Form 7 または Conditional Fields for Contact Form 7 の内部実装が変更され、テンプレートの評価タイミングやショートコードの登録順が変わったためだ
具体的には、Send PDF プラグインの旧バージョンでは、PDF テンプレート全体を do_shortcode で処理していたが、パフォーマンスやセキュリティの改善に伴ってその処理が省略されたり、独自の置換処理に切り替わったりすることがある。結果として、Conditional Fields のショートコードが一切処理されなくなる
また、Conditional Fields 側のアップデートで、[if] タグの内部実装が変わり、PDF 出力時に必要なデータが揃わなくなった可能性もある。どちらにせよ、PDF テンプレート内で直接条件分岐を記述する方式は、プラグインのバージョンに依存しやすく、根本的に不安定と言える
[_mail_body] タグでメール本文をそのまま PDF に流し込む
![[_mail_body] タグでメール本文をそのまま PDF に流し込む](https://www.aandgweb.co.jp/wp-content/uploads/2026/06/2026-06-19_pain_001_h2_003.webp)
最も簡単で安全な解決策は、PDF テンプレート内に [_mail_body] を記述することだ。このタグは、Contact Form 7 が送信する「メール本文」をそのまま PDF 内に差し込む。メール本文のほうでは、Conditional Fields の条件分岐が正常に評価されているため、結果的に PDF にも正しい内容が出力される
この方法を使えば、Conditional Fields に限らず、メール本文で動作するあらゆるショートコードが PDF に反映される。ただし、PDF 独自のレイアウトや追加情報（会社ロゴや利用者に合わせた細かな差し込み）が必要な場合は、[_mail_body] の前後に固定の HTML を加えることで対応できる
注意点として、[_mail_body] はメール本文をそのままコピーするため、メール用の改行やスタイルが PDF に持ち込まれる。どうしてもレイアウトを細かく制御したい場合は、次に紹介するフィルターフックを使った方法を選ぶ
functions.php で PDF 生成前に条件分岐を再評価させる
Send PDF for Contact Form 7 には、PDF の最終的な内容を上書きできるフィルターフックが用意されている。これを利用すれば、テンプレート内の [if] や [hide-*] を手動で再評価できる。テーマの functions.php に次のようなコードを追加すると、Conditional Fields のショートコードが PDF 出力時に正しく展開される
add_filter( 'cf7_send_pdf_template_html', function( $html, $form_id ) {
// フォームの送信データを取得し、ショートコードを再評価する
$submission = WPCF7_Submission::get_instance();
if ( $submission ) {
$posted_data = $submission->get_posted_data();
// 一時的に do_shortcode を再度適用
$html = do_shortcode( $html );
}
return $html;
}, 10, 2 );このコードは、PDF テンプレートが組み立てられた直後に do_shortcode を実行し、[if] や [group] といったショートコードをその場で評価する。投稿データが揃っているため、Conditional Fields の条件判定も正しく動く
ただし、[hide-*] のように独自のショートコードを使っている場合は、そのショートコードがどのプラグインで定義されているかを確認し、該当のプラグインが有効でなければ動作しない。もし自作のショートコードであれば、あらかじめ add_shortcode で登録しておく必要がある
さらに、Send PDF プラグインのバージョンによってはフック名が異なる可能性もあるため、公式ドキュメントを参照し、cf7_send_pdf_template_html の部分を適切なフックに置き換える。このフックが利用できない場合は、wpcf7_before_send_mail などのアクションを使って PDF 生成前にデータを補完する方法もある
よくある質問
[_mail_body] を使うとメールの HTML タグがそのまま PDF に出てしまうのでは？
はい、メールフォーマットが HTML の場合、その HTML が PDF に適用される。多くは問題にならないが、シンプルなテキスト PDF を望むなら、メール設定を「テキスト形式」に切り替えるか、フィルターフックで HTML タグを strip_tags で除去するといった工夫が必要になる
Conditional Fields の [group] ショートコードも [_mail_body] で有効になるのか？
なる。[_mail_body] は、メール送信時に CF7 が最終的に組み立てた本文をそのまま埋め込むため、[group] の条件判定もすでに解決された状態で出力される
functions.php にコードを追加しても PDF が変わらないのはなぜ？
フック名が正しいか、また対象のショートコードが本当に do_shortcode で評価可能な形式かを確認する。Conditional Fields の [if] が内部で別のロジックを使っているレアケースでは、CF7 のメールテンプレート用のフィルター（wpcf7_mail_components など）を利用してメール本文を直接 PDF に渡すほうが確実だ
独自の [hide-*] ショートコードを PDF で動かすにはどうすればいい？
該当のショートコードを定義しているコードがテーマの functions.php にあるなら、そのまま do_shortcode で評価される。もし別のプラグインに依存しているのであれば、そのプラグインが常に有効でなければならない。動作が不安定な場合は、[_mail_body] 方式に切り替えるのが無難だ
この記事のポイント
- PDF テンプレート内で [if] や [hide-*] が効かないのは、Send PDF がそれらのショートコードを処理しないため
- [_mail_body] タグを使えば、メール本文ですでに展開された条件分岐結果をそのまま PDF に流し込める
- functions.php のフックで do_shortcode を再実行すれば、PDF 出力直前に任意のショートコードを動かせる
- プラグイン更新後に動かなくなったのは、ショートコード処理のタイミングが変わったのが原因
- 安定運用には[_mail_body]方式を推奨。細かいレイアウトが必要ならフィルターフック方式を使う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている