First of all, I know this is a lengthy post because I tried to give a complete overview of what I did with as much detail as possible.
Over the years I have created a couple of Grav plugins. The process of creating and figuring out how Grav works was rewarding but often frustrating as well. Last week I decided to make life easier by purchasing PhpStorm. I was really looking forward to inspecting variables when a fatal error 500 occurs. And they do quite frequently since I’m not a developer by far.
To my disappointment I can’t make it all work. To me the “zero config” setup of PhpStorm with Xdebug as shown in the Grav blog post Grav + PHPStorm + Xdebug Video is not as zero as I would like it to be.
Below is a reconstruction of what I tried.
On a Windows 10 machine I’m using Grav’s built-in webserver starting it with:
php bin/grav server. For anyone unfamiliar with this feature, see Using Grav’s new built-in Web Server.
The server uses PHP version 7.4 which is installed in “C:\Users\Medewerker\php7”. There is no other webserver or PHP version installed on this machine.
Grav including the Admin Plugin runs excellent.
As instructed by the Xdebug installation wizard I added this line to my php.ini file:
zend_extension = ext\php_xdebug-3.0.4-7.4-vc15-nts-x86_64.dll
php --version shows:
PHP Warning: Failed loading Zend extension 'ext\php_xdebug-3.0.4-7.4-vc15-nts-x86_64.dll' (tried: ext\ext\php_xdebug-3.0.4-7.4-vc15-nts-x86_64.dll (Kan opgegeven module niet vinden.), ext\php_ext\php_xdebug-3.0.4-7.4-vc15-nts-x86_64.dll.dll (Kan opgegeven module niet vinden.)) in Unknown on line 0
BTW “Kan opgegeven module niet vinden” means “Can’t find the specified module”.
Though “C:\Users\Medewerker\php7” is in my PATH variable (I checked with
$Env:Path) PHP can’t find the Xdebug DLL in the ext directory.
PHP does find the extension when I prepend the path of the ext directory so the entry becomes:
zend_extension = C:\Users\Medewerker\php7\ext\php_xdebug-3.0.4-7.4-vc15-nts-x86_64.dll
After this change a
php --version now shows:
PHP 7.4.16 (cli) (built: Mar 2 2021 14:06:13) ( NTS Visual C++ 2017 x64 ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Xdebug v3.0.4, Copyright (c) 2002-2021, by Derick Rethans
A restart of the built-in webserver shows (shortened a bit):
The Web server is using PHP CGI 7.4.16 https://127.0.0.1:8000 [Web Server ] Apr 25 10:38:42 |DEBUG | PHP Reloading PHP versions [Web Server ] Apr 25 10:38:42 |DEBUG | PHP Using PHP version 7.4.16 (from default version in $PATH) [Web Server ] Apr 25 10:38:42 |INFO | PHP listening path="C:\\Users\\Medewerker\\php7\\php-cgi.exe" php="7.4.16" port=59667
At this point I also have the Xdebug helper extension for Chrome installed. I can enable it and then it shows it’s bug icon in green in the browser.
As a next step I follow the PhpStorm documentation Configure Xdebug.
Using the settings for Xdebug 3 I added these line to the php.ini file:
xdebug.mode = debug
xdebug.client_host = 127.0.0.1
xdebug.client_port = 9003
After changing the ini file I restarted the webserver.
Again inspecting the output of
phpinfo() in the browser I see a section named “xdebug” which shows among many other settings:
IDE Key PHPSTORM
What I think is strange is that though the Xdebug version shown in the output is “3.0.4” it seems like PHP or Xdebug uses version 2 settings. There are many lines like these:
“xdebug.auto_trace (setting renamed in Xdebug 3)”
Then the configuration of PhpStorm starts by doing Ctrl-Alt-S to show the PhpStorm settings. In the PHP section it shows the correct PHP version (7.4.16) and at “Debugger” it states: “Xdebug 3.0.4”. Also it reports the correct (and only) php.ini file (“C:\Users\Medewerker\php7\php.ini”).
At this point the configuration moves into the Debug section in the PHP configuration section. This is where it gets a bit complicated for me.
If I remember correctly all these options where checked by default at my first encounter with PhpStorm (out of the box):
- Resolve breakpoint if it’s not available on the current line (Xdebug 2.8+)
- Force break at first line when no path mapping specified
- Force break at first line when a script is outside the project
I did try with some and all of these options unchecked with no desired results. So I have them all checked at this moment.
The Xdebug Debug port is set to 9003, the same as in the php.ini file.
At this point and onwards I get totally lost in the documentation and settings. For instance, I don’t understand the consequences of the “Force break at first line …” options. To me it says “Whenever a PHP script is called PhpStorm stops at the start of the script” and then I think why is that useful at all?
The setup seems OK if I look at the results of the Web Server Debug Validation check. The result is shown in the attached image.
PhpStorm is listening and reports an incoming connection upon a browser page refresh. But then is writes “Debug session was finished without being paused” to it’s Event Log panel. This makes sense to me: I refreshed the Grav Admin Dashboard page and it runs fine. No errors in there so PhpStorm doesn’t need to stop or pause.
The problem is that the same behaviour occurs when I refresh a page which calls a plugin with an uncaught fatal error.
The Event Log suggests to have a look at the PHP|Servers settings. There it shows PhpStorm creates another server with every page refresh. The name (“localhost:8000”) gets a sequence number appended like “localhost:8000 (2)”. The Host is set to “localhost:8000” with Port “8000” (and Debugger “Xdebug”).
I then remove the extra Server entries and set the Host back to “localhost” without the port number because somewhere I did see logging of “localhost:8000:8000/” which can’t be good.
All I want is having PhPstorm catch unexpected errors, point me to it and let me examine the variables at that point in the code. I’m sure it can be done, I just can’t figure out how to make it work.
I really hope someone read all this all the way down here and knows what is wrong. Any help is greatly appreciated!