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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
SiteGuard WP Pluginでwp-loginが表示される原因とMultiViewsの無効化手順
なぜ /wp-login/ でログイン画面が表示されてしまうのか
この現象は SiteGuard WP Plugin の仕様ではなく、サーバー環境に由来する問題だ。Apache の MultiViews 機能が有効になっていると、/wp-login/ へのアクセスが内部的に /wp-login.php にマッチしてしまい、ログイン画面が表示される。
MultiViews は Apache のコンテンツネゴシエーション機能の一部で、リクエストされたパスに拡張子がない場合に、サーバー側で適切なファイルを探し出して提供する仕組みだ。/wp-login（もしくは末尾スラッシュ付きの /wp-login/）を要求すると、Apache は wp-login.php という実ファイルを見つけて実行してしまう。これが根本の原因であり、ログインページ変更機能で隠しパラメータを追加しても、このフィルタをすり抜けてしまうケースが生まれていた。
実際に WordPress.org フォーラムで報告され、プラグイン開発者によってバージョン 1.8.4 で対策が施された。しかし /wp-login/任意の文字列（例：/wp-login/test）に対しては、引き続き MultiViews の影響でログイン画面が表示される可能性が残っている。完全に防ぐには、Apache 側で MultiViews を無効化する必要がある。
このデモは MultiViews の有無によるアクセス結果の変化を示している。
SiteGuard WP Plugin 側の対策と残る課題
バージョン 1.8.4 で /wp-login/ はブロック対象に
SiteGuard WP Plugin 1.8.4 では、内部的に /wp-login/ へのアクセスを捕捉し、ログインページ変更機能で指定した独自 URL 以外からのアクセスをブロックする処理が追加された。これにより、多くの環境で「/wp-login/」を直接叩かれてもログイン画面が表示されなくなった。
/wp-login/任意の文字列 は依然としてすり抜ける
しかし URL の末尾にさらにパスを付け足した /wp-login/something のようなアクセスは、プラグイン側の正規表現やルールでは補足しきれず、Apache の MultiViews がマッチする限りログインページを返してしまう。これはプラグインのバグというより、Web サーバーのモジュールが優先してしまう構造的な問題だ。
Apache で MultiViews を無効化する手順
最も確実な対策は、Apache の設定で MultiViews を無効にすることだ。レンタルサーバーを利用している場合でも、.htaccess ファイルで制御できるケースが多い。
Options -MultiViews を追加この手順により、Apache が MultiViews を使ったファイルの自動解決を行わなくなり、/wp-login/ や /wp-login/何らかのパス へのアクセスでログイン画面が表示されることはなくなる。
.htaccess の記述例
WordPress の標準的な .htaccess に組み込む場合は、以下のような形になる。Options -MultiViews はリライトルールよりも手前に書くのがセオリーだ。
# BEGIN WordPress
Options -MultiViews
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressMultiViews 無効化ができない場合の代替策
レンタルサーバーの制限で Options -MultiViews が許可されていない環境もまれにある。その場合は、より直接的なリダイレクトルールを追加して、/wp-login/ へのアクセスを 404 ページやトップページに飛ばす方法がある。
RewriteRule ^wp-login/ - [R=404,L]このルールを .htaccess の RewriteEngine On の直後に追記すれば、/wp-login/ というパスで始まるリクエストすべてを 404 で返す。ただしリライトの優先順位によっては、他のルールと競合しないか必ずテストすること。
404 ページをブラウザ標準から WordPress テーマのものに切り替える
質問の中で「ブラウザ標準の 404 ページではなく、WordPress テーマ側の 404 ページに遷移させたい」という要望があった。SiteGuard WP Plugin 1.7.x 系では、ログインページ変更機能が動作すると WordPress の 404 テンプレートを表示する挙動だった。これが 1.8.x 系で Apache の標準エラー応答に変わったのは、プラグインの内部ロジックがより低レイヤーでリクエストを遮断するように再設計されたためだ。
WordPress テーマの 404 ページを表示させたい場合は、プラグイン任せにせず、Apache の ErrorDocument ディレクティブを利用する方法がある。ただし完全に同一の外観を保つのは難しく、セキュリティ上の観点からも、404 ページの表示にこだわるよりも「不正なアクセスをいかに早く遮断するか」に注力したほうが実用的だ。
よくある質問
SiteGuard WP Plugin のログインページ変更だけでは不十分なのか
ログインページ変更機能は、ボットによる辞書攻撃や自動スキャンの大半を防ぐ効果がある。しかしサーバー側の MultiViews のような特殊な設定が残っていると、その穴を突かれる可能性がゼロではない。基本はプラグイン任せ、より強固にしたい場合は MultiViews の無効化を組み合わせるのが現実的な落としどころだ。
MultiViews を無効にすると他の機能に影響はあるか
WordPress は基本、PHP ファイルを直接呼び出すスタイルで動作しているため、通常の運用で MultiViews が必須になることはほぼない。静的ファイルの MIME タイプや言語ネゴシエーションを使っている特殊なカスタマイズがなければ、影響は出ないと考えてよい。
Nginx 環境でも同じことは起きるのか
Nginx には Apache の MultiViews に相当する機能は標準で存在しないため、この問題は発生しない。Nginx の場合は try_files ディレクティブの設定ミスによって似た現象が起こることがあるが、原因はまったく異なる。
プラグインを最新にしたのに管理画面が 404 になることがある
SiteGuard WP Plugin の「管理ページアクセス制限」を有効にしていると、未ログイン状態で /wp-admin/ にアクセスするとサイトトップにリダイレクトされる。また「管理者ページからログインページへリダイレクトしない」設定を ON にしている場合のリダイレクト先も確認しておくと混乱が少ない。
この記事のポイント
- /wp-login/ からのログイン画面表示は MultiViews が原因
- SiteGuard WP Plugin 1.8.4 で基本対策は完了している
- 根本解決には Apache の MultiViews 無効化が必要
- .htaccess に Options -MultiViews を追加するだけで対処可能
- 404 表示にこだわるより、アクセス遮断の仕組みを優先する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
NextGEN GalleryでTrying to access array offset on null警告の原因と直し方
NextGEN Gallery（管理画面では「NextGEN Gallery」と表示）で「Trying to access array offset on null」というPHP警告が繰り返し出力される場合、原因はテンプレートファイル内で $thumb_size 変数がnullのまま配列としてアクセスされていることにある。テーマのfunctions.phpに一時的なnullチェックを追加するか、プラグインの該当テンプレートを直接修正することで警告を止められる。
なぜ「Trying to access array offset on null」が発生するのか
この警告はPHP 7.4以降で追加された「配列オフセットへのnullアクセス」に関するエラーレベル通知だ。NextGEN Galleryの /templates/Thumbnails/index.php 110行目周辺では、サムネイル画像の幅と高さを次のように取得しようとしている。
$thumb_size['width']
$thumb_size['height']通常 $thumb_size にはサムネイルサイズの設定が格納された配列が入るが、特定の条件下（ギャラリー設定の不整合、画像メタデータの欠落、プラグイン内部の処理順序による変数未代入）でnullになる。nullの変数に対して配列のキーでアクセスしようとすると、PHPは警告を発行する仕組みだ。
エラーの発生箇所を特定する手順
警告メッセージにファイルパスと行番号が含まれているため、どこで問題が起きているかは一目瞭然に思える。しかし実際には以下の点を確認しておくと、修正後の再発防止に役立つ。
上図のように、変数が配列であることを確認する is_array() チェックを入れるだけで警告は出なくなる。以下に具体的な修正方法を3つのレベルで示す。
デバッグモードで警告を可視化する
本番サイトでは警告が非表示設定になっていることも多い。問題を見逃さないために、一時的に wp-config.php を編集してデバッグモードを有効にする。
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);WP_DEBUG_DISPLAY をfalseにすれば画面には警告が出ず、/wp-content/debug.log に記録される。警告の再現性を確認したら、必ず WP_DEBUG をfalseに戻すことを忘れないようにしよう。
管理画面からプラグインのバージョンを確認する
「プラグイン」画面でNextGEN Galleryのバージョンが最新かどうかを確認する。2026年6月現在、NextGEN Galleryはバージョン3系が主流で、多くのnull関連の警告はバージョンアップで修正されている。更新が可能であれば、まずプラグインの更新を実行するのが最も安全な対処法だ。
エラーログで発生頻度とパターンを見極める
警告が散発的なのか、特定のページ表示時のみなのかによって対応の緊急度が変わる。デバッグログを確認し、同じ警告が何度も出ているなら恒久的な修正が必要だ。特定のギャラリーページだけなら、そのギャラリーの設定に問題がある可能性が高い。
警告を止める3つの修正アプローチ
NextGEN Galleryのコアファイルを直接編集する方法、子テーマから上書きする方法、functions.phpでフィルターフックを使う方法の3つがある。サイトの運用方針に合わせて選んでほしい。
index.php にnullチェックを追加アプローチ1 プラグインのコアファイルを直接修正する
最も短期的で簡単な方法だ。ただしNextGEN Galleryが更新されると修正が上書きされるため、恒久的な対応にはならない。該当ファイルは以下にある。
wp-content/plugins/nextgen-gallery/templates/Thumbnails/index.php110行目と111行目付近の $thumb_size['width'] と $thumb_size['height'] を、以下のように is_array() で囲む。
if (is_array($thumb_size)) {
$width = $thumb_size['width'];
$height = $thumb_size['height'];
} else {
$width = 240; // デフォルトの幅
$height = 160; // デフォルトの高さ
}デフォルト値には、NextGEN Galleryの「ギャラリー設定 → サムネイル設定」で指定されているサイズを入れておくと、画像が崩れずに表示される。
アプローチ2 子テーマでテンプレートを上書きする
NextGEN Galleryはテーマによるテンプレート上書きをサポートしている。修正した index.php を以下のパスに配置すれば、プラグイン更新後も修正が維持される。
wp-content/themes/your-child-theme/nggallery/thumbnails/index.php元の /templates/Thumbnails/index.php をコピーし、該当行にnullチェックを追加して保存するだけだ。子テーマを使っていない場合は、この機会に作成しておくと今後のカスタマイズにも役立つ。
アプローチ3 functions.phpで警告を抑制する（非推奨）
どうしてもテンプレートを修正できない事情がある場合は、警告そのものを表示させない方法もある。ただし根本解決ではないため、最終手段として理解しておくといい。
add_action('init', function() {
if (defined('WP_DEBUG') && WP_DEBUG) {
error_reporting(E_ALL & ~E_WARNING);
}
});このコードはWordPressのデバッグモードが有効な場合のみ警告レベルを下げる。しかし他の重要な警告も見逃すリスクがあるため、あくまで一時的な回避策として考えてほしい。
修正後も警告が消えない場合の追加チェック
上記の修正を適用してもまだ警告が出るなら、キャッシュのクリアを試す。NextGEN Galleryは独自の画像キャッシュを持っており、テンプレートの変更がすぐに反映されないことがある。
NextGEN Galleryのキャッシュをクリアする
管理画面の「ギャラリー → その他のオプション → 画像オプション」にある「キャッシュをクリア」ボタンを実行する。さらにWordPress全体のキャッシュ（プラグインやCDNを使用している場合はそれらも含めて）をクリアすると、テンプレートの変更が確実に反映される。
nullが発生する根本原因を探る
$thumb_size がnullになるのは、ギャラリー設定や画像のアップロード時にメタデータが正しく生成されなかった場合に多い。管理画面から該当ギャラリーを開き、各画像の「メタデータを更新」を実行する。また、ギャラリー設定で「サムネイルサイズ」が未設定になっていないかも確認してほしい。
よくある質問
この警告を放置してもサイトは壊れないか
警告（Warning）はエラー（Fatal Error）と異なり、スクリプトの実行は継続される。サムネイル画像が一部表示されない可能性はあるが、サイト全体が停止することはない。ただし警告が大量に出力されるとデバッグログが肥大化し、サーバーのディスク容量を圧迫する原因になる。
NextGEN Gallery以外のプラグインでも同様の警告は出るのか
PHP 7.4以降では配列アクセスの扱いが厳格化されたため、古いプラグインやテーマで同様の警告が発生することがある。対象プラグインが更新されていない場合は、今回紹介したnullチェックの手法を応用して修正可能だ。
警告が debug.log に出続けて容量がいっぱいになりそうだ
WP_DEBUG_LOG をtrueにしたまま長期間放置すると、ログファイルが数GBに膨れ上がることがある。問題を特定したら速やかに WP_DEBUG をfalseに戻す。どうしてもデバッグを続ける必要があるなら、定期的にログローテーションを行うか、WP_DEBUG_LOG を '/path/to/custom-debug.log' のように指定して管理しやすくするといい。
プラグインを更新したくない（カスタマイズが消えるのが怖い）
NextGEN Galleryのテンプレートを直接編集している場合、プラグイン更新で修正が上書きされる不安は理解できる。今回紹介した子テーマによるテンプレート上書きを使えば、プラグイン本体には手を加えずに済む。カスタマイズを維持したまま、コアのバグ修正やセキュリティアップデートだけを取り込める。
NextGEN Galleryの代わりになるプラグインはあるか
標準の「メディアとカテゴリー」を使ったギャラリー機能でも十分な場合や、Envira GalleryやFooGalleryといった代替プラグインも選択肢になる。ただしNextGEN Galleryは長年の実績があり、ギャラリー数が多いサイトでは移行コストを考慮する必要がある。
この記事のポイント
- 「Trying to access array offset on null」はPHP 7.4以降の厳格化による警告
- NextGEN Galleryの
/templates/Thumbnails/index.phpで$thumb_sizeがnullになるのが原因 is_array()によるnullチェックで警告を止められる- 子テーマでテンプレートを上書きすればプラグイン更新後も修正が維持される
- 修正後はNextGEN GalleryのキャッシュとWordPress全体のキャッシュをクリアする
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerceアナリティクスでOops something went wrongエラーが出た時の直し方
WooCommerce を 10.6.1 にアップデートした直後、アナリティクス概要に「Oops something went wrong」と表示され、ブラウザコンソールに TypeError: t(…)(…).tz is not a function というエラーが記録される場合、JavaScript のタイムゾーンライブラリを巡るプラグイン競合か、キャッシュの不整合が原因だ。まず全プラグインの無効化と標準テーマへの一時的な切り替えで原因を特定し、競合するプラグインを見つけ出すことから始める。
なぜ WooCommerce アナリティクスで tz is not a function エラーが起きるのか
WooCommerce の管理画面アナリティクスは、内部的に Moment.js とそのタイムゾーン拡張を使い、日付や時間の演算をおこなっている。10.6.1 では JavaScript アセットの読み込み順や依存関係に変更が入ったため、別のプラグインやテーマが同じ Moment.js タイムゾーンライブラリを異なるバージョンで読み込んでいる場合に .tz メソッドが上書きされるか、存在しない状態になり、今回の TypeError が発生する。
また、ブラウザやサーバー側のキャッシュに古いスクリプトが残っていると、管理画面で本来動くはずの新しいコードと混ざり、同様のエラーが出ることもある。まずは「どの拡張機能やテーマが影響しているか」を切り分けるのが近道だ。
エラーの原因を特定する手順
上図の手順で、問題の切り分けができる。WooCommerce 本体だけを有効にした状態でアナリティクスが正常に動けば、あとは再有効化の過程でエラーを再現させるプラグインを見つければよい。
全プラグインを無効化して競合を確認する
「プラグイン」→「インストール済みプラグイン」画面で、全てのプラグインにチェックを入れ、「一括操作」から「停止」を実行する。WooCommerce だけは残すか、最初はすべて停止し、その後 WooCommerce だけ有効化し直す。この状態で管理画面の「WooCommerce」→「アナリティクス」を開き、エラーが出ないか確認する。
テーマを Storefront など標準テーマに切り替える
有効化しているテーマの functions.php やフックが、管理画面の JavaScript 読み込みに干渉しているケースは意外に多い。「外観」→「テーマ」で Storefront や Twenty Twenty-Five など公式の軽量テーマに一時的に切り替え、同じくアナリティクス画面を確認する。
ブラウザキャッシュとサーバーキャッシュをすべて削除する
キャッシュ系プラグイン（W3 Total Cache、WP Rocket など）を使っている場合は管理画面からキャッシュを全削除する。さらにブラウザでシークレットウィンドウ（プライベートブラウジング）を開き、そちらで管理画面にログインしてテストすると、ローカルキャッシュの影響を排除できる。サーバー側で OPcache や Redis オブジェクトキャッシュを導入している場合は、それらのクリアもおこなう。
プラグインを1つずつ再有効化して原因を突き止める
無効化状態でエラーが消えたら、プラグインを1つ有効化するごとにアナリティクス画面を再読み込みし、エラーの再発をチェックする。再現したプラグインが競合元だ。よくあるのは、カスタムレポート系、日付や予約管理、多言語対応（WPML や Polylang）、ページビルダーの管理画面用スクリプトを追加するタイプのプラグインだ。
競合するプラグインを特定したあとの恒久対策
原因のプラグインが判明しても、サイト運営上どうしても外せない場合がある。そのときは、問題のスクリプトだけを管理画面のアナリティクスページでのみ読み込まないようにする手がある。
以下のコードを子テーマの functions.php に追加すると、特定のスクリプトをアナリティクス画面で解除できる。ここでは例として「moment-timezone」ハンドルを一旦解除し、WooCommerce が想定する正しいバージョンを再登録する方法を示す（実際のハンドル名は競合元により異なるため、ブラウザのデベロッパーツールで確認する）。
add_action( 'admin_enqueue_scripts', function( $hook ) {
if ( false === strpos( $hook, 'woocommerce_page_wc-analytics' ) ) {
return;
}
wp_dequeue_script( 'moment-timezone' );
wp_deregister_script( 'moment-timezone' );
wp_enqueue_script( 'moment-timezone', includes_url( 'js/moment-timezone.min.js' ), array( 'moment' ), null, true );
}, 100 );この例では WordPress 本体バンドルの moment-timezone を読み直しているが、WooCommerce が読み込むパスとは異なる場合がある。より安全なのは、競合プラグイン側の更新を待つか、Asset CleanUp 系のプラグインで該当スクリプトを該当ページでのみブロックする方法だ。
それでも直らない場合の応急処置としての WooCommerce のロールバック
どうしてもすぐにエラーを止めたいときは、WooCommerce を問題のなかったバージョン（例：10.5.2）に戻す方法がある。無料プラグイン「WP Rollback」を使えば、管理画面からワンクリックで以前のバージョンにダウングレードできる。
「プラグイン」→「新規追加」で WP Rollback をインストールし有効化すると、プラグイン一覧の WooCommerce に「ロールバック」リンクが現れる。そこから 10.5.2 を選択し、ロールバックを実行する。ただし、これは一時しのぎであり、セキュリティ修正などが含まれている場合はリスクがあるため、問題の根本解決を優先する。
よくある質問
プラグインをすべて無効化してもエラーが消えないのはなぜか
テーマの functions.php や子テーマに管理画面用のスクリプトを追加している可能性が高い。必ず標準テーマ（Storefront や Twenty Twenty-Five）に切り替えて確認する。また、ブラウザ拡張機能やサーバー側のキャッシュが残っている場合もエラーが継続する。
キャッシュを削除しても改善しない場合はどうするか
ブラウザのシークレットウィンドウを使うか、別のブラウザでテストする。サーバー側で OPcache や Varnish、CDN のキャッシュが効いている場合は、そちらも合わせてクリアする。WP CLI が使えるなら wp cache flush も試す。
特定のプラグインが原因とわかったが、そのまま使い続けたい
プラグイン開発元に WooCommerce 10.6.1 への対応状況を問い合わせ、アップデートを待つのが最も確実だ。緊急時は、前述のコード例や Asset CleanUp で競合を回避する方法があるが、サイト全体の動作確認を十分におこなったうえで適用する。
WooCommerce をダウングレードしても問題ないか
ダウングレードすると、10.6.1 で修正されたセキュリティ上の問題や不具合が再発する可能性がある。あくまで原因究明と修正が終わるまでの一時的な措置と考え、早急に恒久対策を講じる。
同じエラーがフロントエンドのカートやチェックアウトでも出る
管理画面だけでなくフロントエンドでも同様の TypeError が発生する場合、テーマかキャッシュプラグインの JavaScript 最適化機能（結合・圧縮）が原因になっていることが多い。キャッシュプラグインの設定で JavaScript の結合を一時的に無効にし、テーマを標準テーマに切り替えて症状が消えるか確認する。
この記事のポイント
- WooCommerce 10.6.1 でアナリティクスに tz is not a function エラーが出るのは JavaScript のタイムゾーンライブラリ競合かキャッシュ不整合
- プラグイン全無効化＋標準テーマへの切り替えで原因を特定し、1つずつ再有効化して競合プラグインを特定する
- 競合プラグインが見つかったら、更新を待つか functions.php でスクリプトを制御する
- 緊急時は WP Rollback で WooCommerce を一時的にダウングレードできるが、恒久対策が優先
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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」を例に手順を示すが、他のパーマリンク系プラグインでも同様の考え方で対処できる。
上記の「除外するクエリパラメータ」には「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ビルダーと相性が悪い可能性がある。以下の対策を順に検討する。
パーマリンクプラグインを別のものに切り替える
カスタムパーマリンク機能自体は別のプラグインでも実現できる。「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を悪化させることがあるため、一時停止して切り分ける
- デバッグモードで詳細なログを確認すれば、除外すべき追加パラメータを特定できる
- 根本的に相性が悪い場合は、パーマリンクプラグインの変更も選択肢に入る
・ 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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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 ‘?’ が発生するのか
WordPress のコアファイル compat-utf8.php は、マルチバイト文字列を安全に扱うための互換関数群を収めている。中では null 合体演算子（??）やシンプルな三項演算子が使われる場面があり、これらは PHP 7.0 以降で導入された構文だ。もしサーバーが PHP 5.6 以前のバージョンで動作していると、「?’」の部分で構文エラーが発生し「unexpected ‘?’」というメッセージを吐く。つまり PHP バージョン不足が根本原因になる。
エラーの「expecting variable (T_VARIABLE)」は、処理系が疑問符を見て、本来そこに変数が来るはずの三項演算子の前半部分と誤解したことを示す。古い PHP は「??」を認識できずに文法的に未知のトークンとしてパースエラーを起こす。WordPress 7.0 が標準で要求する PHP バージョンはさらに高く、8.0 以降を推奨するケースも多い。
サイト全体が真っ白
上図のように PHP バージョンが低いとコアファイルの構文エラーで画面が真っ白になり、適切なバージョンにすると何も修正しなくてもその場で直る。
PHP バージョンを確認してサーバーで変更する手順
最初にサーバーが現在どの PHP バージョンで動いているかを調べ、続いて管理画面からバージョンを切り替える。操作性はレンタルサーバーによって異なるが、多くの場合 cPanel か独自コントロールパネルに PHP セレクターが用意されている。
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 バージョンが適切でも 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 以降の利用が推奨される
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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] と打ち込んだ場合、ブロックの保存・出力の仕様によってはテキストとしてそのまま表示されることがある。クラシックエディタに慣れていると見落としがちなポイントだ。
上図の三方向から原因を絞り込めば、ほとんどのケースで該当箇所が見つかる。次項からは実際の対処手順を具体的に解説する。
ショートコードが機能しないときの具体的な対処手順
手順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.php や page.php など）の出力箇所に追記するコードだ。子テーマを使っていない場合は必ず子テーマを用意してから編集し、テーマのアップデートで変更が失われないようにする。子テーマの作り方は後述の FAQ で扱う。
手順3 ブロックエディタで「ショートコード」ブロックを使う
ブロックエディタでページを編集している場合、ブロック挿入ツール（＋ボタン）から「ショートコード」ブロックを検索して追加する。既存の段落ブロックに直接ショートコードを打ち込んでいる場合は、そのブロックを削除して新しくショートコードブロックを追加し、中にショートコード文字列だけを入力する。
この手順でブロックエディタ上の問題は解決するが、テーマ側の出力処理に起因する問題はこれだけでは直らない。手順2も併せて確認するのが確実だ。
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.css と functions.php の2ファイルを設置する。functions.php には親テーマのスタイルを読み込むコードと、do_shortcode() を含むカスタマイズコードを記述する。詳細な手順は WordPress 公式の子テーマ作成ガイドが役立つ。
ショートコードブロックを使っても特定のページだけ表示されない
キャッシュ系プラグインや CDN が原因のことが多い。キャッシュを全削除し、CDN を使用している場合は一時的に開発モードにしてから表示を確認する。また、該当ページがカスタム投稿タイプで、テンプレートが専用の出力処理をしている場合も同様に do_shortcode() の追加が必要になる。
プラグインを更新したが問題が再発した
更新で一度直っても、WordPress の自動エラーハンドリングが再度働いて同じプラグインを停止することがある。サーバーのエラーログを確認し、PHP のメモリ不足や実行時間制限が原因であれば、wp-config.php で WP_MEMORY_LIMIT を 256M 以上に設定する。根本的にはプラグイン開発者の対応を待つ必要があるケースもある。
この記事のポイント
- ショートコードが文字列のまま表示される主因はプラグイン停止・テーマの処理不足・ブロック選択ミスの3つ
- 管理画面に入れない場合はリカバリモードか FTP でプラグインフォルダをリネームして復旧させる
- テーマ側で do_shortcode() が呼ばれていない箇所は子テーマのテンプレートに追記する
- ブロックエディタでは必ず「ショートコード」専用ブロックの中に記述する
- WordPress 7.0 はエラーハンドリングが強化され互換性問題が表面化しやすい
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている