一般的な PHP デバッグの問題のトラブルシューティング

PhpStorm デバッグログの収集

このセクションで問題が解決されない場合は、サポートエンジニアにお問い合わせください。デプロイログの提供を求められた場合は、指示に従ってログを収集してください。

Xdebug ログの収集

Xdebug を使用する場合、アクションをログに記録(英語)させることができます。

1. 設定ダイアログ（Ctrl+Alt+S）で、PHP に移動します。

2. PHP 実行可能ファイルリストから適切な PHP インタープリターを選択し、その横にある をクリックします。開いた CLI インタープリターダイアログで、構成ファイル: <php.ini へのパス> ファイルの横にあるエディターで開くリンクをクリックします。すべてのダイアログを閉じて、php.ini ファイルが開かれているタブに切り替えます。

3. php.ini で、次の行を追加して Xdebug ロギングを有効にします。

   xdebug.log="path_to_log/xdebug.log"

   xdebug.remote_log="path_to_log/xdebug.log"

   ログファイルには、PhpStorm と Xdebug の間の生の通信、および警告やエラーが含まれています。

   Log opened at 2018-01-08 08:14:28 I: Connecting to configured address/port: 127.0.0.1:9000. I: Connected to client. :-) -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///C:/Projects/Samples/DebuggingTutorial/debugging.php" language="PHP" protocol_version="1.0" appid="3040" idekey="11774"><engine version="2.2.5"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2018 by Derick Rethans]]></copyright></init> <- step_into -i 5 -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="step_into" transaction_id="5" status="break" reason="ok">< xdebug:message filename="file:///C:/Projects/Samples/DebuggingTutorial/debugging.php" lineno="2"></xdebug:message></response>

Xdebug または Zend デバッガーがインストールされ、設定されていることを確認する

PhpStorm を使用して PHP コードをデバッグするには、Xdebug(英語) または Zend デバッガー(英語)のいずれかのデバッグエンジンがインストールされ、正しく構成されていることを確認してください。

これらのツールは、互いにブロックするため同時に使用することはできません。この問題を回避するには、Xdebug を構成するおよび Zend デバッガーの構成の説明に従って、php.ini ファイルの対応するセクションを更新する必要があります。

デバッグエンジンの設定を検証するには、デバッグエンジンの構成を検証する

デバッガーの動作を妨げる起動時の警告とエラー

PHP を実行しているときに、起動時の警告またはエラーが表示される場合があります。この場合、デバッガーが機能しない可能性があります。PhpStorm は、使用されているデバッガーも認識できません。

起動時の警告またはエラーが表示されないことを確認するには、次のコマンドを実行します。

これにより、次のようなメッセージが返されます。

最初の行にエラーまたは警告がある場合は、続行する前に修正することをお勧めします。

デバッガーが接続できない

デバッガーが接続できない場合、または接続を拒否する場合は、以下を確認してください。

• Xdebug または ZendDebugger がホストに接続するように構成されており、ポート PhpStorm が実行されていることを確認してください。

  • Xdebug 構成で、xdebug.remote_host および xdebug.remote_port (Xdebug 3 の場合は xdebug.client_host および xdebug.client_port) が正しいことを確認してください。詳細については、Xdebug のドキュメント(英語)を参照してください。

  • Zend デバッガーを使用する場合は、生成された PhpStorm ブックマークレットまたはブラウザーデバッグ拡張機能が正しい IP アドレスとポートを使用するように設定されていることを確認してください。

  • リモート PHP インタープリターを使用する場合は、SSH トンネル経由のリモートデバッグに記載されている手順を確認してください。

• 設定ダイアログ (Ctrl+Alt+S) で、PHP | デバッグに移動し、PhpStorm と Xdebug/Zend Debugger が同じポート番号で構成されていることを確認します。

• PhpStorm では、次のいずれかを実行して、受信デバッグ接続のリッスンを有効にします。

  • ツールバー / ステータスバーの をクリックします。

  • メインメニューで実行 | PHP デバッグ接続のリッスンを開始を選択します。

  これにより、Web サーバーでデバッグセッションが開始されると PhpStorm が反応し、デバッグツールウィンドウが自動的に開きます。デバッグセッションを開始する前に、ブレークポイントが設定されているか、設定ダイアログ Ctrl+Alt+S のデバッグページで PHP スクリプトの最初の行で中断するオプションが有効になっていることを確認してください。

• ファイアウォール、ルーター、ISP が接続をブロックしていないことを確認します。これは、リモートサーバー（PhpStorm を実行しているローカルマシンの IP アドレス）で telnet host 9000 (for Xdebug) または telnet host 10137 （Zend デバッガー用）を実行し、接続が確立されていることを確認することで確認できます。http://www.canyouseeme.org(英語) などのサービスを使用して、開いている受信ポートを確認できます。

• xdebug.remote_host （Xdebug 2 の場合）、xdebug.client_host （Xdebug 3 の場合）、または zend_debugger .allow_hosts （Zend デバッガーの場合）が正しく構成されていることを確認してください。値は、ホスト名（localhost など）または PhpStorm が実行されているマシンの IP アドレスにすることができ、サーバーから ping 可能である必要があります。Xdebug を使用する場合、トラブルシューティングには xdebug.remote_connect_back(英語)（Xdebug 2 の場合）または xdebug.discover_client_host(英語)（Xdebug 3 の場合）を使用できます。

デバッグサーバーが構成されていない

サーバーのデバッグを構成せずにゼロ構成デバッグセッションを開始した場合、接続の確立時に PhpStorm は受信接続ダイアログを表示し、サーバーアクセス構成（デプロイ構成）からのマッピングのインポートを提案します。デプロイからマッピングをインポートするを選択すると、PhpStorm は最適なデプロイ構成を検出しようとし、デプロイリストで事前に選択します。プレビューエリアは、選択された構成からのマッピングに従って現在実行されているスクリプトに対応するプロジェクトファイルへの絶対パスを表示します。

PhpStorm が関連する構成を検出しない場合:

1. リストから最適な構成を選択するか、 をクリックして開き、デプロイダイアログで新しい構成を作成すると、新しい構成がリストに追加されます。

2. デプロイルートフィールドに、サーバーのルートフォルダーへの絶対パスを入力します。

この場合、手動でローカルファイルまたはプロジェクトを選択するオプションを選択することもできます。この場合、PhpStorm はプロジェクトツリービューを表示します。ここでプロジェクトファイルを選択し、現在実行されているスクリプトをそのファイルにマップできます。プロジェクト全体を選択してマップすることもできます。

インポートまたは手動で指定した構成設定を使用してデバッグを続行するには、受諾をクリックします。

リモートファイルパスがプロジェクト内のファイルパスにマップされていない

デバッガーが接続できる場合もありますが、リモートとプロジェクトファイル間のマッピングが定義されていないことを示すエラーメッセージが表示されます。これは、PhpStorm が、デバッグ中のファイルに対応するローカルファイルを判別できないことを意味します。

この問題を解決するには、クリックしてパスマッピングを設定しますをクリックして、必要なパスマッピングを提供します。

パスマッピングは、サーバーによって処理されるファイルへのパスが PhpStorm プロジェクト内のファイルへのパスと異なる場合に使用されます。これは、次の場合に発生します。

• サーバーはリモートで、プロジェクトファイルはオリジナルのローカルコピーです。

• サーバーで処理されるファイルと IDE で開かれたファイルは同じですが、シンボリックリンクが使用されます。デバッガーはデバッグセッション中にシンボリックリンクを解決するため、IDE の実際の溶質にサーバー上のファイルへの物理パスを伝える必要があります。

パスマッピングを構成するには、設定ダイアログ (Ctrl+Alt+S) で PHP | サーバーに移動します。

サーバーが処理しているファイルがプロジェクトにあり、シンボリックリンクを使用していない場合は、パスマッピングを使用するチェックボックスをオフにします。この場合、IDE はデバッガーから受け取ったパスに従ってファイルを開きます。

親ディレクトリに指定されたパスマッピングは、そのすべてのサブディレクトリに自動的に適用されます。必要に応じて、サブディレクトリまたはファイルのパスマッピングを指定できます。

詳細は Web サーバーに接続するを参照してください。

ブレークポイントがヒットしていない

ブレークポイントにヒットしていないが、デバッガーが接続しているように見える場合は、次のことを確認してください。

• ブレークポイントが無効になっていないことを確認します。実行 | ブレークポイントの表示メニューコマンド Ctrl+Shift+F8 を使用して、ブレークポイントが有効になっていることを確認します。ブレークポイントを有効にするには、ブレークポイントの横にあるチェックボックスを選択します。

• パスマッピングが正しいことを確認してください。

• macOS では、Finder を使用してファイルまたはフォルダーの名前を変更し、大文字と小文字を変更すると、PhpStorm がファイルを見つけられない場合があります。名前の変更が必要な場合は、IDE で行うか、ターミナルと mv コマンドを使用してください。Finder を使用してプロジェクトファイルまたはフォルダーの名前を変更すると、奇妙な動作が発生する可能性があります。詳細については、こちら(英語)を参照してください。

• まれに、技術的な制限によりブレークポイントに到達できない場合があります。たとえば、PHP がバイトコードを生成する方法が原因です。詳細については、こちら(英語)を参照してください。

Xdebug を使うときは、xdebug_break() 関数を使って PHP 内からブレークポイントを強制することができます。実行中に Xdebug がこの関数を検出すると、もともとそこにブレークポイントが定義されていなくても、IDE の次のステートメントで一時停止します。

Xdebug はブレークポイントを無視し、ブレークポイントが定義されていない行で停止する

これは、Xdebug の内部ブレークポイント解決メカニズムが原因で発生する可能性があります。このメカニズムで、デバッガーは、PHP が現在の行の内部実行可能バイトコードを生成できるかどうかを評価します。ブレークポイントが参照する行にそのようなコードがない場合、対応するブレークポイントにヒットできません。Xdebug は、後続の最大 5 行までスキャンし、実行可能コードが配置されている行で停止し、ブレークポイントの定義をこの行に更新します。

デバッグセッション中に PhpStorm がブレークポイントを解決および移動したくない場合は、設定ダイアログ (Ctrl+Alt+S) の PHP | デバッグページでこの機能を無効にすることができます。

Xdebug エリアでは:

• 現在の行で使用できない場合はブレークポイントを解決します (Xdebug 2.8+) チェックボックスの選択を解除して、ブレークポイント解決機能全体を無効にします。解決が無効になっている場合、実行可能コードのないコード行に設定されたブレークポイントは常に無視されることに注意してください。

• ソースと異なる場合は、ブレークポイントを解決された位置に移動しますチェックボックスの選択を解除して、ブレークポイントの解決後に Xdebug が実際に停止する行へのブレークポイント位置の自動調整のみを無効にします。ブレークポイント解決機能は引き続き有効になることに注意してください。

設定領域で、ブレークポイントが別の行に解決されたかどうかを通知します (Xdebug 2.8+) チェックボックスの選択を解除して、ブレークポイントが解決されるたびに PhpStorm 通知をオフにします。

スクリプトは中断されていません

ゼロコンフィギュレーションデバッグセッションの確立は、ブレークポイントにヒットせずに失敗する場合があるため、スクリプトは中断されません。これは、パスマッピングが構成されていないか、誤って構成されている場合、またはブレークポイントを設定していない場合に発生する可能性があります。後者の場合、次のいずれかを実行できます。

• 目的の実行可能コード行のガターをクリックしてブレークポイントを設定します。詳細については、ブレークポイントを参照してください。

• 設定ダイアログ (Ctrl+Alt+S) で PHP | デバッグに移動し、外部接続領域で PHP スクリプトの最初の行で中断するチェックボックスを選択します。

• メインメニューから実行 | PHP スクリプトの最初の行で中断するオプションを有効にします。

スクリプトが中断されていない場合、PhpStorm に通知を表示させるには、設定ダイアログの PHP | デバッグページの詳細設定領域のデバッグセッションが一時停止せずに完了した場合に通知するチェックボックスを選択します。

nginx を使用しているときにデバッガーが動作しない

nginx(英語) Web サーバーを使用する場合、$_SERVER["SERVER_NAME"] が PHP によって提供されていないと、デバッグが失敗することがあります。これを解決するには、nginx 構成に fastcgi パラメーターを追加します。

または

詳細については、nginx のドキュメント(英語)とこのコミュニティの投稿(英語)を参照してください。

Xdebug は PhpStorm に接続できません

Xdebug ログに以下のメッセージが表示された場合:

または

これは、Xdebug がホストへの接続を試み、接続を確立できないことを意味します。この問題を修正するには、xdebug.remote_connect_back=0 （Xdebug 3 の場合は xdebug.discover_client_host=false）を設定し、xdebug.remote_host （Xdebug 3 の場合は xdebug.client_host）が正しく設定されていることを確認します。

フレームワーク CLI コマンドをデバッグしようとすると、PHP エラーが発生する

Symfony コンソールや Laravel Artisan などの PHP フレームワークコマンドラインツールの CLI コマンドをデバッグしようとすると、PHP エラー Fatal error: Class '...\Command' not found" などでデバッグが失敗します。

このようなエラーの一般的な原因は、コマンドを使用してファイルまたはクラスを直接デバッグしようとすることです。代わりに、コマンドラインツールへのパスと実際に実行するコマンドを指定する PHP スクリプトを使用する必要があります。この場合、フレームワークコマンドのブートストラップロジックが適用され、デバッグが正常に進行します。

詳細については、次のフレームワーク固有のガイドを参照してください。

• Symfony CLI コマンドのデバッグ

• Artisan CLI コマンドのデバッグ

• Wordpress WP-CLI コマンドのデバッグ

• Drush CLI コマンドのデバッグ

Zend デバッガーは特権の削除を実行しません

Linux で Zend デバッガーを使用すると、次のエラーが表示されることがあります。

このエラーは、デバッガーが Web サーバープロセスを実行しているユーザーの UID を特定できない場合に発生します。そのユーザーの UID を見つけて、それを php.ini に追加します。

設定を更新したら、Web サーバーを再起動してください。

ionCube をインストールしてデバッグする

一部の PHP 環境では、ionCube(英語) を使用してエンコードされた PHP コードをロードして実行します。ionCube ローダー拡張機能は、実行される PHP コードをデコードし、PHP インタープリターがそれを実行できることを確認することによってこれを行います。

正式には、Xdebug も Zend デバッガーも ionCube を有効にしても動作しませんが、いくつかの回避策があります。これらは JetBrains、ionCube、Xdebug、Zend デバッガーではサポートされていません。

• ionCube ローダーモジュールが最初にロードされていることを確認する

  php.ini では、デバッガー拡張がロードされる前に ionCube ローダがロードされていることを確認します。たとえば、次のようになります。

  zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/ioncube_loader_lin_5.4.so zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so

• ionCube オンデマンドローディングを使用する

  php.ini で ionCube 拡張を無効にして、ionCube のオンデマンドロード機能を利用することができます。最初のエンコードされた PHP スクリプトがロードされると、PHP インタープリターは設定された extension_dir をチェックして ionCube 拡張子を見つけ、エンコードされた PHP スクリプトを実行します。

  この方法は正式にサポートされていないことに注意してください。デバッグ目的でのみ使用し、本番サーバーでは使用しないでください。