投稿者アーカイブ

  1. ホーム   /  投稿者:佐々木 太陽 ( 固定ページ11 )
WooCommerce決済が「処理中」で止まりサンクスページに遷移しない場合の対処法
2026年7月9日 0

WooCommerce決済が「処理中」で止まりサンクスページに遷移しない場合の対処法

WooCommerceでRazorpay決済を利用しているサイトで、支払い自体は成功しているのにチェックアウト画面が「処理中です。しばらくお待ちください」と表示されたまま止まり、注文完了ページへ遷移しない問題は、RazorpayのJavaScript SDKが正常に読み込まれていないか、他のプラグインとの競合によってフォーム送信処理が破損している場合に起こる。

特にサンドボックスモードでは正常に動作するのに本番環境でのみ発生する場合、APIキーの設定ミスや決済スクリプトのパス解決エラーが根本原因である可能性が高い。ブラウザの開発者コンソールを開くと GET .../build/undefined 403 や document.razorpayform.submit is not a function といったエラーが記録されているはずだ。以下では原因の特定から具体的な修正手順までを順に解説する。

ブラウザコンソールでエラーの全体像を把握する

ブラウザコンソールでエラーの全体像を把握する

まず最初に行うべきは、問題が起きているページで開発者ツールを開き、コンソールタブとネットワークタブに出力されているエラーを確認することだ。Razorpayの処理フローはほぼすべてフロントエンドのJavaScriptで制御されているため、バックエンドのログだけでは見えない問題がここに集中して現れる。

Chromeの場合、決済画面で F12 を押してDevToolsを開き、以下の手順で記録を取る。

STEP 1 コンソールタブを開き、ゴミ箱アイコンでログをクリアする
↓
STEP 2 ネットワークタブを開き「プリザーブログ」にチェックを入れる
↓
STEP 3 実際に決済を実行し、処理が止まるまでの全リクエストとエラーを記録する

記録した中で特に注目すべきは以下の2種類のエラーだ。

  • GET https://checkout-static-next.razorpay.com/build/undefined 403 というリクエストが発生している場合、Razorpay SDKのビルドパスが正しく解決されていない。末尾が /undefined になっているのが最大の手がかりだ。
  • Uncaught TypeError: document.razorpayform.submit is not a function は、決済フォームの送信メソッドが何らかの理由で失われていることを示す。他のJavaScriptによって上書きされているか、Razorpayのスクリプト自体が最後まで読み込まれていない可能性が高い。

GET …/build/undefined 403 エラーが示す根本原因

GET .../build/undefined 403 エラーが示す根本原因

Razorpayのチェックアウトスクリプトは、プラグインが動的に生成するパスに基づいて checkout-static-next.razorpay.com/build/【バージョン番号】 というURLから読み込まれる。このバージョン番号が何らかの理由で空になると /build/undefined という不正なURLが生成され、当然ながら403 Forbiddenで拒否される。

この現象は主に次の3つの状況で起こる。

本番用APIキーが未設定または誤ったキーが入力されている

Razorpayプラグインの設定画面（WooCommerce → 設定 → 決済 → Razorpay）を開き「本番用キーID」と「本番用キーシークレット」の両方が 本番環境用の正しい値 になっているか確認する。サンドボックス用のキーが誤って本番フィールドに入力されていると、スクリプトパスの生成に失敗する。キーはRazorpayダッシュボードの「Settings → API Keys」から再発行できる。

プラグインのバージョンが古いか不完全に更新されている

公式の「Razorpay for WooCommerce」プラグインが最新版かどうかを確認する。過去のバージョンには、特定の条件下でSDKバージョン文字列が空になる不具合が報告されている。wp-adminのプラグイン一覧で更新があれば適用し、問題が継続する場合は一度プラグインを完全に削除してから再インストールする。削除前に必ずAPIキーをメモしておくこと。

マルチカレンシープラグインがRazorpayの設定を上書きしている

WooCommerce Currency Switcher（FOXやAeliaなど）を使用している場合、通貨切り替えの過程でRazorpayの決済スクリプトに渡すパラメータが改変されることがある。特にジオベースで通貨を自動切り替えしている環境では、チェックアウトページ読み込み時に想定外の通貨コードがRazorpayに渡され、SDKの初期化に失敗するケースが確認されている。

通貨スイッチャー側の設定で、チェックアウトページと決済完了ページを通貨切り替えの対象外にするルールを追加しても改善しない場合、以下の方法で問題の所在を明確にできる。

Before（通貨スイッチャー有効時）
Razorpayに渡される通貨コードが undefined になり、スクリプトパスが /build/undefined に
NGscript読み込み失敗 → 403
↓
After（通貨スイッチャー無効化後）
Razorpayに正しい通貨コード（INR）が渡り、スクリプトパスが /build/v3.45.0 など正常に
OKscript読み込み成功 → 決済完了
■ エラー状態　■ 修正後

document.razorpayform.submit is not a function を解消する

document.razorpayform.submit is not a function を解消する

このTypeErrorは、決済フォームを送信するタイミングで razorpayform オブジェクトの submit メソッドが存在しないことを意味する。原因は主に2つに絞られる。

JavaScriptの最適化や結合によるメソッド破損

LiteSpeed CacheやAutoptimizeなどのキャッシュ・最適化プラグインがJavaScriptを結合（Combine）したり、圧縮（Minify）したり、遅延読み込み（Defer）したりする設定が有効だと、Razorpayのフォームオブジェクトが初期化される前に他のスクリプトが実行され、document.razorpayform が不完全な状態になる。

JavaScriptの最適化機能をすべてオフにしても改善しない場合でも、LiteSpeed Cacheにはページ単位の最適化設定や「ゲストモード」など追加の最適化機能が存在する。プラグインを完全に無効化してテストした上で、それでも直らなければキャッシュ以外の競合を疑う。

サンクスページカスタマイズプラグインによるリダイレクト干渉

「WooCommerce Thank You Page」のような注文完了ページをカスタマイズするプラグインは、通常のリダイレクトフックを上書きする。Razorpayが決済完了後に実行する razorpayform.submit() が、この上書きされたフローと衝突し、メソッド呼び出し自体が失敗するケースがある。

サンクスページプラグインを無効化してテストした結果、問題が解消するのであれば、そのプラグインが原因だ。Razorpayとの互換性をプラグイン開発者に確認するか、よりシンプルなフックベースのカスタマイズ（テーマのfunctions.phpで制御）に切り替える。

プラグインの競合を段階的に切り分ける手順

プラグインの競合を段階的に切り分ける手順

エラーのパターンから明らかな原因を特定できない場合は、標準的なトラブルシューティングの手順で競合を絞り込む。本番サイトで作業する前に、必ずステージング環境を用意するか、メンテナンスモードを有効にしてから行う。

STEP 1 Razorpay以外の全プラグインを無効化する
↓
STEP 2 標準テーマ（Twenty Twenty-Fourなど）に切り替える
↓
STEP 3 本番APIキーでテスト決済を実行し、正常に動作するか確認する
↓
STEP 4 プラグインを1つずつ有効化し、どのタイミングで問題が再発するか特定する

STEP 4では、まず通貨スイッチャーとキャッシュ系プラグインを最初に有効化してテストする。この2つが最も競合を起こしやすい。次にPixelYourSiteなどの外部スクリプトを注入するプラグインをテストし、最後にサンクスページプラグインを検証する。

RazorpayのWebhook設定も再確認する

フロントエンドのJavaScriptエラーに加えて、バックエンドのWebhookが正しく設定されていないと、決済完了後に注文ステータスが更新されない。Razorpayダッシュボードの「Settings → Webhooks」で以下を確認する。

  • Webhook URLが https://あなたのサイトURL/wc-api/razorpay_webhook/ になっている。
  • イベントに payment.authorized と refund.created が最低限含まれている。
  • WebhookシークレットがWooCommerce側のRazorpay設定に入力した値と完全に一致している。
  • 重複したWebhook登録がない（過去のテストで作成した古いWebhookが残っていると競合する）。

よくある質問

サンドボックスでは正常なのに本番だけで止まるのはなぜですか？

本番用のAPIキー設定ミスか、本番環境専用のプラグイン（セキュリティや最適化）がRazorpayのスクリプトに干渉している可能性が高い。サンドボックスと本番で異なるキーを使っていることを再確認し、本番環境にのみ有効なプラグインを一時停止して切り分ける。

Razorpay以外の決済ゲートウェイでも同じ現象は起こりますか？

StripeやPayPalなど他の決済プラグインでも、JavaScriptの競合やリダイレクトフックの干渉によって同様の「処理中」ループが発生することがある。原因の切り分け手順はほぼ共通しているため、本記事のSTEPを他のゲートウェイにも応用できる。

コンソールにエラーが出ていないのに処理が止まる場合は？

PHPのメモリ不足や実行時間制限が原因で、決済完了後のサーバーサイド処理が途中で止まっている可能性がある。WooCommerceのステータスレポートでPHPのメモリ制限が256MB以上、最大実行時間が300秒以上あるか確認する。サーバーのエラーログも併せて調査する。

Razorpayプラグインを最新にしても直らない場合は？

プラグインの公式GitHubリポジトリで同様のIssueが報告されていないか確認する。解決策としてパッチが提供されていることもある。また、Razorpayのカスタマーサポートに本番環境のドメインとエラーの詳細を伝えて調査を依頼する方法も有効だ。APIキーの発行元アカウントに制限がかかっていないかも合わせて確認してもらえる。

PixelYourSiteを無効化せずに共存させる方法はありますか？

PixelYourSiteの設定で「チェックアウトページでのスクリプト実行を遅延させる」オプションをオフにするか、カスタムコードでRazorpayのスクリプトがPixelYourSiteより先に読み込まれるよう wp_enqueue_scripts の優先度を調整する。functions.phpに以下のようなコードを追加する方法もある。

add_action('wp_enqueue_scripts', function() {
    if (is_checkout()) {
        wp_dequeue_script('pys');
        wp_enqueue_script('pys', 'path/to/pys.js', array('razorpay'), null, true);
    }
}, 100);

このコードはあくまで概念を示すもので、実際のハンドル名やパスはプラグインのソースを確認して書き換える必要がある。

この記事のポイント

  • ブラウザコンソールで /build/undefined 403エラーや razorpayform.submit TypeErrorを確認する
  • 本番用APIキーが正しく入力されているか、Razorpayダッシュボードで再確認する
  • 通貨スイッチャーがチェックアウトページで干渉していないか検証する
  • JavaScript最適化プラグインを完全無効化し、サンクスページカスタマイズプラグインを停止してテストする
  • 全プラグイン無効化と標準テーマ切り替えで競合を段階的に切り分ける
佐々木 太陽
, , , , ,
お悩み・トラブル解決
GTranslateで重大エラーが発生した時の原因と復旧手順
2026年7月8日 0

GTranslateで重大エラーが発生した時の原因と復旧手順

複数サイトで突然「このサイトで重大なエラーが発生しました」と表示され管理画面にアクセスできなくなった場合、GTranslate プラグインの翻訳ファイル（.po / .mo）に含まれる誤ったフォーマット指定子が原因である可能性が高い。

エラーログに “Unknown format specifier” と出ていれば、特定の言語ファイルに壊れた翻訳文字列が混入している。管理画面を復旧するには、問題のプラグインフォルダを一時的にリネームして無効化し、誤った翻訳文字列を修正したうえで再有効化する手順を踏む。

なぜ GTranslate で突然重大エラーが発生するのか

なぜ GTranslate で突然重大エラーが発生するのか

エラーの直接原因は翻訳ファイルの壊れた sprintf 指定子

WordPress でプラグインの翻訳を担うのは .po（翻訳テンプレート）と、それをコンパイルした .mo（機械可読ファイル）だ。プラグイン開発者が sprintf() で動的に文字列を組み立てている箇所に、翻訳者が誤って不完全な置換指定子（例："%1$t" など）を入れてしまうと、PHP が文字列フォーマットを解釈できず E_ERROR（致命的エラー）を投げる。

とくに、GTranslate の無料版では管理画面の上部に「ニューラルネット翻訳へのアップグレードを促す通知バナー」を表示している。この通知文のスペイン語（es_ES）翻訳に、%1$s と書くべきところを %1$t とタイプミスした翻訳が混入し、スペイン語ロケールのサイトだけでなく、他の言語設定のサイトでも GTranslate が管理画面を読み込むたびにクラッシュする事象が確認されている。

なぜ他言語サイトまで影響を受けるのか

一見すると日本語や英語のサイトには無関係に思える。しかし GTranslate の管理画面通知は、サイトの表示言語に関係なく、プラグインに同梱された全翻訳ファイルを読み込んだうえで表示言語に合致する文字列を選択する実装になっている。この読み込み段階で誤った .mo ファイルがパースされると、sprintf() が例外をスローし、管理画面全体が停止する。

問題 スペイン語翻訳ファイルに %1$t が混入
↓
結果 管理画面がすべての言語で「重大なエラー」停止
↓
対処 プラグイン無効化 → 翻訳ファイル修正 → 再有効化
■ エラー発生箇所　■ 修正後の流れ

管理画面にアクセスできない状態からの復旧手順

管理画面にアクセスできない状態からの復旧手順

FTP またはホスティングのファイルマネージャーでプラグインを強制無効化する

管理画面に入れないため、通常の「プラグイン」メニューからの無効化は使えない。FTP クライアント（FileZilla や Cyberduck など）、または契約しているレンタルサーバーのファイルマネージャー機能を使い、サーバー上のディレクトリを直接操作する。

STEP 1 FTP で /wp-content/plugins/ に移動
↓
STEP 2 フォルダ名 gtranslate を右クリック → 「名前の変更」
↓
STEP 3 gtranslate を gtranslate_deactivated に変更する
↓
STEP 4 管理画面にアクセスできるか確認する

WordPress は指定されたフォルダ名のプラグインが存在しないと判断し、自動的に無効化する。管理画面にログインできたら、プラグイン一覧に GTranslate が「無効」と表示されていることを確認する。

壊れた翻訳ファイルを特定して修正する

問題の翻訳ファイルは /wp-content/languages/plugins/gtranslate-es_ES.po だ。この .po ファイルをテキストエディタで開き、誤ったフォーマット指定子を修正する。

  • 当該行を検索：msgstr "Puedes disfrutar de %1$t で始まる行を探す
  • %1$t を %1$s に修正する（”t” の直後に “s” を足す）
  • ファイルを保存し、同名の .mo コンパイル済みファイルが存在する場合はいったん削除またはリネームする

.mo ファイルを削除せずに .po だけ修正しても、WordPress は既存の .mo ファイルを優先して読み込む。そのため修正が反映されず、再度エラーになるケースがある。必ず .mo ファイルを削除するか、Poedit などの専用ツールで新たにコンパイルし直す必要がある。

代替策として該当翻訳ファイルごと一時的に退避させる

.po ファイルの直接編集が難しい場合や、修正しても .mo が再生成されてエラーが戻ってしまう場合は、問題の言語ファイル一式を一時的に別フォルダへ退避させる手もある。

  • /wp-content/languages/plugins/ から gtranslate-es_ES.po と gtranslate-es_ES.mo の両方を、サイト外のローカルフォルダに移動する
  • GTranslate プラグインフォルダを元の名前（gtranslate）に戻し、管理画面から再有効化する
  • 管理画面が正常に動作することを確認できたら、プラグイン作者のアップデートを待つ

これは根本解決ではないが、「とにかく今すぐ管理画面を復旧させたい」という状況では有効な暫定策になる。日本語サイトでの管理画面表示にはスペイン語翻訳ファイルは使用されないため、削除しても翻訳機能に影響は出ない。

再発を防ぐためにできること

再発を防ぐためにできること

プラグインの自動更新を一時停止して様子を見る

翻訳ファイルの自動更新は WordPress 本体の仕組みで行われ、プラグイン開発者が意図しないタイミングで新しい翻訳が配信されることがある。GTranslate のように多言語対応が複雑なプラグインは、管理画面から該当プラグインの自動更新をオフにし、公式のアップデート告知を確認してから手動更新する運用が安全だ。

エラーログを定期的にチェックする習慣をつける

今回のエラーは /wp-content/debug.log に記録されていた。WordPress のデバッグモード（wp-config.php に define('WP_DEBUG', true); と define('WP_DEBUG_LOG', true); を記述）を有効にしておけば、管理画面が停止する前にエラーの予兆をログでキャッチできる。本番運用時は WP_DEBUG_DISPLAY を false にして、エラーを画面に表示せずログだけに留める設定が推奨される。

よくある質問

他プラグインでも同じエラーは起きるのか

起きる。翻訳ファイルに不完全な sprintf() 指定子が混入する不具合は、どのプラグインでも発生しうる。管理画面が突然停止した場合、エラーログに “Unknown format specifier” と書かれていれば翻訳ファイルを疑うとよい。

FTP が使えない場合はどうすればいいか

契約しているレンタルサーバーの管理パネル（cPanel やコンパネ）にログインし、ファイルマネージャーを使う。GTranslate プラグインフォルダのリネーム操作はブラウザ上で完結する。

GTranslate の代わりに別の翻訳プラグインに乗り換えるべきか

このエラーは翻訳ファイルの一時的な不備であり、プラグイン自体の根本的な欠陥ではない。公式の修正が配信されれば再発リスクは下がる。すでに設定済みの翻訳データがあるなら、急いで乗り換える必要はない。

エラーが解消したあと、古い翻訳ファイルを戻す必要はあるか

退避しただけの場合は、GTranslate の次回アップデート時に正しい翻訳ファイルが再配信される。手動で戻す必要はない。削除した場合も同様に、アップデートや翻訳の再読み込みで自動的に復元される。

この記事のポイント

  • GTranslate の翻訳ファイル破損が原因で管理画面が重大エラー停止する
  • 復旧には FTP でプラグインフォルダをリネームし強制無効化する
  • 誤った sprintf 指定子を修正し .mo ファイルを削除または再生成する
  • 暫定策として問題の言語ファイルを退避させる方法も有効
  • エラーログの定期チェックと自動更新の一時停止で再発を予防できる
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
WP Event Manager Calendarで致命的エラーが出た時の原因と直し方
2026年7月8日 0

WP Event Manager Calendarで致命的エラーが出た時の原因と直し方

WP Event Manager Calendarを有効化すると「Call to undefined function get_event_manager_template()」という致命的なエラーが表示される場合、本体プラグインであるWP Event ManagerとCalendarアドオンのバージョンに互換性の問題が生じている。両方のプラグインを最新版に揃え、それでも直らなければ子テーマのfunctions.phpで関数を一時的に手動定義することで回避できる。

なぜWP Event Manager Calendarでエラーが出るのか

このエラーの根本原因は、アドオンプラグインが呼び出すget_event_manager_template()という関数が、本体のWP Event Manager側で削除されたか、名称変更されていることにある。もともとこの関数は、イベントデータの表示やカレンダー画面の生成を担うテンプレートを読み込むための重要な役割を持っていた。

Calendarアドオンがバージョン3.2.2の時点では問題なく動作していたことから、3.2.2とそれ以降の本体プラグインとの間で、関数の定義に何らかの変更が加えられたと考えられる。ところがアドオン側がその変更に追随しておらず、最新の3.4.0でもエラーが解消されていない状態だ。

WordPressでは、依存関係にあるプラグイン同士のバージョン管理はプラグイン開発者に委ねられている。片方だけ更新したり、互換性の確認を怠ったりすると、今回のように未定義の関数呼び出しによる「Fatal error」が発生し、管理画面に「このサイトで重大なエラーが発生しました」と表示される。

エラーメッセージを正確に特定してデバッグモードを有効にする方法

エラーメッセージを正確に特定してデバッグモードを有効にする方法

エラーが発生するとWordPressは「このサイトで重大なエラーが発生しました」という画面を表示し、管理画面にもアクセスできなくなるケースが多い。まずはエラーの詳細を正確に把握するため、WP_DEBUGモードを有効にしよう。

FTPクライアントやサーバーのファイルマネージャーで、WordPressインストールディレクトリにあるwp-config.phpを開く。次の記述を探し、それぞれtrueに変更する。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG_DISPLAYをfalseにすることで、エラーが画面に表示されるのを防ぎつつ、/wp-content/debug.logにログが出力される。このログファイルを確認すれば、先ほどのCall to undefined function get_event_manager_template()と、どのファイルの何行目でエラーが起きたかを正確に特定できる。

WP Event Manager本体とCalendarアドオンの互換性を確保する手順

WP Event Manager本体とCalendarアドオンの互換性を確保する手順

ここでは、エラーを解消するための具体的な手順を4つのステップに分けて示す。まずは基本となるプラグインの全更新から始め、それでも解決しない場合の暫定対応までを押さえる。

STEP 1 WP Event Manager（本体）を最新バージョンに更新する
↓
STEP 2 WP Event Manager Calendarを最新版に更新する
↓
STEP 3 全プラグインを無効化し、キャッシュをクリアして動作確認
↓
STEP 4 子テーマのfunctions.phpに関数を追加して暫定対応

STEP 1からSTEP 3で環境をクリーンな状態に戻す

まず管理画面の「プラグイン」から、WP Event Manager本体が最新であることを確認する。更新可能な場合は更新を実行する。次にCalendarアドオンも同様に最新に揃える。アドオンの更新が提供されていない場合は、一度無効化と再有効化を試すとキャッシュされた古い依存関係が解消されることがある。

両方のプラグインを最新にしたら、一度すべてのプラグインを無効化してから再度必要なものだけを有効化し、ブラウザのキャッシュやサーバー側のキャッシュ（W3 Total CacheやWP Super Cacheなどを使用中の場合）もクリアする。その上で再度カレンダー機能が正常に動くかをテストする。

STEP 4で不足している関数を手動定義する

すべての更新を終えてもエラーが続く場合、WP Event Manager本体が関数の実装を完全に削除してしまっている可能性が高い。この場合の暫定対応として、子テーマのfunctions.phpに、不足している関数を手動で定義する方法がある。

次のコードは、本体プラグインの過去の実装を参考に、get_event_manager_template()関数を再定義する例だ。子テーマのfunctions.phpの末尾に追加する。

if ( ! function_exists( 'get_event_manager_template' ) ) {
    function get_event_manager_template( $template_name, $args = array(), $template_path = 'wp-event-manager', $default_path = '' ) {
        if ( $args && is_array( $args ) ) {
            extract( $args );
        }
        $located = locate_template( array( $template_path . '/' . $template_name ) );
        if ( ! $located && file_exists( WP_PLUGIN_DIR . '/wp-event-manager/templates/' . $template_name ) ) {
            $located = WP_PLUGIN_DIR . '/wp-event-manager/templates/' . $template_name;
        }
        if ( $located ) {
            include( $located );
        }
    }
}

このコードは、まず関数が存在しないかをfunction_exists()で確認し、存在しなければテンプレートファイルをlocate_template()で探して読み込むという最小限の実装だ。本来のWP Event Managerが提供していた機能のすべてを再現するものではないが、Calendarアドオンが最低限必要とする「テンプレート読み込み」の役割を補い、エラーの発生を抑える効果が期待できる。

ただし、これはあくまで緊急回避策だ。WP Event Managerの内部実装に依存しているため、将来のアップデートでさらに互換性の問題が生じる可能性もある。根本的にはプラグイン開発者による修正を待つか、別のイベント管理プラグインへの切り替えを検討する必要がある。

よくある質問

他のイベント管理プラグインに乗り換えたほうがよいのか

WP Event Managerのエコシステム内で完結したい事情がない限り、乗り換えは有効な選択肢だ。The Events CalendarやEvents Managerなどの代替プラグインは、本体とアドオンの互換性がより厳格に管理されている傾向がある。ただし乗り換えの際はイベントデータのエクスポートとインポートの手間が発生する。

無料版のWP Event Managerでもこのエラーは起こるのか

WP Event Managerには無料のコアプラグインと、有料のアドオンが存在する。Calendarアドオンが有料版でのみ提供されている場合、無料版の本体だけではエラーは発生しない。しかし無料アドオンと併用していて同じエラーが起きる場合は、やはり本体とアドオンのバージョン不一致が原因となる。

他のアドオンも同時に影響を受ける可能性はあるか

get_event_manager_template()はWP Event Managerの複数のアドオンから呼び出される共通関数だった可能性が高い。そのため、Calendar以外のアドオン（登録フォームや検索機能など）でも、同じ「Call to undefined function」エラーが発生するリスクがある。本体の更新後は、使用中のすべてのアドオンを一括で最新バージョンに揃えることが重要だ。

重要なサイトで突然このエラーが出た場合の応急措置は

まずFTPでwp-content/plugins/wp-event-manager-calendarフォルダを一時的にリネームしてCalendarアドオンを無効化し、サイトを正常表示に戻す。その間にデバッグログを確認して原因を特定し、STEP 1からSTEP 3の更新作業を進める。どうしても復旧が急がれる場合は、STEP 4の関数手動定義でエラーを抑え込む。

プラグインを最新にしても直らない場合の最終手段は

WP Event Managerのサポートフォーラムや公式ドキュメントで、同じエラーに関する最新の報告がないか確認する。開発チームが修正版をリリースするまでのつなぎとして、古い安定バージョン（今回のケースでは3.2.2）にロールバックする方法もある。WP Rollbackプラグインを使えば、管理画面から安全に旧バージョンへ戻せる。

この記事のポイント

  • エラーはWP Event Manager本体とCalendarアドオンのバージョン不一致が主因
  • 両方のプラグインを最新版に更新し、キャッシュをクリアして動作確認する
  • WP_DEBUGモードでエラーの正確な発生箇所を特定する
  • どうしても直らない場合は子テーマで関数を手動定義して暫定回避する
  • 根本解決にはプラグイン開発者の修正か代替プラグインへの移行を検討する
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WP Review Slider 更新後にレビュー下に空白ができる原因と直し方
2026年7月8日 0

WP Review Slider 更新後にレビュー下に空白ができる原因と直し方

WP Review Slider を v17.7 から v18.2 に更新した後、レビューの「続きを読む」リンクの下に、折りたたまれているテキストと同じ高さの空白が発生するのは、バージョン 18.2 で導入された高さ制御のスタイルが原因である可能性が高い。テーマの追加 CSS に数行のコードを追加することで即座に解消できる。

なぜバージョン 18.2 でレビュー下に空白が生まれるのか

なぜバージョン 18.2 でレビュー下に空白が生まれるのか

WP Review Slider のバージョン 18.2 では、内部のテンプレート構造や CSS クラスに変更が加えられており、長いレビュー本文の折りたたみ表示を実現するために「最小の高さ」（min-height）や「最大の高さ」（max-height）が明示的に指定されるようになったと推測される。

旧バージョンでは、折りたたまれたテキストは表示領域をまったく取らず、クリック時に要素の高さが伸びるという自然な挙動だった。しかし新バージョンでは、非表示のテキスト部分の高さがあらかじめ確保されてしまい、あたかも「読む前から続きテキストのスペースが空いている」ように空白が生まれる。これは下記の CSS プロパティが影響していることが多い。

  • max-height が実際のテキスト全体の高さに設定されている
  • overflow: hidden が適用されている
  • 折りたたみ用の JavaScript が高さ計算を誤っている

いずれにせよ、テーマの追加 CSS で強制的に高さの挙動を上書きすれば問題は解決する。以下に具体的な手順を示す。

追加 CSS で余白を解消する具体的な手順

追加 CSS で余白を解消する具体的な手順

まず対象となる CSS クラスを特定する必要がある。多くの場合、WP Review Slider が出力するレビュー本文のコンテナには wprs-review-text や review-content といったクラスが付与されている。ブラウザの開発者ツールで余白が生まれている要素を検証し、クラス名を確認しておく。

STEP 1 WordPress 管理画面の「外観」→「カスタマイズ」を開く
↓
STEP 2 「追加 CSS」メニューを選択する
↓
STEP 3 下記 CSS を貼り付けて「公開」をクリック
↓
STEP 4 フロントエンドで空白が消えていることを確認

挿入する CSS コードの基本形

まずは以下のコードを追加 CSS に貼り付ける。クラス名 .wprs-review-content は、実際に使用されているクラス名に読み替える。

/* WP Review Slider の折りたたみ余白を解消 */
.wprs-review-content {
    max-height: none !important;
    overflow: visible !important;
}

上記で改善しない場合は、レビュー全体のコンテナに対して同様の指定を加える。

/* 親コンテナも含めてリセット */
.wprs-review,
.wprs-review-body,
.wprs-review-content {
    max-height: none !important;
    overflow: visible !important;
}

開発者ツールで正確なクラス名を特定する方法

上記の汎用コードで直らない場合は、ブラウザの検証機能を使って問題の要素を直接特定する。

  1. Chrome で該当ページを開き、余白が生まれているレビュー部分を右クリック →「検証」を選択する
  2. 要素パネルで、余白を作っている親コンテナを探す。高さ（height / min-height / max-height）がピクセル単位で指定されている要素が原因だ
  3. その要素に付与されているクラス名を確認する（例: wprs-review-text、review-excerpt など）
  4. 特定したクラス名に対して、上記の max-height / overflow リセットを適用する
✕ Before（v18.2 デフォルト）
レビュータイトル
短い冒頭テキストがここに表示される
続きを読む ↓
← この空白が問題
↓
○ After（CSS 適用後）
レビュータイトル
短い冒頭テキストがここに表示される
続きを読む ↓
空白は表示されない
■ Before（不要な空白が確保されている）　■ After（CSS 適用で自然な表示に）

子テーマを使っている場合の注意点

カスタマイズ画面の「追加 CSS」はテーマのアップデートでも消えないため、最も手軽で安全な方法だ。一方、子テーマの style.css に直接書く場合は、キャッシュのクリアを忘れずに行う。また !important を連発すると保守性が下がるため、どうしても必要な場合に限定して使う方がよい。

根本原因がプラグインの JavaScript にある場合の対処

根本原因がプラグインの JavaScript にある場合の対処

上記の CSS で解決しないケースでは、プラグインの JavaScript が要素の高さを動的に計算し、インラインスタイルとして書き込んでいる可能性がある。

  • ページを読み込んだ直後は空白がないのに、少し時間が経ってから空白が現れる → JavaScript の高さ計算が原因
  • 要素に直接 style=”height: XXXpx” や style=”max-height: XXXpx” が書かれている → CSS の !important でもインラインスタイルを上書きできない場合がある

その場合の選択肢は以下の通り。

選択肢A プラグイン設定内に高さ制御のオプションがあれば、そこで最小値や最大値を無効化する
選択肢B プラグインの開発者に問題を報告する。WP Review Slider Pro の場合は公式サイトの問い合わせフォームから連絡できる
選択肢C 本番環境で急ぎの場合は、旧バージョン（v17.7）に一時的にロールバックする。WP Rollback プラグインを使えば管理画面から安全にダウングレードできる

よくある質問

追加 CSS を書いても全く反映されない場合は？

キャッシュ系プラグインや CDN が原因で、古い CSS が配信され続けている可能性が高い。キャッシュをすべてクリアし、CDN を使用している場合はパージを実行する。また、サーバーレベルのキャッシュ（Varnish や Nginx FastCGI キャッシュ）が有効な場合もあるため、サーバー管理画面も確認する。

クラス名がわからず、どの要素に CSS を当てればいいか特定できない

Chrome の開発者ツールで余白が生まれている箇所を右クリック →「検証」で、その要素がハイライトされる。スタイルパネルを見ると適用されている CSS とセレクタが表示されるため、そのクラス名をコピーして使う。矢印アイコン（要素選択ツール）を使うと、画面上の任意の要素をクリックするだけで対応する DOM ノードにジャンプできる。

WP Review Slider の無料版と Pro 版で挙動は異なるのか

基本的なレビュー表示の仕組みは共通だが、Pro 版ではテンプレートのカスタマイズ機能や追加の表示オプションが存在する。そのため、CSS クラスの名前や構造が Pro 版と無料版で一部異なることがある。クラス名の特定手順は同じなので、上記の方法で正確なセレクタを調べて対応する。

「WP Rollback」で旧バージョンに戻しても問題ないのか

WP Rollback は WordPress 公式ディレクトリで提供されている信頼性の高いプラグインで、指定したバージョンに安全にダウングレードできる。ただし、v18.2 で追加されたデータ構造や設定値がある場合、旧バージョンでは正常に読み取れないこともある。ダウングレード前に必ずサイト全体のバックアップを取得しておくことが重要だ。

この記事のポイント

  • v18.2 で発生するレビュー下の空白は、CSS の max-height または overflow 設定が原因
  • 「追加 CSS」から max-height: none !important; を指定すれば即座に解消できる
  • JavaScript による動的な高さ制御が原因の場合は、プラグイン設定の確認や開発者への報告を検討する
  • クラス名が不明な場合はブラウザの開発者ツールで DOM 構造を直接確認する
  • 急ぎの場合は WP Rollback で v17.7 に戻す選択肢もあるが、事前バックアップが必須
佐々木 太陽
, , , , ,
お悩み・トラブル解決
XMLサイトマップで「XML 宣言はドキュメントの先頭でのみ許可されています」エラーの直し方
2026年7月7日 0

XMLサイトマップで「XML 宣言はドキュメントの先頭でのみ許可されています」エラーの直し方

XMLサイトマップのURLを開いたときに「XML 宣言はドキュメントの先頭でのみ許可されています」というエラーが表示された場合、原因はほぼ確実に出力の先頭に空行や余計な改行が混入していることにある。この症状は、PHPファイルの末尾の閉じタグ ?> のあとの空白や、プラグイン・テーマが意図せず出力した文字がXML宣言より前に現れることで発生する。解決には、サイトのキャッシュを完全にクリアしたうえで、すべてのプラグインを停止し標準テーマに切り替えて原因を切り分け、問題のファイルから不要な空白を取り除く手順を踏む。

なぜXMLサイトマップに「XML 宣言は先頭でのみ許可」エラーが出るのか

なぜXMLサイトマップに「XML 宣言は先頭でのみ許可」エラーが出るのか

XMLサイトマップはブラウザや検索エンジンが読み取る形式で、文書の最初に <?xml version="1.0" encoding="UTF-8"?> という宣言がなければならない。ところが、この宣言よりも前に空白や改行が1文字でも出力されると、パーサーが「XML宣言はドキュメントの先頭でのみ許可されています」という旨のエラーを返す。

WordPress環境では、PHPスクリプトが実行されて最終的なXMLを生成するが、意図しない場所で echo や ?php 外の空白が出力されると、それが先頭に紛れ込む。代表的なのは、テーマの functions.php やプラグインファイルの末尾に閉じタグ ?> を書いたうえでその後に改行が入っているパターンだ。PHPファイルでは閉じタグを省略することが推奨されており、記述すると余計な空白が出力されるリスクが常につきまとう。

❌ エラー状態の出力
← ここに空白行が存在する
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url><loc>https...</loc></url>
</urlset>
↓
✅ 正常な出力
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url><loc>https...</loc></url>
</urlset>
■ エラー状態　■ 正常な状態

この図のように、たった1行の空行がXML宣言の前に置かれるだけでサイトマップ全体がエラーになる。実際に自分のサイトのサイトマップURLを開き、ページのソースを表示（ブラウザの「ページのソースを表示」機能）すると、1行目に空行が入っていないか容易に確認できる。

空白行の混入源を特定する手順

空白行の混入源を特定する手順
STEP 1 キャッシュを完全にクリアする
↓
STEP 2 全プラグインを無効化し標準テーマに切り替える
↓
STEP 3 サイトマップを開きエラーが消えたか確認
↓
STEP 4 原因のプラグインかテーマを特定する

STEP 1 キャッシュを完全にクリアする

まず、キャッシュ系プラグイン（WP Super CacheやW3 Total Cacheなど）のキャッシュをすべて削除する。サーバー側のキャッシュが有効な場合、そちらも管理パネルからクリアする。さらにブラウザのキャッシュも念のため削除しておくと、変更がすぐに反映される。

STEP 2 全プラグインを無効化し標準テーマに切り替える

プラグイン画面からすべてのプラグインを一括で無効化する。その際、SEOプラグイン（Yoast SEOなど）も例外なく停止する。その後、外観→テーマで「Twenty Twenty-Five」など公式の標準テーマを有効化する。この状態がいわゆる「切り分けの初期状態」になる。

もし管理画面にすら入れない障害がある場合は、FTPソフトやレンタルサーバーのファイルマネージャーで /wp-content/plugins/ ディレクトリごとリネームする方法でも一括無効化できる。

STEP 3 サイトマップを開きエラーが消えたか確認する

プラグインを無効にして標準テーマの状態で、Yoast SEOのサイトマップURL（通常 /sitemap_index.xml）にアクセスする。この時点でエラーが消え、正常なXMLが表示されれば、テーマやプラグインのいずれかが原因だと確定できる。

STEP 4 原因のプラグインかテーマを特定する

1つずつプラグインを有効化しながらサイトマップを確認し、エラーが再発するタイミングを探る。エラーが出た時点で最後に有効化したプラグインが原因だ。テーマの場合は、標準テーマで問題が消えた段階で疑いが濃くなる。自作ブロックテーマやカスタムブロックを使っているなら、そのテーマの functions.php に余計な空白がないかも確認しよう。

空白を出力しているファイルを修正する具体的方法

空白を出力しているファイルを修正する具体的方法

原因が特定できたら、実際のPHPファイルを編集して不要な空白を取り除く。典型的な作業は次のとおりだ。

閉じタグ ?> を削除する　PHPファイルの末尾に ?> が記述されていると、その後の改行が出力の先頭に混入する。ファイルの最終行が ?> で終わっている場合は、この閉じタグをまるごと削除する。PHPではファイル末尾の閉じタグが省略可能で、むしろ推奨されていない。削除後に空行が残っていればそれも取り除く。

ファイルの先頭と末尾の空白を確認する　<?php の前や、ファイルの最終行より後ろに空白がないかエディタで確認する。改行やスペースが残っている場合はそれらを削除する。複数の開発者が触るテーマでは、意図せず混入していることが多い。

プラグインやテーマのファイルを直接編集する　FTPクライアントやレンタルサーバーのファイルマネージャー、あるいはWordPress管理画面の「プラグインファイルエディター」「テーマファイルエディター」を使って該当ファイルを開き修正する。編集後は必ず再度キャッシュをクリアしてからサイトマップを確認する。

キャッシュとPHP設定が影響するケース

キャッシュとPHP設定が影響するケース

空白行が混入していなくても、キャッシュが原因でエラーが表示され続けることがある。ページキャッシュがXML出力の古い状態を保持していると、修正後もエラーが消えないように見える。以下の点を必ず実施しよう。

WP Super Cacheなどキャッシュプラグインのキャッシュを完全に削除する

キャッシュプラグインの設定画面にある「キャッシュを削除」「全キャッシュを削除」といったボタンで全データをクリアする。さらに、サイトマップURLにクエリパラメータ（例 ?nocache=1）を付けてアクセスすることでキャッシュを通さずに表示し、エラーの有無を確認できる。

PHPのメモリ制限は256MBあれば十分だが512MBにしても直らない

メモリ不足が原因で似たエラーが出ることはあるが、今回の「XML宣言は先頭のみ」というエラーはメモリとは無関係であることがほとんどだ。実際に256Mから512Mに増やしても改善しなかったという報告も多い。メモリ増加で解決しなかった場合は迷わず空白行の調査に戻る。

よくある質問

サイトマップのエラーが特定の投稿タイプ（例 商品）でのみ発生するのはなぜか

WooCommerceの商品サイトマップなど、特定の投稿タイプだけ別のファイルで生成される場合、その処理を行うプラグインやテーマの該当部分に空白が混入している可能性が高い。原因箇所を特定するには、SEOプラグインが生成する個別のサイトマップURL（product-sitemap.xmlなど）に直接アクセスし、同じ手順で切り分けを行う。

空白行を削除してもエラーが直らない場合に次に試すことは

キャッシュの削除漏れや、サーバー側のVarnishやCDNがXMLをキャッシュしている可能性を疑う。また、wp-config.php ファイルの先頭や末尾に空白が入っているケースも、サイト全体の出力に影響を及ぼすため確認する。さらに、PHPの出力バッファリングが影響している場合もあるが、まずは wp-config.php まで含めた全ファイルの空白確認を徹底する。

Health Checkトラブルシューティングプラグインは役に立つのか

Health Check & Troubleshootingプラグインは、管理画面からセッションベースでプラグインの停止やテーマの切り替えを安全に行えるため、切り分け作業を効率化できる。有効化して「トラブルシューティングモード」に入れば、他の訪問者には影響を与えずにテストできる。ただし、空白行の直接の修正までは行わないため、あくまで原因特定の補助ツールとして使う。

Yoast SEOのXMLサイトマップキャッシュを個別にクリアする方法は

Yoast SEOはサイトマップの生成結果をキャッシュしないが、外部のキャッシュプラグインと競合することがある。Yoast SEO側で直接キャッシュをクリアする機能はないため、前述のようにサイト全体のキャッシュを削除し、可能ならSEOプラグインを一度無効化してから再度有効化すると、内部のトランジェントが更新されて問題が解消されることもある。

オリジナルブロックテーマを使っているが、どこに注意すればよいか

ブロックテーマでは functions.php の末尾に空白が入っていないか、そしてカスタムブロックのプラグインとしてのPHPファイル（ブロックの動的レンダリング部分）に閉じタグ ?> と空白が残っていないかを必ずチェックする。自作ブロックは開発時にテストを繰り返すため、ファイル末尾の処理が甘くなりがちで、意外な場所から空白が出力されることがある。

この記事のポイント

  • エラーの直接原因はXML宣言より前に出力された空白行か改行である
  • キャッシュを完全にクリアし、全プラグイン無効化と標準テーマ切り替えで切り分ける
  • PHPファイル末尾の閉じタグ ?> とその後ろの空白を削除する
  • wp-config.php の先頭・末尾や自作テーマのファイルも忘れずに確認する
  • メモリ増加ではこのエラーはまず直らないため空白行調査に集中する
佐々木 太陽
, , , , ,
お悩み・トラブル解決
Yoast SEOが原因でWordPress 7.0の編集画面が読み込めない時の対処
2026年7月6日 0

Yoast SEOが原因でWordPress 7.0の編集画面が読み込めない時の対処

WordPress 7.0 の編集画面で、改訂（リビジョン）を視覚的に比較できる新機能が使えなくなったり、iFrame 版エディターの読み込みに問題が出るケースがある。これは、Yoast SEO のクラシックメタボックスが存在すると、WordPress 7.0 が新機能を意図的に無効化する仕様になっているためだ。Yoast SEO の設定を残したまま問題を回避したい場合は、該当の投稿タイプに対して Yoast SEO のメタボックスを設定からオフにすればよい。

なぜ Yoast SEO が有効だと WordPress 7.0 の新エディター機能が使えなくなるのか

なぜ Yoast SEO が有効だと WordPress 7.0 の新エディター機能が使えなくなるのか

WordPress 7.0 では、ブロックエディターが iFrame 版に移行し、改訂の比較画面がこれまでより直感的な UI に変更された。ところが、Yoast SEO に限らず、ひとつでもクラシックメタボックスが有効な状態だと、WordPress はこれらの新機能を自動的にオフにして旧来の改訂画面にフォールバックする。これは WordPress の意図的な挙動であり、Yoast SEO 単体のバグや不具合ではない。

クラシックメタボックス経由で保存された値（SEO タイトルやメタディスクリプションなど）は、現状の仕組みでは改訂を復元する際に正しく戻せない。そのため、互換性を保証できないメタボックスがある場合は、改訂のビジュアル比較のような高度な機能をまるごと制限する方針がとられている。

全メタボックスをコードで削除する対処がおすすめできない理由

全メタボックスをコードで削除する対処がおすすめできない理由

一部のユーザーは do_meta_boxes フックを使って投稿画面からメタボックスをすべて除去するコードを導入しているが、この方法には大きな副作用がある。公開ボックスだけを残して他の全メタボックスを削除してしまうため、Yoast SEO の SEO 設定が編集画面から消えるだけでなく、入力した値が保存されなくなる。結果として、検索エンジン向けの重要な情報が失われてしまう。

さらに、他のプラグインが提供するメタボックスも同時に削除されるため、カスタムフィールドや追加の設定パネルが一斉に使えなくなり、サイトの運用に支障をきたす可能性が高い。

Yoast SEO の SEO 設定を残したまま問題を解決する手順

Yoast SEO の SEO 設定を残したまま問題を解決する手順

Yoast SEO の開発チームは、特定の投稿タイプでのみ SEO コントロールを無効にする標準的な方法を用意している。この手順を使えば、他の投稿タイプには影響を与えず、該当の編集画面でのみ Yoast SEO メタボックスを非表示にできる。

ただし、現時点ではメタボックスを無効にすると、Yoast SEO の SEO タイトルやメタディスクリプションといった設定欄そのものが編集画面から消える点に注意が必要だ。編集画面のサイドバーにある Yoast SEO のパネルは、内部でメタボックスに依存しているため、メタボックスをオフにするとサイドバーも機能しなくなる。

STEP 1 WordPress 管理画面の左メニューから「Yoast SEO」→「設定」を開く
↓
STEP 2 「コンテンツタイプ」タブを選択し、対象の投稿タイプ（投稿、固定ページ 等）を見つける
↓
STEP 3 「SEO コントロールとアセスメントを有効にする」のトグルをオフにして変更を保存する

この設定変更は該当の投稿タイプにのみ適用され、他の投稿タイプでは引き続き Yoast SEO の全機能を利用できる。もし WordPress 7.0 の新エディター機能をどうしても優先したい場合の現実的な手段といえる。

メタボックスを非表示にした後、SEO 設定はどこで操作するのか

メタボックスを非表示にした後、SEO 設定はどこで操作するのか

この問題について Yoast チームは、現在メタボックスに依存している構造を刷新する作業を進めていると明かしている。将来的には、メタボックスをオフにしてもサイドバーから SEO 設定を操作できるようになる見込みだが、現時点では具体的な対応時期は公表されていない。

また、WordPress 7.1 で導入が検討されているリアルタイム共同編集機能への対応についても、Yoast チームは前向きな姿勢を示している。しかし、多数のアドオンが複雑に連携するエコシステム全体との互換性を保つ必要があるため、拙速なリリースは避け、慎重に開発を進めている段階だ。

一時的な回避策としてメタボックスを残しつつ運用するには

一時的な回避策としてメタボックスを残しつつ運用するには

SEO 設定を引き続き編集画面で操作したい場合、現時点では Yoast SEO のメタボックスを有効にしたまま、WordPress 7.0 の新改訂機能を使わずに従来の改訂画面で作業を続けることになる。これは不具合ではなく WordPress の設計上の制限であるため、Yoast SEO 側のアップデートを待つのが最も安全な対応といえる。

よくある質問

Yoast SEO 以外のプラグインでも同じ現象は起きるのか

起きる。クラシックメタボックスを提供しているプラグインであれば、どのプラグインでも同様の理由で WordPress 7.0 の新エディター機能が制限される。特定のプラグインに限った問題ではない。

設定をオフにした投稿タイプの SEO データは消えてしまうのか

保存済みの SEO タイトルやメタディスクリプションなどのデータが削除されることはない。設定を再度オンにすれば、以前のデータはそのまま復帰する。

コードで特定のメタボックスだけを削除することは可能か

技術的には可能だが、公式に推奨されている方法ではない。Yoast SEO の内部構造に依存するため、アップデートで動作しなくなるリスクが高い。どうしてもコードで対処する場合は、上書きした設定が保存されなくなる副作用を十分に理解したうえで行う必要がある。

この問題は Yoast SEO のアップデートで解決されるのか

Yoast チームはメタボックスへの依存を解消する改修を進めている。時期は未定だが、いずれはメタボックスを無効にしてもサイドバーから全機能を利用できるようになる予定だ。

この問題は WordPress 6.7 以前のバージョンでも発生するのか

発生しない。WordPress 7.0 で新たに導入された仕様であり、6.7 以前のバージョンではクラシックメタボックスが存在していても改訂機能が制限されることはない。

この記事のポイント

  • WordPress 7.0 で Yoast SEO のメタボックスが原因となり新エディター機能が制限されるのは、WordPress の意図的な仕様である
  • 全メタボックスをコードで削除する対処は SEO 設定の消失を招くため推奨されない
  • Yoast SEO の設定画面から特定の投稿タイプの SEO コントロールをオフにすることで問題を回避できる
  • メタボックスをオフにすると SEO 設定欄そのものが使えなくなる点に注意が必要
  • Yoast チームはメタボックス依存の解消を進めており、将来的には問題が根本的に改善される見込み
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WordPressのAllowed memory size exhaustedエラーの原因と直し方
2026年7月5日 0

WordPressのAllowed memory size exhaustedエラーの原因と直し方

WordPressの「Allowed memory size exhausted」エラーは、サーバーに十分な物理メモリがあっても発生する。64GBの専用サーバーで起こるのは、PHPのメモリ上限設定が実際の要求量を下回っているか、特定のプラグインやテーマがバグで際限なくメモリを消費し続けているからだ。まずは設定値の引き上げを試み、それで直らなければログから原因箇所を特定し対処する。

十分な物理メモリがあるのにエラーが起こる仕組み

十分な物理メモリがあるのにエラーが起こる仕組み

多くのレンタルサーバーはPHPのmemory_limitを128MBや256MBに設定している。WordPress本体や軽量なプラグインだけであればこの値で動作するが、WooCommerceの大規模ショップやページビルダー、画像処理、バックアップ系の処理が走ると一瞬で上限を突破する。コンソールに表示される「PHP Fatal error」の文言は、まさにその設定上限を突破したという意味だ。

さらに問題をややこしくしているのが、専用サーバーやVPSと「PHPの設定」の関係だ。64GBの物理メモリを搭載していても、PHPが使えるメモリ上限はOS全体の値ではなく、あくまでphp.iniやwp-config.phpなどで個別に定義された数値が優先される。ハードウェアとソフトウェアの上限は別物だと理解しておく必要がある。

具体的なメモリ上限の引き上げ手順

具体的なメモリ上限の引き上げ手順

最も確実で直接的な方法はwp-config.phpファイルに一行追記することだ。FTPソフトやサーバーのファイルマネージャーでWordPressをインストールしたルートディレクトリにあるwp-config.phpを開き、次のコードを追記する。記述する場所は「/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */」という行の直前が望ましい。

Before（修正前）
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');
↓
After（修正後）
define('WP_MEMORY_LIMIT', '512M');
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

ここでは512MBを指定している。256MBで発生したエラーへの対応としては、まず256MBの2倍にあたる512MBを設定するのがセオリーだ。どうしても足りなければ1024M（1GB）や2048M（2GB）といった思い切った値も試して問題ないが、上限を上げすぎるとプログラムの暴走時にサーバー全体が重くなるリスクもある点は覚えておきたい。

サーバー側のphp.iniや.htaccessで設定を上書きする

共用サーバーではwp-config.phpへの追記だけで解決するケースがほとんどだが、VPSや専用サーバーではもっと根本の設定を見直したほうがいい。php.iniファイルを直接編集できる環境なら、memory_limit = 512Mと指定する。編集権限がない場合は.htaccessにphp_value memory_limit 512Mを追記する方法もあるが、最近のPHPハンドラではこの形式が無効化されている場合がある。

メモリ上限を上げても直らない時の根本原因特定

メモリ上限を上げても直らない時の根本原因特定

メモリ上限を1GBなど潤沢な値に変更してもなお同じエラーが出るなら、特定のプラグインかテーマが無限ループやメモリリークを引き起こしている可能性が高い。質問の事例のように「worker」プラグイン（管理用バックアップツールの類）が409MBものメモリ割り当てに失敗しているなら、それはプラグインが実質的に処理不可能な大規模データを扱っているか、プラグイン自体のバグだ。

管理画面に入れなくても全プラグインを安全に止める方法

エラーが深刻でWordPress管理画面にアクセスできない時は、FTPやSSHで/wp-content/plugins/ディレクトリのフォルダ名を一時的に変更する。例えば「plugins」を「plugins_deactivate」にリネームすると、全プラグインが強制停止されて管理画面にアクセスできる状態に戻せる。エラーがこのタイミングで消えたのなら、停止したプラグイン群に原因がある。

STEP 1 FTPでサーバーに接続し、/wp-content/へ移動する
↓
STEP 2 「plugins」フォルダを「plugins_deactivate」にリネームする
↓
STEP 3 管理画面へアクセスし「プラグイン」を見ると、すべて停止を確認できる
↓
STEP 4 原因の心当たりがあるプラグインだけフォルダ名を元に戻し、有効化して検証する
■ 安全な停止手順

エラーログに記録された具体的なファイル名を手がかりにする

エラーログには「/wp-content/plugins/worker/src/MWP/Http/JsonResponse.php on line 21」のように、エラーを起こしているファイルと行番号が出力される。これはまさに問題のプラグインの内部コードだ。この情報を元に該当プラグインだけを停止し、それでも状況が変わらなければそのプラグインの公式サポートに報告するか、代替のプラグインを検討する。

またWordPressには「サイトヘルス」機能が標準搭載されており、管理画面にアクセスできれば「ツール」→「サイトヘルス」→「情報」タブ内でメモリ上限の現在値が確認できる。FTPで原因プラグインを停止させたら、ここで上限値が意図した通りに変更されているかも併せてチェックしておくと確実だ。

よくある質問

256MBで運用していたが、なぜ急にこのエラーが出たのか

プラグインやテーマのアップデートでコードの処理方式が変わり、消費メモリが増えた可能性が高い。またWooCommerceの商品登録数が増えたり、データベースの肥大化によって1回のクエリで扱うデータ量が閾値を超えたことも原因に挙げられる。

メモリ上限の設定が反映されているか確認する方法は

管理画面の「サイトヘルス」で確認するのが最も簡単だ。あるいは、ルートディレクトリにinfo.phpを作成しphp phpinfo();と記述してブラウザでアクセスする。表示された一覧の中の「memory_limit」の値を見れば、現在の上限が分かる。

プラグイン停止でデータは消えないのか

プラグインのフォルダ名を変更して停止するだけでは、データベースに保存された設定やコンテンツは一切消失しない。単にWordPressがそのプラグインを読み込まなくなるだけなので、フォルダ名を元に戻せば全く同じ状態で再開できる。

512MBまで上げたが足りるか心配だ

一般的なWordPressサイトであれば512MBで十分だが、複数の重量級プラグインが稼働する大規模サイトでは1GBを超える設定が必要になることもある。ただし上限が高すぎるとPHPプロセスがメモリを解放しないまま滞留するリスクもあるため、原因プラグインの特定を優先するのが安全だ。

この記事のポイント

  • PHPのメモリ不足エラーは物理メモリとは別の設定値で起こる
  • まずはwp-config.phpにWP_MEMORY_LIMITを定義して上限を引き上げる
  • 512MBに引き上げても直らないなら、プラグインのバグを疑う
  • 管理画面に入れない時はFTPでプラグインフォルダをリネームして強制停止する
  • エラーログに書かれたファイルパスから原因のプラグインを狙い撃ちする
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WordPressのアコーディオンブロックが開かない原因と直し方
2026年7月5日 0

WordPressのアコーディオンブロックが開かない原因と直し方

WordPress 6.9のアコーディオンブロックをクリックしても展開しない場合は、ページ読み込み時にブロックのJavaScriptが正しく初期化されていないことが原因だ。キャッシュを完全に削除し、プラグインの競合を確認することで大半のケースは解決する。改善しない場合はテーマの読み込み順を調整する。

なぜアコーディオンブロックが展開しないのか

なぜアコーディオンブロックが展開しないのか

この現象は、アコーディオンブロックの内部で使われる view.min.js が、ページの読み込み完了前にクリックイベントを受け取ってしまうことで起きる。具体的には、ブロックの状態（開閉のデータ）がまだ存在しないタイミングで「開く」処理が実行され、「未定義のプロパティを読めない」というTypeErrorが発生するという仕組みだ。

読み込み速度が極端に速い場合も、逆に特定のスクリプトが遅延して遅くなった場合も、内部のタイミングがずれて初期化が完了しないまま操作できてしまう。Twenty Twenty-Fiveテーマに限らず、他のテーマやプラグインがページの読み込み順を変えていると同様の症状が出ることがある。

■ エラー発生時の状態
ページ読み込み → アコーディオンブロックのJS読み込みが完了する前 → ユーザーがクリック → c が undefined → エラー
↓
■ 正常な状態（修正後）
ページ読み込み → JSの初期化が完全に終わる → クリック可能 → 開く／閉じるが動作
■ エラー状態　■ 修正後

JavaScriptエラーの原因を開発者ツールで確認する方法

まずエラーが出ているか正確に把握する。ChromeやEdgeのデベロッパーツール（F12キー）を開き、Consoleタブを確認する。該当ページでアコーディオンをクリックした瞬間に赤いエラーメッセージが出ていれば、今回の症状に合致する。

エラー文は日本語環境でも英語で「Uncaught TypeError: Cannot read properties of undefined (reading ‘isOpen’)」と表示される。ファイル名に view.min.js が含まれていれば、WordPress 6.9の標準アコーディオンブロックの初期化問題だと特定できる。

アコーディオンが開かない場合の5つの対処法

アコーディオンが開かない場合の5つの対処法

以下の手順は、簡単で効果が高いものから順に並べている。1つずつ試し、改善した時点で後続の手順は不要だ。

STEP 1 サイト全体のキャッシュを削除する
↓
STEP 2 プラグインをすべて無効化する
↓
STEP 3 テーマをTwenty Twenty-Fiveのままでリセットする
↓
STEP 4 子テーマのfunctions.phpでスクリプト読み込み順を調整する

サイト全体のキャッシュを完全に削除する

キャッシュ系プラグイン（W3 Total CacheやWP Super Cacheなど）を導入している場合は、管理画面から全キャッシュを削除する。加えてサーバー側のキャッシュ（NGINX FastCGI CacheやLiteSpeed Cache）もクリアする。ブラウザキャッシュを個別に消すよりも、プラグインやサーバー管理パネルからの一括削除のほうが確実だ。

全プラグインを無効化して原因を特定する

プラグインのいずれかがJavaScriptの読み込み順やタイミングに干渉している可能性がある。「プラグイン」→「インストール済みプラグイン」からすべてのプラグインを一時的に無効化し、アコーディオンブロックの動作を確認する。問題が解消したら、1つずつ有効に戻していき、再発するプラグインを特定する。

この方法で原因プラグインが判明した場合、そのプラグインの代替を探すか、開発元に修正を依頼するのが現実的だ。特にJavaScriptを多用するページビルダーや最適化系プラグインは干渉しやすいので注意する。

テーマの状態をリセットする

子テーマやカスタマイズを行っている場合は、一時的に親テーマのTwenty Twenty-Fiveに直接切り替える。必要に応じて「外観」→「テーマ」から親テーマを有効化し、カスタマイザーで追加した独自のCSSやJavaScriptが干渉していないか切り分ける。

functions.phpでスクリプト読み込み順を調整する

上記の手順で解決しない場合、テーマやプラグインの読み込み順が影響している可能性が高い。子テーマの functions.php に以下のコードを追加し、WordPress標準のスクリプトをより早い段階で読み込ませる方法が有効だ。

<?php
function force_accordion_script_priority() {
    if ( has_block( 'core/accordion' ) ) {
        wp_enqueue_script( 'wp-block-library' );
        // モジュールスクリプトの読み込みを優先
        add_filter( 'script_loader_tag', function( $tag, $handle ) {
            if ( false !== strpos( $handle, 'accordion' ) ) {
                $tag = str_replace( 'defer', '', $tag );
            }
            return $tag;
        }, 10, 2 );
    }
}
add_action( 'wp_enqueue_scripts', 'force_accordion_script_priority', 5 );

このコードは、アコーディオンブロックがページ内に存在する場合にだけ動作し、defer 属性を除去して読み込みの優先度を上げる。極端な遅延読み込みが原因でエラーが起きている場合に効果を発揮する。

そもそもこのエラーが起きる条件とは

そもそもこのエラーが起きる条件とは

このエラーはWordPress 6.9の標準ブロックに含まれる view.min.js のタイミング依存が直接の原因だ。以下のような条件が重なると発生しやすい。

  • 高速なサーバー環境やCDNによってHTMLの描画が極端に速い
  • 最適化プラグインがスクリプトに defer や async を追加している
  • ページビルダーが独自の方法でスクリプトを結合・遅延読み込みしている
  • カスタムテーマが wp_head() や wp_footer() を正しく呼び出していない

いずれも、WordPressが想定するスクリプトの読み込み順序が変更されることで、ブロックの状態管理オブジェクトが生成される前にクリックイベントのリスナーが機能し始めてしまう点で共通している。

再発を防ぐための設定ポイント

再発を防ぐための設定ポイント

この問題を恒久的に避けるには、スクリプト最適化の設定を見直すのが最も効果的だ。キャッシュプラグインや高速化プラグインの「JavaScriptの遅延読み込み」「結合」「minify」などの機能を無効化するか、該当ブロックだけ除外設定を追加する。

具体的には、プラグインの設定画面で「遅延読み込みの除外」に view.min.js または accordion を含むパスを指定する。多くの高速化プラグインでは、特定のスクリプトハンドルやファイル名を除外リストに登録できる。

また、WordPressのアップデートによってコア側の修正が入る可能性も高い。そのため、WordPress本体とテーマは常に最新の状態を維持し、修正が公式にリリースされ次第適用することも大切だ。

よくある質問

特定のブラウザだけで起きるのか

いいや、ブラウザの種類よりもページの読み込み速度やスクリプトの実行順序に左右される。Chrome、Edge、Firefox、Safariのいずれでも発生しうる。特定のブラウザだけで再現する場合は、ブラウザ拡張機能の影響も疑うとよい。

プラグインをすべて無効にしても直らない場合は

テーマに原因がある可能性が高い。一度Twenty Twenty-Fiveの親テーマを直接有効化し、それでも改善しなければサーバー側のキャッシュ機構やCDNの設定を見直す。functions.phpに追加したカスタムコードが干渉しているケースもある。

キャッシュをクリアしても改善しないときの次の手順は

ブラウザのシークレットウィンドウでテストし、ブラウザキャッシュを完全に排除した状態で確認する。それでも同じエラーが出るなら、上記のSTEP 4のコード追加を試すか、WordPress本体の再インストールを検討する。

このエラーはWordPressのバグなのか

厳密にはタイミング依存のバグであり、WordPress 6.9に標準で含まれる view.min.js に起因する。今後のアップデートで修正される見込みだが、現時点ではサーバー環境やプラグイン構成によって発生が左右されるため、回避策を講じるのが現実的だ。

テーマ側で何かできることはあるか

ある。先述のfunctions.phpによる defer 属性の除去のほか、テーマが wp_footer() の直前に不要なスクリプトを挿入していないか確認することも有効だ。シンプルなテーマほどこの問題は起こりにくい。

この記事のポイント

  • アコーディオンが開かない原因はJavaScript初期化のタイミングずれ
  • キャッシュの全削除とプラグイン全無効化でほぼ修正できる
  • 改善しなければfunctions.phpでスクリプト優先度を上げる
  • 最適化プラグインの設定で view.min.js を除外登録する
  • WordPress本体とテーマは常に最新版を保つ
佐々木 太陽
, , , , ,
お悩み・トラブル解決
GiveWPアップデート後にStripeの寄付が完了しない原因と直し方
2026年7月5日 0

GiveWPアップデート後にStripeの寄付が完了しない原因と直し方

Stripeの決済は成功しているのにGiveWPで寄付が「完了」にならない。管理画面に寄付データが作成されず、Webhookだけが延々と失敗し続ける。この症状は、GiveWP 4.16のアップデート後にStripeから送られてくるWebhookの中身が空（null）になっていることが原因だ。PHPの致命的エラー「array_keys(): Argument #1 ($array) must be of type array, null given」が記録されているならなおさらで、GiveWPがイベントデータを正しく読み取れていない。

対処の核心はGiveWPとStripeの接続を完全に再確立し、Webhookの登録から正しくやり直すことにある。加えて、サーバー側のキャッシュがWebhookの受信を阻害しているケースも多いため、キャッシュの全削除とWebhookエンドポイントの除外設定が必要だ。

なぜStripeの決済は成功するのにGiveWPの寄付は未完了になるのか

なぜStripeの決済は成功するのにGiveWPの寄付は未完了になるのか

この問題のややこしい点は、Stripe上では決済が正常に完了して見えることだ。PaymentIntentのステータスは「succeeded」になり、クレジットカードの引き落としも問題なく行われる。しかしGiveWP側では寄付レコードが作成されず、寄付者にも完了メールが届かない。

仕組みをたどると、GiveWPは次の流れで寄付を確定させている。

① 寄付者がフォームで決済を実行
Stripeがクレジットカード情報を処理し、PaymentIntentが作成される
↓
② StripeがWebhookをGiveWPのエンドポイントに送信
エンドポイントURLの例 https://example.com/?give-listener=stripe
↓
③ GiveWPがWebhookを受け取り、署名を検証
署名検証に成功するとイベントデータを内部処理に回す
↓
④ GiveWPが寄付レコードを作成し、ステータスを「完了」に変更
寄付者に完了メールが送信される

この流れのうち、手順③の段階でコケているのが今回の症状だ。StripeからのWebhookはGiveWPのエンドポイントに届いているのに、GiveWPがその中身を処理できない。結果として手順④に進めず、寄付は永遠に「処理中」のまま取り残される。

「array_keys null given」エラーが示す根本原因

「array_keys null given」エラーが示す根本原因

GiveWPのデバッグログに次のような致命的エラーが記録されている場合、原因の特定はかなり絞り込める。

Uncaught TypeError: array_keys(): Argument #1 ($array) must be of type array, null given
in vendor/stripe/stripe-php/lib/StripeObject.php

このエラーは、GiveWPがStripeの公式PHPライブラリ（stripe-php）を使ってWebhookイベントのデータを読み取ろうとしたとき、肝心のイベントオブジェクトの中身がnullになっていることを意味する。本来なら配列として渡されるべきデータが空っぽなのだ。

なぜデータが空になるのか。主な原因は次の3つに集約される。

  • GiveWPのアップデートで内部のWebhook処理ロジックが変わり、既存の接続設定との整合性が崩れた
  • サーバーレベルのキャッシュ（LiteSpeedやホスティング側のキャッシュ）がWebhookリクエストを変形させている
  • StripeダッシュボードのWebhook設定とGiveWPが自動管理する署名シークレットとの間にずれが生じている

4.16より前のバージョンではWebhookのデータ取得方法が異なっていた可能性があり、アップデートによって従来の接続状態に不整合が発生したと見るのが自然だ。事実、GiveWP 4.16がリリースされる直前の6月23日までは正常に動作していたという報告は、この仮説を裏付けている。

GiveWPとStripeの接続を完全に再確立する手順

GiveWPとStripeの接続を完全に再確立する手順

部分的な修正では直らない。GiveWPとStripeの間の信頼関係をゼロから組み直すつもりで、以下の手順を上から順に実行する。

STEP 1 GiveWPを最新バージョンに更新する
4.16.0で問題が発生した場合も、まず4.16.1以降への更新を試みる。GiveWPは不具合修正を迅速にリリースすることが多い。
↓
STEP 2 GiveWP管理画面でStripeとの接続を解除する
「寄付」→「設定」→「支払いゲートウェイ」→「Stripe」から「接続を解除」を実行する。
↓
STEP 3 StripeダッシュボードのWebhookを完全に削除する
Stripeダッシュボードの「開発者」→「Webhook」から、GiveWP用のエンドポイントをすべて削除する。古いものや重複しているものも含めて、すべて消す。
↓
STEP 4 WordPressのキャッシュをすべて削除する
プラグインキャッシュ、サーバーキャッシュ（LiteSpeed等）、ホスティングキャッシュの3層すべてをクリアする。キャッシュ系プラグインを一時的に無効化してもよい。
↓
STEP 5 GiveWPでStripeに再接続する
「寄付」→「設定」→「支払いゲートウェイ」→「Stripe」から「Stripeと接続」を実行し、Stripeの認証画面で許可する。
↓
STEP 6 Webhookが自動再作成されるのを確認する
GiveWPが再接続時にStripeへWebhookエンドポイントを自動登録する。StripeダッシュボードのWebhook一覧を開き、新しいエンドポイントが作成されていること、必要なイベントが有効になっていることを確認する。

GiveWP管理画面でのStripe接続解除と再接続の落とし穴

接続解除ボタンを押しても、内部的に完全にクリーンアップされるとは限らない。GiveWPは接続情報をデータベースのoptionsテーブルに保存しているため、万が一解除がうまくいかない場合は、データベースを直接確認する方法も検討する。

再接続時は必ず本番モードで認証を通すこと。テストモードで接続したあとに本番モードに切り替えても、Webhookエンドポイントはテスト用のものが残ったままになり、本番決済のWebhookが正しく処理されない原因になる。

Stripe Webhookエンドポイントに必要なイベントを確認する

GiveWPが自動登録するWebhookには、以下の8つのイベントが最低限有効になっている必要がある。Stripeダッシュボードでエンドポイントを開き、「受信イベント」欄を目視で確認する。

  • charge.refunded（返金処理）
  • checkout.session.completed（チェックアウトセッション完了）
  • customer.subscription.created（定期寄付の作成）
  • customer.subscription.deleted（定期寄付の削除）
  • invoice.payment_failed（請求書の支払い失敗）
  • invoice.payment_succeeded（請求書の支払い成功）
  • payment_intent.payment_failed（支払い意図の失敗）
  • payment_intent.succeeded（支払い意図の成功）

いずれかが欠けている場合は手動で追加する。GiveWPがイベントを自動追加する仕様はバージョンによって変わるため、再接続後に必ず確認する習慣をつけるとよい。

キャッシュがWebhookを壊す仕組みと確実な対処

キャッシュがWebhookを壊す仕組みと確実な対処

Webhookはサーバー間のHTTP POSTリクエストだ。ところが一部のキャッシュプラグインやホスティング側のキャッシュ機構は、このPOSTリクエストに対して予期せぬ挙動を示す。具体的には、リクエストボディを空にしたり、ヘッダー情報を削除したり、レスポンスをキャッシュしてしまったりする。

GiveWPが正しく署名を検証し、イベントデータを読み取るためには、StripeからのPOSTリクエストが一切加工されずに届かなければならない。次の対応を必ず実施する。

Before（キャッシュがWebhookを加工している状態）
Stripe → キャッシュを通過 → リクエストボディが変形・空になる → GiveWPが処理失敗
After（キャッシュからWebhookエンドポイントを除外した状態）
Stripe → キャッシュをバイパス → リクエストボディが完全なまま届く → GiveWPが正常に処理
■ キャッシュがリクエストを加工している状態　■ キャッシュから除外した状態

LiteSpeedキャッシュが原因のケース

LiteSpeedサーバー環境では、LiteSpeed Cacheプラグインの設定画面から「キャッシュ」→「除外」タブを開き、「URLの除外」にGiveWPのWebhookエンドポイントパスを追加する。具体的には「give-listener=stripe」を含むURLパターンを指定する。正規表現が使える場合は次のように記述する。

give-listener=stripe

また、LiteSpeedの「オブジェクトキャッシュ」や「ブラウザキャッシュ」も合わせて無効化した状態でテストすることを推奨する。テストが終わったら再度有効化しても問題はないが、少なくともWebhookエンドポイントだけは常にキャッシュの対象外にしておく。

ホスティング側のキャッシュが原因のケース

一部の共用サーバーやマネージドホスティングでは、サーバーレベルでリバースプロキシキャッシュが動作している。管理パネルからキャッシュを手動でクリアしたあと、一時的にキャッシュ機能を停止してWebhookが正常に処理されるかテストする。

恒常的な解決策としては、ホスティングのサポートに依頼して「https://example.com/?give-listener=stripe」をキャッシュの除外リストに追加してもらう必要がある。

署名シークレットの誤設定が引き起こす症状と修正

署名シークレットの誤設定が引き起こす症状と修正

GiveWP 4.16以降、署名シークレットの管理方法が変わり、手動での設定が不要になった。GiveWPがStripeに接続する際、自動的にWebhookエンドポイントを作成し、署名シークレットもGiveWP内部で管理する。そのため、Stripeダッシュボードから取得した署名シークレットをGiveWPの設定画面に入力する欄は存在しない。

もし過去に手動でWebhookを作成し、その署名シークレットを何らかの方法でGiveWPに設定していた場合、バージョンアップ後にその情報が無視されるか、あるいは競合を起こす可能性がある。そのため、手順としては次のように徹底する。

  1. Stripeダッシュボードから古いWebhookをすべて削除する（手動で作成したものも含む）
  2. GiveWP管理画面でStripeとの接続を完全に解除する
  3. GiveWP管理画面でStripeに再接続する（このとき新しいWebhookと署名シークレットが自動作成される）

署名シークレットに関するエラーがStripeダッシュボードに表示されている場合、ほぼ間違いなく新旧のWebhookが混在しているか、手動設定の名残が残っている。上記の手順で完全にリセットすれば、署名検証エラーは解消する。

それでも直らないときの最終確認リスト

それでも直らないときの最終確認リスト

上記の手順をすべて実行しても症状が改善しない場合、以下のポイントを順に再チェックする。

チェック1 サーバーの時刻が大幅にずれていないか
SSL証明書の評価がAランクでもNTPの同期が外れていると署名検証に失敗する。ホスティングに確認する。
チェック2 .htaccessやNginx設定にWebhookを妨害するルールが入っていないか
特定のクエリ文字列をブロックする設定や、POSTリクエストをGETに変換するリダイレクトルールがないか確認する。
チェック3 セキュリティプラグインがWebhookエンドポイントをブロックしていないか
WordfenceやSucuriなどのWAFがStripeのIPを遮断しているケースがある。一時的に無効化してテストする。
チェック4 StripeのAPIバージョンが極端に新しくなっていないか
Stripeダッシュボードの「開発者」→「APIのバージョン管理」で、使用中のAPIバージョンがGiveWPの対応範囲内か確認する。

よくある質問

GiveWPを最新版に更新したあとにStripeのWebhookが失敗し始めた。ロールバックするべきか

ロールバックは推奨しない。4.16系にはWebhook処理まわりの重要な変更が含まれており、古いバージョンに戻すと将来的にStripe APIの更新に追随できず、より深刻な不具合を引き起こす。まずは本記事の再接続手順を試し、それでも解決しない場合はGiveWPのサポートにシステムレポートを送って調査を依頼するほうが安全だ。

StripeのダッシュボードでWebhookが「失敗」と表示されるが、GiveWP側にエラーログが出ない

GiveWPのデバッグモードが有効になっていない可能性が高い。「寄付」→「設定」→「詳細」→「デバッグモード」を有効にすると、Webhook処理のエラーログが記録されるようになる。ログは「寄付」→「ツール」→「ログ」で確認できる。

再接続してもWebhookがStripeダッシュボードに自動作成されない

GiveWPの接続プロセスの中で、WordPressのREST APIが正しく動作していない可能性がある。パーマリンク設定を「基本」以外に変更して保存し直す。また、セキュリティプラグインがREST APIを制限していないか確認する。

WebhookエンドポイントのURLは手動で変更してもよいか

原則として不要であり、変更すべきではない。GiveWPが自動生成するエンドポイントURLは「https://（サイトURL）/?give-listener=stripe」で固定されており、これをStripeに正しく登録している。URLを手動で変更すると、署名の不一致が発生してすべてのWebhookが失敗する。

GiveWPのシステムレポートはどこで確認できるか

WordPress管理画面の「寄付」→「ツール」→「システム情報」タブを開き、「システムレポートを取得」ボタンをクリックすると、サーバー環境やGiveWPの設定情報がテキスト形式で表示される。サポートに問い合わせる際はこのレポートを添付するとスムーズに調査が進む。

この記事のポイント

  • Stripe決済成功後に寄付が未完了になるのは、Webhook処理の段階でGiveWPがイベントデータを読み取れていないから
  • 致命的エラー「array_keys null given」はWebhookの中身が空であることを示す決定的な手がかり
  • GiveWPとStripeの接続解除からWebhook全削除、再接続までを一気に行い、署名シークレットを完全に再生成する
  • LiteSpeedやホスティングのキャッシュからWebhookエンドポイントを除外し、POSTリクエストが加工されないようにする
  • 署名シークレットはGiveWPが自動管理するため、手動設定は不要であり、むしろ競合の原因になる
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
404ページがホームページのキャッシュとして表示される原因と修正方法
2026年7月4日 0

404ページがホームページのキャッシュとして表示される原因と修正方法

ページキャッシュを有効にしたプラグインで、存在しないはずの404ページにアクセスするとホームページの内容がそのまま表示されてしまう不具合は、該当プラグインのバージョン2.5.0で修正された。管理画面からプラグインを最新版に更新し、キャッシュを全削除すれば解決する。

なぜ404ページがホームページのキャッシュになるのか

なぜ404ページがホームページのキャッシュになるのか

ページキャッシュの仕組みは、最初の訪問者がサイトにアクセスしたタイミングで、その時点のHTML出力をまるごと静的ファイルとして保存する。以降の訪問者には、WordPress本体やデータベースを毎回通さず、この静的ファイルを返すことで表示速度を大幅に上げている。

正常な動作では、訪問者が存在しないURL（いわゆる404ページ）を開いた場合、プラグインはWordPressが「これは404だ」と判定した結果をそのままキャッシュする。もしくは、404ページはそもそもキャッシュの対象から外す設計になっている。しかし今回の事象では、404ページにアクセスした際にWordPressの判定をスキップして、誤ってホームページのキャッシュを返してしまう欠陥がキャッシュ生成処理に含まれていた。

内部の動きを想像で補うと、リクエストが404だとわかった段階でキャッシュを生成せずにスルーすべきところ、テーマやプラグインがフックする前に「URLに対応するキャッシュがないからホームページのキャッシュで代用する」ような分岐に入ってしまっていた可能性が高い。結果として、アドレスバーには存在しないURLが表示されたまま、画面だけホームページのレイアウトという状態が発生する。

Before（不具合発生中）
存在しないURLにアクセスしても、ホームページの画面がそのまま表示される。アドレスバーのURLは404のまま変わらない。
↓
After（修正後）
存在しないURLには、テーマが用意した正しい404ページが表示される。
■ 不具合時の状態　■ 修正後の正常な状態

プラグインをアップデートしてキャッシュを削除する手順

プラグインをアップデートしてキャッシュを削除する手順
STEP 1 管理画面の「プラグイン」から該当プラグインをバージョン2.5.0以降に更新
↓
STEP 2 プラグインの設定画面または専用ボタンから「キャッシュをすべて削除」を実行
↓
STEP 3 ブラウザのシークレットウィンドウで存在しないURLを開き、404表示を確認

アップデートしても直らない場合の追加確認

バージョン2.5.0に更新しキャッシュを全削除したあとも問題が再発するなら、以下の点を順に調べる。

  • プラグインのキャッシュとは別に、サーバー側のVarnishキャッシュやCDNキャッシュが残っていないか
  • 子テーマのfunctions.phpに古いキャッシュ制御コードが残っていないか
  • プラグインの設定で「404ページをキャッシュしない」などの該当オプションが無効になっていないか

アップデート前の一時的な回避策

アップデート前の一時的な回避策

何らかの事情ですぐにプラグインを最新版にできない場合、手元のfunctions.phpにキャッシュ除外用の定数やフックを追加して、404ページをキャッシュ対象から外す一時しのぎが使える。ただしこれはあくまで応急処置であり、根本対応としては必ずアップデートが必要だ。

// 404ページがキャッシュされないようにする一時的な回避策
add_action( 'template_redirect', function() {
    if ( is_404() ) {
        if ( ! defined( 'DONOTCACHEPAGE' ) ) {
            define( 'DONOTCACHEPAGE', true );
        }
    }
});

上記のコードは、WordPressが「このリクエストは404だ」と判定した直後にDONOTCACHEPAGE定数を定義し、該当プラグインのキャッシュ生成を抑止する。テーマのfunctions.phpの末尾、またはCode Snippets系のプラグインで追加する。追加後に改めてキャッシュを全削除すれば、404ページがキャッシュされることを防げる。

ただし定数名はプラグイン固有のものであり、ほかのキャッシュプラグインでも同じ定数が使えるとは限らない。あくまで該当プラグインの一時回避策としてとらえる必要がある。

よくある質問

404ページのキャッシュ問題は特定のテーマが原因になることもあるのか

テーマが独自の404テンプレートを用意している場合でも、基本的には今回のようなバグはプラグインのキャッシュ生成処理に起因する。ただし、テーマが404のときに誤ってホームページと同じクエリを走らせる設計だと、間接的に似た挙動になるケースがありうるため、プラグイン側の問題解決後も念のためテーマの404.phpを確認しておくと安心だ。

キャッシュを削除したのに404ページでホームページが表示され続けるのはなぜか

プラグイン自体のキャッシュだけでなく、ブラウザキャッシュやサーバーレベルのキャッシュ（Varnishやnginx fastcgi cache）、CDNのキャッシュが残っていることが多い。一度シークレットウィンドウでアクセスし、それでも同じならCDNの管理画面からもキャッシュ削除を試す。ホスティングによっては専用のキャッシュクリアボタンが用意されているので確認する。

アップデート後に404表示が直ったが、今後のために404ページをキャッシュさせない設定は必要か

プラグインが正常に404を区別できるようになれば、404ページがキャッシュされることはなくなるため、追加の設定は原則不要だ。むしろ手動で除外設定を重ねると、あとで別の不具合を引き起こす可能性がある。修正が確認できたら、一時回避用のコードは削除しておくほうがよい。

この記事のポイント

  • 404ページがホームページで表示される問題は、該当プラグインのバージョン2.5.0で修正済み
  • 修正後は管理画面からプラグインを更新し、キャッシュをすべて削除すれば解決する
  • 即時更新が難しい場合はfunctions.phpにキャッシュ除外の定数を仕込むことで一時回避できる
  • サーバーやCDNの多段キャッシュが残っていると再発に見えるため、あわせて削除する
佐々木 太陽
, , , ,
お悩み・トラブル解決
« 前ページへ 次ページへ »

メニュー

会社概要
事業紹介
社名の由来
JVパートナー募集

ウェブ開発 最新ニュース

サービス一覧

ウェブシステム開発

B to B のご提案

事業譲渡（M&A）
卸売販売
アフィリエイト

その他

関連サイト
特定商取引法に基づく表示
プライバシーポリシー
お問い合わせ

Copyright 株式会社A&Gウェブ - ライバルには、ひみつ。 All rights reserved.