お悩み・トラブル解決 5 - 株式会社A&Gウェブ

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つの対処法

以下の手順は、簡単で効果が高いものから順に並べている。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本体とテーマは常に最新版を保つ

佐々木太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・「検索しても答えが見つからなかった」を一つでも減らすことが目標
・エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

佐々木太陽

JavaScriptエラー, WordPress, アコーディオンブロック, キャッシュ, トラブルシューティング, ブロックエディタ

お悩み・トラブル解決

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上では決済が正常に完了して見えることだ。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」エラーが示す根本原因

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の間の信頼関係をゼロから組み直すつもりで、以下の手順を上から順に実行する。

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はサーバー間の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に設定していた場合、バージョンアップ後にその情報が無視されるか、あるいは競合を起こす可能性がある。そのため、手順としては次のように徹底する。

Stripeダッシュボードから古いWebhookをすべて削除する（手動で作成したものも含む）
GiveWP管理画面でStripeとの接続を完全に解除する
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が自動管理するため、手動設定は不要であり、むしろ競合の原因になる

佐々木太陽

GiveWP, PHPエラー, Stripe, Webhook, WordPress, トラブル解決, 寄付プラグイン

お悩み・トラブル解決

2026年7月4日 0

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

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

なぜ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の多段キャッシュが残っていると再発に見えるため、あわせて削除する

佐々木太陽

404エラー, WordPress, キャッシュプラグイン, トラブル解決, ページキャッシュ

お悩み・トラブル解決

2026年7月4日 0

Elementorエディターが重い原因と4,400個のコンテナを減らす方法

Elementor エディターが極端に重くなる最大の要因は、ページあたりのコンテナ数が過剰に積み上がっていることだ。4,400 個という数字は Elementor の実用的な上限を大きく超えており、まずはコンテナ構造の見直しと不要なネストの解除から手を付ける。

Elementor エディターが極端に重くなる根本原因は何か

Elementor のエディターは、ページを開くたびに全ウィジェットとコンテナのデータを JSON 形式で読み込み、DOM ツリーをブラウザ上に再構築する仕組みになっている。この処理は要素数に対して指数的に負荷が増えるため、数千単位のコンテナが存在するとエディターの起動そのものが数分単位で遅延する。

とくに深刻なのが、コンテナの深いネスト（入れ子）だ。親コンテナの中に子コンテナ、さらに孫コンテナと階層が深くなるほど、エディター側でのレンダリング計算量が跳ね上がる。4,400 個のコンテナのうち、3 階層以上ネストされたものが多い場合は、構造の平坦化だけでエディターの応答速度が大きく変わる。

もうひとつ見落としがちなのが、ACF（Advanced Custom Fields）の動的データ呼び出しだ。ACF フィールドを Elementor の動的タグで大量に埋め込んでいる場合、エディター読み込み時にすべてのフィールド値がデータベースから取得される。フィールド数が多いほど、このクエリ負荷がエディターの起動時間を押し上げる。

フロントエンドが高速なのは、Elementor が静的 CSS とキャッシュを生成しているからだ。エディター側はその生成前の「生の状態」を扱うため、まったく別のパフォーマンス特性になる。

エディター遅延の原因別インパクト

最大要因過剰なコンテナ数と深いネスト 4,400 個のコンテナのうち多くが 3 階層以上だとエディター起動が致命的に遅くなる

中程度 ACF 動的データの大量呼び出し動的タグが多いほど DB クエリが増え、エディター読み込み時間が延びる

軽度プラグインの競合エディター画面にスクリプトを注入するプラグインがあると応答が鈍る

4,400 個のコンテナは異常な数値なのか

はっきり言えば、異常に多い。Elementor の公式ドキュメントに明示的な上限はないが、実務上の目安として 1 ページあたりのコンテナ数は 200〜500 個に抑えるのが望ましい。4,400 個はその 10 倍近く、エディターがまともに動かなくなるのも当然の数字だ。

100 ページあるサイトで合計 4,400 コンテナであれば 1 ページ平均 44 個だが、質問者のケースでは特定の巨大ページにコンテナが集中している可能性が高い。エディターの遅さは「サイト全体のコンテナ総数」ではなく「開こうとしているページのコンテナ数」に依存する点を押さえておく。

エディター速度を改善する具体的な手順

まずは Elementor の「実験」機能とパフォーマンス設定を最適化する

Elementor の管理画面「Elementor → 設定 → 実験」には、エディターのパフォーマンスに直結する項目がいくつかある。「インライン Font Awesome アイコン」を無効化し、「DOM の出力を最適化」を有効にする。さらに「設定 → 詳細設定」で「エディターローダーの改善」を有効化すると、エディターの初期読み込みが軽くなる。

ページのコンテナ構造を平坦化する

もっとも効果が大きいのがこれだ。深くネストされたコンテナを 1〜2 階層に減らすだけで、エディターの DOM 構築コストが劇的に下がる。以下の手順で進める。

STEP 1 もっとも遅いページを特定し、複製してバックアップを取る

↓

STEP 2 ナビゲーターで 3 階層以上のネストをすべて特定する

↓

STEP 3 内側のコンテナを親レベルに引き上げ、不要なラッパーを削除する

↓

STEP 4 CSS グリッドやフレックスボックスでレイアウトを再構築し、コンテナ数を半減させる

たとえば「セクション＞カラム＞カラム＞テキスト」という 4 階層のネストは、CSS グリッドを使えば「セクション＞テキスト」の 2 階層にまとめられる。この平坦化だけでコンテナ数を 30〜50% 削減できるケースが多い。

ACF 動的タグの使用を見直す

ACF の動的タグは便利だが、1 ページに数十個も埋め込むとエディター読み込み時のデータベースクエリが無視できなくなる。とくにリピーターフィールドやフレキシブルコンテンツを多用している場合は要注意だ。可能であれば、動的タグの代わりにショートコードで一括取得する方式に切り替えるか、ACF の `get_field()` をテーマ側で処理してから Elementor に渡す設計を検討する。

サーバー側のチューニングを確認する

WP Engine のようなマネージドホストであっても、PHP のメモリ制限や実行時間の設定は確認しておく。`wp-config.php` に以下の定数を追加または修正する。

define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
set_time_limit( 300 );

WP Engine の場合はユーザーポータルから PHP の `max_execution_time` と `memory_limit` を確認できる。数値が十分でも、サーバー側のオブジェクトキャッシュ（Redis）が正しく動作しているかも合わせて確認する。

不要なプラグインのスクリプトをエディター画面から除外する

一部のプラグインは、エディター画面であっても独自の CSS や JavaScript を読み込む。16 個のプラグインがアクティブな状態なら、そのうち 2〜3 個がエディターの応答を悪化させている可能性がある。プラグイン「Query Monitor」を一時的に有効化し、エディター画面でどのスクリプトが重いかをプロファイリングする。

問題のスクリプトを特定したら、`functions.php` に以下のようなコードを追加してエディター画面でのみ読み込みを停止する。

add_action( 'admin_enqueue_scripts', function( $hook ) {
    if ( 'post.php' !== $hook && 'post-new.php' !== $hook ) {
        return;
    }
    wp_dequeue_style( 'problem-plugin-style' );
    wp_dequeue_script( 'problem-plugin-script' );
}, 100 );

再構築せずに長期的な安定性を確保する設計の考え方

根本的には、Elementor は「ビジュアルビルダー」であり、数千単位の要素をリアルタイムで操作するようには設計されていない。この規模のサイトでは、ページを「Elementor で編集する領域」と「テーマやプラグインで自動生成する領域」に明確に分ける設計が有効だ。

ニュース記事や個別投稿の一覧表示、ACF の繰り返しフィールドによるコンテンツ部分は、Elementor の「ループグリッド」ウィジェットやテーマテンプレートで処理し、編集者が直接触るコンテナ数を最小限に抑える。この切り分けができれば、エディターの負荷は大幅に下がり、コンテンツ更新の速度も実用的な水準に戻る。

改善前と改善後のエディター負荷比較

改善前

■ コンテナ数:4,400 個（ページあたり最大 600 個）

■ ネスト階層:平均 4 階層

■ エディター起動時間:30〜60 秒

■ 保存時間:15 秒以上

↓

改善後

■ コンテナ数:2,000 個（ページあたり最大 150 個）

■ ネスト階層:最大 2 階層

■ エディター起動時間:5〜8 秒

■ 保存時間:3 秒以内

■ 改善前　■ 改善後

よくある質問

コンテナ数を減らすとデザインが崩れるのでは？

CSS グリッドやフレックスボックスを適切に使えば、ネストを減らしても見た目は維持できる。むしろ不要なラッパーを外すことで CSS の特異性が下がり、スタイルの管理がしやすくなる利点もある。作業前に必ずページを複製し、ステージング環境で検証してから本番に適用する。

ACF の動的タグをやめると運用が面倒にならないか？

ショートコード化やテーマ側での処理に切り替えると、たしかにエディター上のビジュアルプレビューは失われる。しかし、エディターが実用的な速度で動くことと引き換えにすれば、運用全体のストレスは大幅に減る。プレビューはフロントエンドで確認する運用に切り替えればよい。

Elementor 以外のビルダーに移行すべきか？

即座の移行は現実的ではないが、長期的には検討に値する。ネイティブのブロックエディター（Gutenberg）は DOM 構造が比較的平坦で、同規模のサイトでもエディターの動作は軽快だ。まずは新規ページからブロックエディターを試し、既存ページは優先度の高いものから徐々に移行する段階的アプローチが安全だ。

PHP 8.4 との相性問題はあるか？

PHP 8.4 は比較的新しく、一部のプラグインで非推奨警告や互換性の問題が出ることがある。Elementor 本体は 8.4 に対応しているが、ACF や他のプラグインが完全対応していない可能性もある。PHP のエラーログを確認し、Deprecated や Warning が頻出しているようなら PHP 8.2 や 8.3 へのバージョンダウンも一時的な回避策となる。

キャッシュ系プラグインはエディター速度に影響するか？

ページキャッシュや CSS 最適化系のプラグインはフロントエンドには有効だが、エディター画面の速度にはほぼ影響しない。むしろ CSS の最適化処理がエディター保存時に走る設定になっていると、保存がさらに遅くなる場合がある。エディター編集中は CSS 最適化をオフにできるプラグインを選ぶか、保存時のフックを一時的に無効化する。

この記事のポイント

エディターの遅延はコンテナ数とネストの深さが最大の要因
4,400 個のコンテナは実用上限を大幅に超過しており、平坦化で 30〜50% 削減を目指す
ACF 動的タグの大量使用はエディター起動時の DB 負荷を高める
プラグイン「Query Monitor」でエディター画面のボトルネックを特定できる
長期的には、動的コンテンツをテーマ側に寄せて Elementor の編集負荷を下げる設計が有効

佐々木太陽

ACF, Elementor, WordPress, エディター遅延, コンテナ最適化, パフォーマンス改善

お悩み・トラブル解決

2026年7月4日 0

OptinMonsterやTrustPulseが原因でWordPressが乗っ取られた時の対処

特定のプラグインをインストールしていた WordPress サイトで、管理者アカウントが勝手に作られたり、マルウェアを仕込まれる被害が広がっている。無効化した状態でも影響を受けるため、すぐにユーザー一覧とプラグインフォルダを確認しなければならない。

なぜ無効化したプラグインで侵入されたのか

被害報告が相次いでいるのは、OptinMonster、TrustPulse、PushEngage という 3 つのプラグインだ。いずれも単体で配布されているほか、MonsterInsights Pro にバンドル（同梱）されて提供されている。注目すべきは、有効化していなくてもプラグインとして存在するだけで攻撃対象になった点だ。WordPress はプラグインを無効化しても、ファイル自体はサーバー上に残る。攻撃者はそのファイルに含まれる脆弱性を利用して外部からコードを実行し、管理者アカウントの新規作成や Cloudflare／ClearFake マルウェアの設置を行った。

無料版の Wordfence では検知できなかったケースが確認されている。シグネチャ（攻撃パターン）が更新されるまでの時間差や、攻撃手法が亜種に変化していたことが原因とみられる。そのため、目視での確認が不可欠だ。

侵入前プラグインが無効で放置、ファイルはサーバー上に存在

↓

侵入後不明な管理者アカウントが追加され、不正な PHP ファイルが設置される

■ 侵入前（ファイルはあるが無害に見える）　■ 侵入後（管理者アカウントやマルウェアが追加される）

このデモは、プラグインファイルが放置された状態から攻撃者が侵入し、追加の不正な要素を仕込む流れを示している。

自分のサイトが影響を受けているか確認する手順

管理者アカウントの一覧を調べる

WordPress 管理画面の「ユーザー」→「すべてのユーザー」を開き、覚えのない管理者権限のアカウントが追加されていないかを確認する。アカウント名やメールアドレスに覚えがないもの、登録日時が直近のものがあれば要注意だ。

プラグインフォルダに不審な PHP ファイルがないか調べる

FTP ソフトやレンタルサーバーのファイルマネージャーで /wp-content/plugins/ 以下を開く。特に OptinMonster、TrustPulse、PushEngage のフォルダ内に、本来あるはずのない名前の PHP ファイルや、暗号化されたような文字列が書かれたファイルがないかを確認する。

プラグインをすでに削除してしまった場合でも、/wp-content/ 直下や /wp-includes/、テーマフォルダ内に不審な PHP ファイルが残っていないか、更新日時が最近のものに心当たりがないかを見ておくとよい。

STEP 1 管理画面「ユーザー」で管理者アカウントを確認

↓

STEP 2 FTP で /wp-content/plugins/ 以下の不審ファイルを調査

↓

STEP 3 .htaccess や wp-config.php に追記がないかも確認

管理者アカウントとファイルの両面から、侵入の痕跡を短時間で洗い出す手順を示している。

不正アクセスが発覚した場合の緊急対応

不正な管理者アカウントを即座に削除する

覚えのない管理者アカウントを見つけたら、すぐにそのユーザーを削除する。削除時に「すべての投稿を帰属させる」選択肢が出るが、攻撃者が作成した投稿や固定ページがなければそのまま削除してよい。念のため、削除前にゴミ箱や下書きに不審なコンテンツがないかも確認しておく。

不正ファイルを削除し、該当プラグインを完全に除去する

不審な PHP ファイルは必ずバックアップを取った上で削除する。OptinMonster、TrustPulse、PushEngage のいずれかがインストールされているなら、今後も脆弱性が残る可能性を考え、プラグイン自体を完全に削除するのが安全だ。同梱元の MonsterInsights Pro を利用している場合も、これらのアドオンが自動でインストールされていないか確認する。

サイト全体のマルウェアスキャンを実施する

Wordfence や Sucuri などのセキュリティプラグインで手動の詳細スキャンを実行する。無料版の自動スキャンだけでは検知漏れが起こる可能性があるため、手動でフルスキャンをかける。Sucuri のサイトチェック（外部スキャナ）を併用すると、サーバー内部からは見えにくい改ざんも検出しやすくなる。

再発防止と今後のセキュリティ対策

使用していないプラグインやテーマは「無効化」ではなく「削除」する

WordPress では、プラグインを無効化してもファイルはサーバー上に残り続ける。今回の事例が示すように、無効状態でもファイルが存在するだけで攻撃の足場になる。今後は使わないと判断したプラグインやテーマは、面倒でも完全に削除する習慣をつけるのが鉄則だ。

プラグインの更新を常に最新に保ち、導入元を精査する

公式リポジトリ外のプラグインや、長期間更新が止まっているものはリスクが高い。どうしても必要な場合を除き、信頼できる提供元のものだけを使う。自動更新を有効にしておくと、脆弱性が公表された直後の修正パッチを適用しやすくなる。

定期的な管理者アカウントとファイルの監査を組み込む

月に一度は「ユーザー一覧」を開き、見慣れないアカウントがないかを目視点検する。あわせて、サーバーのファイル更新日時を確認し、心当たりのないタイミングで変更されたファイルがないかをチェックする。人が目で見る作業は、自動ツールの検知漏れを補う最後の砦になる。

よくある質問

無効化していてもなぜハッキングされたのか

無効化はあくまでプラグインの動作を止めるだけで、ファイルはそのままサーバーに残る。今回の攻撃はファイルの存在を前提に外部から直接コードを実行する手法だったため、有効か無効かは関係なく被害が発生した。

Wordfence が入っていれば安心なのか

今回の事案では、無料版 Wordfence で検知できなかった例がある。セキュリティプラグインに過度な期待をせず、定期的な手動確認と不要なファイルの削除を組み合わせることが欠かせない。

MonsterInsights を使っているが該当プラグインは入れていない

MonsterInsights Pro の一部バージョンでは、これらのプラグインが同梱されて自動インストールされる場合がある。プラグイン一覧を開き、OptinMonster、TrustPulse、PushEngage が存在しないか今一度確認してほしい。

すでに削除したが、まだ不安が残る場合の最終確認方法は

レンタルサーバーの管理画面で最近のアクセスログを確認し、不審な IP アドレスや POST リクエストがないかを調べる。データベースの wp_users テーブルと wp_usermeta テーブルを直接 SQL で確認し、管理者権限（wp_capabilities に administrator を含む）のユーザーに不明なものがないかを調べる方法も有効だ。

この記事のポイント

OptinMonster、TrustPulse、PushEngage は無効化でも攻撃対象になる
管理者一覧とプラグインフォルダをすぐに目視確認する
不正アカウントと不審ファイルは即座に削除する
今後は使わないプラグインを無効化で放置せず完全削除する
セキュリティプラグインだけに頼らず定期手動監査を組み込む

佐々木太陽

WordPress, セキュリティ, ハッキング対策, プラグイン, マルウェア, 管理者アカウント, 脆弱性

お悩み・トラブル解決

2026年7月3日 0

プラグイン更新後に管理画面が真っ白になった時の原因と直し方

プラグイン更新直後に管理画面が真っ白になりエラー表示された場合、FTP で該当プラグインフォルダをリネームして無効化すればすぐに復旧する。特に Groovy Menu 無料版 1.4.7 で発生する `Call to undefined method GroovyMenuSettings::dashboard()` エラーでは、PHP の未定義メソッドが呼ばれているため管理画面が表示できなくなる。

なぜプラグイン更新で管理画面がクラッシュするのか

原因はプラグイン更新後のコードに含まれる不具合だ。今回のケースでは GroovyMenuSettings クラスに `dashboard()` メソッドが存在しないのに `render()` から呼び出そうとしたため、PHP の致命的なエラーが発生した。これにより WordPress のフック処理が中断され、管理画面が表示されない「重大なエラー」画面に切り替わる。

この種のエラーは特定のプラグインに限らず、バージョンアップ時の関数名の誤りや非互換の変更が原因でよく起こる。Query Monitor などのデバッグプラグインを入れていると、エラーメッセージとコールスタックが確認できる。

管理画面を復旧させる具体的な手順

最も確実な方法は、FTP クライアントまたはサーバーのファイルマネージャーを使って問題のプラグインフォルダ名を変更し、WordPress にそのプラグインを無効化させることだ。以下の手順で行う。

STEP 1 FTP クライアントでサーバーに接続する

↓

STEP 2 /wp-content/plugins/ ディレクトリに移動する

↓

STEP 3 問題のフォルダ（例 groovy-menu-free）を右クリック →「名前の変更」

↓

STEP 4 末尾に -disabled など任意の文字列を付けてリネームする

↓

結果管理画面を再読み込みすると正常に表示される。サイト表側も問題がなければ動作する。

上のデモは Groovy Menu 無料版の例だ。フォルダ名変更によって WordPress が「プラグインが見つからない」と解釈し、自動的に無効化してエラーループから抜け出せる。

FTP が使えない場合の代替方法

レンタルサーバーの管理パネル（コントロールパネル）にログインする
「ファイルマネージャー」機能を開き、上記と同じ操作でフォルダ名を変更する
フォルダ名を変えたら管理画面にアクセスし、復旧を確認する

FTP もファイルマネージャーも使えない時のデータベース無効化

サーバーの制限で上記の操作ができない場合、WordPress のデータベースに直接アクセスしてプラグインを無効化する手段がある。

STEP 1 phpMyAdmin または管理パネルのデータベース管理画面を開く

↓

STEP 2 wp_options テーブルを選択し、option_name が active_plugins の行を探す

↓

STEP 3 option_value カラムの編集画面を開き、一時的に値を空文字列 "" に変更して保存する

↓

結果管理画面にアクセスできるようになる。その後、プラグイン一覧画面で改めて必要なプラグインだけを有効化する。

データベースを直接操作するとリスクが伴うため、作業前に必ずバックアップを取得しておく。正常に管理画面へ入れるようになったら、すぐに問題のプラグインを削除するか、安定版がリリースされるまで更新を控える判断が必要になる。

同じトラブルを防ぐための再発防止策

ステージング環境で事前検証する

プラグイン更新を本番サイトに適用する前に、ステージング環境（本番と同じ構成のテストサイト）で動作確認を行うとトラブルを未然に防げる。多くの国内レンタルサーバーではワンクリックでステージングを作成できる機能が提供されている。

自動更新を制御する

WordPress の管理画面ではプラグインごとに自動更新のオン／オフを設定できる。信頼性の高いプラグインだけ自動更新を許可し、不安定なアップデートが多いものは手動更新に切り替えておくと安全だ。

定期バックアップとデバッグモードの活用

更新前にプラグイン一覧とデータベースをバックアップしておけば、万一の問題発生時にも迅速にロールバックできる。また、`wp-config.php` で `WP_DEBUG` を `true` に設定すると詳細なエラー内容が表示され、原因特定が容易になる。ただし本番公開サイトでは普段は `false` に戻しておく。

よくある質問

プラグインを無効化したらサイトの表示が崩れたがどうすればいい？

無効化によってメニューやレイアウトが一時的に変わることはあるが、管理画面が復旧した時点で別のバージョンのプラグインを再インストールすれば元に戻せる。必ず復旧後に適切なバージョンを入れ直すことが前提だ。

エラーログの確認方法は？

FTP で `wp-content/debug.log` が生成されていればダウンロードして確認できる。なければ `wp-config.php` に `define(‘WP_DEBUG_LOG’, true);` を追加してエラーを記録すると、後から詳しい原因を読み取れる。

フォルダ名を変更しても直らない時は？

キャッシュ系プラグインやサーバー側のキャッシュが残っている可能性がある。ブラウザキャッシュのクリア、CDN のキャッシュ削除、サーバーキャッシュのクリア（管理パネルに機能があれば）を順に試すと改善しやすい。

プラグイン開発者が修正版を出すまで待つしかないのか？

問題のバージョンを避けて1つ前の安定版を手動で上書きアップロードすれば一時的に復旧できる。公式リポジトリの「以前のバージョン」から ZIP ファイルを入手し、FTP で上書きすると過去の状態に戻せる。

この記事のポイント

プラグイン更新後の管理画面クラッシュは、該当フォルダのリネームで直ちに復旧できる
FTP が使えなくてもファイルマネージャーやデータベース操作で対処可能
原因は未定義メソッドの呼び出しで、デバッグログで特定できる
ステージング環境での事前テストと定期バックアップが最も有効な予防策

佐々木太陽

FTP, PHPエラー, WordPress, プラグイン, 管理画面エラー

お悩み・トラブル解決

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 から重複行を削除することで一時的に解決する
プラグインファイルの修正パッチで再発を防げるが、公式アップデートまでは注意が必要
データベース操作前には必ずバックアップを取得する

佐々木太陽

Events Manager, WordPress, イベント管理, データベース, トラブル解決, バグ修正, プラグイン

お悩み・トラブル解決

2026年7月2日 0

WordPress更新後にサイトが完全にダウンした時の復旧手順

プラグインやテーマの更新後にサイト全体がダウンし「このサイトで重大なエラーが発生しました」と表示される場合、多くの原因は .htaccess に書き込まれた不適切な指示がサーバー設定と衝突していることにある。FTP / SFTP でサーバーに接続し .htaccess から問題の行を削除するかファイルを一旦削除したあと、WordPress 管理画面でパーマリンク設定を再保存すれば復旧できる。

更新後にサイトが完全にダウンする仕組み

一部のプラグインやテーマは、更新時にパフォーマンス向上や URL の取り回しを目的として .htaccess に独自のルールを自動挿入する。これがサーバーの許容範囲を超えると、Apache が起動時に設定ファイルを解釈できず「500 Internal Server Error」を返し、フロントエンドも管理画面もアクセス不能になる。

典型的なのが Option MultiViews のような指示を勝手に追記するケースだ。この機能は Apache のコンテントネゴシエーション（ファイル名の拡張子を自動補完してリクエストを解決する仕組み）を有効にするが、レンタルサーバーや共用ホスティングではセキュリティとルーティングの競合を防ぐために AllowOverride で無効化されていることが多い。許可されていない場所に書かれた Option MultiViews は「ここでは許可されていません」というサーバーエラーを引き起こし、サイト全体を落とす。

WordPress 本体の更新ではこのような追記はほぼ発生しない。問題が起きるのは、更新と同時に .htaccess を操作する一部のキャッシュ系プラグイン、セキュリティ系プラグイン、多言語プラグインだ。プラグイン開発者のテスト環境と本番サーバーの設定が異なるために発生する「動作確認済み」とされる更新でも、自分の環境では致命的になることがある。

.htaccess のエラーでアクセス不能になった時の復旧手順

STEP 1 FTP クライアントやサーバーのファイルマネージャでサイトに接続する

↓

STEP 2 WordPress インストールディレクトリ直下の .htaccess をダウンロードしてバックアップする

↓

STEP 3 問題の行（例 Option MultiViews）を削除するか .htaccess を一旦削除する

↓

STEP 4 WordPress 管理画面にログインし「設定」→「パーマリンク」を開いて「変更を保存」をクリックする

FTP 接続と .htaccess の場所を確認する

まずは FTP クライアント（FileZilla など）や契約中のサーバーが提供するファイルマネージャでサーバーに接続する。WordPress をインストールしたディレクトリ（多くの場合は public_html か httpdocs）を開き、直下に .htaccess というファイルがあるかを確認する。ドットで始まるファイルはデフォルトで非表示になっている場合があるので、FTP クライアントの設定で隠しファイルを表示するように切り替える必要がある。

エラーログを確認して原因行を特定する（可能な場合）

サーバーのエラーログを見られれば原因の特定は早い。cPanel やコントロールパネルに「エラーログ」または「Error Log」という項目があるので、直近のエントリを確認する。今回のようなケースでは .htaccess: Option MultiViews not allowed here というエラーメッセージが記録されている。この行がログに残っていれば .htaccess 内の Option MultiViews を含む行やブロックを削除するだけで復旧する可能性が高い。

Before（問題のある .htaccess）

 # BEGIN WordPress
 …
 Option MultiViews
 …
 # END WordPress

↓

After（該当行を削除）

 # BEGIN WordPress
 …
 …
 # END WordPress

■ エラーを引き起こす行　■ 削除後

.htaccess を削除して WordPress に再生成させる方法

エラーログを確認できない場合や問題の行を特定できない場合は .htaccess を一旦削除してしまうのが手っ取り早い。削除する前に必ずファイルをダウンロードして手元にバックアップを取っておく。削除後、サイトが表示されるようになったら WordPress 管理画面の「設定」→「パーマリンク」を開き、何も変更せずに「変更を保存」ボタンを押す。これで WordPress が必要最小限の .htaccess を自動生成する。

パーマリンク設定を保存して再生成された .htaccess には WordPress の標準ルールだけが書かれているため、問題を引き起こしていた余計な指示は含まれない。この状態でサイトが正常動作していれば復旧成功だ。

原因となったプラグインの特定と対処

.htaccess を修正しても、問題のプラグインをそのままにしておくと再度更新が走ったときや設定変更時に同じことが起きる。更新直前にどのプラグインやテーマを更新したかを確認し、該当するものを一時的に無効化しておく。

管理画面に入れるなら「プラグイン」画面から該当プラグインを停止する。管理画面にも入れない場合は、FTP で /wp-content/plugins/ ディレクトリにアクセスし、該当プラグインのフォルダごと名前を変更する（例: plugin-name を plugin-name-disabled にする）。これでプラグインが強制的に無効化され、管理画面にアクセスできるようになる。

.htaccess を修正しても直らない場合の追加対応

ブラウザキャッシュとサーバーキャッシュをすべて削除する

.htaccess を修正してもまだエラー画面が表示される場合、キャッシュが古いエラー状態を保持している可能性がある。ブラウザのキャッシュを削除し、サーバー側で Varnish や OPcache などのキャッシュ機構が動いている場合はそれらもクリアする。コントロールパネルにキャッシュ管理機能があればそこから削除し、WordPress 用のキャッシュプラグインを導入しているなら FTP で /wp-content/cache/ ディレクトリの中身を手動で削除する。

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

.htaccess の問題ではなく、更新されたプラグインやテーマのコードそのものが PHP の致命的エラーを起こしている可能性もある。FTP で /wp-content/plugins/ フォルダ全体を plugins-temp などにリネームし、使用中のテーマ（/wp-content/themes/テーマ名）もリネームする。WordPress はプラグインがなくても動作し、有効なテーマがない場合は標準テーマ（Twenty Twenty-Five など）に自動でフォールバックする。これで管理画面に入れれば、あとは問題のプラグインやテーマを一つずつ戻して原因を絞り込む。

サーバー会社に AllowOverride 設定を確認する

Option MultiViews のような指示がサーバー側でどう扱われるかは Apache の AllowOverride 設定で決まる。自前で httpd.conf やバーチャルホスト設定を編集できない共用サーバーでは、サーバー会社に「.htaccess に Option MultiViews を記述したところサイト全体が停止した。この指示を許可する設定に変更できるか」と問い合わせる手段もある。ただしセキュリティ上の理由で許可されないケースが大半なので、その場合はプラグインの設定を見直すか、代替プラグインを検討する必要がある。

更新による .htaccess 破損を防ぐための対策

更新前必ずサイト全体と .htaccess をバックアップする

更新時可能ならステージング環境で先にテストする

更新後即座にサイト全体が表示されるか確認し、問題があれば即座にロールバックする

更新前にかならずバックアップを取る習慣をつける

WordPress 本体、プラグイン、テーマのいずれを更新する場合でも、更新前にサイト全体とデータベースのバックアップを取ることは最も基本的で強力な防御策だ。.htaccess も設定ファイルの一つとしてバックアップ対象に含めておく。バックアップがあれば、今回のようにサイトが完全にダウンしても数分で元の状態に戻せる。

ステージング環境で事前に検証する

本番環境に直接更新を適用する前に、ステージング環境（本番と同一のサーバー設定を持つテストサイト）で動作確認を行うことで、.htaccess の競合や PHP エラーを事前に検出できる。多くの国内レンタルサーバーはコントロールパネルから簡単にステージングサイトを作成できる機能を提供している。少なくとも重要なプラグインのメジャーアップデートでは、このステップを踏むことで大規模なダウンを回避できる。

プラグインの変更履歴を確認し .htaccess 操作の有無を把握する

更新前にプラグインの変更履歴（Changelog）を確認する習慣も有効だ。特に「Improved .htaccess rules」「Added server-level optimizations」などの記述がある場合は要注意で、更新後に .htaccess が書き換わる可能性が高い。こうした更新は必ずバックアップを取ったうえで適用し、適用直後に .htaccess の内容を確認して想定外の追記がされていないかチェックする。

よくある質問

更新後に管理画面だけでなくフロントエンドも真っ白になるのはなぜか

.htaccess のエラーは PHP の処理に入る手前のサーバーレベルで発生するため、WordPress のエラーハンドリング機構が一切働かない。結果としてフロントエンドも管理画面も同じ「500 Internal Server Error」や真っ白な画面になり、WordPress のデバッグモードでもエラーメッセージが表示されないことが多い。

.htaccess を削除しても問題ないのか

WordPress のパーマリンク設定を保存すれば必要なルールは自動で再生成されるので、.htaccess の削除自体は安全だ。ただし独自に追加したリダイレクトルールや BASIC 認証設定などがある場合はバックアップから手動で戻す必要がある。

FTP でサーバーに接続できない場合はどうすればよいか

サーバー会社が提供するコントロールパネル（cPanel など）のファイルマネージャが使えるかを確認する。多くの場合ブラウザから直接ファイルを編集できる。それも使えない状況であればサーバー会社のサポートに連絡し「.htaccess の特定の行を削除してほしい」と依頼するのが最も早い復旧手段になる。

今回のエラーはプラグインの不具合なのか

厳密にはプラグインのコードに問題があるというより、プラグインが想定するサーバー環境と実際のサーバー設定の不一致によって発生する。プラグイン開発者が Option MultiViews が許可されている環境で開発し、許可されていない共用サーバーでエラーが出るケースが典型だ。したがって「不具合」というより環境依存の問題と呼ぶ方が実態に近い。

同じ問題を起こさないために .htaccess をロックできるか

ファイルのパーミッションを 444（読み取り専用）に設定すれば外部からの書き込みは防げるが、WordPress 本体やプラグインが正当な理由で .htaccess を更新する必要がある場合にエラーの原因となる。現実的な対策は、書き換えが発生する更新の前にバックアップを取り、更新後に diff を取って差分を確認する運用だ。

この記事のポイント

.htaccess への不適切な追記が更新後のサイトダウンの直接原因になりやすい
FTP で問題の行を削除するか .htaccess を一旦削除すれば即座に復旧できる
削除後は管理画面のパーマリンク設定で必要最小限の .htaccess を再生成する
原因プラグインを特定し無効化しないと再発するため忘れずに対処する
更新前のバックアップとステージング検証が最も確実な予防策になる

佐々木太陽

htaccess, WordPress, エラー対処, サーバー設定, サイト復旧, トラブル解決, プラグイン

お悩み・トラブル解決

2026年7月2日 0

WooCommerceの税金レポートが表示されない時の原因と直し方

WooCommerce の分析「税金」レポートが突然「表示するデータがありません」になった場合、履歴データの再インポートと分析キャッシュのクリアでほぼ解決する。この症状は注文データや収益レポートが正常でも、税金レポートだけが空白になるのが特徴だ。

なぜ税金レポートだけが空白になるのか

WooCommerce の分析画面は、注文が発生するたびにバックグラウンドで集計テーブルを更新している。しかし、プラグインの更新やサーバーの一時的な負荷、データベースの不整合が重なると、この集計処理が途中で止まることがある。すると注文や収益といった主要レポートは残余データで表示される一方、国別の税金内訳のような細かい集計を必要とするレポートだけが「表示するデータがありません」と出る。

とくに手動で税率を設定している店舗では、税率コードと注文データの突合作業が必要になるため、集計の中断に対して脆弱だ。一時的な不具合であり、データそのものが消失したわけではない。

Before（エラー状態）

税金レポートに「表示するデータがありません」

注文・収益は正常に表示される

履歴データのインポートが「0件中2件」で止まっている

↓

After（正常状態）

国別の税額が一覧表示される

VAT 申告データをそのまま抽出できる

履歴データのインポートが全件完了している

■ エラー状態　■ 正常状態

履歴データを再インポートして集計を再開する

最も確実な解決策は、分析用の履歴データを手動で再インポートすることだ。この操作は既存の注文や顧客データを消さず、集計テーブルだけを再構築する。

STEP 1 管理画面の「分析」→「設定」を開く

↓

STEP 2 ページ下部の「履歴データをインポート」セクションまでスクロール

↓

STEP 3 期間を「すべて」に設定し、「開始」ボタンを押す

↓

STEP 4 インポート完了後、税金レポートを再確認する

「スキップ」チェックボックスに注意する

履歴データのインポート画面には「以前にインポートした顧客と注文をスキップ」というチェックボックスがある。通常はチェックを入れたままでも問題ないが、インポートが途中で止まっている場合は、このチェックを外して全件を再処理するほうが確実だ。件数が多いと時間はかかるが、税金レポートの不整合を解消する近道になる。

インポートが「準備完了」で止まっている場合

履歴データのインポートが「準備完了」と表示され、クリックしても動かない場合は、WooCommerce のスケジュールアクションが滞留している可能性が高い。「WooCommerce」→「ステータス」→「スケジュールされたアクション」を開き、「保留中」のタスクがないか確認する。もし大量に溜まっているなら、WP Crontrol などのプラグインで手動実行するか、サーバーの WP-Cron が正しく動作しているかを調べる必要がある。

分析キャッシュをクリアして表示をリセットする

履歴データの再インポートだけで改善しない場合、分析画面が参照しているキャッシュが破損している。WooCommerce には専用のキャッシュクリア機能が用意されている。

管理画面で「WooCommerce」→「ステータス」→「ツール」を開く
「分析キャッシュをクリア」という項目を探す
「実行」ボタンを押す
画面を更新して税金レポートを再表示する

この操作は注文データや設定を一切変更しない。キャッシュを消すだけなので、安全に何度でも実行できる。実行後すぐに改善しない場合は、ブラウザのキャッシュも個別にクリアしてから再確認する。

ブラウザキャッシュとサーバーキャッシュも疑う

分析キャッシュをクリアしても改善しない場合、ブラウザが古い管理画面を表示し続けている可能性がある。シークレットウィンドウで管理画面を開き、同じ症状が出るかを試す。また、サーバー側で Redis や Memcached などのオブジェクトキャッシュを導入している場合は、そちらのキャッシュもクリアする。

データベースツールで直接修復する最終手段

ここまでの手順で直らない場合、WooCommerce の分析テーブルそのものに不整合が生じている。管理画面の「WooCommerce」→「ステータス」→「ツール」には、分析データベースの検証や修復を行うツールも含まれている。

「分析データベースのテーブルを作成」を実行する（既存テーブルがある場合は何もしない）
「分析データベースのテーブルを検証」を実行し、エラーがあれば修復を試みる

もしこれでも解決しない場合は、ステージング環境（本番とは別のテスト用サイト）に本番のデータを複製し、WooCommerce と WordPress を最新版に更新してから同じ手順を試す。更新によって分析テーブルの構造が修正され、問題が解消することがある。

よくある質問

注文データは消えていないか

消えていない。税金レポートが表示されないのは集計テーブルの不整合であり、実際の注文データは「WooCommerce」→「注文」から確認できる。VAT 申告に必要な情報も、個別の注文画面で確認可能だ。

WooCommerce を更新するのが怖いが、どうすればよいか

WP Staging などのプラグインでステージング環境を作り、そこで先に更新をテストするのが安全だ。問題なければ本番にも反映すればよい。更新を完全に避けるより、検証した上で適用するほうが長期的なリスクは小さい。

手動税率と自動税率のどちらが税金レポートに強いか

WooCommerce Tax 拡張（自動税率）を使うと、税率の管理と集計が一本化されるため、レポートの安定性は上がる。ただし手動税率でも正しく設定されていれば問題なく動作する。今回のように不具合が出たときは、手動税率のほうが原因特定に手間がかかることがある。

分析キャッシュをクリアすると他のレポートに影響するか

影響しない。キャッシュをクリアしても、次回アクセス時に再集計が走るだけだ。むしろ他のレポートでも古いキャッシュによる誤表示が起きていた場合、一括で改善する。

インポートがいつまでも終わらない時の対処法は

注文件数が数万件を超える大規模店舗の場合、インポートに時間がかかることがある。サーバーの PHP 実行時間制限（max_execution_time）が短すぎると途中で停止するため、サーバー管理者に延長を依頼するか、WP CLI を使ってコマンドラインから実行するのが確実だ。

この記事のポイント

税金レポートだけが空白になるのは、集計テーブルの不整合が主な原因
履歴データの再インポートと分析キャッシュのクリアが最も効果的な解決策
「スキップ」チェックを外して全件インポートするとより確実
スケジュールアクションの滞留やサーバーキャッシュも併せて確認する
どうしても直らない場合はステージング環境で更新をテストする

佐々木太陽

WooCommerce, WordPress, トラブル解決, 分析データ, 税金レポート

お悩み・トラブル解決

2026年7月1日 0

Advanced Ads 2.0.23 アップデート後の致命的エラーの直し方

Advanced Ads 2.0.23 にアップデートした途端に「このサイトで重大なエラーが発生しました」と表示される問題は、Pro版のキャッシュバスティング機能が原因だ。管理画面にアクセスできなければ、FTP またはファイルマネージャーでプラグインを手動で一時無効化し、バージョンを 2.0.22 に戻せば即座に復旧する。

なぜ Advanced Ads 2.0.23 で致命的エラーが起こるのか

エラーの直接の原因は、Advanced Ads のコアプラグイン側にある abstract-group.php の 170 行目で、Pro版のキャッシュバスティングモジュールから渡された配列データの型を正しく取り扱えず、TypeError が発生している点だ。PHP 8.4 系の厳格な型チェックによって、以前のバージョンでは警告で済んでいた箇所が致命的エラーに変わった。

内部的には、get_ad_weights メソッドが想定するデータ構造と、キャッシュバスティングが上書きしたグループ情報との間で不整合が起きている。とくに広告グループの重み付け配列に対して isset や empty でアクセスしようとした際に、オフセットとして配列そのものを渡してしまう形になり、PHP が型エラーを投げている。

Before（エラー状態）

Advanced Ads 2.0.23 + Pro キャッシュバスティング有効
→ 「このサイトで重大なエラーが発生しました」

↓

After（解決後）

Advanced Ads 2.0.22 にロールバック
→ サイトが正常表示される

■ エラー状態　■ 修正後

上記のデモは、キャッシュバスティング機能が有効な状態でのエラー発生と、プラグインのダウングレードによる復旧の流れを表している。

管理画面にアクセスできない場合の緊急復旧手順

致命的エラーによって WordPress 管理画面にもログインできない状態では、ブラウザ上の操作だけで問題を解消できない。FTP クライアントか、レンタルサーバーのファイルマネージャーを使ってサーバー上のファイルを直接操作する。

FTP またはファイルマネージャーでプラグインを一時無効化する

サーバーに接続したら、/wp-content/plugins/ ディレクトリへ移動する。ここで advanced-ads フォルダと advanced-ads-pro フォルダの名前を変更する。フォルダ名の末尾に -disabled を付与すれば、WordPress はそのプラグインを認識しなくなり、エラーが止まる。

フォルダ名の変更例は次のとおりだ。
advanced-ads → advanced-ads-disabled
advanced-ads-pro → advanced-ads-pro-disabled

この状態でサイトのフロントエンドにアクセスすると、致命的エラーは出なくなる。ただし広告が一切表示されない点に注意する。次に管理画面へ入れるようになるので、続けてプラグインのバージョンロールバックを行う。

Advanced Ads をバージョン 2.0.22 に戻す

まず FTP でリネームした advanced-ads-disabled フォルダを元の advanced-ads に戻す。Pro版の advanced-ads-pro-disabled は、まだ無効化されたままにしておく。この操作で Advanced Ads の基本プラグインだけが有効化された状態になる。

管理画面にログインし、「Advanced Ads」→「ツール」→「バージョン管理」へ進む。ここでバージョン 2.0.22 を選択し、ロールバックを実行する。ロールバック完了後、Pro版のフォルダ名を元に戻して有効化すれば、2.0.22 の組み合わせで通常運用に復旧できる。

STEP 1 FTP で advanced-ads フォルダと advanced-ads-pro フォルダをリネーム（末尾に -disabled）

↓

STEP 2 advanced-ads フォルダのみ元の名前に戻す（Pro版は無効のまま）

↓

STEP 3 管理画面「ツール」→「バージョン管理」で 2.0.22 にロールバック

↓

STEP 4 Pro版のフォルダ名も元に戻し、有効化して復旧完了

この一連の手順で、管理画面に入れない状態からでも確実にサイトを復旧できる。

キャッシュバスティングを無効化して一時しのぎする方法

管理画面にアクセスできる状態であれば、Pro版のキャッシュバスティング機能をオフにするだけで致命的エラーを回避できる。Advanced Ads Pro の設定画面を開き、「キャッシュバスティング」セクションのトグルを無効化する。これにより cache-busting.class.php の処理が走らなくなり、エラーの発生箇所が呼び出されない。

無効化後にサイトのフロントエンドを再読み込みして、エラーが消えたことを確認する。この方法はあくまで応急処置であり、根本的な修正が公式から提供されるまではキャッシュバスティング機能を使えない点に留意する。広告のインプレッション計測や表示の最適化に影響が出るため、修正版のリリースを待つか、前述のロールバックを適用するほうが望ましい。

PHP 8.4 環境で注意すべきエラーの傾向

PHP 8.4 では、配列オフセットに対する型の取り扱いがさらに厳格化された。今回のエラーも、Cannot access offset of type array in isset or empty というメッセージにあるとおり、配列を別の配列のキーとして使おうとしたコードがエラーになっている。PHP 7.x 系では E_WARNING で済んでいたコードが、8.x 系では TypeError の致命的エラーに格上げされるケースが増えている。

TagDiv Newspaper のような複合的なテーマとビルダー系プラグインを併用している環境では、テーマが内部的にウィジェットブロックを動的サイドバーとしてレンダリングし、その中で Advanced Ads の広告配置が呼び出される。この呼び出し階層が深いほど、わずかな型の不整合がスタックトレース全体を巻き込む致命的エラーに発展しやすい。エラーログのスタックトレースを読むときは、一番上の発生行だけでなく、そのひとつ下の呼び出し元との関係に着目すると原因特定が早まる。

よくある質問

2.0.23 にアップデートしたあとサイト全体が真っ白になるのは同じ原因か

同じ可能性が高い。とくに Pro版のキャッシュバスティングを有効にしている場合、このエラーが発生する。画面が真っ白になるのは PHP の致命的エラーによって WordPress の表示処理が途中で停止しているためだ。サーバーのエラーログを確認すると、今回と同じ TypeError が記録されているはずだ。

ロールバック機能が管理画面から使えないときはどうすればよいか

FTP でプラグインフォルダをリネームして一時無効化し、コアプラグインだけを有効にして管理画面にアクセスできる状態を作る。そのうえで「バージョン管理」からロールバックを実行する。どうしても管理画面に入れない場合は、WordPress 公式プラグインディレクトリから 2.0.22 の ZIP を手動でダウンロードし、FTP で上書きアップロードする方法でもダウングレードできる。

Pro版のキャッシュバスティングを無効にすると広告収益にどの程度影響があるか

キャッシュバスティングは広告の表示を毎回動的に変えることでキャッシュによる同一広告の連続表示を防ぐ仕組みだ。無効化すると、ページキャッシュが効いた状態では同じ広告が繰り返し表示される可能性が高まり、インプレッションの多様性が下がる。短期的な暫定対処としては許容できるが、修正版リリース後は必ず再有効化するほうがよい。

今回のエラーは Advanced Ads 無料版だけでも発生するのか

エラーの起点はコアプラグインの abstract-group.php だが、実際に問題を引き起こしているのは Pro版のキャッシュバスティングモジュールだ。無料版のみの利用では通常発生しない。ただし同じ PHP 8.4 環境で他のアドオンを使っている場合は、類似の型エラーに注意が必要だ。

この記事のポイント

Advanced Ads 2.0.23 + Pro キャッシュバスティングの組み合わせで発生する
管理画面にアクセスできないときは FTP でプラグインフォルダをリネームして無効化する
コアプラグインを 2.0.22 にロールバックすれば復旧できる
キャッシュバスティングの無効化は暫定対処であり根本解決にはならない
PHP 8.4 の厳格な型チェックがエラーの引き金になっている

佐々木太陽

Advanced Ads, WordPress, トラブル解決, プラグイン, 致命的エラー

お悩み・トラブル解決

« 前ページへ次ページへ »

Category Archive お悩み・トラブル解決

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

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

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

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

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

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

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

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

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

よくある質問

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

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

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

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

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

この記事のポイント

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

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

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

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

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

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

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

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

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

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

よくある質問

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

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

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

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

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

この記事のポイント

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

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

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

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

よくある質問

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

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

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

この記事のポイント

Elementor エディターが極端に重くなる根本原因は何か

4,400 個のコンテナは異常な数値なのか

エディター速度を改善する具体的な手順

まずは Elementor の「実験」機能とパフォーマンス設定を最適化する

ページのコンテナ構造を平坦化する

ACF 動的タグの使用を見直す

サーバー側のチューニングを確認する

不要なプラグインのスクリプトをエディター画面から除外する

再構築せずに長期的な安定性を確保する設計の考え方

よくある質問

コンテナ数を減らすとデザインが崩れるのでは？

ACF の動的タグをやめると運用が面倒にならないか？

Elementor 以外のビルダーに移行すべきか？

PHP 8.4 との相性問題はあるか？

キャッシュ系プラグインはエディター速度に影響するか？

この記事のポイント

なぜ無効化したプラグインで侵入されたのか

自分のサイトが影響を受けているか確認する手順

管理者アカウントの一覧を調べる

プラグインフォルダに不審な PHP ファイルがないか調べる

不正アクセスが発覚した場合の緊急対応

不正な管理者アカウントを即座に削除する

不正ファイルを削除し、該当プラグインを完全に除去する

サイト全体のマルウェアスキャンを実施する

再発防止と今後のセキュリティ対策

使用していないプラグインやテーマは「無効化」ではなく「削除」する

プラグインの更新を常に最新に保ち、導入元を精査する

定期的な管理者アカウントとファイルの監査を組み込む

よくある質問

無効化していてもなぜハッキングされたのか

Wordfence が入っていれば安心なのか

MonsterInsights を使っているが該当プラグインは入れていない

すでに削除したが、まだ不安が残る場合の最終確認方法は

この記事のポイント

なぜプラグイン更新で管理画面がクラッシュするのか

管理画面を復旧させる具体的な手順

FTP が使えない場合の代替方法