WordPressデバッグモードを使用してサイトエラーを修正する方法

公開: 2021-11-11

プラットフォームとしてのWordPressの安定性にもかかわらず、ある時点でエラーが発生します。 さらに、それがどのようにしてそこに到達したのか、またはそれを修正するために何ができるのかがわからない可能性があります。 このような状況では、WordPressのデバッグモードは命の恩人です。

デバッグは、「バグ」が大混乱を引き起こしている理由を見つける方法ですが、それを修正する方法も理解する必要があります。 一部のデバッグメッセージは、ポインタを提供します。 ただし、デバッグモードが役立つと、修復プロセスは簡単になることがよくあります。

この投稿では、WordPressのデバッグモードについて知っておく必要のあるすべてのことを紹介します。 まず、モードの機能について詳しく説明します。

WordPressのデバッグモードとは

多くの場合、デバッグのバージョンが実際に動作しているのをすでに確認しています。 WordPress Webサイトでエラーが発生した場合、これは実行中のデバッグプロセスのごく一部、つまりエンドポイントです。 通常の状況では、サイトに重大な重大なエラーの通知が表示されます。 データベース接続の確立エラーや500内部サーバーエラーなどの問題について考えてみてください。

データベース接続の確立エラーエラー。

ただし、「サイレント」であるエラーは他にもたくさんあります。 つまり、エラーを探し出さない限り、エラーが発生したことはわかりません。 WordPressデバッグモードは、これらの状況に最適です。

サイトのバックエンドまたはフロントエンドに通知が表示されますが、これはエラーに限定されません。 デバッグモード（ WP_DEBUGとも呼ばれます）を有効にすると、基になるコードに関する警告と通知も表示されます。 たとえば、表示されない、または壊れた動作をしないサイトの側面でエラーが発生することがよくあります。 これは仕様によるものです。

そのため、 WP_DEBUGを使用して、サイトのPHPコードの問題をキャッチできます。これを修正すると、より耐性があり、パフォーマンスの高い基盤が得られます。

WordPressデバッグモードを使用する理由

表面的には、 WP_DEBUGを使用しても、平均的なサイトユーザーにとって多くのメリットはないと言っても過言ではありません。 普遍的ではありませんが、これは事実である可能性があります。 実際、ほとんどのサイトでは、WordPressはエラーの処理と表示の両方に優れているため、デバッグモードを使用する必要はありません。

ただし、WordPressのデバッグモードが便利ないくつかの状況を考えることができます。

  • 一般的なサイト所有者の場合でも、 WP_DEBUGをアクティブ化すると、通常の状況では発生しない複雑な問題を診断するのに役立ちます。 一例は、WordPress White Screen of Death（WSoD）です。 多くの場合、WordPressデバッグモードを使用するとエラーが明らかになります。これにより、修正を見つけるのに有利なスタートを切ることができます。
  • 開発者の場合、 WP_DEBUGはワークフローにおいて非常に貴重なツールになります。 これは、サイトを壊すエラーと、将来的に問題を引き起こす可能性のある問題について知りたいためです。 WordPressのデバッグモードでは、これらすべてとそれ以上が表示されます。 たとえば、コード内の減価償却された関数と引数に関する通知も表示されます。 これらは今のところあなたのサイトを壊すことはありませんが、機能が後日消えると問題になります。

一般に、 WP_DEBUGはライブサイトでアクティブにすべきではありません。 そのため、ローカル環境またはステージング環境を使用する場合は、より多くの開発ツールになります。 それでも、デバッグモードはライブサイトで使用できますが、非常に小さく、統制のとれた頻度で使用されます。

ライブサイトでデバッグモードを使用する場合は、従うべきいくつかのルールがあります。長時間使用しないでください。サイトのトラフィックが最も少ないときにアクティブにし、終了後にWP_DEBUGを非アクティブにします。 これにより、関連するリスクが最小限に抑えられ、サイトのメンテナンスがエンドユーザーの目から遠ざけられます。

2つの方法でサイトのWordPressデバッグモードを有効にする方法

WordPressデバッグモードを有効にする場合、2つの一般的な方法があります。

  • wp-config.phpファイルを開き、数行のコードを追加します。
  • プラグインをインストールしてアクティブ化し、デバッグモードを有効にします。

サイトのデバッグに役立つ関連モードとコンパニオンモードもいくつかあります。 これらについては後のセクションで説明しますが、ここでは手動によるアプローチについて説明します。

1.wp-config.phpファイルを使用してデバッグモードを有効にします

WordPressのコアファイルに精通している場合は、 wp-config.phpについて知っているでしょう。 初心者の場合、このファイルにはサイトとサーバーの構成設定が保存されます。 これは、他の問題の中でも特に、データベース接続の確立中にエラーを引き起こす可能性がある1つのファイルです。

そのため、注意が必要なファイルです。 このため、開始する前に、次のことを確認する必要があります。

  • セキュアファイル転送プロトコル（SFTP）の知識、およびそれを使用するスキル。
  • FileZilla、Cyber​​duck、Transmitなどの適切なSFTPクライアント。
  • SFTPクレデンシャル。これは、ホスティングダッシュボード内、またはプロバイダーからの電子メールで見つけることができます。
  • 変更をロールバックする必要がある場合に備えて、サイトのクリーンで最新のバックアップ。
  • 専用のテキストエディタが必要になる場合がありますが、必須ではありません。

これらを配置したら、SFTPを介してサイトにログインします。 1つのサイトのみを実行している場合は、ルートディレクトリ（ wwwまたはpublic_htmlとも呼ばれます）が移動先になります。

SFTPを介したWordPressルートディレクトリ。

ただし、サーバー上で複数のサイトを実行している場合は、サイトの名前のディレクトリにある可能性もあります。 適切な場所に移動したら、 wp-config.phpファイルを探します。 wp-config-sample.phpファイルもありますが、これは必要なものではないことに注意してください。

ファイルが見つかったら、を右クリックして編集するオプションを選択します。 これはSFTPソリューションによって異なりますが、見逃しがたいことがよくあります。

SFTPを使用してファイルを開く。

ファイルを開いたら、デバッグモードを有効にするために1行追加します。

define( 'WP_DEBUG', true);

/* That's all, stop editing! Happy blogging. */ /* That's all, stop editing! Happy blogging. */ /* That's all, stop editing! Happy blogging. */ 。 変更を保存すると、WordPressデバッグモードがアクティブになります。 ファイルに行を追加することもできます。 たとえば、次のように専用の書き込まれたdebug.logファイルを作成できます。

define( 'WP_DEBUG_LOG', true );

ただし、 trueではなくfalse値を使用してWP_DEBUGを無効にすることを忘れないでください。 別の方法として、 wp-config.phpファイルから関連する行を削除し、変更を再保存することができます。

2.専用プラグインを使用してWordPressのデバッグモードを有効にします

プラグインを使用してデバッグモードを有効にすることもできます。 これにより、コアファイルをいじくり回すのが不快な場合に、プロセスにアクセスしやすくなります。 このためのトップソリューションは、WPデバッグです。

WPデバッグプラグイン。

プラグインをインストールしてアクティブ化すると、プラグインはすでに機能しています。 これにより、 wp-config.php内で次の「定数」が有効になります。

 define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'SCRIPT_DEBUG', true ); define( 'SAVEQUERIES', true );

最初の2つの定数はすでに使用しています。 SCRIPT_DEBUGは、WordPressを切り替えて、コアCSSおよびJavaScriptファイルの開発バージョンを使用します。 通常の状況では、WordPressは縮小されたファイルを使用するため、まれに問題が発生する可能性があります。 バグを探している場合、これは影響しませんが、開発者であれば影響する可能性があります。

SAVEQUERIESは、データベースクエリをグローバル配列（ $wpdb->queries ）に格納する開発者向けの定数でもあります。 クエリ自体、実行にかかった時間、およびクエリを呼び出した関数が格納されます。 また、パフォーマンスにも影響するため、プラグインを使用する場合はこの点に注意する必要があります。 上記があなたにとってほとんど意味がない場合、それはあなたの経験にとってあまり重要ではないことを知ってください。

プラグインをインストールすると、追加のプラグインもインストールする必要がある場合があります。

WordPressバックエンドの管理者通知。

実際、特定のタスクを実行する開発者でない限り、これらは必要ありません。

プラグインオプションは最小限であり、使いやすさに役立ちます。 設定はWordPressの[ツール]>[WPデバッグ]メニューにあり、次の3つのオプションがあります。

  • WP_DEBUGを有効にします。
  • WP_DEBUG_DISPLAYをfalseに設定します。 これにより、ログエラーの有無に関係なく、Webサイトの通知が表示または非表示になります。
  • WP_DISABLE_FATAL_ERROR_HANDLERをtrueに切り替えます。 これが何を意味するのかわからない場合は、WSoDをより頻繁に引き起こす可能性があるため、そのままにしておく必要があります。

ログを確認したい場合は、[デバッグクイックルック]メニューから確認できます。

デバッグクイックルックバー。

プラグインは、コアファイルを掘り下げることなくサイトをデバッグするための便利な方法であるため、インストールする価値があります。 もちろん、手動の方法と同じように、終了後にプラグインをアンインストールするか、オプションを無効にすることをお勧めします。

まとめ

WordPressサイトに障害が発生することはまれですが、少なくとも発生した場合は修正できます。 ほとんどの主要なエラーは、サイトの通知またはサイトの読み込み時のページのいずれかで表示されます。 ただし、特に開発者の場合は、知っておく必要のある「サイレント」エラーや懸念事項が他にもたくさんあります。

この投稿では、WordPressデバッグモードをアクティブにする2つの方法を紹介しました。 ここに再びあります：

  • SFTPを使用してwp-config.phpファイルを開き、数行のコードを追加します。
  • WP Debuggingなどのプラグインをインストールし、手間のかからないアプローチでエラーをログに記録します。

WordPressデバッグモードを使用する必要がありますか？この投稿は役に立ちますか？ 以下のコメントセクションでお知らせください。