If you find this extension useful, if it helps you solve your problems and if you appreciate the support given here, consider sponsoring our work.
Install the extension: Press F1
, type ext install php-debug
.
This extension is a debug adapter between VS Code and Xdebug by Derick Rethans. Xdebug is a PHP extension (a .so
file on Linux and a .dll
on Windows) that needs to be installed on your server.
Install Xdebug
I highly recommend you make a simple test.php
file, put a phpinfo();
statement in there, then copy the output and paste it into the Xdebug installation wizard. It will analyze it and give you tailored installation instructions for your environment. In short:
Configure PHP to use Xdebug by adding zend_extension=path/to/xdebug
to your php.ini. The path of your php.ini is shown in your phpinfo()
output under "Loaded Configuration File".
Enable remote debugging in your php.ini
:
For Xdebug v3.x.x:
xdebug.mode = debug
xdebug.start_with_request = yes
For Xdebug v2.x.x:
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_port = 9000
There are other ways to tell Xdebug to connect to a remote debugger, like cookies, query parameters or browser extensions. I recommend remote_autostart
(Xdebug v2)/start_with_request
(Xdebug v3) because it "just works". There are also a variety of other options, like the port, please see the Xdebug documentation on remote debugging for more information. Please note that the default Xdebug port changed between Xdebug v2 to v3 from 9000 to 9003.
If you are doing web development, don't forget to restart your webserver to reload the settings.
Verify your installation by checking your phpinfo()
output for an Xdebug section.
In your project, go to the debugger and hit the little gear icon and choose PHP. A new launch configuration will be created for you with three configurations:
serverReadyAction
directive. The port is random (localhost:0) but can be changed to a desired fixed port (ex: localhost:8080). If a router script is needed, add it with program
directive. Additional PHP/Xdebug directives trigger debugging on every page load.There are also configurations for Xdebug v2 (Legacy) installations.
More general information on debugging with VS Code can be found on https://code.visualstudio.com/docs/editor/debugging.
Note: You can even debug a script without
launch.json
. If no folder is open, and the VS Code status bar is purple, pressingF5
will start the open script with Xdebug3 specific parameters. If the php executable is not in path, you can provide it with the settingphp.debug.executablePath
. For debugging to work, Xdebug must still be correctly installed.
request
: Always "launch"
hostname
: The address to bind to when listening for Xdebug (default: all IPv6 connections if available, else all IPv4 connections) or Unix Domain socket (prefix with unix://
) or Windows Pipe (\\?\pipe\name
) - cannot be combined with portport
: The port on which to listen for Xdebug (default: 9003
). If port is set to 0
a random port is chosen by the system and a placeholder ${port}
is replaced with the chosen port in env
and runtimeArgs
.stopOnEntry
: Whether to break at the beginning of the script (default: false
)pathMappings
: A list of server paths mapping to the local source paths on your machine, see "Remote Host Debugging" belowlog
: Whether to log all communication between VS Code and the adapter to the debug console. See Troubleshooting further down.ignore
: An optional array of glob patterns that errors should be ignored from (for example **/vendor/**/*.php
)ignoreExceptions
: An optional array of exception class names that should be ignored (for example BaseException
, \NS1\Exception
, \*\Exception
or \**\Exception*
)skipFiles
: An array of glob patterns, to skip when debugging. Star patterns and negations are allowed, for example, **/vendor/**
or !**/vendor/my-module/**
.skipEntryPaths
: An array of glob patterns, to immediately detach from and ignore for debugging if the entry script matches (example **/ajax.php
).maxConnections
: Accept only this number of parallel debugging sessions. Additional connections will be dropped and their execution will continue without debugging.proxy
: DBGp Proxy settings
enable
: To enable proxy registration set to true
(default is `false).host
: The address of the proxy. Supports host name, IP address, or Unix domain socket (default: 127.0.0.1).port
: The port where the adapter will register with the the proxy (default: 9001
).key
: A unique key that allows the proxy to match requests to your editor (default: vsc
). The default is taken from VSCode settings php.debug.idekey
.timeout
: The number of milliseconds to wait before giving up on the connection to proxy (default: 3000
).allowMultipleSessions
: If the proxy should forward multiple sessions/connections at the same time or not (default: true
).xdebugSettings
: Allows you to override Xdebug's remote debugging settings to fine tuning Xdebug to your needs. For example, you can play with max_children
and max_depth
to change the max number of array and object children that are retrieved and the max depth in structures like arrays and objects. This can speed up the debugger on slow machines.max_children
: max number of array or object children to initially retrievemax_data
: max amount of variable data to initially retrieve.max_depth
: maximum depth that the debugger engine may return when sending arrays, hashes or object structures to the IDE (there should be no need to change this as depth is retrieved incrementally, large value can cause IDE to hang).show_hidden
: This feature can get set by the IDE if it wants to have more detailed internal information on properties (eg. private members of classes, etc.) Zero means that hidden members are not shown to the IDE.xdebugCloudToken
: Instead of listening locally, open a connection and register with Xdebug Cloud and accept debugging sessions on that connection.stream
: Allows to influence DBGp streams. Xdebug only supports stdout
see DBGp stdout
stdout
: Redirect stdout stream: 0 (disable), 1 (copy), 2 (redirect)Options specific to CLI debugging:
program
: Path to the script that should be launchedargs
: Arguments passed to the scriptcwd
: The current working directory to use when launching the scriptruntimeExecutable
: Path to the PHP binary used for launching the script. By default the one on the PATH.runtimeArgs
: Additional arguments to pass to the PHP binaryexternalConsole
: Launches the script in an external console window instead of the debug console (default: false
)env
: Environment variables to pass to the scriptenvFile
: Optional path to a file containing environment variable definitions>=n
, ==n
and %n
To debug a running application on a remote host, you need to tell Xdebug to connect to a different IP than localhost
. This can either be done by setting xdebug.client_host
to your IP or by setting xdebug.discover_client_host = 1
to make Xdebug always connect back to the machine who did the web request. The latter is the only setting that supports multiple users debugging the same server and "just works" for web projects. Again, please see the Xdebug documentation on the subject for more information.
To make VS Code map the files on the server to the right files on your local machine, you have to set the pathMappings
settings in your launch.json. Example:
// server -> local
"pathMappings": {
"/var/www/html": "${workspaceFolder}/www",
"/app": "${workspaceFolder}/app"
}
Please also note that setting any of the CLI debugging options will not work with remote host debugging, because the script is always launched locally. If you want to debug a CLI script on a remote host, you need to launch it manually from the command line.
The debugger can register itself to a DBGp proxy with a IDE Key. The proxy will then forward to the IDE only those DBGp sessions that have this specified IDE key. This is helpful in a multiuser environment where developers cannot use the same DBGp port at the same time. Careful setup is needed that requests to the web server contain the matching IDE key.
The official implementation of the dbgpProxy.
A Xdebug helper browser extension is also recommended. There the request side IDE key can be easily configured.
"log": true
in your launch.json and observe Debug Console panelxdebug.log = /path/to/logfile
To hack on this adapter, clone the repository and open it in VS Code. You need NodeJS with NPM installed and in your PATH. Also a recent PHP and Xdebug should be installed and in your PATH.
npm install
on command line in the project directory or selecting Terminal / Run Task... / npm / npm: install
in VS Code menu.npm run watch
on command line in the project directory or selecting Terminal / Run Build Task...
in VS Code menu.Debug adapter
configuration and clicking on the green Run arrow (or hitting F5
). The compiled adapter will be running in "server mode" and listening on TCP port 4711.code testproject --extensionDevelopmentPath=.
on command line in the project directory or selecting the Launch Extension
Run and Debug configuration and pressing the green Run arrow. Another shortcut is to run npm run start
. You can also run an Insiders build of VS Code for testing newer features..vscode/launch.json
and uncomment the debugServer
configuration line. Run your PHP debug session by selecting the desired configuration and hitting F5
. Now you can debug the testproject like specified above and set breakpoints inside your first VS Code instance to step through the adapter code.More on testing extensions can be found on https://code.visualstudio.com/api/working-with-extensions/testing-extension.
Tests are written with Mocha and can be run with npm test
or from Terminal / Run Task... / npm: test
. When you submit a PR the tests will be run in CI on Linux, macOS and Windows against multiple PHP and Xdebug versions.
Before submitting a PR also run npm run lint
or Terminal / Run Tasks... / npm: lint
.