Mar 31, 2021 In order to start debugging, you first need to activate the debugger engine on the server. To do this, you need to set a special GET/POST or COOKIE parameter (see the Xdebug and Zend Debugger official documentation for details).
Typically, I rely on a browser extension to trigger Xdebug, however Postman is its own application, so I could not rely on browser extensions. Fortunately, there's an easy solution: Add `XDEBUGSESSIONSTART=PHPSTORM` to the query string and PHPStorm will catch the debug session as it would if you were using a browser extension. Sudo apt-get install php5-xdebug (Debian based servers). With PHP 7.3, the setting xdebug.remoteport has been deprecated, and the setting xdebug.clientport should be used instead. Also the default xdebug port changed from 9000 to 9003. For PhpStorm and xdebug to correctly hit breakpoints and talk to each other, we need to tell PhpStorm how the files it knows about are mapped to the files that VVV knows about. There is a way to get the server going manually but there is an easier way: get PhpStorm to do the important bits for us.
Besides interactive debugging, PhpStorm integration with Xdebug also supports profiling. PhpStorm provides visual representation of profiling data generated by Xdebug. You can select several snapshots at a time and collect the aggregated profiling information.
Before profiling with Xdebug, download, install and configure the components of the PHP development environment. Normally, these are a PHP engine, a web server, and the Xdebug tool.
Enable profiling with Xdebug
Configure Xdebug
Download and install the Xdebug tool.
Integrate Xdebug with the PHP engine.
Integrate Xdebug with PhpStorm.
Enable the Xdebug profiler
Open the active php.ini file in the editor:
In the Settings/Preferences dialog Ctrl+Alt+S, click PHP.
On the PHP page that opens, click next to the CLI Interpreter field.
In the CLI Interpreters dialog that opens, the Configuration file read-only field shows the path to the active php.ini file. Click Open in Editor.
Do one of the following:
To permanently enable the profiler, set the xdebug.profiler_enable (for Xdebug 2) or xdebug.mode (for Xdebug 3) directive:
To enable triggering the profiler from the browser by using the
XDEBUG_PROFILEcookie or a GET/POST parameter, set the following directives depending on the Xdebug version used:xdebug.profiler_enable = 0; xdebug.profiler_enable_trigger = 1;xdebug.mode = profile; xdebug.start_with_request = trigger;
Configure the way to toggle the profiler from the browser
To specify the XDEBUG_PROFILE cookie or a GET/POST parameter, do one of the following:
Specify the values manually.
- Generate the bookmarklets to toggle the debugger through. These bookmarklets will appear on the toolbar of your browser. They provide control over the debugger cookie, through them you will activate and deactivate the debugger.
Enable the Bookmarks toolbar in your browser by doing one of the following depending on the browser type:
In Firefox, choose View | Toolbar | Bookmarks Toolbar.
In Chrome, choose Bookmarks | Show bookmarks bar.
In the Settings/Preferences dialog Ctrl+Alt+S, navigate to PHP | Debug.
On the Debug page, that opens, click the Use debugger bookmarklets to initiate debugger from your favorite browser link.
On the Zend Debugger & Xdebug bookmarklets page that opens, check the debugging engine settings and click Generate. The bookmarks for listed debugging-related actions are generated.
Drag the generated links to the bookmark toolbar in your browser.
Specify the location for storing accumulated profiling data
Open the active php.ini file in the editor:
In the Settings/Preferences dialog Ctrl+Alt+S, click PHP.
On the PHP page that opens, click next to the CLI Interpreter field.
In the CLI Interpreters dialog that opens, the Configuration file read-only field shows the path to the active php.ini file. Click Open in Editor.
Define location for accumulating profiling snapshots by specifying the xdebug.profiler_output_dir (for Xdebug 2) or xdebug.output_dir (for Xdebug 3) directive.
xdebug.profiler_output_dir = '<path to output folder>'Specify the name of the file to store snapshots in through the value of the
xdebug.profiler_output_namedirective. The default name is cachegrind.out.%p, where%pis the name format specifier. Accept the default name or define a custom one in compliance with the following standard:The name should always be cachegrind.out.
Use the supported format specifiers.
Analyze Xdebug profiling data
When integration with Xdebug profiler is enabled, PhpStorm provides visual representation of profiler snapshots. PhpStorm opens a separate editor tab with four views where the data are presented based on different criteria.
Initiate an Xdebug debugging session
Do one of the following:
To start debugging an entire application, create debug configuration of the type PHP Web Page, and launch debugging by clicking .
See Debug with a PHP web page debug configuration for details.
To debug a specific PHP HTTP request, define a debug configuration of the type PHP HTTP Request, and launch debugging by clicking .
See Debug a PHP HTTP request for details.
To initiate a zero-configuration debugging session:
Toggle the Start Listen PHP Debug Connections button on the PhpStorm toolbar so that it changes to . After that PhpStorm starts listening to the port of the debugging engine used in the current project. Debugging ports are set at the PhpStorm level on the PHP | Debug page of the Settings/Preferences dialog Ctrl+Alt+S.
Open the starting page of your application in the browser, choose the Start debugger bookmark to activate the debugging engine from the browser, re-load the current page (the starting page of the application), and then return to PhpStorm.
Retrieve the data accumulated by the profiler
From the main menu, choose Tools | Analyze Xdebug Profiler Snapshot.
In the Select Xdebug profiler snapshot dialog, that opens, choose the folder and the file where the profiling data is stored.
PhpStorm presents the collected profiling data in a separate editor tab with the name of the selected profiler output file.
Examine the profiling data
When you request on the accumulated profiling data, PhpStorm opens its visualized presentation in a separate editor tab. The tab is named after the selected profiler output file and consists of several views. Switch between the views to analyze the profiling data based on various criteria of analysis.
In the Execution Statistics view, examine the summary information about execution metrics of every called function.
In the Call Tree view, explore the execution paths of all called functions.
To explore the execution paths of a specific function, select the function in the Call Tree view and view its callees in the Callees view.
To explore all the paths that can result in calling a specific function, select the function in the Call Tree view and examine its possible callers in the Callers view.
Published on 2020-06-21 • Modified on 2020-10-18
In this post, we will see how to do step by step debugging with Xdebug, Symfony and PHPStorm. We will do a basic example where we will stop the execution of the Symfony code just before rendering a template to check the data passed to it. Let's go! 😎
» Published in 'A week of Symfony 704' (22-28 June 2020).
Prerequisite
I will assume you have a basic knowledge of PHP, Symfony and that you know how to modify your PHP configuration thanks to the php.ini file.
Introduction
Why this blog post? Well, because of this tweet:
Phpstorm Xdebug Not Working
PHP developers that don't use Xdebug for debugging are amateurs.
— Derick Rethans 🔶 (@derickr) June 20, 2020This is the kind of tweet I don't like, a typical troll, trying to make a generality of something more complex. It brings negativity as It can be interpreted by people not using Xdebug by:
“If you don't use Xdebug, you aren't a real developer.” 😔
Even it's not what Derick meant to say, it's what people may understand. There is no smiley. We don't know if the tweet is pure sarcasm or not. I wanted to answer at first. But what about transforming something negative to something positive and useful? 😀 That's why I decided to write this blog post. 🙂
Configuration
I use the following configuration, but it should be OK with previous versions of each of these components. Here, I use the Symfony binary to serve my application. If you use another type of setup (Apache, Docker...), you'll probably have to make small adjustments to the following instructions.
- PHP 7.4
- Symfony 5.2
- Xdebug 2.9.6
- PHPStorm 2020.3
Installation
I will assume you have a working PHP/Symfony installation. So first let's install Xdebug, it can be done with PECL:
If not done, activate the Xdebug extension in your php.ini file. You can find this file by running:
Verify that in this file, the xdebug.so (or .dll) library is loaded. You must see a line like the following (it can also be loaded in an external file like conf.d/ext-xdebug.ini):
If everything is OK, you should now see Xdebug when getting the PHP version:
Or when grepping the module list:
The debug bar also shows if Xdebug is available when you pass over the Symfony version number with your mouse:
Now that Xdebug is activated let's see how to configure it for PHPStorm.
Configuring Xdebug and PHPStorm
Xdebug
First, we must enable the remote option of Xdebug. Add the following parameter in your PHP configuration as we did previously:
We keep the other default parameters to keep the configuration as minimal as possible. So, with this setup, the port used by Xdebug is 9000 and the default IP address is 127.0.0.1. Check out the xdebug.remote_host and xdebug.remote_port parameters in the documentation.
PHPStorm
Now, let's check the configuration inside PHPStorm. Open the menu entry: Run > Web Server Debug Validation. You should see this window:
In the first parameter put the full path of your project public directory where is stored the Symfony front controller (generally public/index.php with Symfony 5). In the second parameter, put the local URL of your project. Then click on validate. If everything is OK, you should see ✅ like above. You can ignore the error of the last line, it seems to be a known problem, but it won't prevent the debugger from working. The final step is to tell PHPStorm to start listening to Xdebug connections. It must be done with the Run > Start Listening for PHP Debug connections menu entry.
Step by step debugging
Now that PHPStorm has validated our setup let's try to add our first breakpoint. Open one of your controllers and click between the line number and the start of the code editor panel of the line you want to stop the execution. A red disc 🔴 appears like this (at line 33 in this example):
Now, open your browser and access a page that calls the action where we put the breakpoint. If it works, PHPStorm gets back as the active window of your OS, and you get the following output:
As you can see, the code window is different from what we use to have. First, after the controller method declaration line, we have the values of the parameters received by the action. $_locale is 'en', $goals is an array with two keys, and lastly, $articleRepository is the Doctrine repository of the Article entity. Just below, we see that the line of the breakpoint is highlighted; this is to show that the code has stopped here like expected. Just before this line, after the declaration of the $data (at the right), we see the value of this new variable. It is empty as we just declared it.
Just below, in the debug panel, we have a Variables section where we can inspect all the local variables available at the breakpoint.
This panel is very convenient; we can see all the variables (even the globals) and expand them to check their content. We also find the function parameters ($_locale, $goals, $articleRepository). As this controller extends the Symfony AbstractController, we can notice that it has access to the dependency injection container ($this->container).
Now let's try to advance to the next 'step', to go to the next line. We can use the 'Step over' button (F6 with my setup).
As you can see the highlighted line has changed, it's now line n°34. We can see the value of the $date variable just above. This new $date variable is now part of the 'Variables' panel. We can continue like this until the end of the action to check that the $data array contains the correct keys and values and can be passed to the Twig template. To continue the execution of the script, click on the 'Resume program' button ⏯️ (F8).
If you don't need the breakpoint for now but want to keep it for later, you can right-click on it and deselect the 'Enabled' option. The red disc appears now as a circle. Refresh the page, and you will notice that the script doesn't stop anymore.
The browser extension
We can also install a browser extension (available for Firefox, Chrome, Safari, Opera) to disable/enable the debug on the fly. When disabled, nothing is caught by PHPStorm even there are still some active breakpoints. It is faster than deactivating the breakpoint manually or altogether disable Xdebug in the PHP configuration. It looks like this:
Conclusion
Et voilà! We have a practical step by step debugging workflow using Xdebug! What about telling Derick that we are now professionals PHP developers? 😁
Phpstorm Xdebug Firefox
About the original tweet, I really liked the answer of Jordi; this is precisely what I think:
I can see a debugger being valuable when code is very complex or unknown, and often use it in JS. In PHP code though I usually am familiar enough with what libs I use and find no benefit to debugging interactively. Like most things, it depends. No need to call people amateurs IMO
— Jordi Boggiano (@seldaek) June 20, 2020If you don't drink Guinness you are an amateur
— Gary Hockin (@GeeH) June 20, 2020PHP developers who don’t use @doctrineproject are amateurs.
— Jonathan H. Wage (@jwage) June 20, 2020Developers that don't use a computer to develop are amateurs
— Gregoire Pineau (@lyrixx) June 21, 2020PHP developers that don't write there own frameworks are amateurs
— Simon Bennett (@MrSimonBennett) June 20, 2020PHP developers that write bugs and need to debug are amateurs. https://t.co/NG5YtmdD3k
— Liam Hammett (@LiamHammett) June 20, 2020That's it! I hope you like it. Check out the links below to have additional information related to the post. As always, feedback, likes and retweets are welcome. (see the box below) See you! COil. 😊
They gave feedback and helped me to fix errors and typos in this article, many thanks to jmsche. 👍
Did you like this post? You can help me back in several ways: (use the Tweet on the right to comment or to contact me )
- Report any error/typo.
- Report something that could be improved.
- Like and retweet!
- Follow me on Twitter
- Subscribe to the RSS feed.
- Click on the More on Stackoverflow buttons to make me win 'Announcer' badges 🏅.
Thank you for reading! And see you soon on Strangebuzz! 😉
[🇬🇧] New blog post, this is my answer to the tweet: 'PHP developers that don't use #Xdebug for debugging are amateurs.' https://t.co/SPd8UIOrQ8 Proofreading, comments, likes and retweets are welcome! 😉Annual goal: 4/6 (66%) #php#strangebuzz#blog#blogging#debug#bug#blogging
— COil #StaySafe 🏡 #OnEstLaTech ✊ (@C0il) June 23, 2020Introducing CW: a cache watcher for Symfony
Adding a custom data collector in the Symfony debug bar