WordPress｜functions.phpのエラーの直し方｜重大なエラーから復旧する手順

WordPressでfunctions.phpを編集した直後に「このサイトで重大なエラーが発生しました」と表示されても、投稿や画像などのデータまで消えたとは限りません。

多くの場合は、追加したPHPコードの構文ミスや関数の重複により、WordPressの処理が途中で停止している状態です。

変更箇所が分かっているなら、編集前のfunctions.phpへ戻すか、直前に追加したコードを削除することで復旧できる可能性があります。

管理画面に入れない場合も、WordPressのリカバリーモード、レンタルサーバーのファイルマネージャー、FTPまたはSFTPから修正できます。

ただし、エラー画面に「functions.php」と表示されていても、テーマのファイルではなくWordPress本体やプラグイン内の同名ファイルを指している場合があります。

この記事では、サイトをいったん表示できる状態へ戻し、エラーの発生箇所を特定して、同じ問題を繰り返さないための手順まで順番に解説します。

WordPress functions.php エラーは変更前に戻すのが最短

functions.phpを編集した直後にエラーが発生した場合は、追加・変更した部分を元に戻すのが最も早い対処法です。

PHPはHTMLやCSSと異なり、セミコロンや括弧が1つ不足しただけでも、そのファイルを読み込めなくなることがあります。

テーマのfunctions.phpは、サイトの表側だけでなくWordPress管理画面でも読み込まれるため、エラーの内容によっては管理画面にも入れなくなります。

なお、正しいファイル名はfunctions.phpであり、「function.php」ではありません。

最初に、現在の状況に応じて次の順番で対処してください。

1. WordPressの管理者メールアドレスにリカバリーモードの案内が届いていないか確認する
2. 届いている場合は、メール内の専用リンクから管理画面へ入る
3. 届いていない場合は、レンタルサーバーのファイルマネージャーまたはFTP／SFTPを開く
4. エラーメッセージに表示されたfunctions.phpの場所を確認する
5. 編集前のファイルへ戻すか、直前に追加したコードを削除する
6. サイトと管理画面を表示し、エラーが解消したか確認する

リカバリーモードのメールが届いている場合

WordPressには、テーマやプラグインなどで致命的なPHPエラーが発生した際に、管理者が復旧作業を行うためのリカバリーモードがあります。

管理者メールアドレスに「サイトで技術的な問題が発生しています」などの案内が届いている場合は、本文に記載された専用リンクを開いてください。

通常のログインURLではなく、メールに記載されたリカバリーモード専用のURLからログインする必要があります。

ログイン後は、問題を起こしたテーマやプラグインが管理者のセッション内で一時停止され、エラーの原因に関する通知が表示されます。

functions.phpを編集していた場合は、表示されたテーマを確認し、直前に追加したコードを修正または削除します。

修正後にサイトを表示して問題がないことを確認し、管理画面上部などに表示される「リカバリーモードを終了」を選択してください。

メールが届かない場合は、迷惑メールフォルダも確認してください。

メール送信処理に使用しているプラグインより先に致命的なエラーが発生すると、サーバーから直接送信されたメールが迷惑メールとして処理される場合があります。

管理画面に入れない場合はサーバー側からfunctions.phpを戻す

リカバリーモードを利用できない場合は、レンタルサーバーのファイルマネージャー、FTPまたはSFTPを使用します。

多くのレンタルサーバーにはブラウザ上でファイルを操作できる機能があるため、必ずしもFTPソフトをインストールする必要はありません。

テーマのfunctions.phpは、一般的に次の場所にあります。

/wp-content/themes/使用中のテーマ名/functions.php

子テーマを使用している場合は、親テーマではなく、現在有効になっている子テーマのフォルダも確認してください。

エラーメッセージにファイルパスが表示されているなら、推測でテーマを選ばず、そのパスと一致するファイルを開きます。

修正する前に、現在の壊れたfunctions.phpもパソコンへダウンロードするか、別名でコピーして保存してください。

エラーが発生する直前のバックアップがある場合は、そのfunctions.phpをアップロードして上書きします。

追加したコードが明確に分かる場合は、そのコードだけを削除し、それ以前から存在していたコードは残します。

括弧や波括弧の位置が分からなくなっている場合は、問題のコードを部分的に修正し続けるより、追加前の状態へ戻す方が安全です。

表示されたfunctions.phpがテーマのファイルとは限らない

WordPress内には、名前にfunctions.phpを含むファイルが複数存在します。

どのfunctions.phpでエラーが起きているかは、ファイル名だけでなく、先頭からのパスで判断してください。

エラーにwp-includes/functions.phpと表示されても、WordPress本体のファイルを直接書き換えてはいけません。

コアファイルはテーマやプラグインから呼び出されるため、実際の原因が別のファイルにあるにもかかわらず、処理が停止した場所として表示されることがあります。

エラー全文に記載された「Stack trace」や、その前に読み込まれたテーマ・プラグインのパスを確認してください。

functions.php エラーの原因をエラーメッセージとdebug.logから特定する

変更前のファイルへ戻して復旧できても、再び同じコードを追加するなら、エラーの種類と発生箇所を確認する必要があります。

最初に確認するのは、WordPressから届いたリカバリーモードのメールです。

メールには、エラーの種類、ファイルの場所、行番号、問題を起こしたテーマやプラグインの名称が記載されている場合があります。

エラーメッセージを一部分だけ見るのではなく、個人情報やサーバー情報を除いて全文を保存してください。

サーバー管理画面にPHPエラーログの閲覧機能がある場合は、そちらも確認します。

WP_DEBUG_LOGでエラーをdebug.logへ保存する

エラーの詳細が表示されない場合は、WordPressのデバッグログを一時的に有効にできます。

WordPressの設置フォルダにあるwp-config.phpをバックアップし、次の設定を「編集が必要なのはここまでです」などのコメントより前に記述します。

すでに同じ定数が記述されている場合は、新しい行を追加せず、既存のtrueまたはfalseを変更してください。

// デバッグ機能を有効にする
define( 'WP_DEBUG', true );

// エラーをwp-content/debug.logへ保存する
define( 'WP_DEBUG_LOG', true );

// エラーをサイト画面には表示しない
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

設定後にエラーが発生する操作を一度だけ再現し、次のファイルを確認します。

/wp-content/debug.log

ログの末尾付近にある、エラーが発生した時刻、エラーの種類、ファイルパス、行番号を確認してください。

同じ警告が大量に記録されている場合でも、サイトを停止させた「Fatal error」「Parse error」「Uncaught Error」などを優先して確認します。

原因を特定した後は、デバッグ設定を無効に戻します。

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

debug.logにはサーバー内のパス、プラグイン名、処理内容などが記録されることがあるため、公開状態のまま長期間残さないでください。

エラーの行番号だけを削除してはいけない

構文エラーに表示される行番号は、PHPが異常を検出した場所であり、入力ミスそのものが存在する行とは限りません。

例えば、閉じる波括弧が不足している場合は、PHPが次の処理へ進んでから異常を検出することがあります。

そのため、表示された行だけでなく、その数行前から確認してください。

末尾でエラーが表示される場合は、追加したコード全体で括弧の数が対応しているか確認します。

エラー行をそのまま削除すると、別の処理まで失われたり、別の構文エラーが発生したりする可能性があります。

よくあるエラーメッセージと確認箇所

functions.phpを戻しても直らない場合の原因別対処法

functions.phpを編集前の状態へ戻しても直らない場合は、テーマ以外のファイル、キャッシュ、PHPの互換性、プラグインの処理を確認します。

直前にfunctions.phpを触っていたとしても、同じ時間帯に実行された自動更新やPHPの切り替えが原因になっている可能性があります。

テーマやプラグインの更新後に発生した場合

テーマ、プラグイン、WordPress本体、PHPのいずれかを更新した後に発生した場合は、エラーのファイルパスから問題の構成要素を特定してください。

プラグインのフォルダが表示されている場合は、該当プラグインを一時停止してサイトが表示されるか確認します。

管理画面に入れない場合は、ファイルマネージャーなどで該当プラグインのフォルダ名を一時的に変更すると、WordPressから読み込まれなくなります。

テーマのフォルダが表示されている場合は、編集内容を戻すか、リカバリーモードで別の正常なテーマへ切り替えます。

PHPのバージョンを変更した直後なら、テーマやプラグインがそのPHPバージョンへ対応しているか確認してください。

古いPHPへ戻すだけで一時的に表示されることはありますが、サポートが終了したPHPを恒久的に使い続ける解決方法にはできません。

問題を起こしたテーマやプラグインの更新版があるか確認し、互換性のないコードを修正することが本来の対処です。

親テーマのfunctions.phpを直接編集していた場合

親テーマのfunctions.phpを直接編集すると、テーマの更新時に変更内容が上書きされます。

更新前のカスタマイズが消えたことに気付かず、同じコードを追加し直した結果、別の場所と重複してエラーになる場合もあります。

今後もテーマに依存するカスタマイズを残す場合は、子テーマのfunctions.phpへ必要なコードだけを記述してください。

ただし、親テーマのfunctions.phpを子テーマへ丸ごとコピーしてはいけません。

子テーマのfunctions.phpと親テーマのfunctions.phpは両方読み込まれるため、同じ関数が定義されると「Cannot redeclare」の致命的なエラーにつながります。

「変更を反映できませんでした」と表示される場合

WordPressのテーマファイルエディターは、保存したコードでサイトが停止しないか確認するため、自分自身のサイトへ通信するループバック処理を使用します。

ループバック通信がサーバー、セキュリティ機能、Basic認証、プラグインなどに妨げられると、コード自体に問題がなくても保存時の確認に失敗する場合があります。

管理画面の「ツール」から「サイトヘルス」を開き、ループバックリクエストに関する問題が表示されていないか確認してください。

この状態でテーマファイルエディターを使い続けるより、バックアップを作成したうえでステージング環境やローカル環境から検証する方が安全です。

バックアップがない場合

直前に追加したコードが分かるなら、その部分だけを削除します。

変更箇所が分からない場合は、現在のfunctions.phpを必ず保存したうえで、使用しているテーマと同じバージョンの配布ファイルを入手し、差分を確認してください。

カスタマイズされていない親テーマであれば、同じバージョンの正常なfunctions.phpへ戻せる場合があります。

独自のカスタマイズが含まれているファイルを確認せずに上書きすると、エラーは直っても必要な機能が失われる可能性があります。

原因を特定できない場合は、エラー全文、発生日時、直前に行った操作、WordPress・PHP・テーマ・プラグインの各バージョンをまとめて、レンタルサーバーまたは制作担当者へ伝えてください。

functions.php エラーを繰り返さないための対策

本番サイトのfunctions.phpを直接編集する運用を避け、バックアップと検証環境を用意することが最も有効な再発防止策です。

編集前にファイルとデータベースをバックアップする

functions.phpだけの変更でも、編集前のファイルを保存してください。

テーマ更新やプラグイン更新を伴う場合は、WordPressのファイルとデータベースの両方をバックアップします。

バックアップは、実際に復元できる場所と形式で保管する必要があります。

親テーマではなく子テーマを使用する

親テーマを直接編集すると、更新によってカスタマイズが消える可能性があります。

テーマのデザインや表示に関係するコードは、原則として子テーマへ追加してください。

子テーマを使用していても、親テーマと同名の関数をそのまま定義すると重複するため、関数名にはサイトやテーマ固有の接頭辞を付けます。

function nch_custom_excerpt_length( $length ) {
    return 80;
}

上記の「nch_」のように固有の接頭辞を付けることで、テーマやプラグインに存在する一般的な関数名との衝突を減らせます。

テーマに依存しない機能はプラグインとして分離する

テーマを変更しても残すべき機能は、functions.phpではなく専用のプラグインとして管理する方法があります。

例えば、独自の投稿処理や管理機能など、サイトのデザインに依存しない機能はテーマから分離した方が管理しやすくなります。

functions.phpはテーマが有効な間だけ読み込まれるため、テーマを変更すると、その中へ追加した機能も読み込まれなくなります。

functions.phpの末尾に閉じるPHPタグを書かない

functions.phpがPHPコードだけで構成されている場合は、末尾の「?>」を省略できます。

閉じるタグの後に空白や改行が入ると、意図しない出力として扱われ、「headers already sent」などの原因になる場合があります。

末尾は次のように、PHPコードのまま終了させます。

<?php
// functions.phpの処理

function nch_example_function() {
    // 処理内容
}

// 末尾に ?> は記述しない

本番サイトのテーマファイルエディターへ直接貼り付けない

WordPressのテーマファイルエディターは手軽ですが、自動で編集前のバックアップを作成する機能ではありません。

保存したコードによってサイトが停止すると、そのエディター自体へ入れなくなる可能性があります。

少なくとも、サーバーのファイルマネージャーへログインできることと、編集前のfunctions.phpを保存していることを確認してから作業してください。

可能であれば、ステージング環境またはローカル環境で動作確認し、その後に本番へ反映します。

まとめ［Q&A］