[Bug]: xdebug hostname not passed correctly trough herd

[wesleylether]

Operating system version

macOs Ventura 13.5.1

System architecture

ARM64 (M1, M2, etc)

Herd Version

1.2.0 (Build: 14)

PHP Version

all

Bug description

After the configuration of Xdebug through the page 'xdebug installation' xdebug is working (which is visible trough php -v).
But when I listen with PHPStorm to Debug connections, It triggers the xdebug server pane in PHPStorm, but it does not provide a hostname. Also, I cannot correctly specify directory mappings. Because of this Xdebug won't work properly trough local websites of Herd.

[liugehao]

Operating system version

macOs Ventura 13.5

System architecture

ARM64 (M1, M2, etc)

Herd Version

1.2.0 (Build: 14)

PHP Version
8.2.10

I am using Heroku 1.2.0 and PHPStorm, and debugging the website fails. However, 'php public/index.php' can debug successfully.

[mpociot]

@wesleylether Did you use Laravel Valet before switching to Herd? Do you know if there's any special requirement regarding the configuration of xdebug to make this work?

[wesleylether]

@mpociot I did indeed use Laravel Valet before. I don't know if there are any special requirements needed. Before on Valet when I listened on PHPStorm I did see the hostname correctly, and path mappings were mostly automatic.
But now trough herd the hostname is lost, and I cannot map the files correctly.

But when I enable break on the first line, it will eventually reach the breakpoint. It would be better if the xdebug works like Valet before.

p.s. the configuration for xdebug on the herd page isn't fully complete because for eacht PHP version you will need a diffrent xdebug.so file :)

[thejmitchener]

Operating system version

macOs Sonoma 14.0

System architecture

ARM64 (M1, M2, etc)

Herd Version

1.2.2 (Build: 16)

PHP Version
8.2.11

Cannot map the files correctly.

[jkbennemann]

Seems that with the new update v1.4.0 the mapping and configuration got fixed 🙌
Thanks a lot @mpociot 💪

Though I still have a question.
You mentioned in the docs that when enabling xdebug manually its required to add

xdebug.start_with_request=yes
xdebug.start_upon_error=yes

Do you know what these settings are in fact needed for?
The reason why I'm asking is that even without those 2 lines everything works just fine with the following settings inside PHPStorm, assuming the correct PHP interpreter of Herd is set up for the project.

So my adjusted php.ini file just contains those lines for PHP 8.2 on Apple M1 Max 14.3 (Sonoma)

zend_extension=/Applications/Herd.app/Contents/Resources/xdebug/xdebug-82-arm64.so
xdebug.mode=debug,develop

An additional question would be a little more technical:
Which parts of the underlying valet?! implementation needed to be adjusted to get the mapping for xdebug recognised correctly?
I'm just curios as I tried the same setup with a fresh valet installation and even there I could not get it running seamlessly.
I think some things need to be changed within the server.php file?!

But again thanks a lot for putting in the effort to get this running!

[wesleylether]

@mpociot I have deleted all valet, herd configuration. Installed this new version of Herd and tried to configure xdebug again.
This time, I can configure a xdebug connection, and it will break at the breakpoint! So we are development ready.

But I do want to share some images. After I configured PHPStorm to accept debug connections, I got this screen:

As you can see, there is no server name! I would expect the .test server name.
When you accept this connection, you can see that most values are blank and the directory mapping isn't what it should be:

Also, on this screen, you would expect some values there. These values are present if you use the valet configuration without herd. So the hostnames that are configured through herd, there are some nginx settings that are not entirely correct I presume.

Hopefully, this information will help you to solve this problem 😄