Opened 5 years ago
Last modified 4 years ago
#49953 new defect (bug)
Xdebug not working out of the box
Reported by: | Jules Colle | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 5.3 |
Component: | Build/Test Tools | Keywords: | has-patch |
Focuses: | Cc: |
Description
This issue is regarding the wordpress-develop repo on github
I expected Xdebug to work out of the box after setting LOCAL_PHP_XDEBUG=true
in the .env file, but that wasn't enough.
It looks like I had to add a couple of lines to tools/local-env/php-config.ini as well:
xdebug.remote_enable=1 xdebug.remote_connect_back=1
In my opinion, these lines should be added to php-config.ini by default.
---
Additionally, I have a suggestion to also add some information on how to use Xdebug for WP core development with VS code, as it turns out you also need some custom configuration in the .vscode/launch.json file. I've written an article about this: https://bdwm.be/wordpress-core-development-with-xdebug-and-vs-code/
Feel free to quote the article or include parts of it in the WP developer documentation.
Attachments (2)
Change History (8)
This ticket was mentioned in Slack in #core by jules-colle. View the logs.
5 years ago
#3
@
5 years ago
- Milestone changed from Awaiting Review to 5.5
- Version changed from trunk to 5.3
Thanks for the patch and the link to the blog post @jules-colle .
Autostarting the remote debugging and automatically connecting back to the initiating client definitely makes sense for a local development environment.
- The Xdebug extension for Chassis enables both of these.
- VVV enables
remote_autostart
but notremote_connect_back
.
This ticket was mentioned in Slack in #core by david.baumwald. View the logs.
4 years ago
#5
@
4 years ago
This has the potential to introduce interesting security vulnerabilities, I don't think it should be enabled by default.
Off the top of my head:
- Some Travis PHPUnit tests run with Xdebug enabled. Would this allow remote connections to the Travis job, potentially exposing encrypted keys?
- Xdebug allows arbitrary code execution, if other people are able to connect to someone's development environment (for example, if it's exposed to the local network at a contributor day, or they use a forwarding service like ngrok), this could very easily open a contributor's computer to attack.
I'd be more comfortable with enabling this if it can reliably restrict who it connects to.
Adds 2 lines of configuration, necessary to make Xdebug work in the docker container.