Kadence Blocksでエディタのフォントがセリフ体になる原因と直し方
Kadence Blocks の Advanced Typography で Google Fonts を選択したにもかかわらず、ブロックエディタ上でセリフ体のフォールバックフォントが表示される問題は、Kadence Blocks 3.7.3 以降のエディタ内フォント読み込み処理の変更に起因する。フロントエンドで正しく表示されているのであれば、エディタ側の設定やバージョン調整で解決できる。
なぜエディタ内だけ Google Fonts が正しく表示されないのか
Kadence Blocks の Advanced Typography は、サイトのフロントエンドとブロックエディタの両方に選択したフォントを読み込む仕組みになっている。しかしバージョン 3.7.3 以降、エディタ画面でのフォント読み込みパスや enqueue のタイミングに変更が入り、特定の環境下で Google Fonts のスタイルシートが正しく適用されなくなった。
実際の症状として、例えば Roboto を指定したのにエディタ上では明朝体や Times New Roman 系のセリフ体で表示される。これはブラウザが指定されたフォントを見つけられず、システムのデフォルトフォントにフォールバックしている状態だ。フロントエンドでは Kadence Theme 側のフォント読み込み処理が正常に機能するため問題が表面化しない。
この問題はプラグインの競合ではなく、Kadence Blocks 単体のエディタ向けフォント読み込み処理に起因する。そのため全プラグインを無効化しても再現し、標準テーマに切り替えても改善しない場合がある。
Kadence のフォント設定を確認して対処する
「外観」→「カスタマイズ」でフォントキャッシュを削除する
Kadence Theme には、Google Fonts のローカルキャッシュを管理する機能が組み込まれている。このキャッシュが破損していたり古い情報を保持していると、エディタで正しいフォントが読み込まれないことがある。
- WordPress 管理画面の「外観」→「カスタマイズ」を開く
- 「General」→「Performance」へ進む
- 「Google Fonts」セクションにある「Clear Font Cache」ボタンをクリックする
- カスタマイザーを保存して閉じ、ブロックエディタをリロードする
この操作で Kadence が保持していたフォント情報がクリアされ、次回エディタを開いた際に最新のフォントファイルが再取得される。キャッシュクリア後も改善しない場合は、次の手順に進む。
「Google Fonts の読み込み方法」を切り替える
Kadence は Google Fonts の読み込み方式を複数用意している。設定によってエディタ側のフォント描画に影響が出るため、別の方式に変更して検証する。
- 「外観」→「カスタマイズ」→「General」→「Performance」→「Google Fonts」を開く
- 「Load Method」を現在とは別のオプションに切り替える（例: 「Local」から「CDN」へ、またはその逆）
- 保存後にブロックエディタを再読み込みしフォント表示を確認する
ローカル読み込み（Local）に設定すると、Google のサーバーからフォントをダウンロードして自サイト内に保存する。CDN 読み込みでは Google の配信網から直接フォントを取得する。サーバー環境やセキュリティ設定によっては、ローカル読み込み時のファイル生成に失敗してエディタ側のフォントが欠落することがある。
Advanced Typography のエディタ向け設定を確認する
Kadence Blocks のブロック設定パネルにある Advanced Typography には、エディタ内プレビュー用のフォント読み込みを制御する内部フラグが存在する。設定画面から直接変更できる項目ではないが、次の操作でリセットできる。
- 問題が発生しているブロックを選択し、右サイドバーの「Advanced」→「Typography」を開く
- フォント選択を一度「Default / Inherit」に戻し、保存する
- ページをリロードしたあと、再度目的の Google Fonts を選択し直す
これにより Kadence Blocks がエディタ向けにフォントを再登録し、正しいスタイルシートが読み込まれるようになる場合がある。
上記のデモはエディタ画面内でのフォント描画の違いを表したものだ。修正後はフロントエンドと同じフォントがエディタでも適用される。
Kadence Blocks のバージョンを変更して問題を回避する
バージョン 3.7.2 にダウングレードする手順
この問題は Kadence Blocks 3.7.3 以降で発生し、3.7.2 では起こらないことが確認されている。どうしてもエディタ内のフォント表示を正しく保ちたい場合、一時的に 3.7.2 へ戻すのが確実な回避策になる。ただしダウングレードはセキュリティ面で推奨されないため、次のアップデートで修正されるまでの応急処置と割り切る。
- 管理画面の「プラグイン」→「プラグインの追加」→「プラグインのアップロード」ボタンをクリックする
- Kadence Blocks の旧バージョン（3.7.2）の ZIP ファイルをアップロードする
- 「現在のプラグインをアップロードしたものに置き換えますか？」という確認で「はい」を選択する
- プラグインが上書きされたら、必ず「自動更新を無効化」して意図しないアップデートを防ぐ
旧バージョンの ZIP ファイルは、WordPress.org のプラグインページにある「Advanced View」→「Previous Versions」からダウンロードできる。上書きインストール後はブロックエディタを再読み込みし、フォント表示が正常に戻ったか確認する。
アップデートで修正されたかを定期的に確認する
Kadence Blocks は更新頻度が高いプラグインのため、数週間以内にこの問題が修正された新バージョンがリリースされる可能性がある。ダウングレードした状態でも、WordPress 管理画面の「プラグイン」ページや Kadence の公式チェンジログを定期的にチェックし、修正版が公開されたら速やかに最新版へ更新する。
手動でエディタ用スタイルを補完する方法
子テーマの editor-style.css でフォントを明示する
Kadence のエディタ内フォント読み込みが不安定な場合、子テーマにエディタ専用のスタイルシートを用意し、使用する Google Fonts を直接指定する方法が有効だ。これは Kadence の処理に依存せず、WordPress 標準の仕組みでエディタにフォントを読み込ませる。
/* 子テーマの functions.php に追加 */
function my_editor_styles() {
add_theme_support( 'editor-styles' );
add_editor_style( 'editor-style.css' );
}
add_action( 'after_setup_theme', 'my_editor_styles' );
/* 子テーマ直下の editor-style.css */
@import url('https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap');
.editor-styles-wrapper {
font-family: 'Roboto', sans-serif;
}
このコードにより、ブロックエディタの読み込み時に指定した Google Fonts が強制的に適用される。Kadence 側のフォント読み込み処理が失敗しても、エディタ上では正しいフォントが表示されるようになる。ただし、この方法はサイト全体に適用されるため、ページやブロックごとに異なるフォントを使い分けている場合は注意が必要だ。
Kadence のフィルターフックでエディタ用フォントを追加する
よりピンポイントに Kadence Blocks のエディタ向けフォント読み込みを補強したい場合、Kadence が提供するフィルターフックを利用する。次のコードを子テーマの functions.php に追加することで、エディタ用のフォントスタイルをプログラム的に挿入できる。
add_action( 'enqueue_block_editor_assets', function() {
wp_enqueue_style(
'custom-editor-fonts',
'https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap',
[],
null
);
}, 99 );
このフックはブロックエディタが読み込まれるタイミングで実行され、優先度 99 で登録することで Kadence の内部処理より後にスタイルを追加する。結果として、Kadence が読み込みに失敗した場合でも確実にエディタ上で Google Fonts が利用可能になる。
よくある質問
フロントエンドでは正しく表示されるのにエディタだけおかしいのはなぜか
Kadence Blocks はフロントエンドとエディタで別々のフォント読み込み処理を行っている。フロントエンドは Kadence Theme の仕組みが、エディタは Kadence Blocks の仕組みが担当しており、後者の処理に不具合があるとエディタ内だけでフォントが崩れる。表示確認の際は必ず両方の環境を見比べることが大切だ。
キャッシュを削除しても直らない場合はどうすればよいか
Kadence のフォントキャッシュクリアで改善しない場合、ブラウザキャッシュやサーバー側のキャッシュ（CDN やキャッシュプラグイン）もすべて削除する。その後も直らなければ、Kadence Blocks のバージョンを 3.7.2 にダウングレードするか、前述の editor-style.css による手動補完を検討する。
特定の Google Fonts だけがエディタで表示されないのはなぜか
フォントのウェイト数が多いものや可変フォント（Variable Fonts）は、Kadence のエディタ向け読み込み処理が対応しきれずに欠落することがある。この場合、問題のフォントを Kadence の「Custom Fonts」機能で手動アップロードするか、前述のフィルターフックで直接 Google Fonts の URL を指定すると安定する。
Kadence Blocks のバージョンを下げると他の機能に影響はあるか
3.7.2 へのダウングレードでは、3.7.3 以降に追加された新機能やバグ修正が失われる。具体的にはブロックの追加オプションやパフォーマンス改善が適用されない。ただし、基本的なブロック編集機能やフロントエンド表示には大きな影響は出ない。ダウングレードはあくまで応急処置として考え、修正版のリリースを待つ姿勢が安全だ。
別のテーマに切り替えたらエディタでフォントが表示されるようになった
Kadence Theme を無効化して別のテーマにすると、エディタ内のフォント管理がそのテーマ側に移るため問題が解消されることがある。これは根本的な解決ではなく、Kadence Blocks と Kadence Theme の組み合わせ特有の不具合であることを示している。テーマを変更できない場合は、やはり前述のコードによる手動補完が現実的な対処になる。
この記事のポイント
- Kadence Blocks 3.7.3 以降のエディタ向けフォント読み込み処理に不具合があり、セリフ体にフォールバックする
- 「外観」→「カスタマイズ」のフォントキャッシュクリアと読み込み方式の切り替えで改善する可能性がある
- 一時的な回避策として Kadence Blocks を 3.7.2 にダウングレードする方法がある
- 子テーマの editor-style.css やフィルターフックでエディタ用フォントを手動補完すると確実に表示できる
- 修正版がリリースされたら速やかに最新バージョンへ更新することが重要
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce HPOSが48時間で100万件以上のアクションスケジューラ完了ジョブを生成した原因と対処法
WooCommerceサイトでデータベースサイズが突然急増し、wp_actionscheduler_actionsテーブルに数百万件もの完了済みジョブが蓄積している場合、HPOSデータ同期バッチプロセスが無限ループを起こしている可能性が極めて高い。ここでは症状の見分け方から原因の特定、停止、クリーンアップまで、具体的な手順をまとめる。
HPOS関連のデータベース肥大化が疑われる症状
以下のような兆候が複数同時に現れたら、Action Schedulerの暴走を疑ってよい。
- データベース容量が短時間で急激に増加する（数GB単位）
- PHPエラーログのファイルサイズが異常に大きくなる
- データベースのロックエラーやデッドロックが頻発する
- 管理画面やフロントエンドで「INSERT command denied」などのエラーが出る
- サーバーのバックグラウンドプロセスがほぼ常時稼働し続ける
- 注文件数が数百件なのにAction Schedulerテーブルだけが肥大化している
これらの症状は、単体では他の原因もあり得るが、データベース内の完了ジョブが異常に増えている点が最大の特徴だ。
Action Schedulerが暴走していないか確認する方法
まずはデータベースを直接調べ、どのジョブが何件蓄積しているかを確かめる。WP-CLIが使えるならコマンドラインから、そうでなければphpMyAdminやAdminerで以下のクエリを実行する。
完了ジョブの数とフック名を調べる
データベースに直接問い合わせる場合、以下のSQLで完了状態のジョブをフック名別に集計できる。
SELECT hook, COUNT(*) AS cnt
FROM wp_actionscheduler_actions
WHERE status = 'complete'
GROUP BY hook
ORDER BY cnt DESC
LIMIT 10;ここで wc_run_batch_process の件数が数十万〜数百万件と突出していれば、疑いは濃厚だ。
引数（args）から発行元を特定する
次に、そのフックの引数を見る。例えば以下のクエリで先頭の数件を取得する。
SELECT action_id, args, scheduled_date_gmt
FROM wp_actionscheduler_actions
WHERE hook = 'wc_run_batch_process'
AND status = 'complete'
ORDER BY action_id DESC
LIMIT 5;引数フィールドにはシリアライズされたデータが入っている。その中に Automattic\WooCommerce\Internal\DataStores\Orders\DataSynchronizer という文字列が含まれていれば、HPOSのデータ同期機構がバッチを発行している証拠だ。
注文件数との比較で異常を確信する
管理画面のWooCommerce → 注文で表示される注文の総数は、データベースの wp_posts（またはHPOS有効時は wp_wc_orders）で確認できる。注文が600件しかないのに、同期バッチの完了ジョブが100万件もあるなら、明らかにループが発生している。
動作中のループをリアルタイムで観察する
WP-CLIが利用可能なら、以下のコマンドでペンディング状態のジョブを監視する。
wp action-scheduler list --hook=wc_run_batch_process --status=pending定期的に実行すると、常に1件だけ存在し、それが完了するとすぐに新たなペンディングが生まれるパターンが観測できるはずだ。これはキューが滞留しているのではなく、バッチ自身が次をスケジュールし続ける無限ループであることを示す。
なぜHPOS DataSynchronizerが無限ループを起こすのか
HPOS（High-Performance Order Storage）を有効にすると、WooCommerceは注文データを従来の wp_posts テーブルから専用テーブルへ移行する。この移行やデータの同期を担うのが DataSynchronizer であり、バックグラウンドでバッチ処理を走らせる。
通常は同期が完了すればバッチは停止するが、何らかの設定不整合やエラーにより「同期が完了したと見なされず、次のバッチが即座に予約される」状態に陥ることがある。具体的には、各バッチが「保留中 → 完了 → 次バッチ予約」というサイクルを際限なく繰り返す。注文数が少なくても、このループによってAction Schedulerのテーブルだけが急激に肥大化し、データベース全体を圧迫する。
このループが起きているかどうかは、データベースを直接見るまで気づきにくい。キャッシュやRedis、WP Rocketなどを最初に疑いがちだが、真因はAction Schedulerの中にある。
データベースの安静化とクリーンアップの手順
原因がHPOSの同期バッチループと判明したら、ループを止め、完了ジョブを削除し、再発を防ぐ。以下の手順を順に実行する。
同期状態のリセット
まず、現在のHPOS同期状況を確認する。WP-CLIで次のコマンドを実行する。
wp wc hpos sync statusここで「status: in-progress」や「pending」が表示される場合、同期が完了しておらず、バッチが動き続けている可能性がある。強制的にリセットし、不要な同期を停止するには以下を実行する。
wp wc hpos sync resetリセット後、再度ステータスを確認し「idle」や「complete」になっていれば、新たなバッチはスケジュールされなくなる。
完了ジョブの一括削除
100万件単位の完了ジョブを削除するには、Action Schedulerが提供するWP-CLIコマンドを使うのが安全で高速だ。以下のコマンドで、完了状態のジョブをすべて削除できる。
wp action-scheduler clean --status=complete特定のフックのみを削除したい場合は、プレーンなSQLで一度に削除してもよいが、必ず事前にデータベース全体のバックアップを取ること。
DELETE FROM wp_actionscheduler_actions
WHERE hook = 'wc_run_batch_process' AND status = 'complete';さらに、関連するログテーブル（wp_actionscheduler_logs）の不要レコードも合わせて削除すると、ディスク容量を大きく回復できる。ただし、こちらは慎重に扱う必要があるため、まずは完了ジョブの削除だけでも効果は大きい。
テーブル最適化で容量を解放
大量のレコードを削除した後は、データベースが断片化し、実際の容量が解放されないことがある。phpMyAdminなどから該当テーブルに対して「最適化（OPTIMIZE TABLE）」を実行するか、以下のSQLを流す。
OPTIMIZE TABLE wp_actionscheduler_actions;
OPTIMIZE TABLE wp_actionscheduler_logs;これにより、削除した領域がOSに返却され、データベース全体のサイズが縮小する。
再発防止とHPOS設定の見直し
ループが再発しないように、WooCommerceのHPOS設定を確認する。管理画面の WooCommerce → 設定 → 詳細設定 → 機能 から「High-performance order storage（高性能注文ストレージ）」が有効になっているか、そして「互換モードを有効にする」や「データ同期を有効にする」オプションがどのようになっているかをチェックする。
既に全注文がHPOSテーブルに完全移行済みで、互換モードが不要なら、これらの同期オプションを無効化することで、バックグラウンドのバッチ処理そのものを止められる。ただし、テーマやプラグインが古い注文データ参照方法を使っている場合は注意が必要だ。
また、WP-CLIのcronを定期的に監視し、Action Schedulerのジョブ数が異常増加していないかをチェックする仕組みをサーバー監視に組み込むと早期発見につながる。
よくある質問
HPOSが有効かどうかはどこで確認できるか
管理画面の「WooCommerce → 設定 → 詳細設定 → 機能」に移動し、「注文データストレージ」の項目で「High-performance order storage」が選択されていれば有効だ。WP-CLIでは wp wc hpos status で確認できる。
完了ジョブを削除してもサイト動作に影響はないか
Action Schedulerの完了ジョブは過去の処理履歴であり、削除しても現在予約されているジョブや進行中の処理には影響しない。ただし、監査やデバッグ目的で残したい場合は、削除前にバックアップを取ることを強く推奨する。
WP-CLIが使えないレンタルサーバーではどうすればよいか
phpMyAdminなどのデータベース管理ツールから直接SQLで削除できる。プラグイン「WP Crontrol」などを利用すれば、Action Schedulerの一覧を管理画面で確認し、フックごとに手動で削除することも可能だが、件数が多い場合はSQLのほうが現実的だ。
同期をリセットしてもループが再発するのはなぜか
根本原因が解消されていないと再発する。たとえば、同期オプションが有効なまま残っていたり、カスタムコードがバッチをトリガーし続けているケースがある。同期の完全停止を試み、プラグインの干渉も疑いながら一つずつ切り分ける必要がある。
この記事のポイント
- データベースの急激な肥大化とAction Schedulerの完了ジョブ数に注目する
- フック名「wc_run_batch_process」と引数からHPOSの同期バッチループを特定する
- WP-CLIで同期状態をリセットし、完了ジョブを一括削除してテーブルを最適化する
- HPOSの同期設定を見直し、不要なバッチ処理を完全に止めて再発を防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
ExtendifyとElementorが競合して編集ボタンが消えた時の直し方
Extendify Onboarding and AI Assistant が有効な環境で「Edit with Elementor」ボタンが消えた場合、原因は Extendify のオンボーディング用 JavaScript が Elementor の管理画面 UI を上書きしていることにある。プラグインを無効化して削除すれば即座に復旧するが、競合を回避したい場合は Extendify の Script 読み込み制御か Elementor の連携設定を調整する必要がある。
なぜ Extendify を有効にしていると「Edit with Elementor」が消えるのか
この問題は、レンタルサーバー側が WordPress の初期セットアップ時に Extendify をプリインストールしているケースで頻発する。Extendify は Gutenberg エディタの拡張として動作し、管理画面の JavaScript 処理全体に影響を与える設計だ。Elementor のエディタ起動ボタンは、ブラウザ上で動的に生成される管理画面 UI の一部で、Gutenberg のスクリプトがロードされた後に挿入される。Extendify のスクリプトがこのタイミングを阻害すると、ボタン生成処理が飛ばされてしまう。
特に「オンボーディングガイド」という機能が原因になる。これは管理画面に重ねて表示されるチュートリアル用のオーバーレイで、初回インストール後に自動で立ち上がる。このオーバーレイがアクティブな間、特定の DOM 要素の描画がブロックされる仕様であり、その対象に Elementor の「Edit with Elementor」ボタンが含まれている。
Elementor 側の設定を正しく行い、投稿タイプで「ページ」にチェックを入れ、「Elementor Full Width」テンプレートを適用していても、管理画面の表示ロジックそのものが Extendify に遮断されるため、ユーザー側の設定では回避できない。
Extendify が有効な状態で Elementor の編集ボタンが消える仕組みを画面で比較した。管理画面の見た目はまったく変わらないのに、特定の操作要素だけが欠落するため、原因の特定に時間がかかりやすい。
管理画面から消えた「Edit with Elementor」ボタンを復活させる手順
Extendify 単体が原因かどうかを確定させる
まずはプラグインの競合切り分けの基本に入る。管理画面の「プラグイン」→「インストール済みプラグイン」から Extendify を探し、一時的に「無効化」する。この時点でページ一覧やブロックエディタを再読み込みし、「Edit with Elementor」が表示されるか確認する。復活すれば Extendify が原因で確定する。
もし無効化だけではボタンが戻らない場合、管理画面キャッシュの影響を疑う。ブラウザのハードリロード（Ctrl + Shift + R / Cmd + Shift + R）を実行し、さらにサーバー側のキャッシュプラグインがあれば全キャッシュを削除する。それでも改善しなければ、他のプラグインも含めた段階的な無効化に進む。
この手順で Extendify が原因かどうかがはっきりする。多くの場合、STEP 2 の段階ですでにボタンが戻る。
Extendify を残したまま競合を回避する方法
Extendify の AI 機能やオンボーディング自体は活用したいという場合、完全に削除する前に設定で回避できるかを試す。Extendify の管理画面「Extendify」→「Settings」にアクセスし、オンボーディングのガイド表示をスキップするか、Gutenberg 以外の場所でのスクリプト読み込みを制限するオプションを探す。バージョン 3.1 では細かい制御が難しいため、実質的には functions.php にコードを追加して Elementor の管理画面だけで Extendify のスクリプトを停止させる手段が現実的だ。
// ページ編集画面でのみ Extendify のスクリプトを解除する例
add_action( 'admin_enqueue_scripts', function( $hook ) {
if ( 'post.php' === $hook || 'post-new.php' === $hook ) {
wp_dequeue_script( 'extendify-assist' );
wp_dequeue_script( 'extendify-onboarding' );
}
}, 100 );上記のコードを有効化した子テーマの functions.php に追加すると、投稿編集画面での Extendify の干渉だけを選択的に遮断できる。完全な動作保証は環境次第だが、根本的な競合を残さずに両立させる現実解としては有効だ。
レンタルサーバーのプリインストールプラグインが原因の場合の注意点
国内のレンタルサーバーでも、WordPress のクイックスタート機能に独自のオンボーディングプラグインやテーマがプリインストールされているケースがある。こうしたプラグインはサーバー会社のブランドでパッケージされており、名前だけでは機能がわからないことも多い。管理画面が日本語であっても、元のプラグイン名が残っている場合や、逆にまったく別の名前に変わっている場合があるため、プラグイン一覧でバージョンや作者を確認する癖をつけておく。
ホスティングプロバイダーがプリインストールするプラグインには、キャッシュや高速化、セキュリティスキャン、オンボーディングアシスタントといった管理画面全体に影響するものが多い。Elementor の編集ボタンに限らず、管理画面上の特定のボタンや項目が突然消えたら、まずはプリインストールプラグインの無効化を試みてほしい。
他のプラグインでも同様の現象は起きるのか
同じように管理画面の JavaScript 全体を上書きするタイプのプラグインであれば、まったく同じ現象が起きる。管理画面の UI をカスタマイズするプラグインや、Gutenberg のブロックを拡張する多機能プラグインが競合しやすい。特に、Elementor と Gutenberg の両方を同時に運用しているサイトでは、両者のスクリプトロード順序が原因で、どちらかの編集ボタンが一時的に消えるトラブルが報告されている。
問題の特定には、ブラウザのデベロッパーツールでコンソールの JavaScript エラーを確認するのが有効だ。Elementor のボタン生成に失敗している場合、”Uncaught TypeError” や “Cannot read properties of null” といったエラーが出ていることが多い。これに加えて、ネットワークタブで Elementor 関連の .js ファイルの読み込み状況を見れば、どのプラグインが原因か絞り込みやすくなる。
よくある質問
Extendify を無効化したら Elementor の編集ボタンは戻ったが、Extendify は削除してもよいか
削除して問題ない。Extendify は Gutenberg の拡張と AI によるコンテンツ生成を目的としたプラグインで、Elementor をメインのページビルダーとして使うなら必須ではない。むしろ残しておくと将来のバージョンアップで再び競合するリスクがあるため、不要と判断したら完全に削除するほうが管理上は安全だ。
「Edit with Elementor」は表示されているがクリックしても反応しない
このケースは Extendify 以外にキャッシュプラグインやセキュリティプラグインが原因であることが多い。ブラウザのコンソールで JavaScript エラーを確認し、403 や 404 のリソース読み込みエラーが出ていれば、プラグインの除外設定を見直す必要がある。
同じ現象が発生したが Extendify は入っておらず、別のプラグインが原因のようだ。どう切り分ければいいか
全プラグインを一括で無効化し、標準テーマ（Twenty Twenty-Five など）に切り替えた状態で Elementor のボタンが復活するかを確認する。復活したら、プラグインを 1 つずつ有効化して原因を絞り込む。この方法で、どのプラグインが管理画面の JavaScript 処理を妨害しているかを確実に特定できる。
子テーマの functions.php にコードを追加するのが不安だ
コードスニペット用のプラグインを使えば、functions.php を直接編集せずに管理画面からコードの追加と削除ができる。競合が起きてもすぐに無効化できるため、動作テストにはこちらのほうが安全だ。
この記事のポイント
- Extendify が有効だと「Edit with Elementor」ボタンが管理画面から消えるのは、オンボーディングスクリプトが原因
- 無効化・削除で即座に復旧する。まずはプラグイン一覧から無効化して確認
- Extendify を残したい場合は、functions.php でスクリプトを選択的に停止するコードを使う
- レンタルサーバーのプリインストールプラグインが同様の競合を起こすケースがあるため注意
- 他のプラグイン切り分けは、全無効化→1 つずつ有効化の手順で行う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressで重大なエラーが発生した時の原因と復旧手順
WordPressで「このサイトで重大なエラーが発生しました」と表示され管理画面にもログインできない場合、まず試すべきはサーバーのエラーログ確認と、FTPを使った原因プラグインの強制停止だ。管理用メールが届かなくても、手動の切り分け作業でサイトを復旧できる。
なぜ「このサイトで重大なエラーが発生しました」と表示されログイン不能になるのか
あのメッセージが表示されるとき、WordPress内部ではPHPの「致命的エラー（Fatal Error）」が起きている。プログラムの処理がそこで停止してしまい、画面表示が途中で終わる。テーマやプラグインの更新失敗、PHPバージョンの非互換、サーバーのメモリ上限超過、あるいはコアファイルの破損など原因は多岐にわたる。
WordPress 5.2以降、致命的エラーが起きると管理画面へのログインも止められる設計になった。これは「壊れかけのサイトを操作し続けて被害を拡大させない」ための安全措置だ。通常なら「サイトに技術的な問題が発生しました。復旧手順のリンクを管理者メールアドレスに送信しました」という案内とともに「回復モード」用のリンクがメールで届く仕組みになっている。
ただ、このメールが届かないケースは実際には非常に多い。メールサーバーの設定不備や、そもそも通知を受け取る管理者アドレスが存在しないサイトもある。つまり「メールが届かない＝打つ手がない」わけではない。手動での復旧手順を覚えておけば、すぐに対処できる。
管理用メールが届かなくてもエラーの原因を特定する手順
原因を特定できないまま闇雲に操作すると、状況をさらに悪化させかねない。まずは「一体どのファイルの何行目で止まっているのか」という技術情報を掴む必要がある。
サーバーのエラーログを最優先で確認する
「重大なエラー」の原因は、ほとんどの場合サーバー上の「エラーログ」に明瞭に記録されている。エックスサーバー、ConoHa WING、さくらのレンタルサーバなど国内の主要レンタルサーバーなら、コントロールパネル内の「エラーログ」や「アクセスログ」といったメニューから確認可能だ。cPanel系であれば「Errors」アイコンから辿れる。
- ログには「PHP Fatal error」という文言と、問題が起きたファイルのパス（/home/…/plugins/xxxx/xxxx.php on line 123 など）が刻まれている
- ここでプラグイン名が明記されていれば原因はほぼ特定できたも同然だ
- もしログの見方が分からない場合は、「エラーログをダウンロードして全文をテキストエディタで開き、Fatal で検索する」とよい
wp-config.php で WP_DEBUG を有効にしてエラーを画面表示させる
エラーログがすぐに見つからない・もしくはより直感的に原因を掴みたい場合は、WordPressのデバッグモードを有効にする。FTPソフト（FileZillaなど）か、サーバーのファイルマネージャーで WordPress インストールディレクトリ直下の wp-config.php ファイルに以下の行を追加する。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );この設定でエラー情報は /wp-content/debug.log に書き出される。ブラウザ上でサイトを再読込し、その後このログファイルを開けば、先ほどと同じように原因ファイルを特定できる。WP_DEBUG_DISPLAY を true にすると画面に直接エラーが表示されるが、一般の訪問者にも見えてしまうので本番環境での使用は推奨しない。問題を解決したあとは false に戻すか、行ごと削除すること。
FTPやファイルマネージャーで原因のプラグインやテーマを強制停止する
原因が特定のプラグインやテーマだと判明したら、管理画面に戻らなくても手動で無効化できる。管理画面を経由せず、ファイル名の変更で読み込ませないようにする手法だ。これでサイトの表示や管理画面へのアクセスが復活する。
原因プラグインのフォルダをリネームする
FTPソフトまたはレンタルサーバーのファイルマネージャーで、WordPress のインストール先に移動し、/wp-content/plugins/ ディレクトリを開く。エラーログに書かれていたプラグイン名と一致するフォルダを見つけて、名前を変更する。末尾に「_deactivated」や「_bk」などを付け足せばよい。
- 変更前:
problem-plugin - 変更後:
problem-plugin_deactivated
WordPress はフォルダ名が一致しないプラグインを読み込まなくなる。結果、致命的エラーの原因が取り除かれ、サイトは無事に表示されるようになる。管理画面にも再びログイン可能になる。
すべてのプラグインを一括で疑う場合の方法
エラーログ上でプラグイン名が特定できないが、何らかのプラグインが原因であることは間違いない場合、/wp-content/plugins/ フォルダそのものをリネームしてしまう手もある。たとえば plugins を plugins_stop に変更すれば、すべてのプラグインが一括で無効化される。その状態で管理画面にログインできれば、原因はやはりプラグインなので、フォルダ名を元に戻し、管理画面から一つずつ有効化していく。テーマが原因と疑われる場合は、/wp-content/themes/ 以下の現在のテーマフォルダをリネームする。WordPress はテーマが存在しないとデフォルトテーマ（Twenty Twenty-Five など）に自動で切り替わる。
復旧後に必ずやっておくべき再発防止策
サイトが無事に表示され管理画面にも入れたら、そのまま運用を再開するのではなく、必ず以下の3つをチェックする。これで同じエラーが二度と起きにくくなる。
WordPress本体、テーマ、プラグインをすべて最新にする
致命的エラーは「古いソフトウェア」と「最新のPHPバージョン」の組み合わせで起きやすい。更新が止まっている長期放置プラグインが混ざっているなら、代替のメンテナンスされているプラグインへの移行を検討する。
PHPバージョンをサーバー管理画面で上げる
WordPress の推奨する PHP バージョンは常に上がっている。サーバーのコントロールパネルで PHP 8.1 以上に設定変更できるか確認する。変更後はサイト全体の動作確認を必ず行う。
WP_DEBUG の設定を本番環境で必ず解除する
wp-config.php にデバッグ設定を追加していた場合、必ず define( 'WP_DEBUG', false ); に戻すか、該当行を削除する。ログ出力を有効にしたまま運用すると、サーバーのディスク容量を圧迫し、別のトラブルを引き起こす。
よくある質問
管理画面の「回復モード」リンクがメールで届かない理由は
主な原因はサイトのメール送信機能そのものが正常に動いていないことだ。特に共用サーバーでは PHP の mail() 関数が制限されているか、WordPress の送信メールが迷惑メールフォルダに分類されている。SMTPプラグインなどで送信経路を信頼性の高いものに変えれば、次回以降の通知は確実に届くようになる。
WordPressログイン画面自体が表示されない場合の対処法は
管理画面へのアクセスすら致命的エラーで遮断されているという状態だ。まず前述の FTP を使ったプラグイン一括停止を試す。それでも改善しないなら、.htaccess ファイルの破損も疑って、ファイル名を .htaccess_bk に変更し、WordPress 管理画面の「設定」→「パーマリンク」で再生成させる。
FTPパスワードがわからないが復旧できるか
レンタルサーバーのコントロールパネルにログインできれば、多くの場合ブラウザ上で操作できる「ファイルマネージャー」が利用可能だ。FTPアカウントの情報が不明でも、ファイルマネージャーさえ使えれば全く同じ手順でプラグインフォルダのリネームができる。
すべてのプラグインを停止してもエラーが消えない
テーマが原因の可能性が高い。FTPで /wp-content/themes/ 以下の現在のテーマフォルダをリネームする。また、WordPress のコアファイルが破損していることもある。「ダッシュボード」→「更新」から WordPress の「再インストール」を実行すれば、コアファイルが上書き修復される。
WP_DEBUG を設定したが debug.log に何も記録されない
サーバー側で PHP エラーログの出力先が別に固定されているケースだ。その場合、レンタルサーバーのコントロールパネルに用意されている「エラーログ」機能に、より詳細な情報が出ている。そこを確認すれば解決の糸口がつかみやすい。また、wp-config.php の記述場所が /* That's all, stop editing! */ より上にあるかも確認する。
この記事のポイント
- 「重大なエラー」はPHPの致命的エラーが原因で起こる
- メールが届かなくてもサーバーのエラーログで原因を特定できる
- FTPやファイルマネージャーでプラグインフォルダをリネームして停止する
- 復旧後はPHPバージョンの確認とWP_DEBUGの解除が必須
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Events Manager 7.3.7更新後に致命的エラーで画面が真っ白になった時の直し方
Events Manager 7.3.7 へ更新した直後にサイトが真っ白になり、WP_HTML_Tag_Processor::apply_attributes_updates() の致命的エラーが発生する現象は、別のプラグインやテーマが開始した出力バッファリングとの競合が原因だ。復旧には、プラグインを 7.3.6 以前に差し戻す。根本解決には、競合相手を特定して対処する必要がある。
なぜ 7.3.7 で WP_HTML_Tag_Processor の致命的エラーが起きるのか
表示されるエラーメッセージは「PHP Fatal error: WP_HTML_Tag_Processor::apply_attributes_updates(): Cannot use output buffering in output buffering display handlers」だ。これは、すでに出力バッファリング（ob_start）が始まっているのに、さらに別の出力バッファリングを入れ子で開始しようとしたときに PHP が送出する。
Events Manager 7.3.7 では、HTML 出力の整形やサニタイズに WordPress の WP_HTML_Tag_Processor を利用している。このクラスは内部的に ob_start() を使うことがあり、タイミングによっては二重バッファリングの禁止に抵触する。単体では問題にならなくても、先に出力バッファリングを開始する別のプラグイン（キャッシュプラグインやページビルダー、一部の翻訳プラグインなど）やテーマが組み合わさると、この競合が表面化する。
WP_HTML_Tag_Processor 経由で 2 重目のバッファを開始しようとして 致命的エラー で停止、画面が真っ白になる。まずはサイトを復旧させる 以前のバージョンに戻す手順
管理画面にアクセスできず真っ白な状態でも、FTP またはサーバーのファイルマネージャーでプラグインを差し戻せば、数分で復旧できる。データベース上のイベント情報や設定は保持される。
/wp-content/plugins/events-manager/ フォルダを events-manager-old にリネームするFTP が使えない場合の代替手段
レンタルサーバーの管理画面にファイルマネージャー機能があるなら、同じ操作ができる。phpMyAdmin から wp_options テーブルの active_plugins 行を直接編集してプラグインの無効化を試みる方法もあるが、操作ミスが起きやすいため、ファイルマネージャーでフォルダ名を変更するほうが安全だ。
競合するプラグインやテーマを特定する手順
7.3.7 へ戻したい場合や、今後のアップデートでも同様の競合を防ぎたい場合は、次の手順で原因の相手を突き止める。
Health Check & Troubleshooting プラグインを使う
「サイトヘルスチェック＆トラブルシューティング」プラグインは、管理者だけが特定のプラグインやテーマを有効化した状態をテストできる公式推奨ツールだ。有効化して「トラブルシューティングモード」を開始すると、サイトの外観を変えずに、Events Manager 7.3.7 だけを有効化した状態でエラーの再現を確認したり、1 つずつ他のプラグインと組み合わせて競合を絞り込める。
手動でプラグインを 1 つずつ検証する
- 管理画面の「プラグイン」→「インストール済みプラグイン」で、Events Manager 以外の全プラグインを無効化する
- テーマを標準テーマ（Twenty Twenty-Five など）に切り替える
- Events Manager 7.3.7 を有効化してエラーが出ないことを確認する
- 1 つずつ他のプラグインを有効化し、エラーが再現した時点で競合相手を特定する
- テーマも元に戻して再現するか確認する
エラーログの取得と開発者への報告
競合相手が特定できたら、Events Manager の開発元に情報を提供することで修正が期待できる。wp-config.php で WP_DEBUG を true にし、WP_DEBUG_LOG も true に設定すると、/wp-content/debug.log にエラーの詳細が記録される。
7.3.7 を有効化し競合プラグインも有効化した状態でエラーを発生させ、そのログを添えて公式フォーラムやサポートに報告する。同時に、競合相手のプラグイン開発者にも情報を伝えると、双方の調整が進みやすくなる。
よくある質問
7.3.7 に更新しなければ、この問題は起こらないのか
その通りだ。Events Manager 7.3.6 では WP_HTML_Tag_Processor を利用していないため、出力バッファリングの競合は発生しない。セキュリティ上や機能上の理由でアップデートしたい場合は、競合相手を特定してから更新するか、修正版のリリースを待つことを推奨する。
プラグインを削除してもイベントのデータは消えないか
Events Manager の予約データやイベント情報、設定はデータベースに保存されている。管理画面からプラグインを削除しても、これらのデータは保持される。ただし、完全に削除した場合、プラグイン側のアンインストール処理で消える可能性もあるため、事前にバックアップを取っておくとより安全だ。
他のプラグインでも同じようなエラーは出る可能性があるのか
WP_HTML_Tag_Processor は WordPress 本体の機能であり、他のプラグインでも利用される可能性がある。出力バッファリングを多用するプラグイン（キャッシュ系、出力圧縮系、外部出力を加工する系）と組み合わさると、同種の致命的エラーが起こりうる。発生時は同様の切り分け手順で原因を突き止められる。
管理画面にすら入れない場合、他に試せることはあるか
FTP でプラグインフォルダをリネームするのが最も確実な復旧手段だ。サーバー管理パネルのファイルマネージャーでも同様に操作できる。どうしてもファイルに触れない場合は、サーバー会社のサポートに依頼してリネームや無効化を依頼する方法もある。WP-CLI が使える環境なら wp plugin deactivate events-manager --skip-plugins=events-manager で無効化できる。
この記事のポイント
- Events Manager 7.3.7 の致命的エラーは、他のプラグインやテーマとの出力バッファリング競合で発生する
- 復旧には FTP でプラグインフォルダをリネームし、7.3.6 以前のバージョンに差し替える
- 競合相手は「サイトヘルスチェック＆トラブルシューティング」プラグインで安全に特定できる
- エラーログを添えて開発者に報告すれば、今後の修正を促せる
- プラグイン削除ではイベントデータは原則消えず、データベースに残る
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Astraのフッターで特定のウィジェットロゴだけ表示されない時の直し方
Astra のフッターウィジェットエリアで、まったく同じ手順で設定したはずのロゴ画像が、ある特定の位置だけ表示されない。この現象はウィジェット個別の「デザイン」設定にある可視性トグルがオフになっているのが原因だ。
なぜ特定のウィジェットだけ表示されないのか
Astra のウィジェットには、共通の外観設定とは別に、各ウィジェット単体で表示を制御する「可視性（Visibility）」というオプションが存在する。この設定は Astra の「デザイン」タブ内にあり、デスクトップ・タブレット・モバイルのデバイスごとにオンオフを切り替えられる。今回のように「画像ファイル自体は正常で、配置場所を入れ替えても問題のウィジェット枠だけが出ない」という症状は、この可視性トグルが何らかの操作ミスやインポート時のずれでオフになっている典型的なケースだ。
WordPress の標準ウィジェット画面と Astra の独自設定が組み合わさっているため、単にウィジェットの中身を見るだけでは原因に気づきにくい。問題のウィジェットを開き、外観の設定ではなく Astra が拡張した「デザイン」パネルの中まで確認する必要がある。
上の手順図は Astra のウィジェット設定から可視性を修正する流れを示している。管理画面左メニューの「外観」から「ウィジェット」画面へ進み、問題のフッターエリアにある該当ウィジェットを開いて Astra の「デザイン」タブ内を確認する。
表示されないウィジェットを特定し設定を修正する手順
可視性トグルの確認と修正
ウィジェット編集画面を開いたら、まず Astra が追加する「デザイン」タブをクリックする。ここには「可視性」という項目があり、「デスクトップで表示」「タブレットで表示」「モバイルで表示」の3つのスイッチが並んでいる。いずれかひとつでもオフになっていれば、対応するデバイスでそのウィジェットは非表示になる。すべてのデバイスでオフになっていると、当然どの端末からも見えなくなる。
このトグルは、ウィジェットを複製したりテーマの設定をインポートした際に、意図せずオフの状態で保存されることがある。特に3カラム構成で同じロゴ画像を並べている場合、1つだけ設定がずれていても他と同じに見えるため、中身を確認しただけで「設定は同じだ」と思い込んでしまう。必ずデザインタブの可視性まで目を通す必要がある。
修正後にキャッシュをクリアして確認する
可視性トグルをオンにしてウィジェットを保存したら、必ずサイトのキャッシュを削除してからフロントエンドを確認する。キャッシュ系プラグインを使っている場合はそのプラグインのキャッシュ削除機能を実行し、ブラウザのキャッシュも念のためクリアしておくと確実だ。修正が即時反映されないケースの多くはキャッシュが残っているだけなので、焦らずキャッシュクリアを行ってから再度表示をチェックする。
似た症状だが可視性設定以外が原因のケース
z-index が競合している
Astra のフッター内で特定の要素だけが見えない場合、z-index の重なり順が原因になっていることがある。特に上に重なる背景要素や疑似要素（::before / ::after）があると、実際には出力されているのに視覚的に隠れてしまう。ブラウザの検証ツールで該当エリアを右クリックして「検証」を開き、要素が DOM 上に存在するかどうかを最初に確認する。要素自体があるのに見えないなら CSS の z-index や opacity、visibility プロパティを疑う。
プラグインやキャッシュの影響
最適化プラグインが CSS や JavaScript を結合・圧縮する過程で、Astra の可視性制御に関わるスタイルが誤って上書きされることがある。また、CDN を経由している場合はエッジサーバーに古いキャッシュが残っている可能性も考慮する。まずは最適化プラグインを一時停止して表示が直るか切り分け、問題が再現しなければ圧縮除外リストに Astra 関連の CSS を追加するといった対応をとる。
子テーマやカスタムコードの干渉
子テーマの functions.php にウィジェットの表示条件を操作するフィルターフック（widget_display_callback など）が記述されていると、Astra の可視性設定と競合することがある。また、独自に追加した CSS で特定のウィジェット ID に対して display: none を指定してしまっていないかも確認する。こうした干渉は、標準テーマに一時的に切り替えることでは Astra 側の問題と区別できないため、子テーマのコードを直接精査する必要がある。
よくある質問
Astra の可視性設定は Elementor で作ったフッターにも影響するのか
Elementor でフッターを構築している場合、Astra のウィジェット可視性設定は直接影響しない。ただし、Elementor で作成したフッターと Astra の標準フッターが混在している環境では、Astra の設定が効くエリアと効かないエリアが発生する。テーマのフッター管理画面で、実際にどちらのフッターが表示される設定になっているかを先に確認する。
可視性トグルをオンにしたのにまだ表示されない
可視性設定以外に、ウィジェット自体の「コンテンツ」が空になっていないか確認する。画像ウィジェットの場合、画像URLが欠落していると何事もなかったかのように空のHTMLが出力される。また、フッターウィジェットエリア全体が Astra のカスタマイザーで非表示に設定されていないかも再確認する。カスタマイザーの「フッター」→「フッターウィジェット」セクションでエリア自体の表示設定を変更できるためだ。
特定のデバイスだけで消えるのは可視性設定だけが原因か
可視性設定以外にも、CSS のメディアクエリで特定の画面幅に display: none が指定されているケースがある。Astra の追加 CSS や子テーマに誤ったメディアクエリが残っていないか、ブラウザの検証ツールでデバイスモードを切り替えながら該当要素の CSS を確認する。可視性トグルがすべてオンでも、別の CSS で上書きされていると表示されない。
この記事のポイント
- Astra の特定ウィジェットだけ非表示になる主因は「デザイン」タブの可視性トグル
- 修正はウィジェット編集画面のデザインタブからすべてのデバイストグルをオンにするだけ
- キャッシュクリア後にフロントエンドで反映を確認する
- z-index やプラグイン競合でも似た症状が出るため、DOM 上の存在確認が切り分けの第一歩
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce PayPal決済が断続的に失敗する原因と直し方
WooCommerce PayPal Payments プラグインで決済が断続的に失敗し OrderProcessor.php のエラーが発生する場合、注文 ID のセッション保存が決済リダイレクトと競合しているか、PayPal ウェブフックの署名検証に失敗している可能性が高い。原因をログから特定し、設定と更新状況を見直せば、決済の取りこぼしを止められる。
なぜ PayPal 決済やカード決済が断続的に失敗するのか
断続的に発生する決済失敗は、一定の条件が重なった時だけ起こる「競合状態」が原因になっていることが多い。WooCommerce PayPal Payments 4.0.4 以前のバージョンでは、購入者が PayPal にリダイレクトされる直前に注文 ID をセッションへ保存する処理と、PayPal 側の承認完了後の戻り処理がうまく噛み合わず、注文 ID を見失うケースが報告されている。
また PayPal から届く CHECKOUT.ORDER.APPROVED ウェブフックの署名検証に失敗すると、ブラウザ経由の戻りが完了しなかった注文を復旧できず、売上が失われる。キャッシュや最適化を完全に停止しても再発するケースは、プラグイン内部のタイミング問題である可能性が極めて高い。
エラーログから失敗のパターンを特定する
WooCommerce PayPal Payments の詳細ログを有効にする
管理画面の「WooCommerce」から「設定」へ進み「決済」タブを開く。PayPal の項目にある「接続を管理」画面の下部に「ログ」というチェックボックスがあるので、これを有効にして保存する。有効化後は決済のたびにログが蓄積され始めるので、エラーが出たタイミングを正確に追える。
ログに記録されるエラーメッセージを読み解く
失敗時のログには「Payment failed: There was an error processing your order. OrderProcessor.php:109」と出力される。ただしこのメッセージだけでは表面的な情報に過ぎない。同じ時刻付近に PayPal API への注文作成リクエストや capture 呼び出しが記録されているかを確認することが重要だ。
もしログに PayPal 側の注文作成すら残っていないなら、プラグインが PayPal へ処理を引き継ぐ前の段階でコケている。逆に注文作成は成功しているのに capture 呼び出しが見つからないなら、戻り処理かウェブフックの不具合を疑う。
上の手順で失敗パターンを大まかに分類できる。注文作成ログが欠けているパターンは後述の注文 ID 消失問題と合致する。
ウェブフック検証失敗の原因と直し方
ウェブフックが届いているのに検証に失敗する仕組み
PayPal から WordPress サイトの REST エンドポイント（/wp-json/paypal/v1/incoming）に届いたウェブフックは、プラグインが PayPal の公開鍵を使って署名を検証する。この検証が通らないと、たとえ CHECKOUT.ORDER.APPROVED イベントを受け取っていても支払いを完了できず、注文は保留のままになる。
署名検証が失敗する典型的な原因
まず疑うのはサーバー時刻のずれだ。署名にはタイムスタンプが含まれており、サーバーの時刻が大きく狂っていると検証に失敗する。次に考えられるのがプラグイン内部で保持している PayPal 公開鍵のキャッシュ不整合だ。接続情報を更新した直後や、マルチサイト構成でドメインが一致していない場合にも起こりうる。
ウェブフック検証を復旧させる具体的な対処
最初に PayPal との接続を一度解除し、再度接続し直す。これで公開鍵のキャッシュが強制的に再取得される。それでも直らない場合は WooCommerce の「ステータス」画面から「ツール」タブを開き、「WooCommerce のトランジェントをクリア」と「期限切れのトランジェントをクリア」を順に実行する。最後に PayPal のデベロッパーダッシュボードでウェブフック URL が本番環境の正しいドメインを指しているか確認する。
上の流れで復旧しない場合はプラグインバージョン固有の不具合が根底にある可能性が高い。
注文 ID がセッションから消える問題に対処する
リダイレクト前に注文 ID が保存されない既知の不具合
GitHub の issue #4458 でも報告されているが、WooCommerce PayPal Payments 4.0.4 以前のバージョンでは、購入者が PayPal へリダイレクトされる直前に注文 ID を正しくセッションへ格納できないケースがある。これが発生すると、PayPal 上で決済が承認されても、戻ってきた WooCommerce 側でどの注文に紐づければよいかわからず、OrderProcessor がエラーを起こす。
修正パッチやバージョンアップで解決できるか
バージョン 4.1.0 ではこのタイミング問題に対する修正が含まれていると開発者からアナウンスされている。まずはプラグインを 4.1.0 以降へ更新することが最も確実な対処となる。どうしても本番環境で即時の更新が難しい場合は、プラグインの公式サポートチャネルを通じて修正パッチの提供を依頼する手もある。
更新前に検証するべき設定
更新前に WooCommerce の「システムステータス」レポートを取得し、PHP のバージョンが 8.0 以上であること、WordPress 本体と WooCommerce が最新の安定版であることを確認する。多言語プラグイン（WPML 等）を併用している場合は、プラグイン同士の互換性もあわせてチェックしておく。
それでも直らない場合に踏むべき最終手順
キャッシュとセキュリティ系プラグインの完全な切り離し
速度最適化プラグインやサーバー側の動的キャッシュはすでに無効化していても、WAF（ウェブアプリケーションファイアウォール）やセキュリティプラグインが PayPal からのコールバック通信をブロックしている場合がある。一時的にすべてのセキュリティ系プラグインを停止し、サーバーのアクセスログで /wp-json/paypal/v1/incoming への POST リクエストが 200 ステータスを返しているか確認する。
注文メタデータとセッションデータの直接確認
失敗した注文の詳細画面を開き、カスタムフィールドに _ppcp_paypal_order_id というメタキーが存在するか調べる。これが空になっている注文は、まさに注文 ID の引き継ぎに失敗した注文だ。WooCommerce が生成した注文番号は存在するのに PayPal 側の注文 ID だけ欠落している場合は、前述の競合が再現したと断定してよい。
この三点を確認すれば、問題がインフラ寄りなのかアプリケーション寄りなのか切り分けられる。
よくある質問
PayPal のウェブフック検証失敗は何が原因か
サーバー時刻のずれや PayPal 公開鍵のキャッシュ不整合が最も多い原因だ。接続を一度解除して再接続し、WooCommerce のトランジェントをクリアすることで解決することが多い。まれにホスティング環境のファイアウォールが PayPal の検証用リクエストを遮断しているケースもある。
決済が断続的に失敗する場合、キャッシュが原因か
キャッシュが直接の原因でないケースも多い。キャッシュを完全に停止し、カートやチェックアウトの除外設定を施しても再発するなら、プラグイン内部の競合状態や注文 ID の引き継ぎ不良を疑うべきだ。
WooCommerce PayPal Payments の最新バージョンで問題は修正されたか
バージョン 4.1.0 では、注文 ID のセッション保存タイミングに関する修正が含まれている。4.0.4 以前で OrderProcessor エラーが断続的に出ている場合は、まず 4.1.0 以降へ更新することが推奨される。
注文 ID が保存されない問題はどうやって確認するか
失敗した WooCommerce 注文のカスタムフィールドを確認し、_ppcp_paypal_order_id というメタキーが空かどうかを調べる。空であれば注文 ID の引き継ぎに失敗している。プラグインの詳細ログにも PayPal 側の注文作成リクエストが記録されない。
ウェブフックのエンドポイントにアクセスできるか確認する方法は
サイトのアクセスログで /wp-json/paypal/v1/incoming への POST リクエストを探し、HTTP ステータスが 200 であることを確かめる。PayPal のデベロッパーダッシュボード上でウェブフック URL が本番ドメインを指しているかも同時に検証する。
この記事のポイント
- ログを有効にして OrderProcessor エラーの前後に PayPal API 呼び出しが存在するか確認する
- ウェブフック検証失敗は接続の再設定とトランジェントクリアで復旧する可能性が高い
- 注文 ID のセッション消失は 4.1.0 以上のプラグイン更新で根本対処できる
- キャッシュ停止だけでは直らない競合はプラグイン内部のタイミング問題を疑う
- 注文メタデータとアクセスログの二面から原因の切り分けを進める
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce更新後に重大なエラーが発生した時の原因と直し方
WooCommerce 10.9.1 への更新後に「このサイトで重大なエラーが発生しました」と表示されたり、管理画面にアクセスできなくなったりした場合、対処の第一歩はサーバー側の PHP OPcache をクリアすることだ。更新中にオートローダーが古いキャッシュを参照して必要なファイルを読み込めず、致命的エラーが発生しているケースが多い。キャッシュをリセットし PHP プロセスを再起動すれば、多くの場合はそのまま復旧する。
なぜ WooCommerce 更新後に「重大なエラー」が発生するのか
このエラーの根本原因は、WooCommerce が内部で使っている Jetpack オートローダーのクラス読み込みに失敗している点にある。class-php-autoloader.php の102行目で Settings.php ファイルを要求しようとしたが、ファイルが存在しないかパスが解決できず、E_ERROR が発生している。
スタックトレースを見ると、REST API の初期化から管理画面の設定データを構築するまでの一連の処理でエラーが連鎖している。通常これは WooCommerce の更新が完了しない中途状態で発生する一時的な不具合で、新しいバージョンのコードが正しく配置された後もサーバーが古い OPcache を参照し続けるために起こる。
実際の環境は WordPress 7.0、テーマ Flatsome 3.20.7、PHP 8.3.31 と非常に新しいバージョン構成であり、各要素の互換性が原因ではなく、更新プロセスの瞬間的なファイル整合性の乱れがトリガーになっている。
オートローダー 存在しないファイルを要求 → 致命的エラー
管理画面 「このサイトで重大なエラーが発生しました」と表示
オートローダー 正しいファイルを見つけて読み込み成功
管理画面 通常通りアクセス可能に
最初に試すべき復旧手順「PHP OPcache のクリア」
管理画面にアクセスできずエラーメールだけが届いている状況では、サーバー側で PHP の OPcache をリセットするのが最も即効性のある対処だ。OPcache は PHP の実行速度を上げるためにスクリプトのコンパイル結果をメモリ上に保持する仕組みだが、プラグイン更新後はこのキャッシュが古くなり、実際には存在するファイルを「見つからない」と誤認させる。
共用サーバーで OPcache をクリアする方法
多くの国内共用サーバーでは、管理パネル（cPanel や独自パネル）の「PHP 設定」や「PHP セレクター」の中に「OPcache のリセット」ボタンが用意されている。このボタンを押すだけでサーバー側のキャッシュが即座に消去され、PHP プロセスが新しいコードを読み直す。
もし管理パネルに専用ボタンが見あたらない場合は、PHP のバージョンを一度別のバージョンに切り替えてから元に戻す操作でも OPcache がクリアされる。たとえば PHP 8.3 から 8.2 に変更し、数分後に再び 8.3 に戻すといった方法だ。この操作はサーバーの設定変更として扱われるため、内部で PHP-FPM の再起動が走り OPcache がリセットされる。
SSH が使える場合のコマンドライン操作
VPS やクラウドサーバーで SSH アクセス権があるなら、ターミナルから直接 PHP-FPM を再起動することで OPcache をクリアできる。よく使われるコマンドは以下の通りだ。
sudo systemctl restart php8.3-fpmサーバーによっては php-fpm のサービス名が異なるため、systemctl list-units | grep php で正確なサービス名を確認してから実行する。OPcache 専用の CLI コマンド opcache_reset() を直接呼ぶ方法もあるが、PHP-FPM 再起動のほうが確実で手間もかからない。
それでも直らない場合の追加手順
OPcache をクリアしても WordPress 管理画面にアクセスできない場合や、「このサイトで重大なエラーが発生しました」というメッセージが消えない場合は、手動でのファイル修復とプラグインのリセットを試す。
FTP で WooCommerce プラグインを手動再配置する
更新中の通信断やタイムアウトで一部のファイルが書き込まれなかった可能性もある。FTP クライアントでサーバーに接続し、/wp-content/plugins/woocommerce/ ディレクトリをいったん削除またはリネームし、WordPress.org からダウンロードした最新の WooCommerce 10.9.1 の ZIP を解凍してアップロードし直す。この操作でオートローダーが参照する Settings.php を含むすべてのファイルが正しく配置される。
この手順を行う前には、必ずサイト全体のバックアップを取っておくこと。WooCommerce のデータベーステーブルはプラグインファイルの差し替えでは影響を受けないが、カスタマイズが入っている場合は注意が必要だ。
管理画面にすらアクセスできない場合の緊急リセット
管理画面が完全にダウンしていて FTP しか使えない状況では、WooCommerce プラグインのフォルダ名を一時的に変更する手段が有効だ。/wp-content/plugins/woocommerce/ を woocommerce_tmp などにリネームする。WordPress は存在しないプラグインディレクトリを無効化するため、WooCommerce に依存しない管理画面の基本機能が復活する。
管理画面にログインできたら、プラグイン一覧で WooCommerce が「無効」になっていることを確認し、その後フォルダ名を元に戻してからプラグイン一覧で再有効化する。この一連の流れで、オートローダーの読み込みエラーがリセットされることが多い。
エラーを未然に防ぐための更新前チェックリスト
WooCommerce のような大規模プラグインの更新は、事前にいくつかの準備をしておくだけで致命的エラーのリスクを大幅に下げられる。
- 更新前に必ずサイト全体とデータベースのバックアップを取得する
- 可能であればステージング環境で先に更新をテストする
- 更新中はブラウザを閉じず、更新完了のメッセージが表示されるまで待つ
- 更新直後に管理画面から「設定」→「パーマリンク設定」を開き「変更を保存」を押してキャッシュをリフレッシュする
更新のタイミングも重要だ。アクセスの少ない深夜帯やメンテナンスモードを有効にした状態で行うと、万一エラーが発生してもユーザーへの影響を最小限に抑えられる。
よくある質問
WooCommerce の更新中にブラウザを閉じてしまったらどうすればいいか
更新中に切断しても、ファイルのダウンロードと展開が完了していれば問題ないことが多い。管理画面にアクセスできるならプラグイン一覧でバージョンを確認し、古いバージョンのままなら再度更新を実行する。管理画面に入れない場合は OPcache クリアか手動再配置を試す。
エラーメールに記載されたファイルが本当に存在しないのか確認する方法は
FTP でサーバーに接続し、/wp-content/plugins/woocommerce/src/Admin/API/Settings.php が実際に存在するか確認する。ファイルが存在するのにエラーが出ているなら、OPcache の問題と判断できる。存在しない場合は手動再配置が必要だ。
OPcache をクリアしてもエラーが繰り返し発生するのはなぜか
他のプラグインやテーマが WooCommerce の REST API 初期化にフックしており、競合が起きている可能性がある。すべてのプラグインを一時的に無効化し、標準テーマに切り替えてから WooCommerce のみを有効にして原因を特定する。
PHP のバージョンを上げた直後にエラーが出た場合の対処は
PHP 8.3 では一部の古いプラグインやテーマが非互換を起こす。WooCommerce 10.9.1 自体は PHP 8.3 に対応しているが、他のプラグインが同バージョンに対応しているか確認し、必要に応じて PHP 8.2 に一時的に戻して様子を見る。
エラーが表示されず画面が真っ白になるだけの場合は
「このサイトで重大なエラーが発生しました」の代わりに真っ白な画面（ホワイトスクリーン）になるのは、PHP のエラー表示が無効になっているためだ。wp-config.php に define('WP_DEBUG', true); と define('WP_DEBUG_LOG', true); を追加すると /wp-content/debug.log にエラー詳細が出力される。
この記事のポイント
- WooCommerce 更新後のオートローダーエラーは PHP OPcache のクリアでほぼ解決する
- 管理パネルの「OPcache リセット」ボタンか PHP 再起動で対処する
- 直らない場合は FTP でプラグインファイルを手動再配置する
- 緊急時は WooCommerce フォルダを一時的にリネームして管理画面に復帰する
- 更新前のバックアップとステージングテストでリスクを下げられる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
W3 Total Cache 2.10.0 更新後に動的コンテンツが表示されない時の直し方
W3 Total Cache 2.10.0 へのアップデート後、動的コンテンツが表示されず「W3TC dynamic mfunc tag refused： missing call：slug + hmac envelope.」と表示される場合、根本原因はバージョン 2.10.0 で導入された HMAC 署名検証の仕様変更である。プラグインを 2.9.x 系に戻すか、動的ブロックの呼び出しコードに正しい slug 属性と HMAC 署名を付与すれば直る。
どんな症状が発生しているのか
W3 Total Cache（以下 W3TC）のページキャッシュを有効にしたサイトを更新したあと、AdRotate Pro など mfunc タグを使って動的コンテンツを部分キャッシュしていた箇所が、エラーメッセージに置き換わる。日本語環境では英文のまま「W3TC dynamic mfunc tag refused： missing call：slug + hmac envelope.」という文言が表示されるケースが多い。この文言は「mfunc 呼び出しが拒否された。slug と HMAC エンベロープが不足している」という意味だ。
対象になるのは、W3TC のページキャッシュ機能と「後期キャッシング（Late Caching）」や「動的 mfunc ブロック」を組み合わせて使っていたサイトである。具体的には、固定ページ全体をキャッシュしつつ、広告ブロックやログイン状態表示などの一部だけを非キャッシュで差し込んでいた構成だ。更新前は問題なく動いていたのに、2.10.0 にした途端に該当箇所だけエラー文言に化ける。
なぜ W3TC 2.10.0 でエラーが起きるのか
W3TC 2.10.0 では、動的 mfunc タグのセキュリティ強化として HMAC（ハッシュベースのメッセージ認証コード）による署名検証が必須になった。これは不正な動的コードの注入を防ぐための仕組みだが、従来の呼び出しコードには slug 属性と HMAC 署名が含まれていなかったため、検証に失敗し、一律で拒否されるようになった。
W3TC の動的 mfunc ブロックは、PHP 関数をページキャッシュ内に埋め込んでおき、キャッシュから配信される直前に実行する仕組みだ。これまでは単純なコールバック名だけで動作していたが、2.10.0 からは「どのスラッグから呼び出されたか」と「正当な呼び出し元であることを証明する HMAC 署名」のセットがなければ mfunc タグが無効化される。
この仕様変更は W3TC 本体のセキュリティアップデートであるため、AdRotate Pro など W3TC 互換モードを持つ他プラグインの側が新しい署名形式に対応していないと、もれなくエラーになる。結果的に、更新後は互換モードで動的コンテンツを提供しているほとんどすべてのサイトで同じ問題が発生している。
すぐにサイトを元に戻す応急処置
W3 Total Cache を 2.9.x 系にダウングレードする
最も短時間で確実に直す方法は、W3TC を 2.10.0 より前のバージョンに戻すことだ。ダウングレード手順は以下のとおり。
- 管理画面の「プラグイン」から W3 Total Cache を停止する
- 「プラグイン」→「プラグインの追加」→「プラグインのアップロード」を使うか、FTP で古いバージョンの ZIP を展開して上書きする
- プラグインを再有効化し、すべてのキャッシュを削除する
古いバージョンの ZIP ファイルは WordPress.org のプラグインページにある「以前のバージョン」セクションから入手できる。バージョン 2.9.8 や 2.9.9 であれば HMAC 署名検証が存在しないため、従来どおり動的 mfunc タグが動作する。
ダウングレードしたあとは、W3TC の自動更新を一時的に停止することを推奨する。管理画面の「プラグイン」で個別に自動更新をオフにするか、wp-config.php に define（ 'AUTOMATIC_UPDATER_DISABLED', true ）; を追加してサイト全体の自動更新を止めておけば、意図しない再アップデートを防げる。
他プラグインの W3TC 互換モードを一時的に無効化する
もし AdRotate Pro など、W3TC 互換モードを個別にオン・オフできるプラグインを使っているなら、当該プラグインの設定で互換モードをオフにする手もある。ただしこの場合、ページキャッシュの影響で広告がローテーションしなくなったり、動的コンテンツが静的になってしまったりする副作用がある。あくまで「エラー表示を消す」ための一時的な回避策と位置づけるのが安全だ。
2.10.0 を使い続ける場合の恒久対応
W3TC 2.10.0 のセキュリティ修正を活かしたまま動的コンテンツを動作させるには、呼び出しコードに正しい slug と HMAC 署名を付与する必要がある。この修正は、動的 mfunc タグを生成している側（多くの場合は広告管理プラグインや自作のテーマ関数）に手を入れることになる。
W3TC の HMAC 署名の仕組みを理解する
mfunc タグはページキャッシュの HTML 内に PHP コード片を残し、キャッシュ配信時に W3TC がそれを検出して実行する。2.10.0 ではこのとき、呼び出しパラメータとして「call：slug」と「hmac」の両方がエンベロープに含まれていなければならない。slug は処理を一意に識別する任意の文字列、hmac は W3TC 内部で生成される署名ハッシュだ。
生成ルールは公開されているが、実際には W3TC が提供する API 関数を使って動的ブロックを登録するのが現実的だ。自作テーマであれば w3tc_fragmentcache_register フィルターを使い、コールバックと slug を W3TC に登録すれば、あとは W3TC 側が自動で HMAC 署名を計算してくれる。
AdRotate Pro での対応状況を確認する
AdRotate Pro は W3TC 互換モードを有効にしている場合、内部的に mfunc タグを生成している。今回のエラーは、AdRotate Pro が生成する mfunc タグが 2.10.0 の新形式に対応していないために発生している。AdRotate Pro の開発元がこの問題に対応したアップデートをリリースするまでは、互換モードの使用が難しい。
AdRotate Pro の管理画面にある「W3 Total Caching compatibility」設定をオフにし、代わりに JavaScript による非同期広告読み込み（AdRotate のダイナミックモード）を使うか、広告ブロックを iframe で埋め込む形に切り替えると、ページキャッシュ機構に依存せず動的広告を配信できる。
自作テーマで動的ブロックを登録し直す
テーマの functions.php などで自作の動的コンテンツを mfunc タグで埋め込んでいた場合は、W3TC のフラグメントキャッシュ API を使った正式な登録に切り替える。基本的な流れは次のとおりだ。
w3tc_fragmentcache_registerフィルターで、slug とコールバック関数のペアを W3TC に登録する- テンプレート内では
w3tc_fragmentcache_output関数を使い、slug を指定して動的出力を行う - W3TC が自動で HMAC 署名を計算し、mfunc タグとしてページキャッシュに埋め込む
この方法なら、W3TC のバージョンが上がっても署名方式の変更に W3TC 本体側が追随するため、サイト側のコードを再度修正する必要がなくなる。フラグメントキャッシュ API の具体的な記述例は W3TC の公式ドキュメントに掲載されている。
Late Caching 設定の確認と調整
W3TC の pgcache.late_caching 設定（後期キャッシング）が有効かどうかも、動作に影響を与える要素のひとつだ。この設定が true の場合、ページ生成の最終段階で mfunc タグを処理するため、プラグイン間の競合が減る傾向がある。すでに true でもエラーが出ている場合は今回の本質的な原因ではないが、念のため設定値を確認しておく。
wp-content 内の w3tc-config/master.php を直接確認するか、管理画面の「パフォーマンス」→「一般設定」からエクスポートした設定ファイルで pgcache.late_caching の値を確認できる。false であれば true に変更し、キャッシュを全削除してから表示を再確認する。
再発を防ぐための注意点
W3TC のような深くサイト機構に組み込まれるプラグインをメジャーバージョンアップする前には、必ずステージング環境で検証する習慣をつける。とくに mfunc やフラグメントキャッシュといった、通常のキャッシュとは異なる高度な機能を使っている場合は、本番適用前に動的コンテンツの全パターンをテストする必要がある。
また、W3TC の設定をエクスポートしてバックアップしておけば、問題が起きたときに設定ごと以前のバージョンに戻せる。管理画面「パフォーマンス」→「一般設定」の下部にある「設定のダウンロード」ボタンで、JSON 形式の設定ファイルを定期的に保存しておくとよい。
よくある質問
「W3TC dynamic mfunc tag refused」はサイト全体が真っ白になるのか
サイト全体が真っ白になるわけではない。ページの大部分は正常にキャッシュ配信されるが、mfunc タグで差し込まれていた動的コンテンツの部分だけがエラー文言に置き換わる。レイアウトが崩れることはあるが、PHP 致命的エラーによる白画面とは異なる。
キャッシュを削除しても直らないのはなぜか
キャッシュ削除はあくまで「現在保存されているキャッシュファイルを消す」行為であり、mfunc タグの生成コード自体を修正するものではない。新しいキャッシュが生成されるときに、同じく新形式に対応していない mfunc タグが再度埋め込まれるため、キャッシュ削除だけでは根本解決にならない。
W3TC 無料版でも同じ問題は起きるのか
起きる。HMAC 署名検証は W3TC のコア機能の一部として Pro 版・無料版の両方に実装されている。フラグメントキャッシュや mfunc タグを使っているサイトは、Pro 版かどうかに関係なく影響を受ける。
このエラーを放置してもサイトには大きな問題はないか
動的コンテンツが表示されないという機能面の問題に加え、エラー文言が来訪者にそのまま見える状態はサイトの信頼性を損なう。また広告が表示されなければ収益にも直結するため、実質的には早期解決が必要な重大トラブルに分類される。
他に W3TC 2.10.0 で影響を受けるプラグインはあるか
AdRotate Pro 以外にも、W3TC 互換モードで動的コンテンツを埋め込む仕組みを持つプラグイン全般が影響を受ける可能性がある。具体的には、動的ウィジェットやパーソナライズ表示を行うキャッシュ対応プラグインが該当する。該当プラグインの更新情報を注視し、開発元が W3TC 2.10.0 対応を表明するまではアップデートを保留するのが安全だ。
この記事のポイント
- W3TC 2.10.0 の HMAC 署名検証強化で mfunc タグが拒否される
- ダウングレードで即時解決するがセキュリティ面は旧版に戻る
- 互換プラグイン側の対応アップデートを待つか公式 API で再実装する
- キャッシュ削除だけでは再発するため mfunc コード自体の修正が必要
- メジャーアップデート前のステージング検証と設定バックアップが再発防止の鍵
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce納品書印刷で致命的エラーが出た時の直し方
WooCommerce の「Print Invoice & Delivery Notes for WooCommerce」プラグインで納品書や請求書を印刷しようとしたとき、管理画面に「このサイトで重大なエラーが発生しました」と表示され、PDF が生成されない問題は、PDF 生成に使う Dompdf ライブラリのクラスが見つからないことが原因だ。プラグインを再インストールし、サーバーのキャッシュをクリアすればほぼ解決する。
なぜ納品書印刷で致命的エラーが発生するのか
エラーログを確認すると「PHP Fatal error: Uncaught Error: Class “Dompdf\Options” not found」というメッセージが記録されている。これはプラグインが PDF を生成するために依存している Dompdf ライブラリを読み込めず、クラスが存在しない状態で呼び出されたことを意味する。原因は主にふたつに集約される。
ひとつはプラグインのインストールやアップデート時に、Dompdf のファイルを含む vendor ディレクトリが正しく配置されなかったケース。FTP アップロードの中断やパーミッションの問題でライブラリが欠落すると、このエラーが起きる。もうひとつは OPcache やプラグインのクラス自動読み込み（オートローダー）の不具合だ。管理画面の Ajax 経由で印刷を実行する際、特定の条件下でオートローダーが動かず、クラスが見つからないと判断される。一括印刷（Bulk Actions）が正常に動作するのも、別のコード経路でライブラリが読まれるためで、単票の印刷だけが失敗する典型的なパターンになっている。
エラーの切り分けと再インストール手順
エラーを解消するには、まずプラグインのファイルが完全に揃っている状態に戻し、キャッシュの影響を断ち切るのが確実だ。以下のステップで順に進めると、根本原因を速やかに取り除ける。
STEP 1 エラーログを確認して確実に特定する
WordPress の wp-config.php に define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); が記述されていれば、/wp-content/debug.log に今回のような致命的エラーが記録される。ログを開き「Dompdf\Options not found」という行が含まれていることを確かめる。もしログが取れていなければ、上記の定数を一時的に有効にしてから問題の印刷操作をもう一度試す。この情報があると、単なる画面の白化や汎用エラーと区別でき、対応を誤らない。
STEP 2 プラグインを完全に再インストールする
管理画面の「プラグイン」→「インストール済みプラグイン」から「Print Invoice & Delivery Notes for WooCommerce」を探し、一度「無効化」をクリックしてから「削除」を実行する。その後、改めて「プラグイン」→「新規追加」で同じプラグインを検索し、最新バージョンをインストールして有効化する。これで vendor ディレクトリ以下の Dompdf ライブラリが確実に揃う。
もしなんらかの事情で管理画面から削除できない場合は、FTP またはサーバーのファイルマネージャーを使って /wp-content/plugins/woocommerce-delivery-notes/ ディレクトリを丸ごと削除し、再度アップロードする。その際、ディレクトリ名やパーミッションが正しいことを確認しておく。
STEP 3 サーバー側のキャッシュをリセットする
PHP 8.2 環境では OPcache が有効になっており、古いクラスパスの情報がキャッシュに残っていると再インストール後もエラーが続く場合がある。レンタルサーバーの管理画面から PHP の OPcache をクリアするか、php.ini などで opcache_reset(); を一時的に実行する。また、nginx の fastcgi キャッシュを使っている場合はそちらも削除しておく。WordPress 側で WP Rocket や W3 Total Cache などのキャッシュプラグインを利用していれば、すべてのキャッシュを完全にクリアする。
管理画面で「印刷」を押すと「このサイトで重大なエラーが発生しました」と表示され PDF が生成されない
納品書や請求書の PDF が問題なく生成され、印刷も正常に動作する
STEP 4 納品書印刷を再度実行して検証する
WooCommerce の注文一覧から該当の注文を選び、「印刷」ボタンをクリックして PDF が開くことを確認する。もしこれでも同じエラーが出る場合は、別の PDF 出力系プラグイン（例 「PDF Invoices & Packing Slips for WooCommerce」など）との競合も疑い、それらを一時的に無効化して原因を絞り込む。Dompdf クラスを上書きするようなカスタマイズや、異なるドキュメント生成ライブラリが同じ名前空間を使っているケースでは、片方のプラグインを停止する必要がある。
キャッシュや競合プラグインの対処をもう少し深掘りする
OPcache の影響は想像以上に大きい。特に PHP のバージョンを上げたり、プラグインを一括更新したあとは、古いオートロードマップが残ってしまい、クラス不存在のエラーが続くことがある。サーバーが共用の場合でも、管理パネルに「PHP 設定」「PHP 再起動」などの項目があればそこから OPcache をクリアするか、何もなければレンタルサーバー会社のサポートに依頼する。
また、Kinsta や WP Engine のようなマネージドホスティングでは独自のキャッシュレイヤーを持っているため、管理画面のキャッシュクリア機能を使ってオブジェクトキャッシュやページキャッシュを完全に削除する必要がある。自前で nginx の fastcgi_cache を組んでいる場合は、fastcgi_cache_path のディレクトリを空にするか、キャッシュ無効化のパラメータを追加してから再度有効化する。
複数の PDF プラグインが有効になっていると、同じ Dompdf ライブラリを異なるバージョンで読み込もうとしてクラス衝突が起きることもある。このプラグインのバージョン 7.2.0 が特に最新の Dompdf に追従していない場合、他のプラグインが読み込んだ後に自前のオートローダーが正しいパスを指せず、今回のエラーになる。こうしたケースでは、問題のプラグイン以外の PDF 関連プラグインをすべて無効化し、一つずつ原因を特定していく。最悪の場合は代替プラグインへの乗り換えも選択肢になる。
よくある質問
プラグインを再インストールしても直らない場合は？
管理画面の「ツール」→「サイトヘルス」でループバックリクエストのエラーや REST API の異常がないかを確認する。Ajax 通信自体がブロックされていると Dompdf の読み込み以前に失敗する。また、サーバーのエラーログで open_basedir 制限や disable_functions の影響が出ていないかもチェックする。
一括印刷は動くのに単票だけ失敗する理由は？
一括印刷は admin-post.php 経由か、直接テンプレートを呼び出す仕組みで動いており、admin-ajax.php を使う単票印刷とは異なるコードパスになる。結果としてオートローダーの読み込みタイミングが変わり、エラーが出たり出なかったりする。根本的には再インストールで解消するが、どうしても直らなければプラグインの設計上の不具合の可能性もある。
エラーログに Dompdf のクラスがないと出るが、ファイルはサーバーに存在している
FTP などで /wp-content/plugins/woocommerce-delivery-notes/vendor/dompdf/dompdf/src/Options.php が実在するのにエラーが出る場合、PHP の OPcache か、nginx のファイルキャッシュが古い状態を返している可能性が高い。OPcache の再起動やサーバーキャッシュのクリアで直ることがほとんどだ。それでも変わらないときは、ファイルのパーミッションが読み取り不可になっていないかも確認する。
ほかの PDF プラグインと同時に使えるか？
同じ Dompdf を内部で使うプラグイン同士は、名前空間の解決順序によってクラスが見つからなくなるリスクがある。実際に複数の PDF 出力系プラグインを有効にしている場合は、トラブルシューティングのために一度すべて無効化し、必要なものだけを再び有効化することを推奨する。
PHP のバージョンを上げた後に起きたが関係あるか？
PHP 8.2 以上ではクラス自動読み込みの挙動が厳格になり、以前は暗黙的に読めていたファイルが読めなくなることがある。プラグインが最新バージョンで PHP 8.2 に対応しているかどうかを開発元の Tyche Softwares のドキュメントで確認し、対応済みであれば再インストールで問題は解消する。
この記事のポイント
- 致命的エラーは Dompdf ライブラリのクラスが読み込めないことが原因
- プラグインをいったん完全に削除し、最新版を再インストールするのが最も確実
- サーバーの OPcache や各種キャッシュを必ずリセットする
- 複数の PDF プラグインの同時利用が競合を引き起こしている可能性も疑う
- 一括印刷が動作していても単票でのエラーは起こり得る
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている