タグアーカイブ トラブル解決

  1. ホーム   /  タグ付きの投稿: "トラブル解決" ( 固定ページ7 )
Mollie決済プラグインでPHP警告「Undefined array key」が出たときの対処法
2026年7月9日 0

Mollie決済プラグインでPHP警告「Undefined array key」が出たときの対処法

Mollie Payments for WooCommerce で「PHP Warning: Undefined array key “identifier”」という警告が出ても、決済フローや Apple Pay の動作に支障はない。この警告は PHP 側の配列キー未定義による軽微な通知であり、プラグイン開発元が修正を予定している。緊急の対応が必要でなければ、エラーログへの出力を抑える設定で一時的に回避できる。

なぜ「Undefined array key “identifier”」警告が発生するのか

なぜ「Undefined array key “identifier”」警告が発生するのか

この警告は、PHP 8.0 以降で強化された型と配列アクセスの安全性チェックによって表面化したものだ。Mollie プラグインの Apple Pay 関連クラス内で、変数やリクエストデータに「identifier」というキーが存在しない状態で配列アクセスを行っているために出力される。

PHP 8.0 以降の配列アクセスへの影響

PHP 7.x までは、配列内に存在しないキーを参照しても通知（Notice）または軽微な警告（Warning）で済む場面が多かった。しかし PHP 8.0 からは「Undefined array key」が Warning に格上げされている。テーマやプラグインが最新の PHP に完全対応していないと、こうした警告が表面化しやすい。

Mollie プラグインの該当コードが生む状況

警告の発生箇所は ResponsesToApple.php の 89 行目と ApplePayDataObjectHttp.php の 193 行目付近だ。Apple Pay のトークン処理やデータオブジェクトの動的生成時に、送信されてくるパラメータが一部欠落している場合や、プロパティが未定義のままアクセスされている場合に警告が記録される。

もう一つの「Creation of dynamic property」は PHP 8.2 で導入された非推奨通知で、クラスに明示的に宣言されていないプロパティへ動的に値を代入している場合に発生する。いずれも決済処理の本筋を妨げるエラーではなく、サーバーのエラーログに記録されるだけの通知レベルだ。

修正前（警告が発生している状態）
PHP Warning: Undefined array key “identifier” in ResponsesToApple.php on line 89
PHP Deprecated: Creation of dynamic property … in ApplePayDataObjectHttp.php on line 193
※ 決済処理は通常通り完了するが、ログに警告が残る
↓
修正後（警告を抑制した状態）
エラーログに警告が出力されず、運用上のノイズがなくなる
※ プラグイン側の根本修正はアップデートを待つ
■ 修正前（警告あり）　■ 修正後（警告を抑制）

エラーログを確認して影響度を判断する

エラーログを確認して影響度を判断する

警告の発生頻度や実際の影響を把握するには、まずサーバーのエラーログを確認する。多くの国内レンタルサーバーでは管理画面のログビューアから確認できるほか、FTP で /wp-content/ 内の debug.log を直接ダウンロードしてもよい。

エラーログの保存場所と見方

WordPress のデバッグモードを有効にしている場合、wp-config.php に定義された WP_DEBUG_LOG の設定に従い、エラーログが出力される。デフォルトでは /wp-content/debug.log に保存される。

ログを開くと日付とともにエラーレベルが記録されている。「PHP Warning」と「PHP Deprecated」の行を探し、該当のプラグイン名とファイルパスが含まれているかを確認する。もし1時間に数千回単位で記録されているようであれば、ログファイルが肥大化してディスク容量を圧迫する可能性があるため対応が必要だ。

警告の発生頻度を調べる簡単なコマンド

SSH 接続が可能なサーバーであれば、grep コマンドで頻度を数えられる。以下のように実行すると「identifier」を含む警告の出現回数がわかる。

grep -c "Undefined array key \"identifier\"" /home/user/domains/example.com/public_html/wp-content/debug.log

数十件程度であれば運用上の支障は少ないが、数百件以上ある場合は早めの抑制を検討する。

PHP 警告を一時的に非表示にする方法

PHP 警告を一時的に非表示にする方法

根本的な修正がプラグイン側で提供されるまでの間、エラーログへの出力を抑える設定で運用上のノイズを減らせる。複数の段階的な手法があるので、サイトの状況に合わせて選択する。

エラーレポートレベルを変更する

wp-config.php に以下の定数を追加すると、Warning と Deprecated をログから除外できる。この設定は本番環境で推奨される標準的なエラー抑制の手法だ。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'error_reporting', E_ALL & ~E_WARNING & ~E_DEPRECATED );

WP_DEBUG_DISPLAY を false にすることで画面表示を防ぎ、error_reporting のビット演算で Warning と Deprecated だけを除外する。Fatal error など重大なエラーは引き続き記録されるため、サイトの異常を見逃すリスクは低い。

Mollie プラグイン固有のフックで抑制する

よりピンポイントに対処するなら、Mollie が提供するフィルターフックを利用する方法もある。ただし、これはプラグインのバージョンによって動作が異なるため、公式ドキュメントを参照のうえ実装する必要がある。

多くの場合、前述のエラーレポート設定で十分に警告は抑制できる。プラグイン更新後に設定を元に戻すことを忘れずに、スケジュールに組み込んでおく。

STEP 1 FTP またはサーバー管理画面で wp-config.php を開く
↓
STEP 2 WP_DEBUG_DISPLAY を false に設定する
↓
STEP 3 error_reporting を設定して Warning と Deprecated を除外
↓
STEP 4 ファイルを保存し、数時間ログを監視して警告が出ていないか確認する

プラグインのアップデートを待つときの注意点

プラグインのアップデートを待つときの注意点

Mollie の開発チームはこの警告を認識しており、将来のバージョンで修正が行われる見込みだ。プラグインの更新を待つ間は、以下の点に注意してサイトを運用する。

自動アップデートを有効にしておく

WordPress の管理画面で Mollie Payments for WooCommerce の自動アップデートをオンにしておくと、修正版がリリースされた際に即座に適用される。更新を手動で行う場合は、Mollie の changelog を定期的にチェックし、「identifier」や「dynamic property」に関する修正が含まれているかを確認する。

ログのローテーションを設定する

警告が高頻度で出ていると debug.log が急速に肥大化する。サーバーのログローテーション機能や、WordPress 用のログ管理プラグインを導入して、一定期間で古いログを圧縮・削除する仕組みを整えておく。これによりディスク容量の圧迫を防げる。

よくある質問

この警告が出ていても決済は正常に動くのか

多くの場合、クレジットカードや Apple Pay の決済処理に影響はない。PHP Warning や Deprecated は実行を停止させるエラーではなく、処理は継続される。実際に決済が通っているかは、テスト購入を行って確認するのが確実だ。

他の決済プラグインでも同じ警告は出るのか

PHP 8.0 以降に完全対応していないプラグインであれば、同様の「Undefined array key」警告が発生する可能性がある。Stripe や PayPal の公式プラグインでも、過去に似たような警告が報告され修正されている。プラグインが最新かどうかを常に確認することが重要だ。

プラグインを自分で修正してもよいのか

PHP の知識があるなら、該当行に isset() によるキー存在チェックを追加すれば警告は消える。ただし、プラグインのアップデートで修正が上書きされるため、修正を維持するには継続的な管理が必要だ。本番環境では推奨しない。

PHP のバージョンを下げれば解決するか

PHP 7.4 に戻せばこの警告は出なくなるが、PHP 7.4 はすでにセキュリティサポートが終了している。サイト全体の安全性を損なうため、PHP のダウングレードは避けるべきだ。サーバー環境は常にサポート対象の PHP バージョンを維持する。

「Creation of dynamic property」も同じ対処でよいのか

同じエラーレポートレベルの設定で抑制できる。こちらも PHP 8.2 以降の非推奨通知であり、機能停止を伴わない。根本対応はプラグイン側でプロパティ宣言を追加する必要があるため、開発元のアップデートを待つ形になる。

この記事のポイント

  • 「Undefined array key」警告は決済機能に影響しない軽微な通知
  • PHP 8.0 以降の配列アクセス厳格化によって表面化している
  • エラーレポートレベルの変更で一時的にログ出力を抑制できる
  • プラグインの自動アップデートを有効にして修正版の適用に備える
  • PHP バージョンのダウングレードはセキュリティリスクがあるため避ける
佐々木 太陽
, , , , ,
お悩み・トラブル解決
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でプラグインフォルダをリネームして強制停止する
  • エラーログに書かれたファイルパスから原因のプラグインを狙い撃ちする
佐々木 太陽
, , , , ,
お悩み・トラブル解決
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の多段キャッシュが残っていると再発に見えるため、あわせて削除する
佐々木 太陽
, , , ,
お悩み・トラブル解決
Events Manager更新後に公開イベントが下書きに戻る原因と修正
2026年7月3日 0

Events Manager更新後に公開イベントが下書きに戻る原因と修正

Events Manager 7.3.7.4 にアップデート後、公開済みイベントの編集画面で「更新」をクリックすると、ステータスが「下書き」に戻ってしまう現象が報告されている。原因は、終日設定のイベントに対してタイムレンジ（時間範囲）が重複してデータベースに登録されてしまうことだ。このバグにより、プラグイン内部のバリデーションが失敗し、自動的に下書きへと巻き戻される。データベースの重複を削除し、プラグインファイルに一時的なパッチをあてることで解決する。

なぜ公開済みイベントが更新時に下書きに戻ってしまうのか

なぜ公開済みイベントが更新時に下書きに戻ってしまうのか

Events Manager はイベントを表す EM_Event クラスが、記事が保存される前に validate_meta() メソッドで内部データの整合性をチェックしている。このチェックに引っかかると wp_insert_post_data フックが介入し、投稿ステータスを強制的に「下書き」に変更する仕様だ。

今回の問題では、「Timeranges cannot overlap with each other.（タイムレンジが重複しています）」というエラーが発生している。しかし、エディタ上では終日（All Day）設定の単一の時間範囲しか表示されていない。実際にデバッグ出力を取得すると、同一イベントに属する同一の終日タイムレンジ（開始 00:00:00、終了 23:59:59）が2件存在しており、これが重複エラーの直接的な原因だ。

データベースで重複したタイムレンジを削除する手順

データベースで重複したタイムレンジを削除する手順
STEP 1 phpMyAdmin でデータベースのバックアップを取得する
↓
STEP 2 重複を検出するSQLクエリを実行する
↓
STEP 3 古い重複行を安全に削除する
↓
STEP 4 イベント編集画面で「更新」して正常化を確認する

STEP 1：必ずデータベースをバックアップする

今回の作業ではデータを直接操作するため、必ず事前にデータベース全体のエクスポートを取得する。何か問題が起きても元に戻せるようにしておこう。

STEP 2：重複タイムレンジを検出する

テーブル名はプラグインの設定により異なるが、多くは wp_em_timeranges となる。phpMyAdmin のSQLタブで次のクエリを実行し、同一 event_id・同一 timerange_start・timerange_end の組み合わせが複数存在しないか確認する。

SELECT event_id, timerange_start, timerange_end, COUNT(*)
FROM wp_em_timeranges
GROUP BY event_id, timerange_start, timerange_end
HAVING COUNT(*) > 1;

結果が返ってきたら、該当の event_id をメモしておく。

STEP 3：重複行のうち一方を削除する

重複している行のうち、より古いIDの行を削除する。以下のクエリは最も小さい ID 以外を削除する例だ。必ず削除対象を SELECT で事前確認してから実行する。

DELETE t1 FROM wp_em_timeranges t1
INNER JOIN wp_em_timeranges t2
WHERE t1.timerange_start = t2.timerange_start
AND t1.timerange_end = t2.timerange_end
AND t1.event_id = t2.event_id
AND t1.ID > t2.ID;

STEP 4：イベントを再編集して正常に保存されるか確認する

データベースの重複を除いたら、WordPress管理画面に戻り、該当のイベント編集画面を開く。内容を微修正して「更新」をクリックし、再び「下書き」に戻らず公開状態が維持されることを確かめる。

プラグインファイルの一時修正で重複登録を防ぐ

プラグインファイルの一時修正で重複登録を防ぐ

根本的な原因は、何らかのトリガーでタイムレンジオブジェクトが二重に追加されてしまうことだ。以下は EM_Event::validate_meta() の中で重複を除去する応急処置のコード例だ。必ずファイルのバックアップを取ったうえで追記する。

// events-manager/classes/em-event.php の validate_meta メソッド内
public function validate_meta( $data, $postarr ) {
    // タイムレンジを取得して重複を排除する
    $timeranges = $this->get_timeranges();
    $unique_timeranges = [];
    foreach ( $timeranges as $timerange ) {
        // timerange_group_id などのキーで一意にする
        $key = $timerange->timerange_group_id . '_' . $timerange->timerange_start . '_' . $timerange->timerange_end;
        if ( ! isset( $unique_timeranges[ $key ] ) ) {
            $unique_timeranges[ $key ] = $timerange;
        }
    }
    // 重複排除済みのコレクションでバリデーション
    if ( ! $unique_timeranges || ! $this->validate_timeranges_collection( $unique_timeranges ) ) {
        // エラー処理...
    }
    // 以下略
}

ただし、このパッチはあくまで暫定的なものだ。プラグインが公式に修正をリリースするまでは、更新のたびに再適用が必要になる。公式サポートフォーラムを定期的に確認し、バグ修正版がリリースされたら速やかにアップデートしよう。

よくある質問

この問題はイベントマネージャーのどのバージョンから発生したのか

少なくとも 7.3.7.4 で報告されている。それ以前のバージョンでは発生していなかった可能性が高いが、同様の重複が偶発的に起きているケースもある。

クラシックエディターを使えば回避できるか

根本原因はデータ保存時のバリデーションにあるため、グーテンベルクエディターかクラシックエディターかは関係ない。ただし、編集画面のUIの違いでトリガーが変わる可能性は否定できない。試す価値はある。

終日イベント以外でも起こるのか

現在報告されているのは終日設定時のケースだ。しかし、時間指定のあるイベントでも重複が起きれば同じエラーで下書きに戻る。該当イベントの編集時は要注意だ。

データベースを直接触らずに直す方法はあるか

現時点では、管理画面から重複を操作できる機能はない。比較的安全な方法としては、一度イベントを複製→元のイベントを削除→複製イベントを公開する、という手順でタイムレンジが正常な状態になることがある。

公式の修正はいつリリースされるのか

これはバグトラッカーや公式フォーラムを見守るしかない。開発チームが認識している問題であれば、次のパッチに含まれる可能性がある。

この記事のポイント

  • Events Manager 7.3.7.4 で発生する既知のバグで、バリデーションエラーによってステータスが下書きに変更される
  • 原因は終日イベントのタイムレンジがデータベース上で重複していること
  • phpMyAdmin から重複行を削除することで一時的に解決する
  • プラグインファイルの修正パッチで再発を防げるが、公式アップデートまでは注意が必要
  • データベース操作前には必ずバックアップを取得する
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
« 前ページへ 次ページへ »

メニュー

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

ウェブ開発 最新ニュース

B to B のご提案

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

その他

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

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