This makes sense to me: I refreshed the Grav Admin Dashboard page and it runs fine. But then is writes “Debug session was finished without being paused” to it’s Event Log panel. PhpStorm is listening and reports an incoming connection upon a browser page refresh. Phpstorm_validate_webserver_debug 709×782 35.6 KB The result is shown in the attached image. The setup seems OK if I look at the results of the Web Server Debug Validation check. 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? For instance, I don’t understand the consequences of the “Force break at first line …” options. The Xdebug Debug port is set to 9003, the same as in the php.ini file.Īt this point and onwards I get totally lost in the documentation and settings. So I have them all checked at this moment. I did try with some and all of these options unchecked with no desired results. Force break at first line when a script is outside the project.Force break at first line when no path mapping specified.Resolve breakpoint if it’s not available on the current line (Xdebug 2.8+).If I remember correctly all these options where checked by default at my first encounter with PhpStorm (out of the box): This is where it gets a bit complicated for me. Also it reports the correct (and only) php.ini file (“C:\Users\Medewerker\php7\php.ini”).Īt this point the configuration moves into the Debug section in the PHP configuration section. In the PHP section it shows the correct PHP version (7.4.16) and at “Debugger” it states: “Xdebug 3.0.4”. Then the configuration of PhpStorm starts by doing Ctrl-Alt-S to show the PhpStorm settings. 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. Using the settings for Xdebug 3 I added these line to the php.ini file:Īfter changing the ini file I restarted the webserver.Īgain inspecting the output of phpinfo() in the browser I see a section named “xdebug” which shows among many other settings: I can enable it and then it shows it’s bug icon in green in the browser.Īs a next step I follow the PhpStorm documentation Configure Xdebug. Apr 25 10:38:42 |INFO | PHP listening path="C:\\Users\\Medewerker\\php7\\php-cgi.exe" php="7.4.16" port=59667Īt this point I also have the Xdebug helper extension for Chrome installed. Apr 25 10:38:42 |DEBUG | PHP Using PHP version 7.4.16 (from default version in $PATH) Apr 25 10:38:42 |DEBUG | PHP Reloading PHP versions With Xdebug v3.0.4, Copyright (c) 2002-2021, by Derick RethansĪ restart of the built-in webserver shows (shortened a bit): The Web server is using PHP CGI 7.4.16 Zend Engine v3.4.0, Copyright (c) Zend Technologies PHP does find the extension when I prepend the path of the ext directory so the entry becomes: 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. (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īTW “Kan opgegeven module niet vinden” means “Can’t find the specified module”. Then php -version shows: PHP Warning: Failed loading Zend extension 'ext\php_xdebug-3.0.4-7.4-vc15-nts-x86_64.dll' Grav including the Admin Plugin runs excellent.Īs instructed by the Xdebug installation wizard I added this line to my php.ini file: There is no other webserver or PHP version installed on this machine. The server uses PHP version 7.4 which is installed in “C:\Users\Medewerker\php7”. For anyone unfamiliar with this feature, see Using Grav’s new built-in Web Server. On a Windows 10 machine I’m using Grav’s built-in webserver starting it with: 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.īelow is a reconstruction of what I tried. To my disappointment I can’t make it all work. And they do quite frequently since I’m not a developer by far. I was really looking forward to inspecting variables when a fatal error 500 occurs. Last week I decided to make life easier by purchasing PhpStorm. The process of creating and figuring out how Grav works was rewarding but often frustrating as well. Over the years I have created a couple of Grav plugins. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |