Xdebug is an extension for debugging your PHP code. Magento Cloud Docker provides a separate container to handle Xdebug requests in the Docker environment. Use this container to enable Xdebug and debug PHP code in your Docker environment without affecting your. This application integrates with VCSs (Version Control Systems) so that you can easily handle many of your routine tasks. PhpStorm 2020.3.2 Crack With License Key includes unlimited built-in developer tools. For instance, it serves you with remote deployment, command-line tools, Docker, Composer, and many other tools. Codeigniter docker-compose phpstorm xdebug docker-desktop. Improve this question. Follow edited Mar 27 at 19:44. Asked Mar 26 at 21:09. 3,828 8 8 gold badges 41 41 silver badges 68 68 bronze badges. Docker file installs Xdebug extension with pecl command It imports our special php.ini to the container filesystem. We can tweak our PHP settings whatever we like for our development environment.

1. Phpstorm Xdebug Docker Server
2. Phpstorm Xdebug Docker Windows
3. Phpstorm Docker Xdebug Not Working
4. Phpstorm Xdebug Docker Wsl2
5. Phpstorm Docker Compose

Download Xdebug

• Download the Xdebug extension compatible with your PHP version and install it as described in the installation guide.

  Xdebug 3 brings performance improvements, simplified configuration, and PHP 8 support. To learn more on upgrading to Xdebug 3, see the Upgrade guide.

  If you are using an AMP package, the Xdebug extension may be already installed. Refer to the instructions specific for your package.

Integrate Xdebug with the PHP interpreter

1. Open the active php.ini file in the editor:

   1. In the Settings/Preferences dialog Ctrl+Alt+S, click PHP.

   2. On the PHP page that opens, click next to the CLI Interpreter field.

   3. In the CLI Interpreters dialog that opens, the Configuration file read-only field shows the path to the active php.ini file. Click Open in Editor.

2. To disable the Zend Debugger and Zend Optimizer tools, which block Xdebug, remove or comment out the following lines in the php.ini file:

   zend_extension=<path_to_zend_debugger> zend_extension=<path_to_zend_optimizer>

3. To enable Xdebug, locate or create the [xdebug] section in the php.ini file and update it as follows:

   [xdebug] zend_extension='<path to xdebug extension>' xdebug.remote_enable=1 xdebug.remote_host=127.0.0.1 xdebug.remote_port='<the port (9000 by default) to which Xdebug connects>'

   [xdebug] zend_extension='<path to xdebug extension>' xdebug.mode=debug xdebug.client_host=127.0.0.1 xdebug.client_port='<the port (9003 by default) to which Xdebug connects>'

   In PHP 5.3 and later, you need to use only zend_extension, not zend_extension_ts, zend_extension_debug, or extension.

   To enable multi-user debugging via Xdebug proxies, locate the xdebug.idekey setting and assign it a value of your choice. This value will be used to register your IDE on Xdebug proxy servers.

4. Save and close the php.ini file.

5. Verify Xdebug installation by doing any of the following:

   • In the command line, run the following command:

     The output should list Xdebug among the installed extensions:

   • Create a php file containing the following code:

     <?php phpinfo();

     Open the file in the browser. The phpinfo output should contain the Xdebug section:

Configure Xdebug in PhpStorm

1. In the Settings/Preferences dialog Ctrl+Alt+S, select PHP.

2. Check the Xdebug installation associated with the selected PHP interpreter:

   1. On the PHP page, choose the relevant PHP installation from the CLI Interpreter list and click next to the field. The list shows all the PHP installations available in PhpStorm, see Configure local PHP interpreters and Configure remote PHP interpreters.

   2. The CLI Interpreters dialog that opens shows the following:

      • The version of the selected PHP installation.

      • The name and version of the debugging engine associated with the selected PHP installation (Xdebug or Zend Debugger). If no debugger is configured, PhpStorm shows the corresponding message:

   Alternatively, open the Installation Wizard, paste the output of the phpinfo(), and click Analyze my phpinfo() output. Learn more about checking the Xdebug installation in Validate the Configuration of a Debugging Engine.

3. Define the Xdebug behaviour. Click Debug under the PHP node. On the Debug page that opens, specify the following settings in the Xdebug area:

   • In the Debug port field, appoint the port through which the tool will communicate with PhpStorm.

     This must be the same port number as specified in the php.ini file:

     xdebug.remote_port='<the port (9000 by default) to which Xdebug connects>'

     xdebug.client_port='<the port (9003 by default) to which Xdebug connects>'

     By default, Xdebug 2 listens on port 9000. For Xdebug 3, the default port has changed from 9000 to 9003. You can specify several ports by separating them with a comma. By default, the Debug port value is set to 9001,9003 to have PhpStorm listen on both ports simultaneously.

   • To have PhpStorm accept any incoming connections from Xdebug engine through the port specified in the Debug port field, select the Can accept external connections checkbox.

   • Select the Force break at first line when no path mapping specified checkbox to have the debugger stop as soon as it reaches and opens a file that is not mapped to any file in the project on the Servers page. The debugger stops at the first line of this file and Examine/update variables shows the following error message: Cannot find a local copy of the file on server <path to the file on the server> and a link Click to set up mappings. Click the link to open the Resolve Path Mappings Problem dialog and map the problem file to its local copy.

     When this checkbox cleared, the debugger does not stop upon reaching and opening an unmapped file, the file is just processed, and no error messages are displayed.

   • Select the Force break at first line when a script is outside the project checkbox to have the debugger stop at the first line as soon as it reaches and opens a file outside the current project. With this checkbox cleared, the debugger continues upon opening a file outside the current project.

4. In the External connections area, specify how you want PhpStorm to treat connections received from hosts and through ports that are not registered as deployment server configurations.

   • Ignore external connections through unregistered server configurations: Select this checkbox to have PhpStorm ignore connections received from hosts and through ports that are not registered as deployment server configurations. When this checkbox is selected, PhpStorm does not attempt to create a deployment server configuration automatically.

   • Break at first line in PHP scripts: Select this checkbox to have the debugger stop as soon as connection between it and PhpStorm is established (instead of running automatically until the first breakpoint is reached). Alternatively turn on the Run | Break at first line in PHP scripts option from the main menu.

   • Max. simultaneous connections Use this spin box to limit the number of external connections that can be processed simultaneously.

By default, PhpStorm only listens for incoming IPv4 connections. To enable IPv6 support, you need to make adjustments in PhpStorm JVM options:

1. Select Help | Edit Custom VM Options from the main menu.

2. In the .vmoptions file that opens, delete the -Djava.net.preferIPv4Stack=true line.

3. Restart PhpStorm.

Configure Xdebug for using in the On-Demand mode

PhpStorm supports the On-Demand mode, where you can disable Xdebug for your global PHP installation and have it enabled automatically on demand only when you are debugging your command-line scripts or when you need code coverage reports. This lets your command line scripts (including Composer and unit tests) run much faster.

1. Disable Xdebug for command-line scripts:

   1. In the Settings/Preferences dialog Ctrl+Alt+S, go to PHP.

   2. From the PHP executable list, choose the relevant PHP interpreter and click next to it. In the CLI Interpreters dialog that opens, click the Open in Editor link next to the Configuration file: <path to php.ini> file. Close all the dialogs and switch to the tab where the php.ini file is opened.

   3. In the php.ini file, find the [xdebug] section and comment the following line in it by adding ; in preposition:

      ;[xdebug] ;zend_extension = '<path to xdebug extension>'

   4. Open the CLI Interpreters dialog and click next to the PHP executable field. PhpStorm informs you that debugger is not installed:

2. To enable PhpStorm to activate Xdebug when it is necessary, specify the path to it in the Debugger extension field, in the Additional area. Type the path manually or click and select the location in the dialog that opens.

Configure Xdebug for using in the Just-In-Time mode

PhpStorm supports the use of Xdebug in the Just-In-Time (JIT) mode so it is not attached to your code all the time but connects to PhpStorm only when an error occurs or an exception is thrown. Depending on the Xdebug version used, this operation mode is toggled through the following settings:

• Xdebug 2 uses the xdebug .remote_mode setting, which has to be set to jit.

• Xdebug 3 uses the xdebug.start_upon_error setting, which has to be set to yes.

The mode is available both for debugging command-line scripts and for web server debugging.

Depending on whether you are going to debug command-line scripts or use a Web server, use one of the scenarios below.

Command-line scripts

For debugging command-line scripts, specify the custom -dxdebug.remote_mode=jit (for Xdebug 2) or -dxdebug.start_upon_error=yes (for Xdebug 3) directive as an additional configuration option:

1. In the Settings/Preferences dialog Ctrl+Alt+S, navigate to PHP.

2. From the PHP executable list, choose the relevant PHP interpreter and click next to it.

3. In the CLI Interpreters dialog that opens, click next to the Configuration options field in the Additional area.

4. In the Configuration Options dialog that opens, click to add a new entry.

   • For Xdebug 2, type xdebug.remote_mode in the Configuration directive field and jit in the Value field.

   • For Xdebug 3, type xdebug.start_upon_error in the Configuration directive field and yes in the Value field.

   When you click OK, you return to the CLI Interpreters dialog where the Configuration options field shows -dxdebug.remote_mode=jit (for Xdebug 2) or -dxdebug.start_upon_error=yes (for Xdebug 3).

Web server debugging

1. From the main menu, choose Run | Web Server Debug Validation.

2. In the Validate Remote Environment that opens, choose the Web server to validate the debugger on.

   • Choose Local Web Server or Shared Folder to check a debugger associated with a local Web server.

     • Path to Create Validation Script: In this field, specify the absolute path to the folder under the server document root where the validation script will be created. For Web servers of the type Inplace, the folder is under the project root.

       The folder must be accessible through http.

     • URL to Validation Script: In this field, type the URL address of the folder where the validation script will be created. If the project root is mapped to a folder accessible through http, you can specify the project root or any other folder under it.

   • Choose Remote Web Server to check a debugger associated with a remote server.

     • Path to Create Validation Script: In this field, specify the absolute path to the folder under the server document root where the validation script will be created. The folder must be accessible through http.

     • Deployment Server: In this field, specify the server access configuration of the type Local Server or Remote Server to access the target environment. For details, see Configure synchronization with a Web server.

       Choose a configuration from the list or click Browse in the Deployment dialog.

3. Click Validate to have PhpStorm create a validation script, deploy it to the target remote environment, and run it there.

4. Open the php.ini file which is reported as loaded and associated with Xdebug.

5. In the php.ini file, find the [xdebug] section.

   Change the value of the xdebug.remote_mode from the default req to jit.

   Change the value of the xdebug.start_upon_error from the default default to yes.

See also Just-In-Time debugging and PHP Exception Breakpoints with PhpStorm and Xdebug

Configure Xdebug running in a Docker container

To configure Xdebug running in a Docker container, provide the Xdebug-specific parameters in the Dockerfile, for example:

In this example, we're modifying /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini providing the remote_enable and remote_host Xdebug parameters.

Note that the xdebug.remote_host value should be replaced with the IP address of the machine where PhpStorm is running, which is accessible from the Docker container. If you are using Docker for Windows or Docker for Mac, you can set xdebug.remote_host to host.docker.internal, which automatically resolves to the internal address of the host, letting you easily connect to it from the container.

In this example, we're modifying /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini providing the mode and client_host Xdebug parameters.

Note that the xdebug.client_host value should be replaced with the IP address of the machine where PhpStorm is running, which is accessible from the Docker container. If you are using Docker for Windows or Docker for Mac, you can set xdebug.client_host to host.docker.internal, which automatically resolves to the internal address of the host, letting you easily connect to it from the container.

Configure Xdebug running on a Vagrant instance

To configure Xdebug running on a Vagrant instance, connect to the Vagrant machine and provide the Xdebug-specific parameters in the php.ini file:

Note that the xdebug.remote_host value is 10.0.2.2. This is the gateway used in the default Vagrant setup, which allows connecting from the instance to host where PhpStorm is running.

Note that the xdebug.client_host value is 10.0.2.2. This is the gateway used in the default Vagrant setup, which allows connecting from the instance to host where PhpStorm is running.

Xdebug's step debugger allows you to interactively walk through your code todebug control flow and examine data structures.

Introduction #

Phpstorm Xdebug Docker Server

Xdebug interacts with IDEs to provide step debugging functionality, andtherefore you also need to configure an IDE that knows how to talk to Xdebugwith the open DBGp protocol.

This protocol is supported by nearly every PHP IDE (including Visual Studio Code and PhpStorm), and also by text-based editors. There isalso a simple Command Line Debug Client available as part of the Xdebug project,but it is strongly recommended that you use an IDE for debugging. (An overview of third party clients is available further downthis page.)

Configuring Step Debugging #

In your php.ini, 90-xdebug.ini, or otherdistribution specific PHP ini file, change (or set) the xdebug.mode setting todebug. In set-ups where PHP/Xdebug and your IDE all run on thesame host, this is all you need to configure on the PHP and Xdebug side.(Skip to Activating the Debugger ifthat's the case.)

If PHP/Xdebug run on a different machine, virtual host, or in a Dockercontainer, you need to tell Xdebug where to make the debugging connectionto, as it is Xdebug that initiates the communication to the IDE, and notthe other way around.

If PHP/Xdebug run on a different machine in the same sub-net, and you runyour browser on the same host as your IDE, then you set thexdebug.discover_client_host setting to 1. Xdebug will then use theHTTP headers to find out the IP address of the host that initiated thedebugging request, and use that IP address to connect to. This is a commonway of set-up if you are sharing a development server among you and your teammates.

In more complex set-ups you need to configure the host and port that Xdebugconnects to yourself. With xdebug.client_host you can select the IP or hostnameof the machine that runs your IDE, and with xdebug.client_port the TCP port.Make sure that the host running PHP/Xdebug can connect to your IDE with theconfigured IP address and port, and that there is no firewall or other softwareblocking an incoming connection.

Phpstorm Xdebug Docker Windows

Activating Step Debugging #

In the default configuration, the debugger activates if a 'trigger' ispresent, although it's possible to instruct the debugger to always initiate adebugging session by setting xdebug.start_with_request to yes.

Which trigger to use depends on whether you're debugging a PHP applicationthrough a browser, or on the command line, such as when running unit tests.

Command Line

To signal the debugger to initiate connections, Xdebug will look whether theXDEBUG_SESSION environment variable is present.

The valueof the variable does not matter unless you have set up a trigger value withxdebug.trigger_value.

On Unix like platforms, you can set it like:

On Windows, you set the environment like:

When you now run a php script with php myscript.php orvendor/bin/phpunit Xdebug will initiate a debugging session andconnect to your IDE.

Please refer to the Troubleshooting section ifit does not seem like Xdebug is activating.

Browser Application #

The recommended way to initiate a debugging session is by configuring yourIDE to accept incoming debugging connections, and then use a browser extensionwhich sets the right trigger cookie.

Browser Extension Initiation

The extensions are:

• Xdebug Helper for Firefox (source).
• Xdebug Helper for Chrome (source).
• XDebugToggle for Safari (source).

Each extension adds an icon to your browser where you can select whichfunctionality you want to trigger. Xdebug will continue to start debugging forevery request as long as the debug toggle has been enabled.

Manual Initiation

Alternatively, you can signal Xdebug to initiate debugging for asingle request by addingXDEBUG_SESSION=session_name as additional GET (orPOST) parameter. You can pick any value forsession_name, unless xdebug.trigger_value is set.

For debugging multiple subsequent requests, Xdebug supportsdebugging sessions managed by a cookie.

Set the XDEBUG_SESSION_START=session_nameGET (orPOST) HTTP parameter.

Xdebug will set the XDEBUG_SESSION cookie. As long as thecookie is present, debugging will be initiated for every HTTP request(including favicons and images if they go through PHP).

The time-out of the cookie is one hour.

If you set the XDEBUG_SESSION_STOPGET (orPOST) HTTP parameter, Xdebug removes the cookie.

Alternative Ways of Triggering the Debugger

There are other ways how debugger activation can be triggered.

By Calling xdebug_break()

Calling xdebug_break() will trigger a debugging connection as long asxdebug.start_with_request is set to trigger and no debugger sessionis active yet. If a debugger session is already active, it will simply act asif a breakpoint was set through your IDE.

Upon an Error Situation

If you set xdebug.start_upon_error to yes then Xdebug willtrigger a debugging connection when a PHP Notice or Warning appears, or when aThrowable(Error or Exception) is thrown.

Troubleshooting #

You can troubleshoot Xdebug's attempts at initiating debugging connectionsby configuring a log file through xdebug.log. When the connection issuccessfully established the log will also contain the communication betweenXdebug and IDE.

The log file will contain to which IP addresses it is attempting to connectand at which ports, which should be a great help debugging why it sometimesdoesn't work. A 'remote log file' is also required when reporting a bug inXdebug's step debugger.

There are several logging levels which can be configured throughxdebug.log_level.

The xdebug.log setting requires as argument a full path to a file, towhich the user that PHP/Xdebug runs as can write to. It is advisable to usesomething like /tmp/xdebug.log.

Be aware: On many Linux distributions that run services throughSystemd, the actual file path could be different, such as:

Debugging Clients #

This is an incomplete list of third-party clients, both free and commercial.Please refer to the original authors of these tools for documentation andsupport:

• Eclipse plugin (IDE).
• KDevelop (IDE: Linux (KDE); Open Source).
• ActiveState's Komodo (IDE: Windows, Linux, Mac; Commercial).
• NetBeans (IDE: Windows, Linux, Mac OS X and Solaris).
• Devsense's PHP Tools for Visual Studio (Plugin; Commercial).
• JetBrains' PhpStorm (IDE; Commercial).
• SublimeTextXdebug (Plugin for Sublime Text 2 and 3, Open Source).
• VIM plugin (Plugin; Open Source).
• VS Code plugin (Plugin; Open Source).

The simple command line client dbgpClient for debugging isavailable on the download page.

Implementation Details #

This section documents some implementation details, that are mostly usefulfor authors of debugging clients that interact with Xdebug.

DBGp: context_names

Xdebug's implementation of theDBGp protocol's context_namescommand does not depend on the stack level. The returned value is always thesame during each debugger session, and hence, can be safely cached.

Custom DBGp commands

The DBGp protocol allows for debugger engine specific commands, prefixed withthe xcmd_ prefix. Xdebug includes a few of these, and they'redocumented here.

DBGp: xcmd_profiler_name_get

If Xdebug's profiler is currently active (See: Profiling), this commandreturns the name of the file that is being used to write the profilinginformation to.

DBGp: xcmd_get_executable_lines

This command returns which lines in an active stack frame can have a workingbreakpoint. These are the lines which have an EXT_STMTopcode on them. This commands accepts a -d option, whichindicates the stack depth, with 0 being the top leve stack frame.

The command returns the information in the following XML format:

Related Settings and Functions

• stringxdebug.client_discovery_header = '
• stringxdebug.client_host = localhost
• integerxdebug.client_port = 9003
• stringxdebug.cloud_id =
• integerxdebug.connect_timeout_ms = 200
• booleanxdebug.discover_client_host = false
• stringxdebug.idekey = *complex*
• stringxdebug.log =
• integerxdebug.log_level = 7
• stringxdebug.mode = develop
• stringxdebug.start_upon_error = default
• stringxdebug.start_with_request = default
• stringxdebug.trigger_value = '

• xdebug_break() : bool
• xdebug_info() : void
• xdebug_is_debugger_active() : bool

Settings

string xdebug.client_discovery_header = '#

If xdebug.client_discovery_header is configured to be a non-empty string, then thevalue is used as key in the $_SERVER superglobal array to determinewhich header to use to find the IP address or hostname to use for 'connectingback to'. This setting is only used in combination withxdebug.discover_client_host and is otherwise ignored.

For example, if xdebug.client_discovery_header is set to FORWARD_HOST,then Xdebug will check $_SERVER['FORWARD_HOST'] before the$_SERVER['HTTP_X_FORWARDED_FOR'] and$_SERVER['REMOTE_ADDR'] variables.

string xdebug.client_host = localhost#

Configures the IP address or hostname where Xdebug will attempt to connect to when initiating adebugging connection. This address should be the address of the machine where your IDE or debuggingclient is listening for incoming debugging connections.

On non-Windows platforms, it is also possible to configure a Unix domain socket which is supported byonly a select view debugging clients. In that case, instead of the hostname or IP address, useunix:///path/to/sock.

If xdebug.discover_client_host is enabled then Xdebug will only use the value of this setting incase Xdebug can not connect to an IDE using the information it obtained from HTTP headers. In thatcase, the value of this setting acts as a fallback only.

This setting can additionally be configured through theXDEBUG_CONFIGenvironment variable.

integer xdebug.client_port = 9003#

The port to which Xdebug tries to connect on the remote host. Port9003 is the default for both Xdebug and the Command Line Debug Client.As many clients use this port number, it is best to leave this settingunchanged.

This setting can additionally be configured through theXDEBUG_CONFIGenvironment variable.

string xdebug.cloud_id = #

With this setting you configure Xdebug for use with Xdebug Cloud. It needs to match one of thetokens from your profilepage.

Your IDE needs to be configured with the same token for Xdebug and your IDE tocommunicate through Xdebug Cloud.

In PhpStorm you can find this setting under:
File | Settings | PHP | Debug | Xdebug Cloud for Windows and Linux
PhpStorm | Preferences | PHP | Debug | Xdebug Cloud for macOS

integer xdebug.connect_timeout_ms = 200#

The amount of time in milliseconds that Xdebug will wait for on anIDE to acknowledge an incoming debugging connection. The default value of 200ms should in most cases be enough. In case you often get dropped debuggingrequests, perhaps because you have a high latency network, or a development boxfar away from your IDE, or have a slow firewall, then you can should increasethis value.

Please note that increasing this value might mean that your requests seem to'hang' in case Xdebug tries to establish a connection, but your IDE is notlistening.

boolean xdebug.discover_client_host = false#

If enabled, Xdebug will first try to connect to the client that made theHTTP request. It checks the $_SERVER['HTTP_X_FORWARDED_FOR'] and$_SERVER['REMOTE_ADDR'] variables to find out which hostname or IPaddress to use.

If xdebug.client_discovery_header is configured, then the $_SERVERvariable with that configured name will be checked beforeHTTP_X_FORWARDED_FOR and REMOTE_ADDR.

If Xdebug can not connect to a debugging client as found in one of the HTTPheaders, it will fall back to the hostname or IP address as configured by thexdebug.client_host setting.

This setting does not apply for debugging through the CLI, as the$_SERVER header variables are not available there.

This setting can additionally be configured through theXDEBUG_CONFIGenvironment variable.

Warning: Please note that there is no filteravailable, and anybody who can connect to the webserver will then be able tostart a debugging session, even if their address does not matchxdebug.client_host.

Phpstorm Docker Xdebug Not Working

string xdebug.idekey = *complex*#

Controls which IDE Key Xdebug should pass on to the debugging client orproxy. The IDE Key is only important for use with the DBGp Proxy Tool,although some IDEs are incorrectly picky as to what its value is.

The default is based on the DBGP_IDEKEY environment setting. Ifit is not present, the default falls back to an empty string.

If this setting is set to a non-empty string, it selects its value overDBGP_IDEKEY environment variable as default value.

The internal IDE Key also gets updated through debugging session managementand overrides the value of this setting as is explained in theStep Debugging documentation.

This setting can additionally be configured through theXDEBUG_CONFIGenvironment variable.

string xdebug.log = #

Configures Xdebug's log file.

Xdebug will log to this file all file creations issues, Step Debuggingconnection attempts, failures, and debug communication.

Enable this functionality by setting the value to a absolute path. Make surethat the system user that PHP runs at (such as www-data if you arerunning with Apache) can create and write to the file.

The file is opened in append-mode,and will therefore not be overwritten by default. There is no concurrencyprotection available.

The log file will include any attempt that Xdebugmakes to connect to an IDE:

It includes the opening time (2020-09-02 07:19:09.616195), theIP/Hostname and port Xdebug is trying to connect to(localhost:9003), and whether it succeeded (Connected toclient :-)). The number in brackets ([2693358]) is theProcess ID.

It includes:

[2693358]

process ID in brackets

2020-09-02 07:19:09.616195

opening time

For Step Debugging:

For Profiling:

For Function Trace:

All warnings and errors are described on the Description of errors page, withdetailed instructions on how to resolve the problem, if possible. All errors are always logged throughPHP's internal logging mechanism (configured with error_login php.ini). All warnings and errors also show up in thediagnostics log that you can view by calling xdebug_info().

Step Debugger Communication

The debugging log can also log the communication between Xdebug and an IDE.This communication is in XML, and starts with the <init XMLelement:

The fileuri attribute lists the entry point of yourapplication, which can be useful to compare to breakpoint_setcommands to see if path mappings are set-up correctly.

Beyond the <init element, you will find the configuration offeatures:

And continuation commands:

You can read about DBGP - A common debugger protocol specification at its dedicated documation page.

The xdebug.log_level setting controls how much information islogged.

Note: Many Linux distributions now use systemd, whichimplements private tmp directories. This means that when PHPis run through a web server or as PHP-FPM, the /tmp directory isprefixed with something akin to:

This setting can additionally be configured through theXDEBUG_CONFIGenvironment variable.

integer xdebug.log_level = 7#

Configures which logging messages should be added to the log file.

The log file is configured with the xdebug.log setting.

The following levels are supported:

Criticals, errors, and warnings always show up in thediagnostics log that you can view by calling xdebug_info().

Criticals and errors are additionally logged throughPHP's internal logging mechanism (configured with error_login php.ini).

This setting can additionally be configured through theXDEBUG_CONFIGenvironment variable.

string xdebug.mode = develop#

This setting controls which Xdebug features are enabled.

This setting can only be set in php.ini orfiles like 99-xdebug.ini that are read when a PHP process starts(directly, or through php-fpm), but not in .htaccess and.user.ini files, which are read per-request.

The following values are accepted:

off

Nothing is enabled. Xdebug does no work besides checking whetherfunctionality is enabled. Use this setting if you want close to 0overhead.

develop

Enables Development Aids including the overloaded var_dump().

coverage

Enables Code Coverage Analysis to generate code coverage reports, mainly incombination withPHPUnit.

debug

Enables Step Debugging. This can be used to step through your code while itis running, and analyse values of variables.

gcstats

Enables Garbage Collection Statistics to collect statistics about PHP's GarbageCollection Mechanism.

profile

Enables Profiling, with which you can analyse performance bottleneckswith tools like KCacheGrind.

trace

Enables the Function Trace feature, which allows you record every functioncall, including arguments, variable assignment, and return value that is madeduring a request to a file.

You can enable multiple modes at the same time by comma separating theiridentifiers as value to xdebug.mode: xdebug.mode=develop,trace.

You can also set the mode by setting the XDEBUG_MODE environmentvariable on the command-line; this will take precedence over the xdebug.mode setting, but will no change the value of the xdebug.mode setting.

string xdebug.start_upon_error = default#

Step Debugging can be activated when a PHP Notice or Warning is emitted, orwhen a Throwable(Exception/Error) is thrown, depending on the value of this setting:

Initialise a debugging session when a PHP Notice or Warning is emitted, orwhen a Throwable is thrown.

Do not start a debugging session upon an error situation.

This setting is independent of xdebug.start_with_request, and therefore it isnot necessary to set xdebug.start_with_request=trigger.

string xdebug.start_with_request = default#

A Function Trace, Garbage Collection Statistics, Profiling, or Step Debuggingcan be activated at the start of a PHP request. Whether this happens depends onthe value of this setting:

The functionality starts when the PHP request starts, and before any PHPcode is run.

For example xdebug.mode=trace andxdebug.start_with_request=yes starts a Function Trace for thewhole request.

The functionality does not get activated when the request starts.

You can still start a Function Trace with xdebug_start_trace(), Step Debugging with xdebug_break(), or Garbage Collection Statistics with xdebug_start_gcstats().

The functionality only gets activated when a specific trigger is presentwhen the request starts.

The name of the trigger is XDEBUG_TRIGGER, and Xdebug checksfor its presence in either $_ENV (environment variable),$_GET or $_POST variable, or $_COOKIE(HTTP cookie name).

There is also a legacy fallback to a functionality specific trigger name:XDEBUG_PROFILE (for Profiling), XDEBUG_TRACE(for a Function Trace), and XDEBUG_SESSION (forStep Debugging).

Debug session management for Step Debugging is alsoavailable through XDEBUG_SESSION_START.

With xdebug.trigger_value you can control which specific trigger value willactivate the trigger. If xdebug.trigger_value is set to an emptystring, any value will be accepted.

The default value depends on xdebug.mode:

Phpstorm Xdebug Docker Wsl2

• debug: trigger
• gcstats: no
• profile: yes
• trace: trigger

string xdebug.trigger_value = '#

This setting can be used when xdebug.start_with_request is set totrigger, which is the default for Step Debugging and Function Trace.

In trigger mode, Xdebug will only start itsfunctionality when the XDEBUG_TRIGGER is set in the environment,or when the XDEBUG_TRIGGER GET, POST, or COOKIE variable isset.

The legacy names XDEBUG_SESSION (for Step Debugging),XDEBUG_PROFILE (for Profiling), and XDEBUG_TRACE(for Function Trace) can also be used instead of XDEBUG_TRIGGER.

Normally, Xdebug does not look at which value is actually used. If thissetting is set to a non-empty string, then Xdebug will only trigger if thevalue matches the value of this setting.

With the following settings:

Xdebug's profiler will only start when either the environment variableXDEBUG_TRIGGER is set to StartProfileForMe, the GETor POST variable XDEBUG_TRIGGER is set toStartProfileForMe, or when the cookie XDEBUG_TRIGGERhas the value StartProfileForMe.

Phpstorm Docker Compose

See also:

xdebug.start_with_request#trigger

For how the triggering mechanism works, and which environment and server variables Xdebug acts on.

Functions

xdebug_break() : bool#

This function makes the debugger break on the line it is called from, as if a normal file/line breakpoint was set on this line through the debugger protocol.

If no debugging session is active yet, and xdebug.start_upon_request is set to trigger, then Xdebug will attempt to start a new debugging session first.

The function returns true if a debugging session is (now) active, and the breakpoint was succesfully set. It returns false if a debugging session was not active and could not be activated.

xdebug_info() : void#

This function returns an HTML page which shows diagnostic information. It is analogous to PHP's phpinfo() function.

The HTML output includes which mode is active, what the settings are, and diagnostic information in case there are problems with debugging connections, opening of files, etc.

Each warning and error in the diagnostics log also links through to the Description of errors documentation page.

xdebug_is_debugger_active() : bool#

Returns true if a debugging session through DBGp is currently active with a client attached; false, if not.