タグアーカイブ FTP

  1. ホーム   /  タグ付きの投稿: "FTP"
WooCommerce納品書印刷でFTPエラーが起きた時の原因と直し方
2026年8月6日 0

WooCommerce納品書印刷でFTPエラーが起きた時の原因と直し方

WooCommerceのマイアカウント画面から「納品書を印刷」や「領収書を印刷」をクリックした瞬間に「このサイトで重大なエラーが発生しました」と表示されてページが落ちる場合、原因はプラグインがFTPの認証情報なしにファイルシステムへアクセスしようとしたことにある。PHP 8環境で発生しやすいこの問題は、WP_Filesystem()の呼び出し方を修正すれば直る。

エラーの原因は何か

エラーの原因は何か

この問題は「Print Invoice & Delivery Notes for WooCommerce」などの納品書プラグインが、フロントエンドからWP_Filesystem()を呼び出す際にFTPの認証情報を渡していないことが根本原因だ。WP_Filesystem()はWordPressがサーバー上のファイルを操作するためのAPIで、通常は管理画面から操作するときに使われる。しかしプラグインのコードがこのAPIをバックグラウンドで実行しようとしたとき、必要なFTP接続情報が揃わず、接続オブジェクトがnullのままになってしまう。

PHP 8では関数の引数の型チェックが厳格化されたため、nullの接続オブジェクトをftp_nlist()などの関数に渡すと即座に致命的なTypeErrorが発生する。これが「Uncaught TypeError: ftp_nlist(): Argument #1 ($ftp) must be of type FTP\Connection, null given」というエラーの中身だ。

エラー発生時の状態
プラグインが WP_Filesystem() を引数なしで呼び出す
↓
FTP認証情報がないため接続オブジェクトが null になる
↓
PHP 8の型チェックで TypeError が発生し画面がクラッシュ
↓
修正後の正しい流れ
まず request_filesystem_credentials() で認証情報を取得
↓
取得した認証情報を WP_Filesystem( $credentials ) に渡す
↓
FTP接続が正常に行われ、ファイル操作が完了する
■ エラー発生時　■ 修正後

上の図で見るとわかるように、修正前は認証情報の取得ステップが丸ごと抜け落ちている。WordPressが用意している標準的な手順は「まず認証情報を集め、それからファイルシステムを初期化する」という2段階だ。プラグインがこの流れを省略したことで、FTP接続が確立されないまま後続の処理が走り、致命的エラーに至っている。

自分のサイトでエラーが発生しているか確認する方法

自分のサイトでエラーが発生しているか確認する方法

まずはエラーの詳細を把握するためにWordPressのデバッグモードを有効にしよう。wp-config.phpに以下の行を追加する。

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

この設定をすると、エラーの内容が/wp-content/debug.logに記録されるようになる。ページが真っ白になる現象は本番環境では特に厄介だが、ログを見ればスタックトレースが残っているため原因を特定できる。スタックトレースの中にwp-admin/includes/class-wp-filesystem-ftpext.phpやwoocommerce-delivery-notesというパスが見つかれば、今回のケースに該当する可能性が高い。

プラグインのコードを修正してエラーを止める手順

プラグインのコードを修正してエラーを止める手順

根本的な修正はプラグイン本体のコードを書き換えることだが、これはプラグインが更新されるたびに変更が上書きされてしまう一時しのぎの対策だ。それでも今すぐエラーを止めたい場合には有効なので、まずは直接修正する手順を説明する。

修正対象のファイルとコードの場所

対象ファイルはプラグインディレクトリ内の includes/helpers/class-utils.php にある get_filesystem() メソッドだ。このメソッドが WP_Filesystem() を引数なしで呼び出している箇所が問題の中心になる。

// 修正前のコード
public static function get_filesystem() {
    global $wp_filesystem;
    if ( ! $wp_filesystem ) {
        require_once ABSPATH . 'wp-admin/includes/file.php';
        WP_Filesystem(); // ← 引数がないためFTP接続に失敗する
    }
    return $wp_filesystem;
}

修正後のコード

以下のように書き換える。request_filesystem_credentials() であらかじめ認証情報を取得し、それを WP_Filesystem() に渡す形にする。さらに、request_filesystem_credentials() が認証情報を問い合わせるHTMLフォームを出力してしまうのを防ぐために、出力バッファリングで囲んでおく。

// 修正後のコード
public static function get_filesystem() {
    global $wp_filesystem;
    if ( ! function_exists( 'WP_Filesystem' ) ) {
        require_once ABSPATH . 'wp-admin/includes/file.php';
    }
    if ( ! $wp_filesystem ) {
        ob_start(); // バッファリング開始
        $credentials = request_filesystem_credentials( '' );
        ob_end_clean(); // バッファを捨てる（フォーム出力を抑制）
        WP_Filesystem( $credentials ); // 認証情報を渡す
    }
    return $wp_filesystem;
}
STEP 1 FTPまたはサーバーのファイルマネージャーでプラグインファイルにアクセス
↓
STEP 2 includes/helpers/class-utils.php をテキストエディタで開く
↓
STEP 3 get_filesystem() メソッドを見つけてコードを差し替え
↓
STEP 4 ファイルを保存してアップロードし、動作を確認

この修正を施すと、wp-config.phpに定義されたFTP定数（FTP_HOST、FTP_USER、FTP_PASS）や、WordPressがデータベースに保存している認証情報が自動的に使われるようになる。結果としてFTP接続が正常に確立され、exists()などのファイル操作メソッドが問題なく動作する。

プラグイン更新で修正が消えないようにする恒久対策

プラグイン更新で修正が消えないようにする恒久対策

プラグインのコアファイルを直接編集する方法は、アップデートがあるたびに上書きされてしまうため本番運用には不向きだ。より持続的な対策として、以下のいずれかの方法を選ぶとよい。

子テーマのfunctions.phpでフックを使って上書きする

プラグインが提供しているフィルターフックやアクションフックを利用し、テンプレートのレンダリング時にファイルシステムアクセスが発生する処理を迂回する方法だ。ただし、このプラグインではフックが十分に用意されていない可能性が高いため、テーマのCSSやテンプレートの上書きだけで対応しきれないこともある。

プラグインのIssueトラッカーやサポートフォーラムに修正を依頼する

今回の修正はすでにWordPress.orgのサポートフォーラムにも報告されている。プラグインの開発者がこの修正を取り込めば、次回以降のアップデートで公式に問題が解決される。開発者の対応を待つ間は、前述のファイル直接編集でしのぎつつ、アップデートのたびに修正を再適用する運用になる。

プラグイン全体をフォークして独自バージョンを使う

どうしても自前で管理したい場合は、プラグインのコードをコピーして別のプラグインとしてインストールし直す方法もある。ただし今後のアップデートやセキュリティパッチの追従をすべて自分で行う必要があるため、開発リソースに余裕がある場合に限った選択肢だ。

同じエラーが別のプラグインで出る場合の一般的な対処法

同じエラーが別のプラグインで出る場合の一般的な対処法

今回のエラーは「Print Invoice & Delivery Notes for WooCommerce」に限らず、フロントエンドから WP_Filesystem() を不用意に呼び出しているあらゆるプラグインで発生しうる。バックアップ系、インポート系、PDF生成系のプラグインで似たような「ftp_nlist()」を含むTypeErrorが出た場合は、以下の共通チェックポイントで原因を絞り込める。

  • スタックトレースの2〜3行目に表示されているプラグインのパスを特定する
  • 該当プラグインのファイルシステム呼び出し部分を探す（WP_Filesystem() または $wp_filesystem を grep する）
  • 認証情報の取得が行われているか確認する（request_filesystem_credentials() の有無）
  • PHPのバージョンを確認する（PHP 8.0未満では暗黙の型変換でエラーが表面化しないことがある）
エラーパターンの見分け方
パターンA 管理画面では動くがフロントエンドでだけ落ちる → FTP認証情報の未取得が原因
パターンB PHP 7.xでは問題なかったがPHP 8に上げたら発生 → 型チェック厳格化の影響
パターンC 特定のサーバー環境（ftpext方式）でのみ発生 → ファイルシステム方式の不一致

特に「ftpext」というファイルシステム方式を使用しているサーバー環境で顕著に発生する。多くのレンタルサーバーでは「direct」方式が使われるため問題が起きにくいが、FTP経由でファイル操作を行う設定になっているとこのエラーに遭遇しやすい。

よくある質問

エラーが出ているのに管理画面にはアクセスできるのはなぜか

管理画面ではWordPressがWP_Filesystem()を呼び出す前に自動的に認証情報を収集する仕組みが働くため、正常に動作する。フロントエンドではその仕組みが起動しないため、プラグインが自前で認証情報を取得しない限り接続に失敗する。これが「管理画面では動くのにマイアカウント画面では落ちる」という現象の理由だ。

出力バッファリングをしないとどうなるのか

request_filesystem_credentials() は認証情報が不足している場合にFTPのホスト名やユーザー名を入力するHTMLフォームを画面に直接出力してしまう。フロントエンドのページに突然フォームが表示されると、サイトのレイアウトが崩れたり、ユーザーを混乱させたりする。出力バッファリングでこのフォーム出力を捕捉して破棄することで、見た目に影響を与えずに認証情報だけを取得できる。

wp-config.phpにFTP定数を設定するだけで直らないのか

FTP定数（FTP_HOST、FTP_USER、FTP_PASS）を定義していても、プラグインがWP_Filesystem()を引数なしで呼び出している限り、WordPressは認証情報を探しに行かない。定数はあくまで「情報の置き場所」であり、「その情報を取りに行く処理（request_filesystem_credentials()）」が実行されなければ意味がない。コードの修正が不可欠な理由はここにある。

PHP 8にアップグレードした直後から発生したのだが関係あるのか

大いに関係がある。PHP 8.0から関数の引数と戻り値の型が厳密にチェックされるようになり、それまで暗黙的に許容されていたnullの受け渡しがTypeErrorとして検出されるようになった。PHP 7.x時代は同じコードでも警告で済んでいたか、あるいはエラーが発生しても表面的に無視されていた可能性が高い。

この修正でセキュリティ上の問題は起きないのか

起きない。request_filesystem_credentials()はWordPressのコア関数であり、管理画面で日常的に使われている安全な方法だ。認証情報はwp-config.phpの定数やデータベースに保存された情報から取得され、フロントエンドの訪問者にFTPのパスワードが表示されることはない。出力バッファリングでフォームの表示を抑制するのも、余計な情報を露出させないための適切な処置だ。

この記事のポイント

  • WooCommerceの納品書印刷で重大エラーが発生するのは、プラグインがWP_Filesystem()を認証情報なしで呼び出しているのが原因
  • PHP 8の厳格な型チェックにより、FTP接続オブジェクトがnullのまま関数に渡されてTypeErrorが起きる
  • プラグインのclass-utils.phpにあるget_filesystem()メソッドを修正すれば即座に直る
  • request_filesystem_credentials()で認証情報を先に取得し、出力バッファリングでフォーム表示を防ぐのが正しい修正手順
  • プラグインのアップデートで修正が消えるため、恒久対応は開発者による公式修正を待つかフォークしての運用が必要
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
プラグイン更新後に管理画面が真っ白になった時の原因と直し方
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 もファイルマネージャーも使えない時のデータベース無効化

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 が使えなくてもファイルマネージャーやデータベース操作で対処可能
  • 原因は未定義メソッドの呼び出しで、デバッグログで特定できる
  • ステージング環境での事前テストと定期バックアップが最も有効な予防策
佐々木 太陽
, , , ,
お悩み・トラブル解決
WordPressで重大なエラーが発生した時の原因と復旧手順
2026年6月29日 0

WordPressで重大なエラーが発生した時の原因と復旧手順

WordPressで「このサイトで重大なエラーが発生しました」と表示され管理画面にもログインできない場合、まず試すべきはサーバーのエラーログ確認と、FTPを使った原因プラグインの強制停止だ。管理用メールが届かなくても、手動の切り分け作業でサイトを復旧できる。

なぜ「このサイトで重大なエラーが発生しました」と表示されログイン不能になるのか

なぜ「このサイトで重大なエラーが発生しました」と表示されログイン不能になるのか

あのメッセージが表示されるとき、WordPress内部ではPHPの「致命的エラー（Fatal Error）」が起きている。プログラムの処理がそこで停止してしまい、画面表示が途中で終わる。テーマやプラグインの更新失敗、PHPバージョンの非互換、サーバーのメモリ上限超過、あるいはコアファイルの破損など原因は多岐にわたる。

WordPress 5.2以降、致命的エラーが起きると管理画面へのログインも止められる設計になった。これは「壊れかけのサイトを操作し続けて被害を拡大させない」ための安全措置だ。通常なら「サイトに技術的な問題が発生しました。復旧手順のリンクを管理者メールアドレスに送信しました」という案内とともに「回復モード」用のリンクがメールで届く仕組みになっている。

ただ、このメールが届かないケースは実際には非常に多い。メールサーバーの設定不備や、そもそも通知を受け取る管理者アドレスが存在しないサイトもある。つまり「メールが届かない＝打つ手がない」わけではない。手動での復旧手順を覚えておけば、すぐに対処できる。

管理用メールが届かなくてもエラーの原因を特定する手順

管理用メールが届かなくてもエラーの原因を特定する手順

原因を特定できないまま闇雲に操作すると、状況をさらに悪化させかねない。まずは「一体どのファイルの何行目で止まっているのか」という技術情報を掴む必要がある。

サーバーのエラーログを最優先で確認する

「重大なエラー」の原因は、ほとんどの場合サーバー上の「エラーログ」に明瞭に記録されている。エックスサーバー、ConoHa WING、さくらのレンタルサーバなど国内の主要レンタルサーバーなら、コントロールパネル内の「エラーログ」や「アクセスログ」といったメニューから確認可能だ。cPanel系であれば「Errors」アイコンから辿れる。

  • ログには「PHP Fatal error」という文言と、問題が起きたファイルのパス（/home/…/plugins/xxxx/xxxx.php on line 123 など）が刻まれている
  • ここでプラグイン名が明記されていれば原因はほぼ特定できたも同然だ
  • もしログの見方が分からない場合は、「エラーログをダウンロードして全文をテキストエディタで開き、Fatal で検索する」とよい

wp-config.php で WP_DEBUG を有効にしてエラーを画面表示させる

エラーログがすぐに見つからない・もしくはより直感的に原因を掴みたい場合は、WordPressのデバッグモードを有効にする。FTPソフト（FileZillaなど）か、サーバーのファイルマネージャーで WordPress インストールディレクトリ直下の wp-config.php ファイルに以下の行を追加する。

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

この設定でエラー情報は /wp-content/debug.log に書き出される。ブラウザ上でサイトを再読込し、その後このログファイルを開けば、先ほどと同じように原因ファイルを特定できる。WP_DEBUG_DISPLAY を true にすると画面に直接エラーが表示されるが、一般の訪問者にも見えてしまうので本番環境での使用は推奨しない。問題を解決したあとは false に戻すか、行ごと削除すること。

FTPやファイルマネージャーで原因のプラグインやテーマを強制停止する

FTPやファイルマネージャーで原因のプラグインやテーマを強制停止する

原因が特定のプラグインやテーマだと判明したら、管理画面に戻らなくても手動で無効化できる。管理画面を経由せず、ファイル名の変更で読み込ませないようにする手法だ。これでサイトの表示や管理画面へのアクセスが復活する。

STEP 1 サーバーのエラーログを確認する
↓
STEP 2 wp-config.php に WP_DEBUG 設定を追記する
↓
STEP 3 エラーメッセージから原因プラグインを特定する
↓
STEP 4 該当プラグインをリネームして無効化する

原因プラグインのフォルダをリネームする

FTPソフトまたはレンタルサーバーのファイルマネージャーで、WordPress のインストール先に移動し、/wp-content/plugins/ ディレクトリを開く。エラーログに書かれていたプラグイン名と一致するフォルダを見つけて、名前を変更する。末尾に「_deactivated」や「_bk」などを付け足せばよい。

  • 変更前: problem-plugin
  • 変更後: problem-plugin_deactivated

WordPress はフォルダ名が一致しないプラグインを読み込まなくなる。結果、致命的エラーの原因が取り除かれ、サイトは無事に表示されるようになる。管理画面にも再びログイン可能になる。

すべてのプラグインを一括で疑う場合の方法

エラーログ上でプラグイン名が特定できないが、何らかのプラグインが原因であることは間違いない場合、/wp-content/plugins/ フォルダそのものをリネームしてしまう手もある。たとえば plugins を plugins_stop に変更すれば、すべてのプラグインが一括で無効化される。その状態で管理画面にログインできれば、原因はやはりプラグインなので、フォルダ名を元に戻し、管理画面から一つずつ有効化していく。テーマが原因と疑われる場合は、/wp-content/themes/ 以下の現在のテーマフォルダをリネームする。WordPress はテーマが存在しないとデフォルトテーマ（Twenty Twenty-Five など）に自動で切り替わる。

復旧後に必ずやっておくべき再発防止策

復旧後に必ずやっておくべき再発防止策

サイトが無事に表示され管理画面にも入れたら、そのまま運用を再開するのではなく、必ず以下の3つをチェックする。これで同じエラーが二度と起きにくくなる。

WordPress本体、テーマ、プラグインをすべて最新にする

致命的エラーは「古いソフトウェア」と「最新のPHPバージョン」の組み合わせで起きやすい。更新が止まっている長期放置プラグインが混ざっているなら、代替のメンテナンスされているプラグインへの移行を検討する。

PHPバージョンをサーバー管理画面で上げる

WordPress の推奨する PHP バージョンは常に上がっている。サーバーのコントロールパネルで PHP 8.1 以上に設定変更できるか確認する。変更後はサイト全体の動作確認を必ず行う。

WP_DEBUG の設定を本番環境で必ず解除する

wp-config.php にデバッグ設定を追加していた場合、必ず define( 'WP_DEBUG', false ); に戻すか、該当行を削除する。ログ出力を有効にしたまま運用すると、サーバーのディスク容量を圧迫し、別のトラブルを引き起こす。

よくある質問

管理画面の「回復モード」リンクがメールで届かない理由は

主な原因はサイトのメール送信機能そのものが正常に動いていないことだ。特に共用サーバーでは PHP の mail() 関数が制限されているか、WordPress の送信メールが迷惑メールフォルダに分類されている。SMTPプラグインなどで送信経路を信頼性の高いものに変えれば、次回以降の通知は確実に届くようになる。

WordPressログイン画面自体が表示されない場合の対処法は

管理画面へのアクセスすら致命的エラーで遮断されているという状態だ。まず前述の FTP を使ったプラグイン一括停止を試す。それでも改善しないなら、.htaccess ファイルの破損も疑って、ファイル名を .htaccess_bk に変更し、WordPress 管理画面の「設定」→「パーマリンク」で再生成させる。

FTPパスワードがわからないが復旧できるか

レンタルサーバーのコントロールパネルにログインできれば、多くの場合ブラウザ上で操作できる「ファイルマネージャー」が利用可能だ。FTPアカウントの情報が不明でも、ファイルマネージャーさえ使えれば全く同じ手順でプラグインフォルダのリネームができる。

すべてのプラグインを停止してもエラーが消えない

テーマが原因の可能性が高い。FTPで /wp-content/themes/ 以下の現在のテーマフォルダをリネームする。また、WordPress のコアファイルが破損していることもある。「ダッシュボード」→「更新」から WordPress の「再インストール」を実行すれば、コアファイルが上書き修復される。

WP_DEBUG を設定したが debug.log に何も記録されない

サーバー側で PHP エラーログの出力先が別に固定されているケースだ。その場合、レンタルサーバーのコントロールパネルに用意されている「エラーログ」機能に、より詳細な情報が出ている。そこを確認すれば解決の糸口がつかみやすい。また、wp-config.php の記述場所が /* That's all, stop editing! */ より上にあるかも確認する。

この記事のポイント

  • 「重大なエラー」はPHPの致命的エラーが原因で起こる
  • メールが届かなくてもサーバーのエラーログで原因を特定できる
  • FTPやファイルマネージャーでプラグインフォルダをリネームして停止する
  • 復旧後はPHPバージョンの確認とWP_DEBUGの解除が必須
佐々木 太陽
, , , , , ,
お悩み・トラブル解決

メニュー

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

ウェブ開発 最新ニュース

B to B のご提案

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

その他

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

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