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 エラーログを確認しましょう。ログには `/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 が返すはずの埋め込みは表示されませんが、警告の発生そのものは止まり、画面の上部にエラー文言が出る状況を解消できます。
外部 oEmbed の呼び出しに失敗している場合、根本的には該当 URL が貼られた投稿を編集し埋め込み形式を変えるのが一番です。エンドポイントが停止したサービスや、TLS 設定が古いプロバイダを指しているときにも警告が出ます。
特定の URL パターンだけ埋め込みを無効化したい場合は、`oembed_discovery_links` フィルタやキャッシュ期間を変える方法も検討できます。社内のプライベートクラウド上にある独自メディアサーバーを oEmbed で呼んでいる場合などは、ネットワーク設定や HTTP タイムアウトの調整も必要です。
よくある質問
コアの embed.php を修正するとアップデートで上書きされるため、現実的ではありません。どうしても早期にパッチしたい場合も、WordPress コアの Trac に報告する形が安全です。上書きリスクを避けるため、必ずフィルタで対処しましょう。
画面に埋め込みは表示されるがデバッグログだけ警告が出る状態なら、前述の `is_array()` チェックを入れたフィルタでログ汚染を防げます。ただし埋め込みが正しく機能しているなら、根本原因（特定の URL の一時的応答失敗）が解消されるのを待つだけでも構いません。
PHP のバージョンを下げると表面的に警告が消える可能性はありますが、セキュリティ面で大きなリスクがあります。PHP 8.5 環境のままで、WordPress とプラグインを最新に保ちながらフィルタで予防する方向が安全です。
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 の見直しやキャッシュ設定の再考も検討する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressのキーが長すぎるエラーをMariaDB 11.4で修正する方法
「指定されたキーが長すぎます。最大キー長は 1000 バイトです」というエラーが WordPress サイトのデータベースで発生した場合、対象となるテーブルの複合インデックス定義で長すぎるカラムのプレフィックス長を制限すれば解決する。これはデータベースの照合順序と文字コードの関係で、インデックスが許容バイト数を超過することが直接の原因だ。
「キーが長すぎる」エラーが発生する根本原因
このエラーは特定のデータベーステーブルに複合インデックスを作成しようとした際に、インデックスに含まれるカラムの合計バイト数がデータベースの上限を超えたために発生する。MariaDB や MySQL では、InnoDB ストレージエンジンの行フォーマットとサーバー設定によってキー長の上限が決まる。具体的には ROW_FORMAT が COMPACT または REDUNDANT のテーブルでは最大 767 バイトまでしか許容されず、DYNAMIC や COMPRESSED の場合でも実質的に 3072 バイトが上限となる。
今回のようなエラーが顕在化しやすいのは、データベースを MariaDB の最新バージョン（11.4 系など）に移行したタイミングだ。デフォルトの文字コードが utf8mb4 に設定されている環境で、VARCHAR 型のカラムをインデックスに含めると、1 文字が最大 4 バイトとして計算されるため、たとえば VARCHAR(255) のカラムが含まれているだけで、そのカラムだけで 1020 バイトを消費する計算になる。
プラグインが独自に追加した CHANGE_LOG テーブルでは、object_type、object_id、created_at という 3 つのカラムで複合インデックスを作ろうとしている。object_id は外部キーや参照用に VARCHAR で定義されていることが多く、これが長いままだとバイト数制限に引っかかる。解決の本質は、インデックスで実際に使用する範囲を object_id カラムの先頭部分だけに限定することにある。
エラーを特定するための確認手順
実際のエラーメッセージをログから確認する
データベースエラーの内容を正確に把握するために、まずは WordPress のデバッグログを有効化する。wp-config.php に以下の定数を追加する。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );エラーを再現させたあと、/wp-content/debug.log を確認すると「Specified key was too long; max key length is 1000 bytes」というエラーが記録されているはずだ。このエラーには対象のテーブル名や、キーを作成しようとした SQL 文も含まれている。
テーブルのインデックス定義を直接調べる
データベース管理ツール（phpMyAdmin など）で CHANGE_LOG テーブルの構造を開き、「インデックス」タブを確認する。object_lookup という名前の複合インデックスが存在し、そこに object_id カラムがフルサイズで含まれていれば、これがエラーの原因だと特定できる。
SQL コマンドに慣れているなら、以下のクエリでインデックス情報を取得してもよい。
SHOW INDEX FROM wp_change_log;文字コードとバイト数の関係を理解する
utf8mb4 は 1 文字を最大 4 バイトで表現するため、VARCHAR(255) として定義されたカラムは、インデックス上で最大 1020 バイトを占める。複合インデックスでは、含まれる全カラムの最大バイト数の合計が制限値となる。VARCHAR(100) なら最大 400 バイト、VARCHAR(50) なら 200 バイトと計算していき、上限（1000 バイトや 767 バイト）を超えていないかを確認する。この計算を怠ると、一見問題ない定義に見えても実行時にエラーとなる。
複合インデックスを修正する具体的な手順
修正の基本方針は object_lookup インデックスから既存の定義を削除し、object_id カラムのプレフィックス長を制限した新しいインデックスを作り直すことにある。これによりバイト数制限を回避しながら、インデックスの機能自体は維持できる。
このデモは object_id にプレフィックス長を設定する前後のインデックス定義の違いを表している。修正後はバイト数制限に収まるため、エラーが解消される。
phpMyAdmin で安全にインデックスを変更する
データベースの直接操作に不慣れな場合、phpMyAdmin を使うとミスが少ない。該当テーブルを開き、「構造」タブから「インデックス」セクションに移動する。object_lookup インデックスを選択して削除し、新たに「インデックスを作成」から複合インデックスを追加する。
カラムを選択する際、object_type と created_at はそのまま指定し、object_id だけ「サイズ」欄に 100 と入力する。これで object_id(100) としてインデックスが作成される。
SQL コマンドで直接修正する場合
コマンドラインや SQL タブから実行するなら、以下の 2 文を順に実行する。DROP で既存のインデックスを削除し、ADD で新しいインデックスを作成する。
ALTER TABLE wp_change_log DROP INDEX object_lookup;
ALTER TABLE wp_change_log ADD INDEX object_lookup (object_type, object_id(100), created_at);実行前に必ずデータベースのバックアップを取得すること。誤った ALTER TABLE はテーブル構造を壊す可能性がある。
プラグインのアップデートで上書きされないようにする
このインデックスはプラグインが管理するスキーマファイル（class-change-log-schema.php）で定義されているため、プラグインがアップデートされると修正が上書きされてしまう可能性が高い。恒久的な対策としては、プラグインのアクティベーションフックやスキーマ更新処理にフックし、独自のインデックス定義を適用するコードを子テーマの functions.php かカスタムプラグインに記述する方法が有効だ。
データベースのバージョンや設定に依存する問題のため、サーバー環境を変更しない限りこの修正は必須となる。プラグイン開発者が将来的に修正を加えるまでは、自前のフックで対応しておくと安全だ。
よくある質問
このエラーは MariaDB 11.4 だけで発生するのか
MariaDB 11.4 に限らず、キー長制限が厳格に適用される環境ならば発生する可能性がある。古い MySQL 5.6 以前の設定や、InnoDB の ROW_FORMAT が COMPACT のテーブルでも同様のエラーが起こる。
object_id(100) のようにプレフィックスを制限しても検索性能は落ちないのか
先頭 100 文字までをインデックス化するため、100 文字を超える部分での検索精度は低下する可能性がある。ただ、object_id のような識別子は冒頭部分で十分に一意性が確保されることが多く、実際のクエリ性能に大きな影響は出ない。
エラーが WordPress 本体のテーブルで出た場合はどうすればよいか
WordPress コアのテーブルでこのエラーが発生することは稀だ。通常はプラグインやテーマが独自に追加したカスタムテーブルで起こる。もしコアテーブルで起こった場合は、データベースの文字コードや ROW_FORMAT の設定自体を見直す必要がある。
SQL の直接実行が不安なときの代替手段はあるか
WP-CLI（WordPress のコマンドライン管理ツール）が利用できるなら、「wp db query」コマンドで安全にクエリを実行できる。また、データベースの移行や最適化を支援するプラグイン（WP Migrate など）にも SQL 実行機能が備わっているものがある。
この記事のポイント
- インデックスに含まれるカラムの合計バイト数がデータベースの上限を超えるとキー長エラーが発生する
- utf8mb4 環境では VARCHAR 型のカラムが 1 文字最大 4 バイトを消費する点に注意が必要
- object_id(100) のようにカラムのプレフィックス長を指定してインデックスを再作成することでエラーを回避できる
- プラグインのアップデートで修正が上書きされるため、恒久的な対処にはフックを用いたコード管理が推奨される
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている