PHP 8.5でCannot use bool as array警告が出る原因と直し方
PHP 8.5 環境の WordPress 7.0 で「Cannot use bool as array」の警告が出るのは、oEmbed レスポンスが想定する配列ではなく false（真偽値）を返し、それを配列として処理しようとした型エラーです。コード改修に踏み切らなくても、`oembed_response_data` フィルタで安全性を担保する一時回避が有効です。
PHP 警告の原因は何か「Cannot use bool as array」
この警告は `wp-includes/embed.php` 742 行目付近、oEmbed レスポンスを iframe 埋め込みコードに加工するフィルタ処理で出ています。もともと配列が入る想定の変数に真偽値 `false` が入り、その要素にアクセスして停止するパターンです。
外部 oEmbed プロバイダへの通信失敗、エンドポイントの一時停止、クラウドや CDN 経由のキャッシュが古い応答を返した場合などに起きます。WordPress コアの型チェックがまだ強化しきれていない箇所で、PHP 8.5 の厳格な型チェックとぶつかったものです。投稿本文に貼られた Twitter / YouTube / Vimeo 等の埋め込みが読み込まれるたびに断続的に発生します。
なぜ PHP 8.5 で特に出やすいのか
PHP 8.0 以降、型の不一致に対する警告やエラーが段階的に強化されています。8.5 では false 値を直接配列の添字アクセスに使おうとすると通らなくなり、今回のような「発生条件がまれで、一度に複数回出る」断続的な警告になります。
エラー箇所をサーバーエラーログで特定する手順
まずログを正確に把握します。レンタルサーバーの管理画面やコントロールパネルから PHP エラーログを確認しましょう。ログには `/wp-includes/embed.php` の行番号と `Cannot use bool as array` の文言が残っています。
上のデモはエラーログに現れる典型的な記録と、原因特定後の流れを示しています。ログ内で同じ秒に 3 回出現したという報告もあるように、1 件の埋め込みが複数のインスタンスを生む場合があります。
コード編集せずに一時回避する方法
今すぐ警告を止めたい場合は、テーマの functions.php やサイト専用のプラグインに以下の `add_filter` を追加します。これは oEmbed レスポンス加工の入り口で変数が配列であることを確かめ、配列でなければ空の配列を返す安全策です。
add_filter( 'oembed_response_data', function( $data ) {
if ( ! is_array( $data ) ) {
$data = array();
}
return $data;
}, 0 );上記はコアファイルを触らず、フィルタ段階で致命的な型エラーを封じます。本来 WordPress が返すはずの埋め込みは表示されませんが、警告の発生そのものは止まり、画面の上部にエラー文言が出る状況を解消できます。
functions.php に記述する際の注意
- 子テーマの functions.php に必ず追記する（親テーマ直編集は更新で消える）
- コードスニペット系プラグイン（WPCode 等）を使うと管理が楽になる
- 記述後はサーバーの OPCache やプラグインキャッシュをクリアする
根本対応としての oEmbed プロバイダ見直し
外部 oEmbed の呼び出しに失敗している場合、根本的には該当 URL が貼られた投稿を編集し埋め込み形式を変えるのが一番です。エンドポイントが停止したサービスや、TLS 設定が古いプロバイダを指しているときにも警告が出ます。
特定の URL パターンだけ埋め込みを無効化したい場合は、`oembed_discovery_links` フィルタやキャッシュ期間を変える方法も検討できます。社内のプライベートクラウド上にある独自メディアサーバーを oEmbed で呼んでいる場合などは、ネットワーク設定や HTTP タイムアウトの調整も必要です。
よくある質問
コアファイルを直接修正してもよいのか
コアの embed.php を修正するとアップデートで上書きされるため、現実的ではありません。どうしても早期にパッチしたい場合も、WordPress コアの Trac に報告する形が安全です。上書きリスクを避けるため、必ずフィルタで対処しましょう。
警告は出ているが埋め込みは見えている場合の対処は
画面に埋め込みは表示されるがデバッグログだけ警告が出る状態なら、前述の `is_array()` チェックを入れたフィルタでログ汚染を防げます。ただし埋め込みが正しく機能しているなら、根本原因（特定の URL の一時的応答失敗）が解消されるのを待つだけでも構いません。
PHP 7.x に戻すのは対策になるか
PHP のバージョンを下げると表面的に警告が消える可能性はありますが、セキュリティ面で大きなリスクがあります。PHP 8.5 環境のままで、WordPress とプラグインを最新に保ちながらフィルタで予防する方向が安全です。
WordPress 7.0 のアップデートでこのエラーが起きた可能性は
WP 7.0 固有の不具合というより、PHP 8.5 との組み合わせで型チェックが厳しくなった影響です。特に大きなリファクタリングが行われたコア部分で、今まで隠れていた型不一致が警告として顕在化している状況です。
埋め込みをすべて無効にする設定はあるか
完全に oEmbed 機能を止めるには `remove_action` で関連フックを外す方法もあります。ただし、既存の埋め込み投稿の見栄えが大きく変わるため、テスト環境で事前検証する必要があります。
この記事のポイント
- PHP 8.5 と WP 7.0 の型不一致が原因で oEmbed 処理中に「Cannot use bool as array」警告が発生する
- 即効の回避策は `oembed_response_data` フィルタで `is_array()` チェックを追加すること
- コアファイルの直接修正は避け、子テーマの functions.php または専用プラグインで管理する
- 外部 oEmbed プロバイダの応答エラーが根本原因の場合、該当 URL の見直しやキャッシュ設定の再考も検討する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce支払いページで重大エラーが出る原因と直し方
WooCommerce の「支払いページ（Pay for Order）」で「このサイトで重大なエラーが発生しました」と表示されたり、決済フォームが読み込まれない場合、原因はほぼプラグインの競合かテーマのテンプレート不整合だ。管理画面からエラーログを確認し、プラグインの全無効化と標準テーマへの切り替えで原因を特定する手順を取れば、数十分で復旧できる。
Pay for Order ページで重大なエラーが出る原因
WooCommerce の Pay for Order（支払い）ページは、注文確認メールやマイアカウントの「注文の支払い」リンクから遷移する専用のチェックアウト画面だ。通常のチェックアウトと異なり、すでに作成済みの注文に対して決済だけを行う設計のため、内部で呼ばれる処理やパラメータが少し異なる。
決済プラグインやカスタムコードがこの固有のフローに対応していない場合、「このサイトで重大なエラーが発生しました」という WordPress の致命エラー画面が表示されたり、決済フォーム部分だけが真っ白になる。特に注文件数が多いサイトほど、Pay for Order の動作不良は直接売上に響くため即時対応が必要だ。
支払いページだけが壊れる仕組み
WooCommerce の内部では、Pay for Order ページの URL に pay_for_order=true と key（注文キー）というパラメータが渡される。通常のチェックアウトとは異なり、カートの中身を参照するのではなく、指定された注文 ID のデータを直接読み込んで決済処理を開始する流れだ。
このとき、決済ゲートウェイプラグインや注文カスタマイズ系プラグインが「カートが空」「注文データが見つからない」といった前提でコードを書いていると、Pay for Order のフローでは関数がエラーを吐き、画面全体が停止する。また、テーマが checkout/payment.php などのテンプレートを上書きしている場合、WooCommerce のバージョン更新に追従できておらず古いテンプレートが原因で決済フォームが欠落することもある。
エラーの詳細を特定する手順
Pay for Order ページでエラーが発生したら、まずエラーログを有効にして原因の PHP エラーを記録させる。WordPress 5.2 以降のサイトヘルス機能や、wp-config.php のデバッグ定数を使えば、エラーメッセージをファイルに出力できる。画面に何も表示されない場合でもログには原因が記録されているケースがほとんどだ。
デバッグログを有効化してエラーを特定する流れ。ログのパスがわからない場合は管理画面の「ツール」→「サイトヘルス」→「情報」タブの「WordPress 定数」セクションで確認できる。
wp-config.php に追加するデバッグ定数
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG_DISPLAY を false にすることで、エラーを画面に表示せずログファイルだけに出力する。公開中のサイトでもこの設定なら訪問者にエラーメッセージを見せずに原因を特定できる。debug.log は /wp-content/ ディレクトリに生成される。
ログに記録されているエラーメッセージには、発生元のプラグインディレクトリ名やテーマ名が含まれる。たとえば /wp-content/plugins/woocommerce-gateway-stripe/ のようなパスが出れば、その決済プラグインが Pay for Order に対応できていない可能性が高い。
エラーログから原因を読み解く
Pay for Order ページで頻出するエラーには次のようなパターンがある。PHP の致命的エラー（Fatal error）では「未定義の関数を呼び出した」「null に対してメソッドを実行した」といったメッセージが記録される。特に Call to a member function 〜 on null は、注文オブジェクトの取得に失敗している典型的な兆候だ。
決済ゲートウェイプラグインが WC()->cart や WC()->session に依存している場合、Pay for Order のフローではこれらのオブジェクトが期待通りに動作せずエラーになる。ログにプラグイン名が出たら、まずそのプラグインを開発元のサポートに報告し、Pay for Order 対応の有無を確認するのが確実だ。
プラグイン競合を切り分ける短時間の方法
管理画面にアクセスできるなら、プラグインの一括無効化とテーマ切り替えによる切り分けが最も速い。この作業は公開中のサイトには影響が出るため、メンテナンスモードを有効にするか、低トラフィック時間帯に実施する。
プラグイン競合の切り分けで目指す最終状態。すべての不要プラグインを無効化し標準テーマに切り替えた状態で動作すれば、原因は無効化した中にある。
全プラグインを一括無効化して一つずつ再有効化する
WooCommerce 本体と、その動作に必須な決済プラグインを除くすべてのプラグインを一度無効化する。特に注意すべきは、キャッシュ系プラグイン、セキュリティプラグイン、そして注文カスタマイズ系のプラグインだ。Pay for Order の URL パラメータをキャッシュやリダイレクトルールが干渉して弾いているケースも多い。
無効化後に Pay for Order ページが正常に表示されれば、原因は無効化したいずれかのプラグインにある。次に、WooCommerce と決済プラグイン以外のプラグインを一つずつ再有効化し、その都度 Pay for Order ページを再読み込みしてエラーの再発を確認する。エラーが再発した時点で直前に有効化したプラグインが原因だ。
標準テーマに切り替えてテーマ由来の不具合を除外する
プラグインをすべて無効化しても直らない場合、使用中のテーマが WooCommerce のテンプレートを上書きしている可能性が高い。管理画面の「外観」→「テーマ」から Twenty Twenty-Five などの標準テーマに一時的に切り替え、再度 Pay for Order ページを表示する。標準テーマで問題なく動作するなら、元のテーマ側のテンプレートファイルが原因だ。
切り分け時に注意すべきキャッシュの削除
WooCommerce のチェックアウト周りはキャッシュの影響を強く受ける。プラグインを無効化しても、サーバーキャッシュや CDN キャッシュが残っていると古いエラー画面が表示され続けることがある。管理画面の「WooCommerce」→「ステータス」→「ツール」タブから「WooCommerce の一時データをクリア」「商品の参照カテゴリをカウントする」を実行し、さらに利用中のキャッシュプラグインのキャッシュも全削除してからテストする。
テーマと WooCommerce テンプレートのバージョン不整合を解消する
テーマが WooCommerce のテンプレートファイルを子テーマや独自ディレクトリで上書きしている場合、WooCommerce 本体がバージョンアップするとテンプレートの構造や関数が変更され、古いテンプレートでは Pay for Order の処理に失敗する。特に checkout/form-pay.php や checkout/payment.php は Pay for Order ページで直接使われるファイルのため、上書きされていると影響が大きい。
上書きテンプレートの状態を確認する
管理画面の「WooCommerce」→「ステータス」画面を開き、「テンプレート」セクションを表示する。ここに「上書きあり」と表示されているテンプレートの一覧がある。checkout/form-pay.php が上書きされていて、かつ WooCommerce 本体のバージョンより古いテンプレートバージョンが記載されている場合、このファイルを最新の WooCommerce テンプレートと比較して更新する必要がある。
テンプレートを安全に更新する手順
まず WooCommerce プラグインディレクトリの templates/checkout/form-pay.php を最新の状態で確認し、現在テーマ側で上書きしている同名ファイルと差分を比較する。差分が少ない場合はテーマ側のファイルを最新に置き換え、カスタマイズがある部分だけ必要な修正を手動で適用する。差分が多い場合は、WooCommerce のアクションフックを使ってテンプレート上書きを避ける設計に移行するのが長期的に安全だ。
よくある質問
Pay for Order ページだけがエラーになるのはなぜか
通常のチェックアウトと Pay for Order では WooCommerce 内部のフローが異なり、カートセッションの状態や注文オブジェクトの取得方法が変わる。多くの決済プラグインは通常のチェックアウトだけを想定して開発されているため、Pay for Order の特殊なパラメータを受け取った際に未定義エラーや null 参照が発生する。
管理画面にもアクセスできなくなった場合はどうすればよいか
FTP またはサーバーのファイルマネージャーで /wp-content/plugins/ ディレクトリにアクセスし、エラーの原因と思われるプラグインのディレクトリ名を変更する（例 plugin-name → plugin-name-disabled）。これで強制的にプラグインを無効化できる。復旧後に管理画面から原因の特定を進める。
WooCommerce のステータスページで推奨される PHP 設定はあるか
WooCommerce の推奨 PHP メモリ制限は 256MB 以上、実行時間の上限は 300 秒以上だ。「WooCommerce」→「ステータス」画面の「サーバー環境」セクションで現在値を確認し、不足している場合はレンタルサーバーの管理画面や php.ini から引き上げる。メモリ不足が原因で Pay for Order の処理中にプロセスが停止することもある。
特定の決済プラグインだけが Pay for Order で動かない場合の対処は
まずその決済プラグインの公式サポートに「Pay for Order ページでエラーが発生する」と明記して問い合わせる。急を要する場合は、WooCommerce 標準の銀行振込や代金引換などの決済手段を一時的に有効化して Pay for Order での支払いを受け付けつつ、該当プラグインの修正を待つ運用で売上を止めないようにする。
エラーログに何も記録されない場合はどうすればよいか
JavaScript のエラーが原因で画面が動作しないケースが考えられる。ブラウザの開発者ツール（F12 キー）の「コンソール」タブを開き、Pay for Order ページを読み込んだ際の赤いエラー表示を確認する。jQuery の競合や決済フォームのスクリプト読み込み失敗が主な原因で、PHP ログには記録されない。
この記事のポイント
- Pay for Order ページのエラーは主にプラグイン競合かテーマのテンプレート不整合が原因
- wp-config.php のデバッグ定数でエラーログを取得し原因プラグインを特定する
- 全プラグイン無効化と標準テーマへの切り替えで短時間に原因を切り分ける
- テーマの WooCommerce テンプレート上書きはステータス画面でバージョン確認し最新化する
- JavaScript エラーの場合はブラウザの開発者ツールで別途確認が必要
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Vercelがソースマップ保護機能を発表、本番環境のコード露出を防止
Vercelは2026年5月、本番環境のソースマップを安全に配信する新機能「Protected Source Maps」をリリースした。ブラウザが読み取る .map ファイルを Vercel Authentication の背後に置き、開発チームだけがアクセスできる仕組みだ。これにより、デバッグ情報を必要な人間にだけ提供し、それ以外の第三者には 404 を返す。
フロントエンドのバンドルは本番ビルドで圧縮・ミニファイされるため、可読性を保つにはソースマップが欠かせない。しかし従来は、そのソースマップが認証なしで公開されてしまい、コードの内部ロジックやコメントが誰でも閲覧できる状態だった。Protected Source Maps は、このセキュリティリスクを根本的に解決する。
ソースマップがなぜ重要か
ミニファイとデバッグのジレンマ
本番サイトの JavaScript や CSS は、ファイルサイズ削減のためにミニファイされる。変数名を短縮し、空白やコメントを取り除く処理だ。ところが、エラーが発生したとき、ブラウザのコンソールには圧縮後のコードしか表示されず、スタックトレースが「at a.a (bundle.js:1:2345)」のように読めなくなる。デバッグがほぼ不可能になるのだ。
この問題を解決するのがソースマップである。ミニファイ元のファイル名や行番号、元の変数名を記録した .map ファイルとして生成し、ブラウザがそれを使って元のソースコードを復元する。つまり、ビルド後の難読コードを、開発時の読みやすいコードに戻す「翻訳辞書」のような役割だ。
ソースマップの仕組み
ソースマップは通常、ミニファイされたファイルの末尾に //# sourceMappingURL=app.js.map というコメントを挿入することでブラウザに通知される。ブラウザがこのコメントを見つけると、対応する .map ファイルを別途リクエストし、デベロッパーツール上でオリジナルのソースコードを表示する。ここまでは開発者にとって日常的な光景だ。
しかし、本番環境でこの .map ファイルが認証なしに取得できると、第三者が容易にソースコードを読めてしまう。公開を想定していないコメントや、内部のビジネスロジックがダダ漏れになるリスクがある。
本番ソースマップが晒されてきたリスク
従来の典型的な対策は、ビルド時にソースマップを生成しないか、本番サーバーにアップロードしないというものだった。しかし、それでは本番環境で発生したエラーの調査が困難になる。また、サーバー側で特定の IP アドレスや VPN 経由のみアクセスを許可する方法もあるが、設定が複雑で、動的に変わるチームメンバーの管理には向かない。
実際に、JavaScript フレームワークの設定ミスによってソースマップが公開され、内部の API キーやテスト用のパスワードが漏えいした事例も報告されている。ソースマップは開発者にとって便利な一方、扱いを誤ると大きなセキュリティホールになりうる。
上の図は、認証がない場合と今回の保護機能を適用したあとの応答の違いを示している。従来は誰でも .map を取得できたが、Protected Source Maps を有効にすると、チーム外のリクエストには 404 Not Found が返る。
Protected Source Maps の動作と設定
Vercel Authentication によるアクセス制限
この機能の核は、プロジェクトの .map ファイルが Vercel Authentication で保護される点にある。通常、Vercel Authentication はデプロイプレビューや特定のパスをチームメンバーだけに公開するために使われる認証フレームワークだ。今回これがソースマップにも適用された。
つまり、ブラウザがソースマップをリクエストしても、Vercel のエッジネットワークが認証情報を確認する。チームの開発者であれば、普段から使っているブラウザのセッションでそのまま .map ファイルを取得できる。しかし、チーム外の人物や認証されていないブラウザからのリクエストには 404 が返るため、存在そのものを隠蔽する効果もある。
新規プロジェクトではデフォルトで有効、既存も後から移行可能
Vercel は、新規に作成するプロジェクトでは Protected Source Maps をデフォルトで有効にした。これにより、これからデプロイするプロジェクトは意識せずとも本番ソースマップが保護される。既存のプロジェクトについては、管理画面の「Settings」〜「Deployment Protection」からスイッチをオンにするだけで有効化できる。再デプロイも不要だ。
この設定変更は即座にエッジネットワーク全体に反映される。認証なしの .map リクエストはその瞬間から 404 になるため、段階的な移行作業を必要としない。
開発フローへの影響と注意点
セキュリティとデバッグ効率の両立
Protected Source Maps を導入しても、認証済みの開発者には従来通りソースマップが提供される。つまり、ブラウザのデベロッパーツールでエラーを追う際に元のコードが見えなくなることはない。本番環境で発生した問題を調査するチームにとって、利便性は一切損なわれない。
一方で、認証されていないサードパーティには 404 が返るため、ソースコードの漏えいリスクを大幅に低減できる。特に、エラーログに .map ファイルの URL が含まれていた場合でも、外部からはアクセスできない。
導入時に確認すべき点
この機能を使ううえで、いくつか注意点がある。まず、Vercel Authentication はブラウザのセッションを利用するため、開発者がログイン状態である必要がある。シークレットウィンドウやチームアカウント外のブラウザからはデバッグできない点に注意が必要だ。
また、CI/CD ツールなど自動化された環境でソースマップを処理する場合は、Vercel の API トークンを使って認証を通すか、あるいは別途プライベートなストレージにマップをアップロードする運用を検討してもよい。ただし、多くのケースでは開発者のブラウザからのリクエスト以外にソースマップが必要になるシチュエーションは少ないため、まずは Protected Source Maps をオンにして、必要に応じて調整するのが現実的だ。
この記事のポイント
- Vercel が Protected Source Maps をリリース、本番ソースマップをチーム限定に
- ブラウザからの
.mapリクエストは Vercel Authentication で保護される - 認証なしのアクセスには
404 NotFoundを返却、コードの露出を防止 - 新規プロジェクトはデフォルトで有効、既存プロジェクトも管理画面から即時有効化可能
- 導入後も開発者のデバッグ体験は変わらず、セキュリティと利便性を両立
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験