WordPress デバッグ: 知っておくべきことすべてガイド

公開: 2023-06-27

コーディング プロジェクトにおける最も弱い部分はあなたです。 つまり、人的エラーはほぼ確実に発生し、バグやその他の問題の形で発生します。 これらが実際のサイトに反映されることは望ましくありません。そのため、プロジェクト中に WordPress のデバッグが必要な手順となります。

実際、WordPress には独自のデバッグ モードが含まれており、プラットフォームを操作するときに役立ちます。 これをオフプラットフォーム デバッガーと組み合わせれば、暗闇に潜むあらゆるものを捕捉する堅牢なシステムが得られます。

この投稿では、🔎 WordPress のデバッグを見て、その設定方法を説明します。 ただし、最初に、WordPress のデバッグと他の種類のバグ キャッチがどのように異なるかを見ていきます。 そこから、WordPress の使用方法を説明する前に、WordPress に独自のデバッグ システムが必要な理由を説明します。

WordPress のデバッグと一般的なコードのデバッグの違い

もちろん、他の多くの Web アプリケーションと同様に、WordPress は PHP を使用して、内部でほとんどすべてを実行します。 ただし、WordPress のデバッグは、その特有の構造とエコシステムにより、一般的なコードのデバッグとは異なる場合があります。

WordPress のデバッグと一般的なコードのデバッグの主な違いは、エラーを表示する方法です。 WordPress は、フロントエンドのプラットフォームに関連するエラー メッセージを表示します。 対照的に、一般的なコードのデバッグは、ターミナルまたは専用のコード エディター内で行われることがよくあります。

デバッガーを実行する Intellij IDEA IDE。

もう 1 つの違いは、デバッグ プロセスを支援する WordPress 固有の関数の使用です。 WordPress は、コンテンツ管理システム (CMS) と対話するために使用する独自の関数セットを提供します。 これらは一般的な PHP 関数とは異なり、デバッグに使用するには特定のアプローチが必要です。

全体として、WordPress のデバッグと一般的なコードのデバッグの違いは、WordPress の特定の構造とエコシステムにあります。 そのため、WordPress のアーキテクチャと、問題を効果的にデバッグするためにプラットフォームが提供するものを理解する必要があります。

WordPress のデバッグに特定のプロセスが必要な理由

WordPress はコアとなる PHP だけを使用しているわけではありません。 また、テーマやプラグインの形式で外部 PHP も実行します。 サードパーティの開発とこれらすべての接続方法を組み合わせると、すべてのコードをメッシュ化するときにバグが発生する可能性があります。 そのため、WordPress は開発中にこれらの問題を根絶するのに役立つ独自のデバッグ ツールを提供しています。

理解する必要があるもう 1 つの領域 (専用の WordPress デバッグが必要な理由に影響する) は、コア ファイルとフォルダーの構造です。 たとえば、テーマの作成はテンプレート階層に依存します。これは、エラーの原因を見つけるためにライン スキャンを実行するときに重要になる可能性があります。

WordPress テンプレート階層の概要。
画像クレジット: WordPress.org

また、WordPress のデザインは優れたユーザー エクスペリエンス (UX) に基づいています。 専用の WordPress デバッグ プロセスでは、ユーザー フレンドリーなエラー レポートの必要性が考慮されています。 コードエディター内で複雑なスタック トレースを使用する代わりに、WordPress はフロントエンドに明確なエラー メッセージを表示します。

ウェブサイトのフロントエンドでの WordPress エラー。

UX について言えば、WordPress はワークフローをより効率的かつ安全にするための一連のカスタム関数を提供します。 そのため、WordPress 固有のデバッグ プロセスでは、これらの関数と、それらがプラットフォームとどのように対話するかを理解する必要があります。

全体として、WordPress には複雑なエコシステムがあり、UX に重点が置かれ、カスタム機能が備わっています。 これらすべてには独自のデバッグ モードが必要です。 次のセクションでは、これをオンに切り替える方法を見ていきます。

WordPress のデバッグモードをオンにする方法 (およびこれによって何が行われるか)

wp-config.phpファイルを通じて WordPress のデバッグモードをオンにすることができます。 これを行う方法については簡単なガイドを用意していますので、1 分程度で完了するはずです。 ただし、知っておくと使用できる可能性があるさまざまなモードがいくつかあります。

  • WP_DEBUG 。 これは WordPress の基本的なデバッグ モードです。 これにより、プラットフォーム内で一般的なデバッグが可能になります。
  • WP_DEBUG_LOG 。 このモードでは、すべての PHP エラー、警告、通知がwp-contentディレクトリ内のdebug.logファイルに保存されます。 フロントエンドには現れない、見つけにくい問題を特定するのに役立ちます。
  • WP_DEBUG_DISPLAY 。 このモードでは、すべての PHP エラー、警告、および通知がフロントエンドに表示されます。 これはテーマやプラグインの問題を特定するのに役立ちますが、壊れていないように見える要素についてのメッセージが表示される場合もあります。 たとえば、データ検証規則が間違っているという通知が頻繁に表示されます。

これら 3 つの機能は相互に絡み合う可能性があるため、最適かつ安全な方法で使用するには注意が必要です。 たとえば、 WP_DEBUGとWP_DEBUG_LOGオンにして、エラーをdebug.logファイルに保存することがよくあります。 ただし、 WP_DEBUG_DISPLAYオフにしない場合、フロントエンドにこれらのエラーが表示されると、UX に悪影響を及ぼします。

また、基本的なコマンドを超えて、別の記事で説明する他の定数をアクティブにすることもできます。

  • SCRIPT_DEBUG 。 パフォーマンス上の理由から、WordPress は縮小された CSS ファイルと JavaScript ファイルを使用しますが、これらのデバッグは悪夢のようなものになる可能性があります。 SCRIPT_DEBUGオンにすると、WordPress は代わりに最適化されていない開発バージョンのファイルを使用します。
  • SAVEQUERIES 。 これにより、すべてのデータベース クエリが配列に保存されるため、サイトのパフォーマンスに影響を与える遅いクエリや非効率なクエリを特定するのに役立ちます。

プラグインがなければ WordPress は現在のプラットフォームではありません。 そのため、WordPress のデバッグを支援する便利なプラグインがたくさんあります。 次に、いくつか見ていきます。

開発中にWordPressデバッグプラグインを使用する

エラーの調査に役立つプラグインを武器の一部として含める必要があります。 実際、WordPress のデバッグに関する公式ドキュメントには、推奨されるオプションがいくつか含まれています。

たとえば、Query Monitor は、実行するクエリに関する詳細情報を提供します。 これは、パフォーマンスの問題を引き起こすクエリを特定するのに役立つ素晴らしい方法です。

デバッグ バーは、WordPress 管理バーにデバッグ メニューを追加します。 これにより、デバッグ情報にいつでもアクセスできるようになり、PHP エラー、データベース クエリ、HTTP リクエストに関する詳細情報が含まれます。

WordPress は多くのカスタム関数と定数を使用するため、それらが非推奨になるかどうかを常に監視する必要があるでしょう。 Log Deprecated Notices プラグインは、WordPress での非推奨の関数、フック、または引数の使用を識別 (およびログ) します。 このプラグインを使用すると、コードを最新の WordPress 標準に合わせて最新の状態に保つことができます。

ただし、WordPress のデバッグに役立つようにインストールできるプラグインは他にもたくさんあります。 素晴らしいオプションの 1 つは、単純にフックを表示することです。

このプラグインを使用すると、ページが実行するすべてのフックを表示できます。 ページでどの WordPress フックが使用されているかが一目でわかるため、最初のバグ探しの手間が軽減され、頼りになるプラグインになることがよくあります。

よりオールインワンのソリューションであるプラグインを探したい場合は、DebugPresssc が良い選択になるでしょう。

このプラグインは、PHP エラー、データベース クエリ、HTTP リクエストなどのリアルタイムのデバッグ情報を提供します。 サーバー側のエラーを監視するためのリアルタイム コンソールも含まれています。

WordPress のデバッグ モードの初期インスタンス化を半自動化したい場合があります。 これが、優れた WP Debugging プラグインの目的です。

これにより、 wp-config.phpファイルを開かなくても、利用可能なすべてのデバッグ定数のデフォルト状態を設定できます。 WordPress の[プラグイン]メニュー内でクイック有効化と無効化を行うことで、それらを切り替えることができます。

WordPress デバッグプラグインの選択

WordPress デバッグ プラグインを選択する場合、最終更新時間などのプラグインの品質指標はそれほど重要ではありません。 これは、一定の最新のコードベースを必要としないタスクを実行することが多いためです。

たとえば、Log Deprecated Notices の最後の更新は 2021 年に行われています。ただし、それにもかかわらず、WordPress 開発者にとっては依然として推奨されるプラグインです。 したがって、プラグインが意図したとおりに動作し、さらなる問題が発生しない場合は、デバッグ目的で使用しても問題ないと考えられます。

アプリケーション パフォーマンス監視 (APM) の利点

APM ツールを使用すると、WordPress Web サイトなどのアプリケーションのパフォーマンスを監視できます。 詳細なパフォーマンス情報には、応答時間、エラー率などが含まれます。

APM ツールとデバッグにはあまり共通点がないように思えるかもしれません。 ただし、これはシナリオによっては、デバッグ作業の一部を軽減するのに役立ちます。 さらに、最初にデバッグしてから、APM を使用してそのパフォーマンスを維持できます。

WordPress のデバッグに関しては、APM ツールには多くの利点があります。

  • WordPress Web サイトのパフォーマンスのボトルネックを特定できます。 リアルタイム分析は、Web サイトの速度を低下させる可能性のある問題を特定できることを意味します。
  • APM ツールは、サイトのパフォーマンスの最適化に役立ちます。 これにより、的を絞った改善を行い、全体的なパフォーマンスを向上させることができます。
  • 主要なパフォーマンス指標を監視することで、Web サイトの健全性に影響を与える可能性のある問題を特定できます。
  • APM ツールは、WordPress Web サイトのセキュリティ問題を特定するのにも役立ちます。 トラフィックとサイトのアクティビティを監視することで、セキュリティの問題を示す可能性のある異常な動作や不審な動作を特定できます。

WordPress に適した APM ツールがいくつか利用可能です。 たとえば、Kinsta には独自の APM ツールがあり、WP Engine は New Relic の APM をサービスに統合しています。

一般に、APM ツールは WordPress Web サイトの UX の向上に役立ち、デバッグ作業に影響を与えます。 APM は代替品ではありませんが、バグ修正が最適かどうか、コードを改善できる箇所を確認するのに役立ちます。

WordPress のデバッグに役立つヒント

この投稿の焦点は WordPress のデバッグです。 これを念頭に置いて、デバッグ セッションをより効果的に行うための 6 つのヒントを紹介します。

  1. 静的コード分析から始める
  2. デバッグツールを活用する
  3. 遭遇した各バグを分類する
  4. バックトラックしてバイナリ検索を実行して、考えられるすべてのバグを探します
  5. 新しいコードスイートを作成するたびにデバッガーを実行する
  6. バグを潰すのではなく問題を解決することに目を向ける

1. 静的コード分析から始める

静的コード分析では、コードを実行せずに分析します。 あなたの目標は、潜在的なエラーと脆弱性を特定することです。 行ごとにスキャンすることもできますが、ツールを使用した方が効率的です。 ここでは PHP CodeSniffer と PHP Mess Detector の両方がうまく機能し、前者は JetBrains の編集ツールの一部でもあります。

これらのツールは、コーディング標準違反、未使用のコード、WordPress Web サイトのパフォーマンスとセキュリティに影響を与える可能性のあるその他の潜在的な問題を特定するのに役立ちます。 通常、これらを開発環境にインストールし、コードベースに対して実行します。 生成されたレポートには、潜在的な問題の概要が示されます。 これにより、それらを特定して修正する方法が得られます。

静的コード分析から始めると、開発プロセスの早い段階で潜在的な問題の芽を摘み取ることができます。 これにより、問題の修正が難しくなり、時間がかかる前に、WordPress Web サイトが適切に機能していることを確認できます。

2. デバッグツールを活用する

デバッグ ツールと言えば、言語や CMS プラットフォームに関係なく、ほぼ必須です。 これは WordPress に特に当てはまります。役立つさまざまな優れたプラグインがあるからです。 ただし、サードパーティのオフプラットフォーム ツールも価値を提供します。

ほとんどの場合、デバッグ ツールを使用すると、サイトをより深く理解できます。 これにより、パフォーマンスの最適化、UX の向上、セキュリティの強化に関して、より多くの情報に基づいた意思決定ができ​​るようになります。

3. 遭遇した各バグを分類する

デバッグに関する日常的な管理タスクの 1 つは、遭遇した各バグを分類することです。 これは、問題の根本原因を特定し、最適な修正を決定するという点で役立ちます。

ここでは、問題の重大度、UX への影響、修正の複雑さなど、複数の要素を考慮する必要があります。 たとえば、クリティカル、メジャー、マイナー、または表面的な重大度レベルのシステムを使用できます。 これは、Web サイトの機能と UX への影響に基づいて、最初に対処するバグの優先順位を決定するのに役立ちます。

バグを分類するもう 1 つの方法は、使いやすさ、機能、セキュリティなどのカテゴリを使用することです。 これは、バグが Web サイトの特定の領域にどのような影響を与えるかを特定するのに役立ちます。 これにより、問題の根本原因とそれを修正するための最適なアプローチを特定しやすくなります。

さらに、これらを保存するための特別なシステムは必要ありません。スプレッドシートで十分に機能します。 コード エディターや統合開発環境 (IDE) 内にカラー コーディングなどのシステムがある場合もあります。

4. バックトラックしてバイナリ検索を実行して、考えられるすべてのバグを探します

「バックトラッキング」とは、バグが最初に発生した場所を特定するために自分の手順を遡ることです。 最近のコード変更を確認したり、以前のコード ベースをテストしたり、ログを確認したりすることができます。 これは、デバッグ プロセスを合理化し、潜在的なすべての問題に確実に対処するための良い方法です。

同様に、バイナリ検索は、特に複雑な問題に対処する場合、WordPress のデバッグに役立つテクニックとなります。 これには、体系的な方法でコードベースのさまざまな部分をテストして、バグの場所を特定することが含まれます。 コードの特定のセクションを分離し、テストを実行してから、次のセクションに移動して問題をさらに絞り込むことができます。

これはバグを特定し、修正する方法を見つけるための効率的な方法です。 無計画なデバッグ手法に比べて、時間と労力を節約できる可能性があります。 さらに良いことに、これは、大規模なコードベースやより複雑な問題に対しては、より良いアプローチである可能性があります。

ただし、二分探索では、すべての潜在的な問題をテストして評価するために、系統的かつ組織的なアプローチが必要です。 したがって、特定した問題を簡単に再現して修正できるように、ドキュメントは重要です。

5. 新しいコードスイートを作成するたびにデバッガーを実行します

変更を定期的に保存するのと同じように、コード スイートが完成するたびにデバッガーを実行する習慣を身に付ける必要があります。 もちろん、次に進む前に、コードが意図したとおりに機能することを確認する必要があります。

ここでの大きな利点の 1 つは、バグがいつまでも残り続けることがなくなることです。 これは、開発が進むにつれて問題が雪だるま式に増えて修正が難しくなるのを防ぐのに役立ちます。

ただし、このアプローチは、特に大規模なコードベースまたは重要ではない問題の場合に時間がかかる可能性があります。 このため、デバッガーの実行を、重要なコード変更のみ、またはコードベースのより問題のある領域に限定する場合があります。

6. バグを潰すのではなく問題の解決に目を向ける

WordPress のデバッグに関しては、単に「バグを潰す」ことから問題の解決に焦点を移すと役立つ場合があります。 これは、エラーが発生したときに単に対応するのではなく、問題を特定して対処するために、より積極的なアプローチを取ることを意味します。

まず、問題の根本原因を探し、問題の当面の症状を単に解決するのではなく、その原因に対処するように努めます。 これには、将来同様の問題が発生するのを防ぐために、コードベースの特定のセクションを再加工したり、新しい開発手法を採用したりすることが含まれる場合があります。

このアプローチにより、プロジェクトの全体的な品質と信頼性が向上し、将来の問題が発生する可能性が軽減され、UX が向上します。 さらに、このアプローチは、開発プロセスの改善点を特定するのに役立ち、より効率的かつ効果的な開発実践につながります。

トップへ戻る

結論🧐

つまり、WordPress のデバッグでは、プラットフォームを使用して、その動作に影響を与えるコード エラーを報告します。 さらに、ほとんどの場合、問題を警告するためにいくつかの専用プラグインを使用します。 実際、WordPress をデバッグするためのオプションは、Xdebug などの一般的なデバッグ ツールと並行して動作できます。

幸いなことに、WordPress に関しては、不器用な統合プロセスは必要ありません。 wp-config.phpファイルを操作し、ブール値を使用してデバッガー (およびログ) をオンに切り替えることができます。 これにより、関連するエラーが表示され、通常よりも詳細な情報が表示されます。 そこからバグの修正に取り組み、サイトを完成に近づけることができます。

WordPress のデバッグ、または遭遇したシナリオについて何か質問がありますか? 以下のコメントセクションでお知らせください。