Published on 2020-06-21 • Modified on 2020-10-18

1. Postman Xdebug Phpstorm Crack
2. Xdebug Phpstorm Cli
3. Phpstorm Setup Xdebug

• Configure Xdebug in PhpStorm In the Settings/Preferences dialog Ctrl+Alt+S, select PHP. Check the Xdebug installation associated with the selected PHP interpreter: On the PHP page, choose the relevant PHP installation from the CLI Interpreter list and click next to the field.
• It is an open source testing framework for PHP that is used for development and debugging of codes. The protocol which is used for debugging is DBGp protocol. It supports code coverage analysis and profiler for integrating with the PHPUnit.

Postman Xdebug Phpstorm Crack

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.

The following video describes how to debug PHP applications using PHP Xdebug extension and PHPStorm.The video describes this on Windows Xampp installation, b. 这篇文章主要介绍了mysql中You can’t specify target table for update in FROM clause错误解决方法,需要的朋友可以参考下MySQL中You can't specify target table for update in FROM clause错误的意思是说，不能先select出同一表中的某些值，再update这个表(在同一语句中)。. Configure PhpStorm. Now the project has been cloned from GitHub and the dependencies have been installed. PhpStorm can be setup to use Docker. Thanks to Gary Hockin’s excellent YouTube video Running PHPUnit Tests in PhpStorm with Docker, the setup process can be easily replicated. There is a four stage process: Configure PhpStorm to use Docker.

Introduction

Why this blog post? Well, because of this tweet:

PHP developers that don't use Xdebug for debugging are amateurs.

— Derick Rethans 🔶 (@derickr) June 20, 2020

This 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? 😁

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, 2020

To see parodic tweets of the original one, click on this link 😜.

If you don't drink Guinness you are an amateur

— Gary Hockin (@GeeH) June 20, 2020

PHP developers who don’t use @doctrineproject are amateurs.

— Jonathan H. Wage (@jwage) June 20, 2020

Developers that don't use a computer to develop are amateurs

— Gregoire Pineau (@lyrixx) June 21, 2020

PHP developers that don't write there own frameworks are amateurs

— Simon Bennett (@MrSimonBennett) June 20, 2020

PHP developers that write bugs and need to debug are amateurs. https://t.co/NG5YtmdD3k

— Liam Hammett (@LiamHammett) June 20, 2020

That'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, 2020

Xdebug Phpstorm Cli

Introducing CW: a cache watcher for Symfony

Adding a custom data collector in the Symfony debug bar

Besides debugging the entire application, you can debug separate HTTP Requests. This is helpful when you are actually interested in a specific page that is accessed in a number of steps, but for this or that reason you cannot specify this page as the start page for debugging, for example, because you need to 'come' to this page with certain data.

To debug PHP HTTP requests in PhpStorm, you can use the following methods:

• Compose and debug the request via the HTTP client in the code editor, which is the recommended approach.

• Use the PHP HTTP Request run configuration. Based on the configuration settings, PhpStorm composes the request to run.

Phpstorm Setup Xdebug

Prepare the debugging engine

• Before you start debugging, make sure that you have a debugging engine installed and configured properly. PhpStorm supports debugging with two most popular tools: Xdebug and Zend Debugger. These tools cannot be used simultaneously because they block each other. To avoid this problem, you need to update the corresponding sections in the php.ini file as described in Configure Xdebug and Configure Zend Debugger.

  Open the active php.ini file in the editor:

  1. In the Settings/Preferences dialog Ctrl+Alt+S, click PHP.

  2. On the PHP page that opens, click next to the CLI Interpreter field.

  3. 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.

Set the breakpoints

Breakpoints are source code markers used to trigger actions during a debugging session. Typically, the purpose behind setting a breakpoint is to suspend program execution to allow you to examine program data. However, PhpStorm can use breakpoints as triggers for a variety of different actions. Breakpoints can be set at any time during the debugging process. Your breakpoints don't affect your source files directly, but the breakpoints and their settings are saved with your PhpStorm project so you can reuse them across debugging sessions.

1. Place the caret at the desired line of the source code.

   Breakpoints can be set in the PHP context inside php, html, and files of other types. Line breakpoints can be set only on executable lines, but not on comments, declarations, or empty lines.

2. Do one of the following:

   • Click the gutter area at a line where you want to toggle a breakpoint.

   • From the main menu, choose Run | Toggle Line Breakpoint.

   • Press Ctrl+F8.

Debug the request via the HTTP client in the code editor

Using the built-in HTTP Client, you can compose, execute, and debug HTTP requests directly from the PhpStorm code editor.

1. Open an existing HTTP request file, or create a new one: in the File menu, point to New, and then click HTTP Request.

2. Compose an HTTP request for the query that you need to debug.

3. Position the caret at the request and press Alt+Enter or click in the editor gutter. From the popup menu, select PHP Debug <host>.

   If you have environments defined, select PHP Debug with ... and choose the environment in the popup menu. The selected environment will be used as the default one when executing or debugging the request later.

   PhpStorm will automatically add the XDEBUG_SESSION cookie to the request, execute it, and stop at the specified breakpoint.

When a request is executed, PhpStorm automatically creates a dedicated temporary HTTP Request run/debug configuration for it. You can save it as a permanent run/debug configuration if necessary.

Press Shift+F10 to run or Shift+F9 to debug the corresponding saved run/debug configuration at any moment without the need to open the request file in the editor. This can be useful if you are working on the web service endpoint implementation in a .php file and want to quickly test it by sending an HTTP request.

Create a debug configuration of the type PHP HTTP Request

PhpStorm comprises the settings specified in this configuration into a PHP HTTP request. Note that using HTTP Client in editor for debugging HTTP requests is a more convenient and recommended approach.

1. Open the Run/Debug Configuration dialog by doing one of the following:

   • From the main menu, choose Run | Edit Configurations.

   • Press Alt+Shift+F10, then press 0 to display the Edit Configuration dialog or select the configuration from the popup and press F4.

2. Click on the toolbar or press Insert. From the list, select the PHP HTTP Request configuration type. The PHP HTTP Request dialog opens.

3. Specify the configuration name.

4. In the Server list, specify the debug server configuration to interact with the Web server where the application is executed. Select one of the existing configurations or click Browse and define a debug server configuration in the Servers dialog that opens as described in Create a PHP debug server configuration.

5. In the URL field, complete the host element of the request to debug. Type the path relative to the host specified in the debug server configuration. As you type, PhpStorm composes the URL address on-the-fly and displays it below the field.

6. Specify whether you want to bring any data to the target page. From the Request method list, choose the relevant request type:

   • To access the page without bringing any data, choose GET.

   • To access the page with some data saved in variables, choose POST and type the relevant variables in the Request body field.

     By default, the Project Encoding is used in requests' encoding if it is not specified explicitly, for example:

     header('Content-type: text/html;charset=utf-8');

     The Project Encoding is specified on the File Encodings page of the Settings/Preferences dialog Ctrl+Alt+S.

7. In the Query field, type the query string of the request. This string will be appended to the request after the ? symbol.

8. Click OK, when ready.

Initiate a debugging session and examine the suspended program

1. To start debugging, click the Debug button on the toolbar.

2. As soon as the debugger suspends on reaching the first breakpoint, examine the application by analyzing frames. A frame corresponds to an active method or function call and stores the local variables of the called method or function, the arguments to it, and the code context that enables expression evaluation. All currently active frames are displayed on the Frames pane of the Debug tool window, where you can switch between them and analyze the information stored therein in the Variables and Watches panes. For more details, see the section Examining a Suspended Program.

3. Continue running the program and examine its frames as soon as it is suspended again.

   • To control the program execution manually, step through the code using the commands under the Run menu or toolbar buttons: Step IntoF7, Step OutShift+F8, Step OverF8, and others. For more details, see Step through the program.

   • To have the program run automatically up to the next breakpoint, resume the session by choosing Run | Debugging Actions | Resume Program or pressing F9.