タグアーカイブ 重大なエラー

WP-Stagingサイトが重大なエラーで表示されない原因と直し方

WP-Stagingサイトが重大なエラーで表示されない原因と直し方

WP-Stagingの複製サイトにアクセスすると「このサイトで重大なエラーが発生しました」と表示され、デバッグログに call_user_func_array の TypeError が記録される場合、PHP 8系ではコアファイルの欠落や混在が致命的エラーへ変わる。PHP 7.4系へ一時的に切り替えて管理画面へ入り、WordPressコアの再インストールとプラグイン更新を行えば根本から直る。

WP-Stagingサイトが重大なエラーになる原因

WP-Stagingサイトが重大なエラーになる原因

デバッグログの最終行には call_user_func_array() が「Argument #1 ($callback) must be a valid callback」という趣旨の TypeError を投げ、_wp_register_default_icon_collections という関数が見つからないことが記録される。この関数は WordPress 本体の wp-includes/theme.php で定義されるもので、本来は必ず存在しているはずだ。

WP-Staging はライブサイトのファイルとデータベースをコピーしてステージングサイトを作る。このとき wp-includes 内のファイルが不完全にコピーされていたり、旧バージョンのコアファイルと新バージョンが混在したりすると、関数が未定義のまま WordPress の読み込み処理が進み、このエラーが発生する。

PHP 8.0 以降は call_user_func_array() に存在しない関数を渡すと、警告ではなく TypeError を投げて処理を停止する。PHP 7.4 までは警告を出して読み込みが続いたため、バージョンを下げると画面が復帰する。ただし原因であるコアファイルの欠落は残ったままなので、根本解決にはならない。

同じログに Wordfence や ThemeWhizzie の Deprecated 警告も出ている。これらは PHP 8 で廃止予定になった古い記法への警告で、単体ではサイトを落とさない。ただ PHP 8 非対応の古いコードが残っている証拠なので、更新で片付けておく必要がある。

debug.logに記録されたエラーを読み分ける

debug.logに記録されたエラーを読み分ける

WordPress のデバッグ情報は wp-content/debug.log に保存される。今回のログには Deprecated 警告が数件並び、最後に Fatal error が1件出ている。サイトが落ちる直接原因は Fatal error の1件だけだ。まだログを有効にしていない場合は、wp-config.php を編集して次の3行を追加する。

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

Fatal error の内容は「呼び出そうとした関数が見つからない」という意味だ。_wp_register_default_icon_collections が WordPress 本体に無いことから、コアの関数定義が不足していると判断できる。Wordfence の Non-canonical cast や ThemeWhizzie の Creation of dynamic property は、PHP 8 で非推奨となった書き方を警告しているにすぎない。

PHP 7.4系へ切り替えて管理画面に戻る

PHP 7.4系へ切り替えて管理画面に戻る

最初の応急処置として、サーバーの PHP バージョンを 7.4 系へ変更する。ホスティングの管理画面にある「PHP バージョン管理」や「PHP Selector」などから選択するのが一般的だ。IIS 10 で FastCGI を使っている場合は、php-cgi.exe のパスを 7.4 系へ変更する。切り替え後はステージングサイトを再読み込みして、管理画面に入れるか確認する。

PHP 8系での動作
■ call_user_func_array() が TypeError を投げる
■ 致命的エラーとして処理が停止する
■ 画面に「重大なエラー」と表示される
↓
PHP 7.4系での動作
■ 同じ呼び出しが警告(Warning)になる
■ 処理がスキップされて読み込みが継続する
■ 管理画面へ復帰できる

PHP 8 系ではコールバック不足が TypeError で致命化し、PHP 7.4 系では警告として読み込みが継続する。この違いにより、バージョンを下げると一時的にサイトが復帰する。

ただし PHP 7.4 系はセキュリティサポートが終了している。常用するのは避け、次の手順で WordPress 本体とプラグインを整えた後、PHP 8 系へ戻すのが安全だ。

WordPressコアを再インストールして欠落ファイルを戻す

WordPressコアを再インストールして欠落ファイルを戻す

根本原因は WordPress 本体のファイルが不完全なことだ。管理画面に戻れたら、ダッシュボードの「更新」画面から現在のバージョンを再インストールするのが最も簡単だ。ファイルの欠落や破損が解消され、関数が再び見つかるようになる。

STEP 1 PHP を 7.4 系へ切り替える
↓
STEP 2 管理画面からコアを再インストールする
↓
STEP 3 Wordfence とテーマを更新する
↓
STEP 4 PHP 8 系へ戻して再発を確認する

復旧手順の全体像は上のとおり。各ステップの詳細を以下に示す。

ダッシュボードからコアを再インストールする

管理画面の「ダッシュボード」→「更新」を開くと、「WordPress の最新バージョンを実行しています」の下に「バージョン XX を再インストール」というボタンが表示される。ここを押せば、同じバージョンのコアファイルが公式配布パッケージから取得され、欠落している wp-includes 内のファイルが上書きされる。

再インストール後にステージングサイトを更新し、重大なエラーが消えたかを確認する。もし管理画面にも入れない状態なら、次の FTP で対処する方法を試す。

管理画面に入れないなら FTP で wp-includes を上書きする

ステージングサイトにアクセスできない場合、FTP または SFTP でサーバーへ接続する。WordPress の公式サイトから同じバージョンのパッケージを取得し、その中の wp-includes と wp-admin フォルダを、壊れているステージング側へ上書きアップロードする。

wp-content フォルダは上書きしない。ここにはテーマやプラグイン、アップロード画像が入っており、上書きすると設定が消える危険がある。あくまでコアのファイルだけを入れ替えるのが安全だ。

ステージングサイトを作り直す判断

破損の範囲が広い場合や、エラーが複数回繰り返される場合は、WP-Staging でステージングサイトを作り直すのも有効だ。その際、除外設定やファイルコピーの途中で止まっていないか、保存容量が十分かを確認する。ライブサイト側が正常なら、再作成のほうが速く済むことも多い。

Wordfenceと使用テーマをPHP 8対応版へ更新する

Wordfenceと使用テーマをPHP 8対応版へ更新する

Fatal error とは別に、Wordfence と ThemeWhizzie から Deprecated 警告が出ている。これは今すぐサイトを落とすものではないが、PHP 8 系で廃止された書き方を使っており、将来の PHP 更新で同じく致命的エラーへ変わる可能性がある。根本解決の段階でまとめて更新しておく。

Wordfence はプラグインの更新画面から最新版へ更新できる。テーマが市販テーマで更新が止まっている場合は、PHP 8 非対応の警告が出続けるため、テーマの差し替えや該当するウィザード機能の無効化を検討する。更新が終わったら PHP を 8 系へ戻し、ステージングサイトが表示されるか、デバッグログに Fatal error が出ないかを確認する。

よくある質問

PHP 7.4に戻すだけで問題は解決するのか

サイトは一時的に復帰するが、コアファイルの欠落や混在という原因は残る。PHP 7.4 系はセキュリティサポートが終了しているため、WordPress コアの再インストールで根本解決してから PHP 8 系へ戻すのが正しい流れだ。

管理画面にも入れないときはどうするのか

FTP または SFTP でサーバーへ接続し、WordPress 本体の wp-includes と wp-admin を公式パッケージから上書きする。その前に wp-config.php でデバッグログを有効にしておくと、上書き後もエラーが出る場合に原因を特定しやすい。

WordPressコアの再インストールでデータは消えるのか

ダッシュボードからの再インストールでは wp-content を触らないため、テーマやプラグイン、アップロード画像、データベースの内容は消えない。念のため実行前にバックアップを取るのが安全だ。

ステージングサイトを作り直した方が速いのか

ファイル破損の範囲が広い場合や再発を繰り返す場合は、WP-Staging で作り直す方が確実だ。その際は除外設定と保存容量を確認し、ライブサイト側が正常であることを先に確かめておく。

Wordfenceの警告をPHP 8のままで消せるのか

Wordfence を最新版へ更新すれば大半の Deprecated 警告は消える。テーマ側の警告が残る場合は、該当するウィザード機能を無効化するか、PHP 8.1 系を選んで一時的に警告を抑える方法もある。ただし警告を無理に隠すより、コードを更新する方が安全だ。

この記事のポイント

  • call_user_func_array の TypeError はコアファイル欠落が PHP 8 で致命化したもの
  • PHP 7.4 への切り替えは応急処置で根本解決ではない
  • 管理画面から WordPress コアを再インストールして欠落ファイルを戻す
  • Wordfence とテーマを更新し PHP 8 へ戻して確認する
  • ステージング作成時の除外設定やファイルの完全性も確認する
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はプラグインページの詳細表示から入手できる
  • 更新前にはバックアップと旧版の確保、ステージングでの確認を行っておく
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.php が is_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 からのプラグイン無効化は管理画面にアクセスできないときの最終手段