タグアーカイブ プラグイン更新

CCBillプラグイン1.3.2更新で重大なエラーが出た時の対処法

CCBillプラグイン1.3.2更新で重大なエラーが出た時の対処法

CCBillプラグインを1.3.2へ更新した直後にサイトが落ちた場合、原因は更新版に必須のincludes/GelatoConfig.phpが同梱されていないことだ。対処は1.3.1へロールバックするのが確実で、require_once行の削除や空ファイルの作成では正常に戻らない。

なぜプラグイン更新後にサイトが落ちるのか

なぜプラグイン更新後にサイトが落ちるのか

プラグインのメインファイルは読み込み時にrequire_once ‘includes/GelatoConfig.php’;という命令を実行する。ところが1.3.2の配布ZIPにはincludesディレクトリに該当ファイルが含まれていない。PHPは必要なファイルを開けないため、その場で処理を中断し、WordPressは「このサイトで重大なエラーが発生しました」という画面に切り替わる。

更新後 1.3.2 require_once で includes/GelatoConfig.php を読み込む
エラー ファイルが存在しないため「このサイトで重大なエラーが発生しました」と表示される
対処後 1.3.1 必要なファイルが揃っている旧版に戻して正常動作

このデモは、更新版で必須ファイルが欠落した際にエラーが発生し、旧版で解消する流れを表している。

読み込み失敗が致命的エラーへ進む流れ

require_onceは指定したファイルを必ず読み込む命令であり、見つからなければPHPの実行が止まる。WordPressはこの致命的エラーを検知して、訪問者には復旧用の画面を表示し、管理者には状況を伝えるメールを送ることがある。サイトが突然止まった場合は、まず更新直後に起きたことを前提に動くと早期に原因へたどり着ける。

他のファイルも同じクラスに依存している

1.3.2の他の複数ファイルはGelatoConfigクラスのメソッドやプロパティを呼び出している。そのため、require_once行をコメントアウトしたり、中身のないincludes/GelatoConfig.phpを作ったりしても、次の段階でクラスが見つからないエラーへ変わるだけだ。今回の不具合は行の書き換えで吸収できる規模ではない。

エラーログで原因を確定させる手順

エラーログで原因を確定させる手順

画面が真っ白になったり、重大なエラーの表示だけでは原因が見えない。まずはWordPressのデバッグログを有効にして、どのファイルで止まっているかを確認する。

wp-config.phpでデバッグログを有効にする

FTP・SFTPでサーバーに接続し、WordPressのルートにあるwp-config.phpを編集する。以下の定数を設定すると、エラー内容がwp-content/debug.logに記録される。

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

debug.logに記録された該当行を確認する

debug.logを開くと、require_once()がincludes/GelatoConfig.phpを開けなかったことや、GelatoConfigクラスが見つからない趣旨のエラー(英語表示では ‘Class GelatoConfig not found’)が記録されている。このログが取れたら、原因はプラグインのファイル欠落であると確定できる。

旧バージョンへ戻す具体的な手順

旧バージョンへ戻す具体的な手順

管理画面にアクセスできるかどうかで手順が変わる。ここでは先に全体フローを確認し、それぞれの詳細を説明する。

STEP 1 配布ページから1.3.1のZIPをダウンロードする
STEP 2 FTP・SFTPで wp-content/plugins/ へ接続する
STEP 3 既存プラグインフォルダを旧版で上書きする
STEP 4 キャッシュを削除し、サイトと管理画面を確認する

ロールバックの基本手順を示した。それぞれの詳細は次項で解説する。

公式配布ページから1.3.1のZIPを入手する

WordPress.orgのプラグインページを開き、下部にある詳細表示(Advanced View)から過去の版を選べる。画面下部のバージョン選択で1.3.1を指定し、ZIPをダウンロードする。ローカルに展開して、includes/GelatoConfig.phpが含まれていることをこの段階で確認しておくと安心だ。

FTP・SFTPでプラグインフォルダを置き換える

FTP・SFTPクライアントでサーバーに接続し、wp-content/plugins/ の該当プラグインフォルダを開く。既存のフォルダをいったん別名にリネームして退避し、展開した1.3.1のフォルダをアップロードする。リネーム後に新しいフォルダを置くと、サイト上では1.3.1が読み込まれる。

管理画面に入れないときの一時的な復旧

サイト全体が落ちて管理画面にも入れない場合は、FTP・SFTPで該当プラグインのフォルダをリネームして無効化する。これでサイトが表示されるようになれば、管理画面にログインして旧版ZIPをアップロードできる。自動更新が走る環境では、復旧前に更新を止めておくのが確実だ。

キャッシュを削除して反映を確認する

旧版への置き換え後は、サイトのキャッシュプラグインとブラウザのキャッシュを削除する。サーバー側キャッシュを使っている場合はそれもクリアする。その後、フロントと管理画面の両方が表示され、プラグイン設定が1.3.1に戻っていることを確認する。

require_once行の削除や空ファイルでは直らない理由

require_once行の削除や空ファイルでは直らない理由
誤った対処 行の削除 → クラスが見つからず別のエラーが発生する
誤った対処 空ファイルの作成 → 同じくクラス未定義で停止する
正しい対処 旧版1.3.1へ戻す → 欠落ファイルが揃い正常動作

部分的なコード修正では別のエラーへ移るだけで、旧版への切り戻しが最短の解決になる。

GelatoConfigクラスは複数のファイルから参照されている

1.3.2のコードはGelatoConfigクラスに依存する構造になっている。require_once行を消すとファイル読み込みは通っても、その後でクラスのプロパティやメソッドを呼ぶ箇所がエラーになる。空ファイルを作ってもクラス定義がないため、PHPは同じ理由で停止する。問題の本質は設定ファイルの有無ではなく、配布物からクラス定義ごと抜け落ちている点にある。

誤った修正をした場合のリスク

プラグイン本体を直接書き換えると、将来の更新で上書きされ、変更が失われる。また、クラス定義を部分的に再現できたとしても、決済処理など他の機能に影響が出るおそれがある。商用サイトでは旧版へ戻す方法が最も安全だ。開発元が修正版を配信するまでは、1.3.1に留めて更新を保留する。

再発を防ぐために更新前に確認したいこと

再発を防ぐために更新前に確認したいこと

ステージング環境で先に更新を試す

本番サイトへそのまま更新を適用せず、コピー環境(ステージング)でプラグイン更新を実行する。更新後にフロントと管理画面、主要な導線を一通り確認し、エラーがないことを確かめてから本番へ反映する。ステージング環境が用意できない場合は、更新前にフルバックアップを取っておく。

更新前に旧版のZIPを確保しておく

プラグインは自動更新で最新版だけが残り、旧版の入手経路が分からなくなることがある。今回のように最新版が壊れているケースでは、更新前に利用中のバージョンのZIPをダウンロードして保管しておくと速やかに戻せる。プラグインページの詳細表示からダウンロードできる。

更新直後に異常を検知したらすぐに切り戻す

サイトを更新した直後は、必ずトップページと管理画面、問い合わせフォームなど主要機能を開いて確認する。重大なエラーが出た場合は、原因調査より先に旧版へ戻すのが先決だ。ログの確認はその後で行い、開発元の修正版が出るまで更新を保留する。

よくある質問

プラグインを1.3.2に更新したのに管理画面に入れません。どうすればいいですか

FTP・SFTPでwp-content/plugins/ の中にある該当プラグインのフォルダをリネームして無効化する。これで管理画面に入れるようになったら、旧版1.3.1のZIPをアップロードして再び有効化する。

旧版の1.3.1はどこでダウンロードできますか

WordPress.orgのプラグインページにある詳細表示(Advanced View)から過去の版を選んでダウンロードできる。今回のような更新直後の不具合に備え、普段から利用中のバージョンのZIPを手元に保管しておくのが有効だ。

require_once行を削除してもサイトは戻らないのでしょうか

戻らない。削除すると次の段階でGelatoConfigクラスが見つからないエラーに変わる。空のファイルを置いてもクラス定義がないため解消しない。旧版へ戻すのが最短の対処だ。

プラグイン1.3.2に自動更新されないようにするには

該当プラグインの自動更新をオフにするか、サイト全体の自動更新設定でプラグイン更新を手動に切り替える。ただし修正版が公開された場合は、手動で更新を適用する必要がある。

サイトが重大なエラー画面のままの場合は、メールは届きますか

WordPressがサイト管理者へ復旧用リンク付きのメールを送ることが多い。メールが届かない場合は、FTP・SFTPでプラグインを無効化して管理画面への導線を確保する。

この記事のポイント

  • 1.3.2では必須ファイルincludes/GelatoConfig.phpが欠落している
  • 行の削除や空ファイルではエラーの種類が変わるだけで直らない
  • 旧版1.3.1へ戻すのが最短の対処だ
  • 旧版ZIPはプラグインページの詳細表示から入手できる
  • 更新前にはバックアップと旧版の確保、ステージングでの確認を行っておく
プラグイン更新でテーマの色設定が消えた時の原因と戻し方

プラグイン更新でテーマの色設定が消えた時の原因と戻し方

プラグインを更新した直後に、テーマのカスタマイザーやページビルダーで設定したリンク色やボタン色がデフォルトに戻る現象は、プラグインが出力する CSS の読み込み順序やスタイルの上書きルールが更新によって変わったことが主な原因だ。まずは設定パネルで該当の色をもう一度選んで保存し、サーバーキャッシュとブラウザキャッシュを完全にクリアすれば、多くのケースは即座に解決する。

更新後にテーマの色やスタイルが消えるのはなぜか

更新後にテーマの色やスタイルが消えるのはなぜか

プラグインのアップデートでは新機能の追加やバグ修正だけでなく、内部で使う CSS クラス名の変更やスタイルシートの構造そのものが刷新される場合がある。とくにページビルダー系のプラグインや、テーマが提供する「グローバルカラー」機能を拡張するアドオンでは、アップデートによって優先度の高い新しいデフォルトスタイルが追加され、それまでサイトの表示に適用されていたユーザー定義の色指定が打ち消されてしまう。

管理画面の設定パネル上では、以前に選んだ紫色や緑色が「選択中」として残っているように見えるのに、実際のフロントエンドではプラグインが用意したデフォルトの青色や無指定状態に戻ってしまうのはこのためだ。設定データ自体がデータベースから消えたわけではなく、CSS の読み込み優先順位の変化によって見た目だけが元に戻っている状態と理解するとよい。

更新直後に起こっていること
【更新前】
ユーザー指定の紫色(#9b59b6)が矢印やリンクに反映されている
【更新直後】
プラグイン追加のデフォルト青(#1976d2)がユーザー指定を上書きしてしまう
設定データは残っている
データベース内のカラー設定値に変更はない
管理画面の設定パネルでは紫色が選択されたまま
更新前・更新直後の表示状態  設定データの保存状況

上の図のように、データベースに保存された色の設定値は更新後も消えていない。プラグインが出力する CSS の層が一枚増えて、その層のデフォルト指定が手前にかぶさっているだけの状態だ。この仕組みを理解しておけば、むやみにテーマ全体を作り直す必要はないとわかる。

色設定を元に戻すための具体的な4つの手順

色設定を元に戻すための具体的な4つの手順
STEP 1 設定の再保存とキャッシュの完全削除
STEP 2 全プラグインを一時停止して競合を確認
STEP 3 セーフモード(リカバリーモード)で編集
STEP 4 旧バージョンへのロールバック

設定データが無事なら、原因の多くは CSS の読み込み順序の衝突とキャッシュの残留だ。小手先の修正を重ねるよりも、この4ステップを順番に試していく方が結果的に早い。

STEP 1|設定を再保存してキャッシュをすべて消す

該当のプラグイン設定画面を開き、色指定のフィールドでいったん別の色を選んでから再度目的の色に設定し直し、「変更を保存」ボタンを押す。この操作でプラグインは最新バージョンの CSS 生成ロジックを使って、現在の設定値を CSS として書き出す。

保存後は以下の3つのキャッシュを完全に削除する。どれか一つでも残っていると、古い表示のまま問題が続いているように見える。

  • プラグインやサーバー側で使っているキャッシュ(WP Rocket や W3 Total Cache など)をすべて削除する
  • CDN(Cloudflare など)を使っている場合は、CDN のキャッシュもパージする
  • ブラウザのキャッシュを削除するか、シークレットウィンドウで表示を確認する

ここまで実施して色が戻れば、問題は一時的な読み込み順序の不整合だったことになる。これで直らない場合は、次にプラグイン同士の競合を疑う。

STEP 2|全プラグインを停止して問題の範囲を絞る

更新したプラグイン以外にも、CSS や JavaScript を操作するプラグインが複数入っていると、スタイルの打ち消し合いが起こることがある。トラブルシューティングの基本として、更新したプラグインだけを有効にし、それ以外のプラグインをすべて無効化した状態で表示を確認する。

この状態で正しい色が表示されれば、他のプラグインとの競合が原因だ。一つずつ再有効化して、問題が再発するタイミングを特定する。操作は本番環境ではなく、必ずステージング環境かローカル環境で行う。本番サイトでプラグインをまとめて停止すると、レイアウト崩れや機能停止が起こる可能性がある。

STEP 3|セーフモードでクリーンな状態を作る

WordPress 5.2 以降に搭載されたサイトヘルス機能の一部として「致命的エラーからの保護(リカバリーモード)」がある。更新後に画面が真っ白になったり「このサイトで重大なエラーが発生しました」というメッセージが出た場合は、この仕組みが自動で発動し、管理者宛てにリカバリーモード用のリンクがメールで届く。

リカバリーモードでは、問題のプラグインが無効化された状態で管理画面に入れる。ここで該当プラグインの設定を開き、色指定を再保存してからプラグインを再有効化することで、破損したキャッシュや不完全な更新ファイルが原因の不具合を解消できる場合がある。

STEP 4|プラグインを旧バージョンに戻す

STEP 1〜3 で解決しない場合や、どうしてもサイトを今すぐ正常な見た目に戻す必要がある場合は、WP Rollback などの専用プラグインを使って該当プラグインを更新前のバージョンに戻す。この方法を取れば、開発者側の修正パッチがリリースされるまでの間もサイトの見た目を維持できる。

旧バージョンへのロールバックは一時的な回避策であり、セキュリティ修正や脆弱性対策が含まれるアップデートの場合は注意が必要だ。ロールバックを実施したら、必ずプラグインの公式サポートフォーラムや変更履歴を確認し、次の安定版がリリースされたタイミングで速やかに更新すること。

修正パッチを適用する際の注意点

修正パッチを適用する際の注意点

プラグイン開発者から修正版の ZIP ファイルが提供される場合がある。通常の管理画面から「プラグイン」→「新規追加」→「プラグインのアップロード」でインストールできるが、すでに同名のプラグインが存在する場合は「上書きインストール」を求められる。

上書きインストールの前に、必ずサイト全体のバックアップ(データベースとファイル)を取得しておく。ZIP ファイルのアップロード時に「500 Internal Server Error」が発生した場合は、サーバーの PHP メモリ不足やアップロードサイズ制限が原因の可能性が高い。サーバーのエラーログを確認し、必要に応じて `php.ini` や `.htaccess` でメモリ上限や実行時間の設定を一時的に引き上げる。

FTP が使える環境なら、管理画面からのアップロードではなく、ZIP を解凍してプラグインフォルダ(`/wp-content/plugins/プラグイン名/`)に直接アップロードする方法もある。この場合はファイルの上書きミスを防ぐため、既存フォルダをリネームして退避させてから新しいファイルを配置する方が安全だ。

よくある質問

プラグインを更新前のバージョンに戻すにはどうすればよいか

「WP Rollback」プラグインをインストールすると、プラグイン一覧画面に「Rollback」リンクが追加される。クリックすると過去のバージョン一覧が表示され、任意のバージョンにワンクリックで戻せる。手動で戻す場合は、プラグインの公式ディレクトリにある「Previous Versions」から旧バージョンの ZIP をダウンロードし、FTP で上書きアップロードする。

色設定が毎回のアップデートで消えるのを防ぐ方法はあるか

プラグインのグローバルカラー機能に頼らず、子テーマの `style.css` にカスタム CSS として直接色指定を書いておく方法が最も安定する。テーマやプラグインのアップデートでは子テーマのファイルは上書きされないため、色指定が勝手にリセットされる心配がなくなる。

キャッシュを削除しても色が戻らない場合はどうするか

ブラウザの「検証ツール(F12キー)」を開き、色が変わってしまった要素をクリックして Styles パネルを確認する。目的の色指定に打消し線が入っていて、別の CSS ルールが優先されている場合は、そのルールの出どころ(プラグイン名やファイル名)を特定できる。特定できたら、より強いセレクタ(ID セレクタや `!important`)を使って子テーマ側で上書きする。

プラグイン更新後にサイト全体が真っ白になった時の対処法は

「このサイトで重大なエラーが発生しました」と表示される場合は、FTP で `/wp-content/plugins/該当プラグインのフォルダ/` をリネームして無効化し、管理画面にアクセスできる状態を確保する。その後、`wp-config.php` に `define(‘WP_DEBUG’, true);` を追加してデバッグモードを有効にし、具体的なエラー内容を確認してから対応を進める。

自動更新を止めておくことは可能か

特定のプラグインだけ自動更新を無効化するには、`wp-config.php` に手を加えるか、Easy Updates Manager のような管理プラグインを使う。ただし自動更新を止めるとセキュリティ修正の適用も遅れるため、本番環境では更新前にステージング環境で動作確認する運用体制を整えておくことが現実的な対策になる。

この記事のポイント

  • プラグイン更新で色が消えるのは、設定データの消失ではなく CSS の読み込み順序や優先度が変わったことが原因
  • 設定の再保存とキャッシュ完全削除でほとんどは即座に解決する
  • 直らない場合はプラグイン競合の切り分けやリカバリーモードを試す
  • 恒久対策として、重要な色指定は子テーマの CSS に直接書いておくとアップデートに左右されない
Premium Addonsの更新で重大なエラーが出た時の原因と対処法

Premium Addonsの更新で重大なエラーが出た時の原因と対処法

Premium Addons for Elementor の更新後に「このサイトで重大なエラーが発生しました」と表示されサイトが落ちる場合、原因は更新パッケージのファイル欠損や破損にある。is_widget() メソッドが見つからないエラーがログに記録されているなら、プラグインの手動再インストールで解決する可能性が高い。

なぜ Premium Addons の更新で致命的エラーが起きるのか

なぜ Premium Addons の更新で致命的エラーが起きるのか

Premium Addons 4.11.91 から 4.11.93 への更新中に「このサイトで重大なエラーが発生しました」が表示されるケースでは、エラーログに Call to undefined method PremiumAddons\Modules\Woocommerce\Module::is_widget() が記録される。

このエラーは、WordPress の自動更新や管理画面からのワンクリック更新を実行した際に、プラグインのファイル一式が完全に展開されず、一部の PHP ファイルが欠損した状態でバージョンだけが切り替わった場合に発生する。module-base.phpis_widget() メソッドを呼び出そうとしたタイミングで、その定義が存在せず PHP が致命的エラーを返す仕組みだ。

この種のエラーは Premium Addons に限らず、大規模なアドオン系プラグインの更新時に時折見られる。サーバーの実行時間制限やメモリ不足が引き金になることもあるが、今回は開発元が更新パッケージの不備を認めて修正版を再提供している。つまり原因は利用者側の環境ではなく、配信された更新ファイル自体の不備だ。

Before(エラー発生時)
管理画面から Premium Addons 更新 重大エラー
Error: Call to undefined method
PremiumAddons\Modules\Woocommerce\Module::is_widget()
After(修正後)
手動で 修正済み ZIP をアップロード 更新成功
WooCommerce モジュールが正常に読み込まれ、エラーログにも記録なし
エラー状態  修正後

このデモは、ファイル欠損が原因で起こる典型的なエラーパターンとその解消後の状態を示している。

手動でプラグインを再インストールする手順

手動でプラグインを再インストールする手順

自動更新でエラーが起きた場合、有効な解決策は修正版の ZIP ファイルを入手し手動でアップロードすることだ。以下の手順で進める。

STEP 1 Premium Addons の公式サイトまたは WordPress.org のプラグインページから最新の ZIP ファイルをダウンロードする
STEP 2 WordPress 管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP を選択
STEP 3 「今すぐインストール」を実行し、既存のプラグインを上書きすることを確認
STEP 4 プラグインを有効化し、サイトキャッシュを全削除して動作を確認

手動アップロードによる上書き更新は、ファイルの破損や欠損を確実に修復できる方法だ。

公式サイトから ZIP を入手する

Premium Addons は WordPress.org の公式プラグインディレクトリで配布されている。検索エンジンで「Premium Addons for Elementor WordPress」を検索し、プラグインページの「ダウンロード」ボタンから ZIP ファイルを取得する。有料版を使っている場合は、購入元のアカウントページから最新バージョンをダウンロードする。

管理画面から ZIP をアップロードする

「プラグイン」→「新規追加」を開き、ページ上部の「プラグインのアップロード」ボタンをクリックする。ファイル選択画面で先ほどダウンロードした ZIP を選び、「今すぐインストール」を押す。WordPress が「すでにインストールされています」と検出した場合、「現在のものをアップロードしたものに置き換える」という選択肢が出るのでそれを選ぶ。

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

プラグインの上書きが完了したら、サイトのキャッシュを徹底的に削除する。キャッシュ系プラグイン(W3 Total Cache や WP Super Cache など)の「全キャッシュ削除」機能を実行し、さらにブラウザのキャッシュもクリアする。サーバー側で Nginx FastCGI キャッシュや Redis オブジェクトキャッシュを使っている場合はそれらも合わせてクリアする。

それでもエラーが続く場合の追加対応

それでもエラーが続く場合の追加対応

エラーログの詳細を確認する

手動再インストール後もエラーが続くなら、まず WooCommerce のステータスログを開く。「WooCommerce」→「ステータス」→「ログ」タブから、fatal-errors で始まる最新のログを確認する。別のメソッドやファイルでエラーが出ている場合、プラグインの競合が原因である可能性が高い。

プラグイン競合の切り分けを実施する

Premium Addons 以外の全プラグインを一時的に無効化し、WordPress の標準テーマ(Twenty Twenty-Five など)に切り替える。その状態で Premium Addons だけを有効にしてエラーが再現するか確認する。ここで問題が解消すれば、無効化したプラグインの中に競合相手がいる。

開発元に修正版をリクエストする

公式リポジトリのバージョンでもエラーが解消しない場合は、Premium Addons のサポートフォーラムにエラーログ全文と環境情報(WordPress バージョン、PHP バージョン、Elementor バージョン)を添えて報告する。開発元が個別の修正パッケージを提供してくれることがある。

よくある質問

管理画面すら開けない状態でどうやって直せばいいか

FTP クライアントまたはレンタルサーバーのファイルマネージャーで /wp-content/plugins/premium-addons-for-elementor/ ディレクトリを一旦リネームする。これでプラグインが無効化され管理画面にアクセスできるようになる。その後、正しい ZIP を展開し直して元のディレクトリ名に戻し、管理画面から有効化する。

WooCommerce を無効にすればエラーは出なくなるのか

エラーの発生箇所が WooCommerce 用モジュールであるため、WooCommerce 本体を無効化すればこの特定のエラーは止まる。しかしショップ機能が完全に停止するため、恒久対応にはならない。あくまで緊急避難として認識し、速やかに Premium Addons の修正を行うべきだ。

自動更新を止めて手動更新に切り替えるべきか

Premium Addons に限って一時的に自動更新を無効化するのは有効な予防策だ。「プラグイン」画面で該当プラグインの「自動更新を有効化」のチェックを外せば、次回以降の更新は手動で制御できる。問題が完全に解決したと確認できた後に再度自動更新を有効化すればよい。

PHP のバージョンが原因ということはあるか

Premium Addons は PHP 8.3 に対応しているため、今回の is_widget() エラーは PHP バージョンに起因するものではない。ただし PHP 8.x 系ではメソッドの未定義エラーが例外ではなく致命的エラーとして扱われるようになったため、以前の PHP 7.x 系では警告で済んでいた問題がサイト停止に直結するようになっている。

この記事のポイント

  • Premium Addons 更新後の重大なエラーは、更新ファイルの欠損や破損で定義されていないメソッドを呼び出すのが原因
  • 手動で最新の ZIP ファイルをアップロードして上書きすれば解決する
  • キャッシュの全削除を忘れずに行う
  • 再発防止として自動更新の一時停止や更新前のバックアップが有効
  • FTP からのプラグイン無効化は管理画面にアクセスできないときの最終手段
プラグイン更新後に WordPress ログイン不能になる「Cookie がブロックされました」エラーの直し方

プラグイン更新後に WordPress ログイン不能になる「Cookie がブロックされました」エラーの直し方

CF7 Google Sheet Connector バージョン 5.2.1 へのアップデート直後から、WordPress の管理画面にまったくログインできず、ログインページで「Cookie は予期しない出力のためにブロックされました」というエラーが表示されるなら、直接の原因はそのプラグインの不具合にある。FTP を使ってプラグインフォルダをリネームし、強制的に無効化すればログイン機能をすぐに回復できる。

プラグイン更新後に WordPress へログインできなくなる根本原因

プラグイン更新後に WordPress へログインできなくなる根本原因

WordPress のプラグインやテーマは、PHP の開始タグを閉じずにファイルを記述するのが一般的だ。しかし、何らかの原因でファイルの末尾に余分なスペースや空行が紛れ込んだり、意図しない echoprint が実行されたりすると、WordPress 本体が HTTP レスポンスを送信する前に「予期しない出力」が生まれる。

この予期しない出力は、ログイン機能で使われるセッション Cookie や setcookie() 関数の動作を妨げる。PHP は一度でも出力が行われると、後から HTTP ヘッダーを書き換えられないため、WordPress が正しく Cookie を発行できなくなり、結果として「重大なエラー」画面や「Cookie は予期しない出力のためにブロックされました」というエラーメッセージを返すようになる。

Before(異常なプラグイン有効時)
WordPress プラグイン 予期しない出力(空行や echo 等)
ヘッダー送信前にボディが出力される
→ ログイン時に Cookie 発行失敗
→ 「重大なエラー」「Cookie がブロックされました」表示
After(プラグインを無効化後)
WordPress 問題プラグイン停止中
不要な出力なし
→ Cookie 発行成功、ログイン再開
エラー状態  修正後

このデモが示すのは、問題のプラグインが WordPress のログインプロセスに割り込んでしまう仕組みだ。CF7 Google Sheet Connector 5.2.1 をはじめ、ごく一部のバージョンでこの現象が発生するケースが海外フォーラムでも報告されている。根本的には、プラグイン開発者が PHP ファイルの末尾やインクルード処理に余計な出力を残してしまうヒューマンエラーに起因する。

「Cookie がブロックされました」はなぜ起こるのか── unexpected output の詳細

「Cookie がブロックされました」はなぜ起こるのか── unexpected output の詳細

「Cookie は予期しない出力のためにブロックされました」は、WordPress のログイン時でなくても、プラグインの有効化画面で「このプラグインは有効化中に 3 文字の予期しない出力を生成しました」といった警告文とともに現れる。この警告は、まさに PHP が <?php の開始タグよりも前やファイル末尾に余計な空白文字を出力している証拠だ。

コンタクトフォームの送信自体は成功し、Google スプレッドシートへのデータ転送も動いているのに、ログインだけが機能しなくなるのは、フォーム送信とログイン認証で通る PHP の実行経路が異なるためだ。フォーム送信時にはセッション Cookie を新たに発行する必要がないため、表面上は問題が表面化しにくい。しかし wp-login.php や管理画面の認証周りでは、必ず Cookie のセットが行われるので、エラーが必ず検出される。

FTP で問題のプラグインを無効化する具体的な手順

FTP で問題のプラグインを無効化する具体的な手順

管理画面にログインできない状態では、ブラウザ上の操作だけではプラグインを停止できない。ここで必要なのが、契約しているレンタルサーバーの FTP アカウントを使った直接のファイル操作だ。FTP クライアントやサーバー管理画面のファイルマネージャー機能を利用して、次の手順を実行する。

STEP 1 FTP クライアントまたはサーバーのファイルマネージャーで WordPress インストール先に接続する
STEP 2 /wp-content/plugins/ ディレクトリに移動する
STEP 3 問題のプラグインのフォルダ(例 cf7-google-sheet-connector)を探し、リネームする(末尾に _disable などをつける)
STEP 4 ブラウザで /wp-admin/ にアクセスし、通常通りログインできるか確認する

リネームはフォルダ名の先頭や末尾に「_」を付けるだけでも十分であり、WordPress がそのプラグインを認識できなくなる。ログインが回復したら、管理画面の「プラグイン」一覧から、無効化された状態の当該プラグインを確認できる。ここで「削除」を選べば、問題のバージョンは完全に取り除かれる。

プラグインを以前のバージョンに戻して再発を防ぐ

プラグインを以前のバージョンに戻して再発を防ぐ

CF7 Google Sheet Connector を使い続ける必要があるなら、安定していた旧バージョンに戻すか、開発元が修正パッチを公開するのを待つことになる。WordPress 管理画面からプラグインを再インストールする際は、あえてバージョン 5.2.1 を避け、プラグインページ下部の「以前のバージョン」セクションや、WP Rollback のようなロールバック専用プラグインを使って前のバージョンにダウングレードできる。

また、問題が発生したプラグインをどうしても最新で使い続けたいのであれば、プラグインのサポートフォーラム(WordPress.org 内)で「バージョン 5.2.1 で unexpected output が発生しログイン不能になる」という事象を報告し、修正を促すのが建設的だ。開発者が原因を把握すれば、比較的早期に新しいバージョンがリリースされる可能性が高い。

よくある質問

FTP アカウント情報がわからない場合はどうすればいいか

契約しているレンタルサーバーの管理画面(コントロールパネル)に、FTP アカウントの設定やファイルマネージャー機能が用意されているケースが多い。cPanel なら「FTP アカウント」メニューから新規作成やパスワード再設定が可能だ。サーバー会社のサポートに問い合わせれば、FTP 接続情報を再発行してもらえることもある。

プラグインを無効化してもログインエラーが直らない

同様の症状が他のプラグインやテーマでも発生する可能性がある。全プラグインを無効化し、標準テーマ(Twenty Twenty-Five 等)に切り替えた状態で症状が消えるかどうかを確認する。それでも直らない場合は、サーバーの PHP エラーログを調べ、別の致命的エラーが起きていないか検証する必要がある。

プラグインの更新を止める方法はあるか

WordPress の標準機能では特定プラグインの自動更新だけを選択的に止めることはできないが、プラグイン「Easy Updates Manager」を使うと、プラグイン単位で自動更新を無効化できる。問題のあるバージョンを避けつつサイトを安全に保つには、ステージング環境で事前に更新テストを行うのが最も確実だ。

フォームのデータが送信されていれば問題ないのか

フォームが動いているからといって放置するのは危険だ。ログイン不能はサイト全体の管理を妨げるだけでなく、同じ予期しない出力が他の機能(RSS フィードや REST API)にも影響を及ぼす恐れがある。できる限り早急に原因のプラグインを停止し、サイト全体の健全性を取り戻す必要がある。

プラグインを手動で削除してもデータは残るのか

CF7 Google Sheet Connector の場合、コンタクトフォームの設定や Google スプレッドシートとの認証情報はデータベースに保存される。そのため、プラグインフォルダを削除しても設定情報は消えない。再度同じプラグインをインストールすれば、以前の連携設定を引き継げる可能性が高いが、念のためデータベースのバックアップを取ってから削除するのが安全だ。

この記事のポイント

  • CF7 Google Sheet Connector 5.2.1 では unexpected output によりログイン不能になる不具合が報告されている
  • 「Cookie がブロックされました」は PHP の予期しない出力が原因で、FTP を使ったプラグイン無効化で回復する
  • 管理画面にログインできなくても、FTP やファイルマネージャーからプラグインフォルダをリネームすれば強制停止可能
  • 旧バージョンへのダウングレードや開発元へのフィードバックで再発を防止できる
WooCommerce Mollie決済プラグイン更新後の致命的エラー対処法

WooCommerce Mollie決済プラグイン更新後の致命的エラー対処法

WooCommerce の Mollie 決済プラグイン(Mollie Payments for WooCommerce)をバージョン 8.1.8 から 8.1.9 に更新した直後、サイトに「このサイトで重大なエラーが発生しました」と表示されたり、WordPress から致命的エラーの通知メールが届いたりする場合は、プラグイン内部のコンストラクタが想定する引数の数と実際に渡される引数の数が一致しないことが直接の原因だ。バージョン 8.1.8 へのロールバックで即座に復旧できる。

Mollie プラグイン更新後に起きる致命的エラーの正体とは

Mollie プラグイン更新後に起きる致命的エラーの正体とは

今回のエラーは「ArgumentCountError(引数の数が一致しない)」に分類される。具体的には、プラグイン内部の RestApi.php というファイルの 26 行目に定義された __construct() メソッド(クラスの初期化時に呼び出される特別な関数)が 4 つの引数を必要としているにもかかわらず、呼び出し元の services.php 127 行目から 3 つしか渡されていない。

この種の不具合は、プラグインの開発過程でメソッドのシグネチャ(引数の数や型の定義)が変更されたにもかかわらず、すべての呼び出し箇所が追従しなかった場合に発生する。今回のケースでは 8.1.8 から 8.1.9 へのアップデートで RestApi クラスのコンストラクタに新しい依存オブジェクトが 1 つ追加されたが、サービスコンテナ側の定義が更新に追いつかず、3 つのまま残ってしまった可能性が高い。

このエラーは Mollie プラグインの開発元も再現できておらず、特定の環境(PHP バージョンや他のプラグインとの組み合わせ)でのみ発生する。そのため、原因の完全な特定と恒久的な修正には開発元の調査を待つ必要がある。

Before(エラー状態)
プラグイン更新後、管理画面とサイトに「このサイトで重大なエラーが発生しました」と表示される
エラーログに「Too few arguments to function」のメッセージ
チェックアウトページが動作しない、または管理画面の一部が読み込めない
After(ロールバック後)
サイトと管理画面が正常に表示される
Mollie 決済機能が通常通り動作する
致命的エラーの通知メールが停止する
エラー状態  回復後

上図のとおり、ロールバックによってサイトの全機能が即座に回復する。このエラーは PHP の実行を完全に停止させる E_ERROR レベルのため、チェックアウトページを含むサイト全体に影響が及ぶ点が深刻だ。

バージョン 8.1.8 へロールバックして即時復旧する手順

バージョン 8.1.8 へロールバックして即時復旧する手順

最も確実で安全な対処法は、プラグインを直前の安定バージョンである 8.1.8 に戻すことだ。管理画面にアクセスできる場合とできない場合で手順が異なる。

管理画面にアクセスできる場合のロールバック

管理画面にログインできる状態であれば、WP Rollback プラグインを使うのが最も簡単だ。このプラグインは、WordPress.org の公式プラグインディレクトリに登録された任意のプラグインを、過去の特定バージョンにワンクリックで戻せる。

STEP 1 「プラグイン」→「新規追加」から WP Rollback をインストールして有効化する
STEP 2 「プラグイン」→「インストール済みプラグイン」で Mollie Payments for WooCommerce を探す
STEP 3 プラグイン名の下に表示される「ロールバック」リンクをクリックする
STEP 4 バージョン一覧から「8.1.8」を選択してロールバックを実行する

WP Rollback を使わない場合は、プラグインを一度削除してから旧バージョンを手動でインストールする。削除しても Mollie の API キーや決済設定はデータベースに残るため再設定は不要だが、念のため作業前に WooCommerce のシステムレポートを控えておくと安心だ。

管理画面にもアクセスできない場合の復旧

エラーによって管理画面にも入れなくなっている場合は、FTP クライアントまたはレンタルサーバーのファイルマネージャーを使って対処する。手順は以下のとおりだ。

  1. FTP でサーバーに接続し、/wp-content/plugins/ ディレクトリに移動する
  2. mollie-payments-for-woocommerce フォルダの名前を「mollie-payments-for-woocommerce-broken」などに変更する(これでプラグインが無効化され、管理画面に入れるようになる)
  3. 管理画面にログインしたら、WP Rollback をインストールする
  4. フォルダ名を元に戻してから、STEP 1〜4 を実行して 8.1.8 にロールバックする

フォルダ名の変更でプラグインを無効化するとサイトのフロントエンドも正常に表示されるようになるが、その間 Mollie 決済は利用できない点に注意する。

手動 ZIP アップロードで 8.1.9 を試す場合の注意点

手動 ZIP アップロードで 8.1.9 を試す場合の注意点

フォーラムの一部ユーザーは、WordPress 管理画面の自動更新ではなく GitHub からダウンロードした ZIP ファイルを手動アップロードすることでエラーを回避できたと報告している。しかし別のユーザーは同じ手順でもエラーが再発しており、確実な回避策ではない。

手動 ZIP アップロードを試す場合は、以下の点に注意する必要がある。まず、GitHub のリリースページ(Mollie の公式 WooCommerce リポジトリ)から 8.1.9 の ZIP を入手する。プラグイン画面の「新規追加」→「プラグインのアップロード」から ZIP を選択し、「既存のプラグインと置き換える」を確認してアップロードする。

手動アップロード後はサイト全体をくまなく確認し、特に実際のテスト購入でチェックアウトフローが最後まで動作することを確かめる。エラーが再発した場合は速やかに 8.1.8 に戻す。

調査中の自動更新を止めて再発を防ぐ

調査中の自動更新を止めて再発を防ぐ

開発元が修正版をリリースするまでの間、Mollie プラグインが勝手に 8.1.9 に再更新されるのを防ぐ必要がある。WordPress の自動更新設定ではプラグイン単位で自動更新のオンオフを切り替えられる。

「プラグイン」→「インストール済みプラグイン」で Mollie Payments for WooCommerce の行を見ると「自動更新を有効化」または「自動更新を無効化」のリンクがある。これをクリックして自動更新を無効にしておけば、8.1.8 のまま安全に運用を継続できる。修正版がリリースされたら、自動更新を再度有効にしてから手動で更新を実行する。

よくある質問

8.1.8 を使い続けてもセキュリティ上の問題はないか

8.1.8 と 8.1.9 の差分は軽微な機能追加やバグ修正が中心であり、8.1.8 に既知の重大な脆弱性は報告されていない。数週間程度の運用であれば実務上のリスクは低い。とはいえ、決済プラグインに限らず常に最新バージョンを使うのが基本のため、修正版がリリースされたら速やかに更新する。

手動 ZIP アップロードと管理画面からの自動更新で何が違うのか

一般的には同じ ZIP ファイルを使うため内容に差はないが、自動更新時には WordPress のアップデーターがファイルの置き換えを段階的に行うのに対し、手動アップロードでは一度に全ファイルが上書きされる。キャッシュやオートローダーの生成タイミングの違いが結果に影響している可能性がある。ただし本件では原因が完全に特定されていないため、効果には個体差がある。

PHP バージョンはエラーに関係するか

関係する可能性は高い。PHP 8.0 以降は引数の数の不一致に対して E_ERROR レベルの厳格なエラーを出すが、PHP 7.x では E_WARNING で済んでいたケースもある。Mollie プラグインのシステム要件を確認し、推奨される PHP バージョン(通常 7.4 以上)を使っているかどうかを WooCommerce のステータス画面で確認する。

エラーメールが大量に届いて困っている。どう止めればよいか

WordPress の致命的エラー通知はサイトにアクセスがあるたびに発生するため、更新直後は短時間で大量のメールが届くことがある。最も早い対処は前述のとおり FTP でプラグインフォルダの名前を変更して無効化することだ。メールが止まったら、すぐに 8.1.8 へのロールバックに取りかかる。

他の決済プラグインに切り替えるべきか

このエラーはバージョン 8.1.9 固有の一時的な不具合であり、Mollie プラグイン全体の品質に問題があるわけではない。8.1.8 で問題なく運用できていたのであれば、慌てて乗り換える必要はない。オランダ発の Mollie は欧州で高いシェアを持つ決済プロバイダーであり、プラグインも活発にメンテナンスされている。

この記事のポイント

  • Mollie 8.1.9 の致命的エラーはコンストラクタ引数の数が一致しないことが原因
  • 最も確実な対処は WP Rollback で 8.1.8 に戻すこと
  • 管理画面に入れない場合は FTP でプラグインフォルダをリネームして無効化する
  • 手動 ZIP アップロードは回避できる場合とできない場合があり確実性に欠ける
  • 修正版が出るまで自動更新を無効にして 8.1.8 のまま運用する
Booking Calendar更新後にサイトが壊れた時の原因と直し方

Booking Calendar更新後にサイトが壊れた時の原因と直し方

Booking Calendar プラグインを 11.4.1 から 11.4.2 へ更新した直後にサイトが壊れた場合、無料版(Booking Calendar)と有料版(Booking Calendar Pro または Booking Manager)のバージョン不一致が主要因だ。手動で両方を同一の最新バージョンに揃え、かつ Pro 版のライセンスを再適用すれば復旧できる。

なぜバージョン 11.4.2 への更新でサイトが壊れたのか

なぜバージョン 11.4.2 への更新でサイトが壊れたのか

Booking Calendar は無料版(WordPress.org 配布)と、追加機能を提供する Pro 版(開発元サイトで購入)が連携して動作する設計になっている。無料版は管理画面の「プラグイン」から自動更新される一方、Pro 版は手動で更新する必要がある。両者のバージョンが食い違うと、共有する関数やデータベース構造に不整合が生じ、PHP の致命的エラーを引き起こして画面が表示されなくなる。

とくに 11.4.2 では内部 API の変更が加えられており、Pro 版が旧バージョンのまま無料版だけを更新すると競合が起きやすい。この状態で WordPress の「このサイトで重大なエラーが発生しました」というメッセージが表示されたり、管理画面にアクセスできなくなったりする。

サイトを元に戻す具体的な手順

サイトを元に戻す具体的な手順

以下の手順で、無料版と Pro 版を安全に最新へ揃える。作業前に必ずサイト全体のバックアップを取得しておく。

STEP 1 FTP またはホスティングのファイルマネージャで /wp-content/plugins/ にアクセスする
STEP 2 無料版と Pro 版の両方のフォルダを一時的にリネームして無効化する(例: bookingbooking_old
STEP 3 無料版を WordPress.org から最新版(11.4.2)で再インストールし有効化する
STEP 4 開発元サイトから Pro 版の最新をダウンロードし、管理画面からアップロードして有効化、ライセンスキーを再入力する

プラグインフォルダを特定して無効化する

サイトが壊れて管理画面に入れない場合は、FTP(File Transfer Protocol)クライアントやレンタルサーバーのファイルマネージャを使う。/wp-content/plugins/ ディレクトリ内に、無料版(通常は booking または booking-calendar)と Pro 版(booking-calendar-prowpdev-booking など)のフォルダが存在する。両方をリネームすれば、WordPress はプラグインを強制的に無効化し、サイトが最低限の状態で表示されるようになる。リネーム後のフォルダ名は削除せず控えておく。

無料版を最新にして Pro 版を再適用する

管理画面にアクセスできる状態になったら、プラグイン一覧画面で一度 Booking Calendar を削除する。削除しても予約データはデータベースに保持されるため、消えることはない。その後「新規追加」から再度 Booking Calendar 11.4.2 をインストールし有効化する。

続いて開発元サイト(wpbookingcalendar.com)のアカウントページから、無料版と同一バージョン(11.4.2)に対応した Pro 版の ZIP ファイルをダウンロードする。管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP を投入し、有効化後にライセンスキーを入力すれば復旧が完了する。Pro 版の最新ファイルが入手できない場合は、開発元のサポートへ直接更新ファイルを依頼する。

どうしても復旧できない場合の最終手段

Pro 版の最新 ZIP が手元になく、サイトのダウンタイムが許容できない状況では、無料版を旧バージョン(11.4.1)にダウングレードする選択肢もある。WordPress.org のプラグインページにある「以前のバージョン」から 11.4.1 の ZIP を入手し、FTP で手動上書きすれば以前の動作に戻せる。ただしセキュリティ修正が含まれている可能性があるため、この状態は恒久的な対策にはならず、早期に Pro 版を最新化する必要がある。

再発を防ぐための運用ルール

再発を防ぐための運用ルール

Booking Calendar のように無料版と有料版が連動するプラグインは、無料版の自動更新をオフにするか、更新前に必ず Pro 版の対応バージョンがリリースされているかを確認する習慣をつける。開発元のチェンジログやメーリングリストを購読しておくと、更新のタイミングを逃さない。

また本番環境に直接適用する前に、ステージング環境(本番と同一構成のテストサイト)で無料版と Pro 版の同時更新を試すのが最も確実な予防策になる。レンタルサーバーのステージング機能を使うか、WP Staging のようなプラグインで簡易的なテスト環境を用意できる。

よくある質問

Pro 版の最新ファイルがアカウントページに見当たらない場合はどうすればよいか

開発元の公式サイトにある問い合わせフォームまたはサポートチケットから、Pro 版の最新 ZIP ファイルを直接依頼する。購入時のメールアドレスやライセンスキーを記載すれば、通常は数営業日以内にダウンロードリンクが提供される。

フォルダをリネームしたがサイトがまだ壊れている

キャッシュ系プラグインや CDN(コンテンツデリバリネットワーク / 配信網)が古いエラー画面を配信し続けている可能性がある。サーバー側のキャッシュをすべてクリアし、ブラウザのシークレットモードで確認する。また wp-content/mu-plugins/ に手動で入れたファイルが競合していないかも調べる。

ライセンスキーを入力しても Pro 版の機能が有効にならない

ライセンスキーが旧バージョン向けのまま失効している可能性がある。開発元のマイページでキーを再発行するか、サポートにキーのリセットを依頼する。ドメインを変更した場合もライセンスの再割り当てが必要になる場合がある。

この記事のポイント

  • Booking Calendar 11.4.1 から 11.4.2 への更新障害は無料版と Pro 版のバージョン競合が原因
  • FTP で両方のプラグインフォルダをリネームし強制無効化して管理画面へ復帰
  • 無料版は削除後に 11.4.2 を再インストール、Pro 版は開発元から同一バージョンを入手
  • Pro 版がすぐ用意できない場合は無料版のみ旧バージョン 11.4.1 に戻す応急処置も可能
  • 再発防止には無料版の自動更新を止め、Pro 版のリリース確認後に揃えて更新する
WP Review Slider 更新後にレビュー下に空白ができる原因と直し方

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-textreview-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-textreview-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 に戻す選択肢もあるが、事前バックアップが必須
WooCommerce更新後に重大なエラーが発生した時の原因と直し方

WooCommerce更新後に重大なエラーが発生した時の原因と直し方

WooCommerce 10.9.1 への更新後に「このサイトで重大なエラーが発生しました」と表示されたり、管理画面にアクセスできなくなったりした場合、対処の第一歩はサーバー側の PHP OPcache をクリアすることだ。更新中にオートローダーが古いキャッシュを参照して必要なファイルを読み込めず、致命的エラーが発生しているケースが多い。キャッシュをリセットし PHP プロセスを再起動すれば、多くの場合はそのまま復旧する。

なぜ WooCommerce 更新後に「重大なエラー」が発生するのか

なぜ WooCommerce 更新後に「重大なエラー」が発生するのか

このエラーの根本原因は、WooCommerce が内部で使っている Jetpack オートローダーのクラス読み込みに失敗している点にある。class-php-autoloader.php の102行目で Settings.php ファイルを要求しようとしたが、ファイルが存在しないかパスが解決できず、E_ERROR が発生している。

スタックトレースを見ると、REST API の初期化から管理画面の設定データを構築するまでの一連の処理でエラーが連鎖している。通常これは WooCommerce の更新が完了しない中途状態で発生する一時的な不具合で、新しいバージョンのコードが正しく配置された後もサーバーが古い OPcache を参照し続けるために起こる。

実際の環境は WordPress 7.0、テーマ Flatsome 3.20.7、PHP 8.3.31 と非常に新しいバージョン構成であり、各要素の互換性が原因ではなく、更新プロセスの瞬間的なファイル整合性の乱れがトリガーになっている。

Before(エラー状態)
OPcache 更新前の古いパス情報を保持
オートローダー 存在しないファイルを要求 → 致命的エラー
管理画面 「このサイトで重大なエラーが発生しました」と表示
After(復旧状態)
OPcache クリアされ最新のパス情報を読み込み
オートローダー 正しいファイルを見つけて読み込み成功
管理画面 通常通りアクセス可能に
エラー発生時の状態  OPcache クリア後の復旧状態

最初に試すべき復旧手順「PHP OPcache のクリア」

最初に試すべき復旧手順「PHP OPcache のクリア」

管理画面にアクセスできずエラーメールだけが届いている状況では、サーバー側で PHP の OPcache をリセットするのが最も即効性のある対処だ。OPcache は PHP の実行速度を上げるためにスクリプトのコンパイル結果をメモリ上に保持する仕組みだが、プラグイン更新後はこのキャッシュが古くなり、実際には存在するファイルを「見つからない」と誤認させる。

STEP 1 サーバーの管理パネル(cPanel 等)または SSH にログインする
STEP 2 PHP 設定のセクションから「OPcache をリセット」または「PHP を再起動」を実行する
STEP 3 ブラウザのキャッシュもクリアし、シークレットウィンドウで管理画面に再度アクセスする
STEP 4 管理画面に正常にログインできたら、WooCommerce の更新が完了していることを「プラグイン」一覧で確認する

共用サーバーで OPcache をクリアする方法

多くの国内共用サーバーでは、管理パネル(cPanel や独自パネル)の「PHP 設定」や「PHP セレクター」の中に「OPcache のリセット」ボタンが用意されている。このボタンを押すだけでサーバー側のキャッシュが即座に消去され、PHP プロセスが新しいコードを読み直す。

もし管理パネルに専用ボタンが見あたらない場合は、PHP のバージョンを一度別のバージョンに切り替えてから元に戻す操作でも OPcache がクリアされる。たとえば PHP 8.3 から 8.2 に変更し、数分後に再び 8.3 に戻すといった方法だ。この操作はサーバーの設定変更として扱われるため、内部で PHP-FPM の再起動が走り OPcache がリセットされる。

SSH が使える場合のコマンドライン操作

VPS やクラウドサーバーで SSH アクセス権があるなら、ターミナルから直接 PHP-FPM を再起動することで OPcache をクリアできる。よく使われるコマンドは以下の通りだ。

sudo systemctl restart php8.3-fpm

サーバーによっては php-fpm のサービス名が異なるため、systemctl list-units | grep php で正確なサービス名を確認してから実行する。OPcache 専用の CLI コマンド opcache_reset() を直接呼ぶ方法もあるが、PHP-FPM 再起動のほうが確実で手間もかからない。

それでも直らない場合の追加手順

それでも直らない場合の追加手順

OPcache をクリアしても WordPress 管理画面にアクセスできない場合や、「このサイトで重大なエラーが発生しました」というメッセージが消えない場合は、手動でのファイル修復とプラグインのリセットを試す。

FTP で WooCommerce プラグインを手動再配置する

更新中の通信断やタイムアウトで一部のファイルが書き込まれなかった可能性もある。FTP クライアントでサーバーに接続し、/wp-content/plugins/woocommerce/ ディレクトリをいったん削除またはリネームし、WordPress.org からダウンロードした最新の WooCommerce 10.9.1 の ZIP を解凍してアップロードし直す。この操作でオートローダーが参照する Settings.php を含むすべてのファイルが正しく配置される。

この手順を行う前には、必ずサイト全体のバックアップを取っておくこと。WooCommerce のデータベーステーブルはプラグインファイルの差し替えでは影響を受けないが、カスタマイズが入っている場合は注意が必要だ。

管理画面にすらアクセスできない場合の緊急リセット

管理画面が完全にダウンしていて FTP しか使えない状況では、WooCommerce プラグインのフォルダ名を一時的に変更する手段が有効だ。/wp-content/plugins/woocommerce/woocommerce_tmp などにリネームする。WordPress は存在しないプラグインディレクトリを無効化するため、WooCommerce に依存しない管理画面の基本機能が復活する。

管理画面にログインできたら、プラグイン一覧で WooCommerce が「無効」になっていることを確認し、その後フォルダ名を元に戻してからプラグイン一覧で再有効化する。この一連の流れで、オートローダーの読み込みエラーがリセットされることが多い。

エラーを未然に防ぐための更新前チェックリスト

エラーを未然に防ぐための更新前チェックリスト

WooCommerce のような大規模プラグインの更新は、事前にいくつかの準備をしておくだけで致命的エラーのリスクを大幅に下げられる。

  • 更新前に必ずサイト全体とデータベースのバックアップを取得する
  • 可能であればステージング環境で先に更新をテストする
  • 更新中はブラウザを閉じず、更新完了のメッセージが表示されるまで待つ
  • 更新直後に管理画面から「設定」→「パーマリンク設定」を開き「変更を保存」を押してキャッシュをリフレッシュする

更新のタイミングも重要だ。アクセスの少ない深夜帯やメンテナンスモードを有効にした状態で行うと、万一エラーが発生してもユーザーへの影響を最小限に抑えられる。

よくある質問

WooCommerce の更新中にブラウザを閉じてしまったらどうすればいいか

更新中に切断しても、ファイルのダウンロードと展開が完了していれば問題ないことが多い。管理画面にアクセスできるならプラグイン一覧でバージョンを確認し、古いバージョンのままなら再度更新を実行する。管理画面に入れない場合は OPcache クリアか手動再配置を試す。

エラーメールに記載されたファイルが本当に存在しないのか確認する方法は

FTP でサーバーに接続し、/wp-content/plugins/woocommerce/src/Admin/API/Settings.php が実際に存在するか確認する。ファイルが存在するのにエラーが出ているなら、OPcache の問題と判断できる。存在しない場合は手動再配置が必要だ。

OPcache をクリアしてもエラーが繰り返し発生するのはなぜか

他のプラグインやテーマが WooCommerce の REST API 初期化にフックしており、競合が起きている可能性がある。すべてのプラグインを一時的に無効化し、標準テーマに切り替えてから WooCommerce のみを有効にして原因を特定する。

PHP のバージョンを上げた直後にエラーが出た場合の対処は

PHP 8.3 では一部の古いプラグインやテーマが非互換を起こす。WooCommerce 10.9.1 自体は PHP 8.3 に対応しているが、他のプラグインが同バージョンに対応しているか確認し、必要に応じて PHP 8.2 に一時的に戻して様子を見る。

エラーが表示されず画面が真っ白になるだけの場合は

「このサイトで重大なエラーが発生しました」の代わりに真っ白な画面(ホワイトスクリーン)になるのは、PHP のエラー表示が無効になっているためだ。wp-config.phpdefine('WP_DEBUG', true);define('WP_DEBUG_LOG', true); を追加すると /wp-content/debug.log にエラー詳細が出力される。

この記事のポイント

  • WooCommerce 更新後のオートローダーエラーは PHP OPcache のクリアでほぼ解決する
  • 管理パネルの「OPcache リセット」ボタンか PHP 再起動で対処する
  • 直らない場合は FTP でプラグインファイルを手動再配置する
  • 緊急時は WooCommerce フォルダを一時的にリネームして管理画面に復帰する
  • 更新前のバックアップとステージングテストでリスクを下げられる
W3 Total Cache 2.10.0 更新後に動的コンテンツが表示されない時の直し方

W3 Total Cache 2.10.0 更新後に動的コンテンツが表示されない時の直し方

W3 Total Cache 2.10.0 へのアップデート後、動的コンテンツが表示されず「W3TC dynamic mfunc tag refused: missing call:slug + hmac envelope.」と表示される場合、根本原因はバージョン 2.10.0 で導入された HMAC 署名検証の仕様変更である。プラグインを 2.9.x 系に戻すか、動的ブロックの呼び出しコードに正しい slug 属性と HMAC 署名を付与すれば直る。

どんな症状が発生しているのか

どんな症状が発生しているのか

W3 Total Cache(以下 W3TC)のページキャッシュを有効にしたサイトを更新したあと、AdRotate Pro など mfunc タグを使って動的コンテンツを部分キャッシュしていた箇所が、エラーメッセージに置き換わる。日本語環境では英文のまま「W3TC dynamic mfunc tag refused: missing call:slug + hmac envelope.」という文言が表示されるケースが多い。この文言は「mfunc 呼び出しが拒否された。slug と HMAC エンベロープが不足している」という意味だ。

対象になるのは、W3TC のページキャッシュ機能と「後期キャッシング(Late Caching)」や「動的 mfunc ブロック」を組み合わせて使っていたサイトである。具体的には、固定ページ全体をキャッシュしつつ、広告ブロックやログイン状態表示などの一部だけを非キャッシュで差し込んでいた構成だ。更新前は問題なく動いていたのに、2.10.0 にした途端に該当箇所だけエラー文言に化ける。

なぜ W3TC 2.10.0 でエラーが起きるのか

なぜ W3TC 2.10.0 でエラーが起きるのか

W3TC 2.10.0 では、動的 mfunc タグのセキュリティ強化として HMAC(ハッシュベースのメッセージ認証コード)による署名検証が必須になった。これは不正な動的コードの注入を防ぐための仕組みだが、従来の呼び出しコードには slug 属性と HMAC 署名が含まれていなかったため、検証に失敗し、一律で拒否されるようになった。

W3TC の動的 mfunc ブロックは、PHP 関数をページキャッシュ内に埋め込んでおき、キャッシュから配信される直前に実行する仕組みだ。これまでは単純なコールバック名だけで動作していたが、2.10.0 からは「どのスラッグから呼び出されたか」と「正当な呼び出し元であることを証明する HMAC 署名」のセットがなければ mfunc タグが無効化される。

この仕様変更は W3TC 本体のセキュリティアップデートであるため、AdRotate Pro など W3TC 互換モードを持つ他プラグインの側が新しい署名形式に対応していないと、もれなくエラーになる。結果的に、更新後は互換モードで動的コンテンツを提供しているほとんどすべてのサイトで同じ問題が発生している。

W3TC 2.10.0 の動的 mfunc 呼び出し変化
Before
<!– mfunc callback_name –>
slug・HMAC なし → 拒否される
After
<!– mfunc callback_slug –><!– mfunc hmac_signature –><!– /mfunc –>
slug・HMAC 付き → 正常動作
エラー状態(旧形式)  2.10.0 の要求仕様

すぐにサイトを元に戻す応急処置

すぐにサイトを元に戻す応急処置

W3 Total Cache を 2.9.x 系にダウングレードする

最も短時間で確実に直す方法は、W3TC を 2.10.0 より前のバージョンに戻すことだ。ダウングレード手順は以下のとおり。

  1. 管理画面の「プラグイン」から W3 Total Cache を停止する
  2. 「プラグイン」→「プラグインの追加」→「プラグインのアップロード」を使うか、FTP で古いバージョンの ZIP を展開して上書きする
  3. プラグインを再有効化し、すべてのキャッシュを削除する

古いバージョンの ZIP ファイルは WordPress.org のプラグインページにある「以前のバージョン」セクションから入手できる。バージョン 2.9.8 や 2.9.9 であれば HMAC 署名検証が存在しないため、従来どおり動的 mfunc タグが動作する。

ダウングレードしたあとは、W3TC の自動更新を一時的に停止することを推奨する。管理画面の「プラグイン」で個別に自動更新をオフにするか、wp-config.php に define( 'AUTOMATIC_UPDATER_DISABLED', true ); を追加してサイト全体の自動更新を止めておけば、意図しない再アップデートを防げる。

他プラグインの W3TC 互換モードを一時的に無効化する

もし AdRotate Pro など、W3TC 互換モードを個別にオン・オフできるプラグインを使っているなら、当該プラグインの設定で互換モードをオフにする手もある。ただしこの場合、ページキャッシュの影響で広告がローテーションしなくなったり、動的コンテンツが静的になってしまったりする副作用がある。あくまで「エラー表示を消す」ための一時的な回避策と位置づけるのが安全だ。

2.10.0 を使い続ける場合の恒久対応

2.10.0 を使い続ける場合の恒久対応

W3TC 2.10.0 のセキュリティ修正を活かしたまま動的コンテンツを動作させるには、呼び出しコードに正しい slug と HMAC 署名を付与する必要がある。この修正は、動的 mfunc タグを生成している側(多くの場合は広告管理プラグインや自作のテーマ関数)に手を入れることになる。

W3TC の HMAC 署名の仕組みを理解する

mfunc タグはページキャッシュの HTML 内に PHP コード片を残し、キャッシュ配信時に W3TC がそれを検出して実行する。2.10.0 ではこのとき、呼び出しパラメータとして「call:slug」と「hmac」の両方がエンベロープに含まれていなければならない。slug は処理を一意に識別する任意の文字列、hmac は W3TC 内部で生成される署名ハッシュだ。

生成ルールは公開されているが、実際には W3TC が提供する API 関数を使って動的ブロックを登録するのが現実的だ。自作テーマであれば w3tc_fragmentcache_register フィルターを使い、コールバックと slug を W3TC に登録すれば、あとは W3TC 側が自動で HMAC 署名を計算してくれる。

AdRotate Pro での対応状況を確認する

AdRotate Pro は W3TC 互換モードを有効にしている場合、内部的に mfunc タグを生成している。今回のエラーは、AdRotate Pro が生成する mfunc タグが 2.10.0 の新形式に対応していないために発生している。AdRotate Pro の開発元がこの問題に対応したアップデートをリリースするまでは、互換モードの使用が難しい。

AdRotate Pro の管理画面にある「W3 Total Caching compatibility」設定をオフにし、代わりに JavaScript による非同期広告読み込み(AdRotate のダイナミックモード)を使うか、広告ブロックを iframe で埋め込む形に切り替えると、ページキャッシュ機構に依存せず動的広告を配信できる。

自作テーマで動的ブロックを登録し直す

テーマの functions.php などで自作の動的コンテンツを mfunc タグで埋め込んでいた場合は、W3TC のフラグメントキャッシュ API を使った正式な登録に切り替える。基本的な流れは次のとおりだ。

  1. w3tc_fragmentcache_register フィルターで、slug とコールバック関数のペアを W3TC に登録する
  2. テンプレート内では w3tc_fragmentcache_output 関数を使い、slug を指定して動的出力を行う
  3. W3TC が自動で HMAC 署名を計算し、mfunc タグとしてページキャッシュに埋め込む

この方法なら、W3TC のバージョンが上がっても署名方式の変更に W3TC 本体側が追随するため、サイト側のコードを再度修正する必要がなくなる。フラグメントキャッシュ API の具体的な記述例は W3TC の公式ドキュメントに掲載されている。

Late Caching 設定の確認と調整

W3TC の pgcache.late_caching 設定(後期キャッシング)が有効かどうかも、動作に影響を与える要素のひとつだ。この設定が true の場合、ページ生成の最終段階で mfunc タグを処理するため、プラグイン間の競合が減る傾向がある。すでに true でもエラーが出ている場合は今回の本質的な原因ではないが、念のため設定値を確認しておく。

wp-content 内の w3tc-config/master.php を直接確認するか、管理画面の「パフォーマンス」→「一般設定」からエクスポートした設定ファイルで pgcache.late_caching の値を確認できる。false であれば true に変更し、キャッシュを全削除してから表示を再確認する。

再発を防ぐための注意点

再発を防ぐための注意点

W3TC のような深くサイト機構に組み込まれるプラグインをメジャーバージョンアップする前には、必ずステージング環境で検証する習慣をつける。とくに mfunc やフラグメントキャッシュといった、通常のキャッシュとは異なる高度な機能を使っている場合は、本番適用前に動的コンテンツの全パターンをテストする必要がある。

また、W3TC の設定をエクスポートしてバックアップしておけば、問題が起きたときに設定ごと以前のバージョンに戻せる。管理画面「パフォーマンス」→「一般設定」の下部にある「設定のダウンロード」ボタンで、JSON 形式の設定ファイルを定期的に保存しておくとよい。

更新前の準備と検証フロー
STEP 1 W3TC 設定を JSON でダウンロードしてバックアップ
STEP 2 ステージング環境で W3TC を更新し動作確認
STEP 3 動的コンテンツ全種をテストし問題なければ本番に適用
STEP 4 本番反映後すぐにキャッシュ全削除して再チェック

よくある質問

「W3TC dynamic mfunc tag refused」はサイト全体が真っ白になるのか

サイト全体が真っ白になるわけではない。ページの大部分は正常にキャッシュ配信されるが、mfunc タグで差し込まれていた動的コンテンツの部分だけがエラー文言に置き換わる。レイアウトが崩れることはあるが、PHP 致命的エラーによる白画面とは異なる。

キャッシュを削除しても直らないのはなぜか

キャッシュ削除はあくまで「現在保存されているキャッシュファイルを消す」行為であり、mfunc タグの生成コード自体を修正するものではない。新しいキャッシュが生成されるときに、同じく新形式に対応していない mfunc タグが再度埋め込まれるため、キャッシュ削除だけでは根本解決にならない。

W3TC 無料版でも同じ問題は起きるのか

起きる。HMAC 署名検証は W3TC のコア機能の一部として Pro 版・無料版の両方に実装されている。フラグメントキャッシュや mfunc タグを使っているサイトは、Pro 版かどうかに関係なく影響を受ける。

このエラーを放置してもサイトには大きな問題はないか

動的コンテンツが表示されないという機能面の問題に加え、エラー文言が来訪者にそのまま見える状態はサイトの信頼性を損なう。また広告が表示されなければ収益にも直結するため、実質的には早期解決が必要な重大トラブルに分類される。

他に W3TC 2.10.0 で影響を受けるプラグインはあるか

AdRotate Pro 以外にも、W3TC 互換モードで動的コンテンツを埋め込む仕組みを持つプラグイン全般が影響を受ける可能性がある。具体的には、動的ウィジェットやパーソナライズ表示を行うキャッシュ対応プラグインが該当する。該当プラグインの更新情報を注視し、開発元が W3TC 2.10.0 対応を表明するまではアップデートを保留するのが安全だ。

この記事のポイント

  • W3TC 2.10.0 の HMAC 署名検証強化で mfunc タグが拒否される
  • ダウングレードで即時解決するがセキュリティ面は旧版に戻る
  • 互換プラグイン側の対応アップデートを待つか公式 API で再実装する
  • キャッシュ削除だけでは再発するため mfunc コード自体の修正が必要
  • メジャーアップデート前のステージング検証と設定バックアップが再発防止の鍵
プラグイン更新後にログイン不可「ユーザー名またはパスワードが間違っています」と表示される原因と直し方

プラグイン更新後にログイン不可「ユーザー名またはパスワードが間違っています」と表示される原因と直し方

プラグインの更新後、正しいユーザー名とパスワードを入力しているにもかかわらずログインできず「ユーザー名またはパスワードが間違っています」というエラーが表示されるなら、その原因は特定のプラグインが認証フローに干渉したことによる競合だ。特にログインフォームをカスタマイズするプラグインと、追加のセキュリティ認証(Cloudflare Turnstileなど)を組み合わせている場合に発生しやすい。

なぜ正しいパスワードなのに「間違っています」と表示されるのか

なぜ正しいパスワードなのに「間違っています」と表示されるのか

WordPressは通常、ログイン認証を「wp-login.php」を通じて処理している。ここにプラグインが独自のログインフォームを追加したり、認証前にCAPTCHAや追加認証を挟むと、データの送信順序や検証の流れが変わる。プラグインのバージョンアップでこの処理順序が微妙に変わった結果、正しい認証情報がバックエンドの判定に渡る前に「誤り」と判定されるケースが起きる。

典型的なパターンとして、会員制サイト用のプラグイン(Ultimate Memberなど)が生成する独自ログインページと、追加のボット対策機能(Cloudflare TurnstileやreCAPTCHA)が衝突する問題が挙げられる。どちらか一方が先にフォームの値を検証し、もう一方に正しい情報を渡せなくなることが原因だ。

■ エラー発生時の処理の流れ(競合)
ログインフォーム セキュリティ認証(Turnstile) WordPress認証
認証トークンの不一致や情報の欠落が発生 → WordPressが「ユーザー名またはパスワードが間違っています」と誤判定する

まず試す緊急回避策 管理画面に入れない場合の対処

まず試す緊急回避策 管理画面に入れない場合の対処

ログインできない状態では管理画面からプラグインを停止できない。次のいずれかの方法でプラグインを一時的に無効化し、管理画面に再アクセスできるようにする。

FTPやファイルマネージャーでプラグインフォルダの名前を変更する

レンタルサーバーのファイルマネージャーやFTPソフトでサイトのファイルにアクセスし、「/wp-content/plugins/」ディレクトリを開く。問題を起こしているプラグインのフォルダ名を一時的に「_(アンダースコア)」を付けるなどして変更する。WordPressは存在しないプラグインディレクトリを無効化するため、余分な認証処理が外れて本来のログインフローが復活する。

具体的な対象は、直近で更新したプラグインか、ログインフォームをカスタマイズしているプラグインだ。Ultimate Memberのような会員制プラグインや、Cloudflare Turnstileを追加しているプラグインが該当する。

wp-config.phpでプラグインを一括無効化する

FTPでWordPressのルートディレクトリにある「wp-config.php」をダウンロードし、次の一行を「/* 編集が必要なのはここまでです ! */」の直前に追加する。

define('DISABLE_PLUGINS', true);

この状態でファイルを上書きアップロードすると、すべてのプラグインが一時的に無効化される。管理画面にログインできたらこの行を削除し、原因のプラグインだけを停止してから他のプラグインを再有効化する。ただし、この定数は非公式の回避策で、すべての環境で動作するとは限らない点に注意する。

原因となったプラグインの特定と恒久対応

原因となったプラグインの特定と恒久対応

管理画面にログインできたら、プラグイン一覧画面で「直近更新されたプラグイン」を順に停止し、問題が再現するか確認する。特に次の組み合わせに心当たりがあれば、真っ先に疑うべきだ。

  • 独自のログインフォームを提供するプラグイン(Ultimate Memberなど)
  • Cloudflare TurnstileやreCAPTCHAなどの認証機能をログイン画面に追加するプラグイン
STEP 1 プラグイン一覧で更新日時を確認し、直近更新されたプラグインを特定する
STEP 2 そのプラグインの追加認証機能(Turnstileなど)を設定画面で一時的に「無効」にする
STEP 3 シークレットウィンドウでログイン画面を開き、正しくログインできるかテストする
STEP 4 問題が解決したら、プラグインを旧バージョンに戻すか、開発元に不具合を報告する

旧バージョンに戻す方法

プラグインの以前のバージョンは、WordPress公式プラグインディレクトリの「以前のバージョン」セクションからダウンロードできる。プラグインページの下部にある「詳細を見る」→「開発」→「以前のバージョン」の順に進むと、過去のすべての安定版がzipで入手可能だ。管理画面のプラグイン新規追加から手動でアップロードし直すか、FTPで「/wp-content/plugins/」に解凍して上書きすれば戻せる。

Cloudflare Turnstileをそのまま使いたい場合の設定見直し

TurnstileのWidget Modeを「Managed」から「Non-interactive」に変更するか、ログインページだけ設定を除外する方法を試すと競合が緩和されることがある。Cloudflareのダッシュボード側で該当サイトの「Security → Bots → Turnstile」から、Fail-open動作(認証失敗時にアクセスを通す)を有効にするのも有効な回避策だ。

根本原因を理解して今後の更新に備える

根本原因を理解して今後の更新に備える

この問題の本質は、WordPressの認証フック(authenticateフィルター)に対して複数のプラグインが非標準的な順序で割り込んだことにある。WordPressのコア認証は、ユーザー名とパスワードが一致したらWP_Userオブジェクトを返す。しかし追加認証を挟むプラグインは、認証が成功しても「null」を返したり、エラーオブジェクト(WP_Error)に差し替えたりする。バージョンアップでこのフィルターの優先度(priority)が変わると、突然認証が通らなくなるというわけだ。

将来的に同様のトラブルを避けるには、本番環境の更新前にステージング環境で動作確認することが最も確実な対策になる。また、会員制プラグインとセキュリティ認証プラグインの両方を使用している場合は、片方のログイン機能をオフにしてWordPress標準のログインページに一本化するのも安定性を高める選択肢だ。

よくある質問

Ultimate Memberのログインフォームだけエラーになるのはなぜか

Ultimate MemberはWordPress標準の認証処理を大きくカスタマイズし、独自の認証フックを追加している。ここにCloudflare Turnstileのような外部検証が割り込むと、UM側で生成したnonce(ワンタイムトークン)やセッション情報が検証前に消費されたり、書き換えられてしまう。UMはバリデーションが1つでも失敗すると「認証情報が間違っている」と一般化して表示する設計のため、実際のパスワードは合っていてもエラーになる。

プラグインを旧バージョンに戻したがサイトが脆弱にならないか

旧バージョンに戻すことは一時的な対処であり、修正が適用された最新版に更新できるまでの猶予と考えるべきだ。緊急回避の間は、WAF(Webアプリケーションファイアウォール)のルールを厳しくする、ログイン試行回数の制限をかける、IP制限を追加するなど、他の手段で防御を補強しておく。該当プラグインのサポートフォーラムで同様の報告がないか確認し、解決パッチを待つか、開発元に直接報告するのが安全な進め方だ。

Cloudflare Turnstileを完全に外す以外の選択肢はあるか

Cloudflare側の設定で「アクション」を「管理モード」から「監視モード」に変更し、認証を可視化せず裏側でリスク評価だけさせる手がある。また、一部のプラグインでは特定のページ(wp-login.phpなど)だけ検証をスキップするフックが用意されている場合がある。プラグインのドキュメントやフックリファレンスに「bypass turnstile on specific page」の情報がないか探してみるとよい。

管理画面にすら入れない場合、データベースから直接プラグインを無効化できるか

可能だ。phpMyAdminなどでWordPressのデータベースにアクセスし、「wp_options」テーブルの「active_plugins」レコードを編集する。このレコードには有効化されているプラグインの一覧がシリアライズされた配列で保存されている。該当プラグインのパスを削除して保存すれば、そのプラグインだけが無効化される。ただしシリアライズされたデータの文字数カウントを修正する必要があるため、FTPでのフォルダ名変更のほうが手軽で安全だ。

この記事のポイント

  • 正しいパスワードでログインエラーになるのは、認証フックに割り込むプラグインの競合が原因
  • FTPで問題のプラグインフォルダをリネームするか、wp-config.phpで全プラグインを一時停止して管理画面に入る
  • Cloudflare TurnstileやreCAPTCHAの設定をオフにするか、旧バージョンへのダウングレードで即座に解決する
  • 恒久対応は、開発元への不具合報告と、ステージング環境での更新前検証の徹底
  • 同種のプラグインを併用する場合は、WordPress標準ログインページへの統一も検討する