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

  1. ホーム   /  タグ付きの投稿: "プラグイン更新"
WooCommerce Mollie決済プラグイン更新後の致命的エラー対処法
2026年7月23日 0

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更新後にサイトが壊れた時の原因と直し方
2026年7月19日 0

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 版の両方のフォルダを一時的にリネームして無効化する（例: booking → booking_old）
↓
STEP 3 無料版を WordPress.org から最新版（11.4.2）で再インストールし有効化する
↓
STEP 4 開発元サイトから Pro 版の最新をダウンロードし、管理画面からアップロードして有効化、ライセンスキーを再入力する

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

サイトが壊れて管理画面に入れない場合は、FTP（File Transfer Protocol）クライアントやレンタルサーバーのファイルマネージャを使う。/wp-content/plugins/ ディレクトリ内に、無料版（通常は booking または booking-calendar）と Pro 版（booking-calendar-pro や wpdev-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 更新後にレビュー下に空白ができる原因と直し方
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 に戻す選択肢もあるが、事前バックアップが必須
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WooCommerce更新後に重大なエラーが発生した時の原因と直し方
2026年6月27日 0

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.php に define('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 更新後に動的コンテンツが表示されない時の直し方
2026年6月27日 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 コード自体の修正が必要
  • メジャーアップデート前のステージング検証と設定バックアップが再発防止の鍵
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
プラグイン更新後にログイン不可「ユーザー名またはパスワードが間違っています」と表示される原因と直し方
2026年6月23日 0

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

プラグインの更新後、正しいユーザー名とパスワードを入力しているにもかかわらずログインできず「ユーザー名またはパスワードが間違っています」というエラーが表示されるなら、その原因は特定のプラグインが認証フローに干渉したことによる競合だ。特にログインフォームをカスタマイズするプラグインと、追加のセキュリティ認証（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標準ログインページへの統一も検討する
佐々木 太陽
, , , , ,
お悩み・トラブル解決
Contact Form 7 PayPal Stripe Add-onの脆弱性と最新版への更新手順
2026年6月20日 0

Contact Form 7 PayPal Stripe Add-onの脆弱性と最新版への更新手順

Contact Form 7 PayPal & Stripe Add-on のバージョン 2.4.9 以前には、PayPal 決済を本来の支払い金額や通貨と無関係に「支払い完了」として通過させてしまう脆弱性がある。最新版へ更新すれば対処でき、放置すると注文だけが成立して金銭が回収できない重大なリスクを抱えるため、至急確認する必要がある。

Contact Form 7 用 PayPal & Stripe Add-on にどんな脆弱性があるのか

Contact Form 7 用 PayPal & Stripe Add-on にどんな脆弱性があるのか

この脆弱性は CVE-2026-9189 として採番されており、攻撃者が PayPal の正当な通知（IPN）に見せかけたリクエストを送信することで、実際の支払い金額や通貨、受取人の一致をまったく検証せずに「支払い済み」とマークできてしまう。プラグインは PayPal からの通知の署名検証は行っていたものの、肝心の取引金額・通貨コード・受取人メールアドレスの突き合わせを実装していなかったため、ゼロまたは極端に低い金額の注文が成立してしまう。

具体的には、フォーム送信時に生成される注文レコードに対して、PayPal のトランザクション ID と支払いステータスのみが照合され、注文時に設定された金額と実際に PayPal 上で決済された金額の比較が行われない。このため、正規のトランザクション ID を悪用、あるいは偽装した通知に対してプラグインが「正当な支払い」と誤認する状況が生まれていた。

Before（脆弱な状態）

PayPal 通知の受信 → 署名検証のみ実施 → 金額・通貨・受取人の検証なし → 0円でも「支払い完了」

↓
After（修正後）

PayPal 通知の受信 → 署名検証 → 金額・通貨・受取人を注文情報と突合 → 一致時のみ「支払い完了」

■ 脆弱な状態　■ 修正後の状態

上の図が示す通り、修正後は金額・通貨・受取人の3点を必ず比較するロジックが追加されている。この検証が欠けていたことが、支払いバイパスを成立させる根本原因だった。

どのバージョンが影響を受けるのか

どのバージョンが影響を受けるのか

Contact Form 7 PayPal & Stripe Add-on のバージョン 2.4.9 以下が影響を受ける。2026年6月中旬時点で修正済みのバージョンがリリースされており、2.5.0 以降に更新すればこの脆弱性は解消される。

自分のサイトでどのバージョンを使用しているかは、WordPress 管理画面の「プラグイン」→「インストール済みプラグイン」一覧で確認できる。該当プラグインが有効化されている場合は、バージョン番号を直ちにチェックしておきたい。

最新版へ更新する具体的な手順

最新版へ更新する具体的な手順
STEP 1 管理画面「ダッシュボード」→「更新」を開く
↓
STEP 2 該当プラグインの更新チェックボックスをオンにする
↓
STEP 3 「プラグインを更新」をクリックして完了

更新前にサイト全体のバックアップを取得しておくとなお安心だ。更新が完了したら、プラグイン一覧でバージョンが 2.5.0 以降に切り替わっていることを必ず確認する。

更新がすぐに実行できない場合の対処

更新がすぐに実行できない場合の対処

何らかの理由で即時更新が難しい場合は、一時的に PayPal 決済機能を停止し、フォームそのものを別の決済手段に切り替えるなどの対策が有効だ。とはいえ、あくまで暫定的な措置であり、根本対策は最新版への更新以外にない。

プラグインを無効化すれば脆弱性は発動しなくなるが、フォーム経由の PayPal 決済も一切使えなくなる。その間に代替として WooCommerce の標準決済や別のフォームプラグインへ移行する判断も必要になるだろう。

よくある質問

Stripe 決済にも同じ問題はあるのか

この脆弱性は PayPal の通知処理に起因する問題であり、Stripe 側の処理ロジックには同様の不備は確認されていない。ただし、セキュリティ修正の一環で Stripe 関連のコードにも改善が加えられているため、プラグイン全体を最新に保つのが賢明だ。

すでに不正な取引が行われていないか調べる方法はあるか

PayPal の取引履歴と Contact Form 7 の送信ログを突き合わせ、注文金額と実際の決済金額が一致しているかを手動で検証する必要がある。プラグイン自体に取引監査の機能はないため、自社の売上レポートと PayPal の管理画面を定期的に照合する習慣をつけることを推奨する。

自動更新を有効にしていれば問題は起きなかったのか

自動更新が有効でも、WordPress.org のプラグインディレクトリに修正版が配信されるタイミング次第では数時間から数日のラグが生じる。さらに、サイトの更新設定によってはメジャーアップデートが自動適用されないケースもあるため、手動での確認を怠らないほうが安全だ。

このプラグインを使い続けるリスクは他にもあるか

Contact Form 7 のアドオンは多数の開発者によって提供されており、サポートや更新の頻度はプラグインごとにまちまちだ。決済を扱う以上、常に開発が継続され、すみやかにセキュリティパッチが提供されるプラグインを選ぶことが大前提となる。

この記事のポイント

  • Contact Form 7 PayPal & Stripe Add-on 2.4.9 以前に支払いバイパスの脆弱性がある
  • PayPal 通知の金額・通貨・受取人を検証しないため 0 円でも「支払い完了」になる
  • 修正済みの最新版（2.5.0 以降）に更新すれば問題は解消される
  • 更新前にバックアップを取り、バージョン番号を必ず確認する
  • 決済系プラグインは常に最新を保ち、定期的なログ照合を習慣化する
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
UpdraftPlusに深刻な脆弱性、300万サイトが認証迂回の危険
2026年6月13日 0

UpdraftPlusに深刻な脆弱性、300万サイトが認証迂回の危険

WordPressの人気バックアッププラグイン「UpdraftPlus Backup & Migration」に深刻な脆弱性が発見された。インストール数は300万サイトを超えており、影響範囲は極めて広い。この問題を悪用されると、ログイン情報を持たない攻撃者がサイトの管理者権限を取得し、悪意あるプラグインを設置できる。

脆弱性が確認されたのはバージョン1.26.4以前の全バージョン。開発元はすでに修正版1.26.5をリリースしている。Wordfenceの報告によれば、24時間で8,000件を超える攻撃が観測されており、早急な対応が求められる。

脆弱性の概要と影響範囲

脆弱性の概要と影響範囲

UpdraftPlusはWordPressサイトのバックアップ、復元、移行を一手に担う定番プラグインだ。Google DriveやDropboxなど多数のクラウドストレージへのバックアップに対応し、無料版でも一通りの機能を使える。300万というアクティブインストール数は、WordPressプラグイン全体でもトップクラスに位置する。

これだけの規模で使われているプラグインに認証回避の脆弱性が見つかったことは、WordPressエコシステム全体にとって大きな脅威である。とくに今回の問題は、攻撃者がログインする必要すらない点で深刻度が一段高い。

脆弱性のあるバージョン
UpdraftPlus バージョン 1.24.0 から 1.26.4 まで （危険）
↓
修正済みバージョン
UpdraftPlus バージョン 1.26.5 以上 （安全）

上図のとおり、1.26.4以前はすべてのバージョンが影響を受ける。1.26.5への更新で修正されるため、管理画面から利用可能なアップデートがないかすぐに確認してほしい。

すべてのサイトが攻撃対象になるわけではない

注意すべき点として、UpdraftPlusをインストールしているだけでは攻撃が成立しない。プラグインの変更履歴によれば、攻撃が可能になるのは「アクティブなMigratorキー」または「UpdraftCentralキー」が設定されているサイトに限られる。

Migratorキーは有料版でのみ使われる移行機能で、UpdraftCentralキーは無料版・有料版の両方で利用できるリモート管理機能である。これらのキーを有効化しているサイト運営者は、とくに注意が必要だ。

攻撃成立の条件
UpdraftCentral キー有効 無料版・有料版の両方
Migrator キー有効 有料版のみ
いずれかのキーが有効なサイトが攻撃対象となる

認証バイパスの仕組み

認証バイパスの仕組み

この脆弱性は「認証バイパス（Authentication Bypass）」に分類される。認証バイパスとは、本来必要なはずの本人確認の仕組みをすり抜けてしまう欠陥のことだ。

UpdraftPlusはリモート通信を受け取る際、その命令が正当な管理者から送信されたものかを検証する仕組みを持っている。ところが今回の問題では、この検証プロセス自体を迂回できてしまう。結果として、攻撃者の偽造命令が「正規の管理者命令」として処理されてしまうのだ。

暗号署名の検証が機能しない根本原因

Wordfenceの技術分析によれば、問題の核心は「リモート通信メッセージの検証不備」にある。

通常、プラグインは受信した命令の署名（デジタルな印鑑のようなもの）を検証し、改ざんや偽造がないことを確認する。検証に失敗した場合、システムはその命令を拒否するべきだ。ところがUpdraftPlusのコードには、署名検証に失敗したときにエラーを返して処理を停止するのではなく、暗号鍵として「オールゼロ（すべてのビットが0の鍵）」に陥ってしまう欠陥があった。

これをもっと身近なたとえで説明しよう。たとえば、オフィスの入館ゲートでICカード認証が失敗したとする。本来ならゲートは閉じたままでなければならない。しかし今回の問題は、認証に失敗したときに「鍵が全部0の状態のマスターキー」が自動的に発行されてしまうようなものだ。攻撃者はそれを知っていれば、簡単にゲートを通れてしまう。

脆弱な動作（Before）
署名検証 → 失敗 → 鍵がオールゼロに → 攻撃者の命令が通る
↓
本来あるべき動作（After）
署名検証 → 失敗 → 処理を拒否して終了 → 命令は実行されない

この欠陥により、攻撃者は任意のRPC（リモートプロシージャコール、遠隔操作命令）を偽造し、接続中の管理者として実行できるようになる。

攻撃の実態とリモートコード実行の危険性

攻撃の実態とリモートコード実行の危険性

認証バイパスによって攻撃者が得るのは、単なる閲覧権限ではない。管理者権限での操作が可能になるため、サイトの運命を左右する重大な操作を自由に行える。

もっとも危険なシナリオは、悪意あるWordPressプラグインのアップロードと有効化だ。攻撃者は見た目は普通のプラグインに見せかけたバックドア（裏口）を設置できる。このバックドアが有効化されると、サーバー上で任意のコードが実行可能になり、以下のような被害が現実のものとなる。

  • サイトデータの窃取（顧客情報、メールアドレス、パスワードハッシュなど）
  • マルウェアの注入による訪問者への二次被害
  • サイトの改ざんやフィッシングページの設置
  • 管理者アカウントの不正作成と恒久的な支配
  • 他のサーバーへの攻撃拠点としての悪用

すでに8,000件以上の攻撃を観測

Wordfenceの脅威インテリジェンスチームは、24時間で8,172件の攻撃試行をブロックしたと報告している。これは実際に悪用が試みられている明確な証拠だ。

ブロックされた攻撃の数だけでは、実際に侵入に成功したサイトの数はわからない。しかし攻撃者が積極的にスキャンと攻撃を仕掛けている以上、未対策のサイトはきわめて危険な状態にあると言わざるを得ない。

サイト運営者がいますぐ取るべき対策

サイト運営者がいますぐ取るべき対策

脆弱性への対応はシンプルだ。UpdraftPlusをバージョン1.26.5以降にアップデートすること。これだけで問題は解消される。

STEP 1 WordPress管理画面で「プラグイン」→「インストール済みプラグイン」を開く
↓
STEP 2 UpdraftPlusに更新通知が表示されていれば「今すぐ更新」をクリック
↓
STEP 3 更新後、バージョンが1.26.5以上になっていることを確認
↓
STEP 4 可能であればサイト全体のセキュリティスキャンを実施し、不正なプラグインや管理者アカウントの有無を確認

UpdraftPlusの変更履歴では「すべてのユーザーは直ちに更新すべき」と明記されている。有料版・無料版を問わず、更新の猶予はない。

更新以外に検討すべき安全策

今回の脆弱性は、WordPressサイトの基本的なセキュリティ対策の重要性を改めて示している。以下の対策もあわせて検討してほしい。

  • プラグインの定期的な自動更新を有効にする
  • 使用していないプラグインは削除し、攻撃対象を減らす
  • セキュリティプラグインを導入し、不審な通信を監視する
  • 定期的にバックアップを取得し、復旧手順を確認しておく
  • UpdraftCentralやMigratorキーを現在使っていないなら、無効化を検討する

この記事のポイント

  • UpdraftPlus 1.26.4以前に認証バイパスの脆弱性が存在し、300万以上のサイトが影響を受ける
  • 攻撃者はログイン不要で管理者権限を取得し、悪意あるプラグインの設置が可能
  • 24時間で8,000件以上の攻撃が観測されており、すでに悪用が進行中
  • バージョン1.26.5への即時更新で修正される
  • MigratorキーまたはUpdraftCentralキーを有効化しているサイトはとくに危険
海田 洋祐
, , , ,
SEO対策

メニュー

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

ウェブ開発 最新ニュース

B to B のご提案

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

その他

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

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