Add Xdebug support - #2242
Conversation
📊 Performance Test ResultsComparing bc4a134 vs trunk site-editor
site-startup
Results are median values from multiple test runs. Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change |
| disabled={ ! xdebugEnabledSite || xdebugEnabledSite.id === selectedSite?.id } | ||
| text={ sprintf( | ||
| __( | ||
| 'Xdebug is currently enabled for "%s" site. Disable it there first to enable it for this site.' |
There was a problem hiding this comment.
Have you considered allowing the user to enable here with a notice that it will disable the other site?
The current flow requires ~6 steps:
close modal → switch site → open modal → disable Xdebug → save → switch back → open modal → enable Xdebug.
A single confirmation would be much smoother.
What do you think?
There was a problem hiding this comment.
Yes, but I wanted to avoid overcomplicating this in this initial Beta Feature release.
This is a bit of a rabbit hole. If Studio disabled Xdebug for all sites, it should restart them. If it restarts sites, it should first ask users if they want to restart them.
| </div> | ||
|
|
||
| { isXdebugFeatureEnabled && ( | ||
| <div className="flex flex-col gap-2 mt-4 p-4 border border-a8c-gray-200 rounded"> |
There was a problem hiding this comment.
The current disabled state does not look very clear in my opinion. It uses the disabled format for the checkbox but the label could also have some visible changes.
The tooltip provides all the information, but we could make it clear to the user that the option is disabled just by looking at it:
What do you think?
There was a problem hiding this comment.
Code looks good. I confirm it adds a feature flag, and enables the Xdebug parameter when the checkbox is active. I confirm the site property enableXdebug is saved in one site at a time in Studio settings file.
I was not able to make it work with Cursor, VSCode and PhpStorm. @wojtekn, I would appreciate pairing to double check my testing steps. I followed your testing instructions and also those provided in https://make.wordpress.org/playground/2025/11/24/debugging-with-xdebug-is-now-available-in-wordpress-playground/
I agree with @bcotrim's suggestion. It would be great if users could enable Xdebug on any site, and Studio could automatically remove the flag from the previous site. Maybe we could display a dismissible modal to confirm that action.
A couple of ideas to improve the UI that could be follow-ups:
1. Make the checkbox block consistent with Use custom domain and Enable HTTPS
I suggest making the checkbox more consistent between them, by removing the border around the Xdebug option or adding the border to the rest of checkboxes.
2. Add the action to Enable/Disable Xdebug in the site actions menu.
Enable Xdebug would automatically disable the option from any other site, and start or restart the site.
3. Replace the green dot with a green 🪲 when Xdebug is running in a given site.
PhpStorm and Cursor display the play button like this:
| // Enable Xdebug support if requested | ||
| if ( options.enableXdebug ) { | ||
| console.log( __( 'Enabling Xdebug support' ) ); | ||
| args.xdebug = true; |
There was a problem hiding this comment.
Should we also add experimentalUnsafeIdeIntegration argument or is not necessary? I tried it to add it, but it didn't help during my testing.
args.experimentalUnsafeIdeIntegration = [ 'vscode', 'phpstorm' ];`
There was a problem hiding this comment.
No, because it's experimental and unsafe :D I tested it, and besides being broken, it was only updating IDE configs. I think it's better if Studio enables user to use Xdebug, instead of modifying their IDE configs.
I had some issue and was missing the {
"version": "0.2.0",
"configurations": [
{
"name": "Listen for Xdebug",
"type": "php",
"request": "launch",
"port": 9003,
"pathMappings": {
"/wordpress": "${workspaceFolder}"
}
}
]
}
❤️ I love this idea. |
Good idea. Added in 24204af |
Thanks, I updated it in 1bd4aa1
The site context menu has "Edit site..." which contains Xdebug field, so I would hold with this change at this point.
Sounds cool, but I would hold with this under this PR, and we could push follow-up after we check it more with the design team. @sejas let's pair tomorrow to see how it works on your environment. |
358d0c8 to
60ab25c
Compare
|
@wojtekn I added the CLI changes to support x-debug flag. I also implemented the |
|
Thanks @bcotrim . |
There was a problem hiding this comment.
It worked for me. I tested it using Cursor and the this launch.json and it worked great. @bcotrim, thanks for sharing the pathMappings trick.
Note that the breakpoint set in wp-config.php was ignored, while breakpoints in other parts of the app, such as in a plugin, worked correctly.
I just noticed that we are not consistent with the bold/regular font weight in the checkbox. I recommend making them consistent or creating a new issue to discuss that.
It works for me when I debug in PhpStorm - I can set breakpoints in
I fixed this, good catch. I tested it again after Studio CLI changes, and it works fine, too. The only change is that console output doesn't show Playground CLI messaging so "Enabling Xdebug support" is not visible there. |
# Conflicts: # src/storage/user-data.ts
7223493 to
3241fe7
Compare

Related issues
Proposed Changes
Testing Instructions
Test feature in Studio
and console shows "Enabling Xdebug support"Test debugging in IDE
I used PhpStorm:
/wordpressPre-merge Checklist