There is no need to configure xdebug for the first launch at all! How to start debugging in Phpstorm in a minute and without a browser

Many people think that getting xdebug debugging to run successfully after installing it is difficult and painful. But in fact, you can do the first launch in less than a minute, without making any settings or even touching the .ini configuration files (php.ini/xdebug.ini). How to do this? This is what this article will discuss.

What's the trick?

There are two types of php debugging – debugging a web application, and Debugging a CLI script. With the first option, debugging is launched through the browser, and this is the option that most people use, and which almost all manuals are devoted to. In this case it is really necessary dance with tambourines make adjustments. With the second option, the PHP script is launched directly in the IDE (it will launch it in the console, but without your participation).

So, the key difference between the second option and the first is that there are all sorts of directives (like xdebug.client_host), do not need to be written in the xdebug.ini file or anywhere else, they are transferred at startup dynamicallyand the IDE fills them in automatically. All you need after installing xdebug is to create a PHP Script configuration in Phpstorm, connect an interpreter to it, and register the xdebug connection to it in the Debugger Extension field – its value will go into the directive zend_extension (how to fill out – see herepoints 2 and 4), and don’t forget to click Reload phpinfo.

And then we just press the start button and start debugging without dancing with tambourines

Option without manually creating PHP Script configuration

You need to specify the default interpreter for the project (it is assumed that the xdebug connection is already registered there):

And then you can simply start debugging the currently open file:

Then the configuration will be created automatically, and will use the default interpreter.

By the way, what’s interesting is that in most manuals for setting up xdebug (for example here), connecting an interpreter is a mandatory item, although in fact this is an unnecessary action – since in the end web debugging is launched.

This option is suitable for both local connections and remote connections (SSH), and for Docker too – the Phpstorm interface allows you to connect an interpreter from all of the above sources.

The probability of a successful launch on the first try is high, but not 100%

For example, if debug ports 9000/9003 are closed on the server, then debugging will not start. In this case, you will need to forward the SSH tunnel:

ssh -R 9003:localhost:9003 username@host-ip

And also set the directive in the interpreter settings xdebug.client_host with meaning localhost.

There is also a Phpstorm bug that debugging does not start if Phpstorm is installed in Program Files and not in the user folder (C:\Users\UserName\AppData\Local\Programs\PhpStorm). In this case, the SSH tunnel should also help, or reinstall Phpstorm in the desired folder.

Is everything still the same for launching web debugging?

Well, firstly, it may not be useful to you at all if you need to debug not the entire web application, but a separate script. And secondly, if you still need to debug the application, then of course you will have to adjust the configuration, but if you previously managed to successfully launch debugging of a CLI script, then it will be much easier for you with web debugging. It's like the same Hello World, but in the world of debugging – as soon as you manage to launch it, then half the work (or even more) is already done.

I won’t describe the setup for Web debugging, since there are already enough manuals about this. Moreover, they are usually not useful to me, I just remember that:

1. On the server side, you need to fill in at least the minimum configuration in xdebug.ini/php.ini, and after that restart web server.

   Configuration example

   Here is an example of a minimal configuration for remote debugging on Linux, where there is no need to forward an SSH tunnel:

   zend_extension=xdebug
   xdebug.mode=debug
   xdebug.discover_client_host=on

   The tunnel is not needed, because thanks to the directive xdebug.discover_client_hostyour IP address is automatically detected. But you need to use this with caution, because debugging can then be started by anyone who opens the application page. If the server is accessible from the outside, then it will still be safer to use xdebug.client_host=localhostAnd forward SSH tunnel. But for the first launch you can use xdebug.discover_client_host.

   Instead of localhost You can hardcode your IP, then the tunnel will not be needed, but no one except you will be able to start debugging. And for Docker they usually indicate xdebug.client_host=host.docker.internal.

2. A PHP Remote Debug configuration must be created and launched, with a server in which the mappings will be specified, and the specified IDE key (usually PHPSTORMbut depends on the Xdebug browser extension).

3. The browser should have extension for working with Xdebug With activated beetle

Everything else that is written about in the manuals – connecting a CLI interpreter, connecting DBGP-proxy in Phpstorm – is optional.

Or you can have zero debug configuration, but it doesn’t always work

In this case, you do not need to create a PHP Remote Debug configuration. You just need to fill out the config in the ini, and then you just need to enable listening for incoming connections in Phpstorm.

Well, activate the bug in the browser. And then you can launch the file/page in the browser in which a breakpoint was previously set.

And a bonus

You may not know, but in a debugging session you can not only look at the values ​​of variables, but also execute expressions:

And also execute them in a separate window:

This is in addition to the console, where you can also execute code, but you will need to copy it there manually. Please note that executing code and expressions may affect the execution of the program (for example, if you change the values ​​of variables).