Here’s how I got it working. From the wrench/site configurations option in DevKinsta I made sure “enable xdebug” was checked. In the PHP.ini editor I had the following lines:
xdebug.remote_autostart=1
xdebug.remote_enable=1
xdebug.profiler_enable=1
xdebug.profiler_enable_trigger = 1
xdebug.discover_client_host = 1
You can verify this with a phpinfo(); output, but the config on my system was still using the classic port 9000, not the 9003 XDebug 3 supposedly moved to.
I have the PHP Debugv1.30.0
extension installed in VS Code. With that in place you’ll have the ‘Run and debug’ option on the left. Or press Shift-Command-D to open it. Let it create a launch.json file for you.
I removed everything but the “Listen for Xdebug” configuration; it’s not possible to launch a script for remote execution as far as I know so they were just cluttering up the options.
here’s what one of mine looks like, where my workspace is in the wordpress wp-content directory (I don’t want any visibility into the stock WP code or have searches find Automattic’s classes)
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Listen for Xdebug",
"type": "php",
"request": "launch",
"port": 9000,
"pathMappings": {
"/www/kinsta/public/devwebsite/wp-content/": "${workspaceRoot}/",
}
}
]
}
My experience has been that setting breakpoints visually can be iffy for triggering; I tend to add an xdebug() call in my code where I want it to halt. Just be careful you don’t leave them in when you push to Kinsta.