Closed mjblacker closed 4 weeks ago
@mjblacker do you use Herd Pro?
@mjblacker do you use Herd Pro?
No. Followed these instructions: https://herd.laravel.com/docs/windows/1/advanced-usage/xdebug Only enabled the mode though not the start commands.
Already had a workflow for using xdebug so wanted to use it as I would if I was using local, docker, artisan serve.
Might also be an issue with all requests IF you are using the browser extension like me as the nginx rule is just based on the cookie.
Plugin I'm using: https://chromewebstore.google.com/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc
The reason the "pro" file is included is from the base nginx file in the config includes it and the valet file.
From the bottom of the ~/.config/herd/config/nginx/nginx.conf
include "C:/Users/xxx/.config/herd/config/pro/nginx/*.conf";
include "C:/Users/xxx/.config/herd/config/valet/Nginx/*.conf";
include herd.conf;
Right - that's a bug in Herd in this case. With Herd Pro we automatically switch to the debug FPM process based on the triggers. But as you're not using Herd Pro, the pro config should not be loaded.
So you can fix it yourself right now by removing/commenting out the line that includes the pro configuration file.
So i have the same issue i followed the instructions in the Herd docs to activate xdebug.
Then i found this issue and tried commenting out the "pro" inclusion, but that was a bad tip since the nginx variable herd_sock
is being mapped in "C:\Users\
So all that did was break Herd even more ^^
Edit:
I just bought Pro just for the fun of it and with Pro this actually just works 🤨
So i have the same issue i followed the instructions in the Herd docs to activate xdebug.
Then i found this issue and tried commenting out the "pro" inclusion, but that was a bad tip since the nginx variable
herd_sock
is being mapped in "C:\Users.config\herd\config\pro\nginx\debug.conf" So all that did was break Herd even more ^^
My original solution to fix (as I posted this bug after figuring it out) Edit the debug.conf file in the ~.config\herd\config\pro\nginx folder and change the debug ports to match the base ports.
Glad that it's all working with Pro though.
Platform
Windows
Operating system version
Windows 10 22H2
System architecture
Intel (x86)
Herd Version
1.6.1
PHP Version
No response
Bug description
When xdebug is enabled with trigger based debugging it will try to change the port for the fastcgi daemon by adding 100 to the base port. (There is a config option for this but doesn't do anything from what I could find)
The windows php-cgi processes are already running on the base port + version number so adding 100 just gives a 502 Bad Gateway error as there is no fastcgi available on the port trying to be accessed.
To fix: Edit the debug.conf file in the ~.config\herd\config\pro\nginx folder and either negate the map for detecting the xdebug cookies or change the debug ports to match the base ports.
Steps to reproduce
Turn on xdebug but do not enable for all requests, use a browser plugin to trigger the debug session as needed.
Relevant log output