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.
#Xdebug phpstorm windows windows 10
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. This proves our breakpoints work as intended, and Xdebug has been successfully set up.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. Our $a array has one less element due to the array_pop operation we performed.
Clicking the Resume button once more produces a slightly different output:
Also notice you can expand it to see what it contains. Clicking the Resume button moves on to the next breakpoint and produces the following output: You’ll notice in the right panel that only the superglobals are declared – no other variables are present at this time. The left frame lists the stacktrace – the files the request already went through – and stops at routes.php, our file. A new tab should launch and immediately return you to PHPStorm with an output similar to this one: Then, go to Run -> Debug and run your predefined debug configuration. If you have the app open in your browser, close that tab now, otherwise PHPStorm won’t be able to re-run it. Then, put a breakpoint next to each line of the closure that does something, like so:
#Xdebug phpstorm windows code
In app/routes.php, alter the home route’s closure so that it looks like the code below: Route :: get ( '/', function ( ) )
0 kommentar(er)
