Debugging in POSTMAN. In general, we can debug get requests directly in the browser, but sometimes we need to send headers or posts, We will choose the tool of postman to request. At this time, we only need to add Xdebug to the request parameter SESSION Start = phpstorm. Debugging with Postman and PHPStorm (Xdebug) Submitted by Anonymous (not verified) on Mon, - 12:13 Postman started out as an API development tool, but has developed more into, as they put it, an 'API Development Environment'. 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.
This blog post shows how to setup a fully dockerized development suite with PhpStorm, GIT and Postman. But what is development without debugging? If all apps are dockerized you will need a workaround to be able to debug the application e.g. with PhpStorm and Xdebug. This is also considered. If you not familiar with Dockerized desktop apps, check out the Dockerized introduction. You should create your own Docker images, but for testing my Docker images should work too. The bash scripts refer to a folder data/x11docker in your home directory where x11docker stores the container config. Please create it before.
Setup GIT
Xdebug and Postman If you wish to debug a request sent by Postman, all you need to do is add XDEBUGSESSIONSTART=PHPSTORM as a key-value pair to the request body and start the debug config as you would when debugging via Chrome. Xdebug and Postman. If you wish to debug a request sent by Postman, all you need to do is add XDEBUGSESSIONSTART=PHPSTORM as a key-value pair to the request body and start the debug config as you would when debugging via Chrome. Developer documentation - Previous.
To work properly with Dockerized GIT you need three things. A Docker container with GIT, the mounted source of course and your SSH credentials.
Docker Image
Let's start with the GIT Docker image. The minimal packages are git and openssh.
Start script
One cool thing of x11docker is, that it does all the heavy lifting. Don't worry about file permissions, how to share the ssh socket or to mount directories. All my sources are stored under data/sources. This makes it easy to mount the root source directory. I set the working directory to the current directory where the git command is executed. With this is feels like native GIT usage.
Create the following script named git and put it to a directory which is in your PATH variable e.g. ~/bin and make it executable.
Now you can use GIT as always and it works seamlessly. Ok, there are some small caveats. The start time is compared to native GIT long and you don't have bash completion. But I use PhpStorm mostly for VCS stuff.
If some SSH keys are not found, you can mount the ssh folder with --sharedir $HOME/.ssh:ro.
Setup PhpStorm
To work efficiently with Dockerized PhpStorm you will need a Docker container with PhpStorm and the same packages like in the GIT dockerfile.
Docker Image
PhpStorm can be downloaded and extracted to /opt. I use this method in my PhpStorm Docker image. You will need the packages git, openssh, vim, gnome-keyring and libsecret to work properly. PhpStorm stores connection credentials in the Linux keyring.
Start script
The PhpStorm script has some more options like git, because we need a clipboard for copy & paste and hostdbus for credentials. I use also hostdisplay but you can also try xpra. To debug applications with PhpStorm you must add PhpStorm to the network of the application which should be debugged. I use a trick in the PhpStorm startup script to add the phpstorm container to every default network.
You have to set the xDebug XDEBUG_CONFIG option to remote_host=phpstorm and ensure that xdebug.remote_connect_back is disabled. Read more about Docker PHP debugging.
Setup Postman
Postman is a popular tool for API development. It has many features like test, debug and documentation of your APIs.
Docker Image
Simply install Postman for your distro. That's it.
Start script
To interact with other Docker containers via a local domain you have to add the add-host option with the IP of your Docker network. In this example it's 172.17.0.1 but may be vary on your host. You can also share your Downloads folder to import / export Postman collections. Debugging your APIs with xDebug works like a charm.
Chromium
I use a dedicated Chromium for development with installed development plugins. Some plugins have access to all data of the webpage or can even manipulate the website data. To browse a development website which is served by a Docker container via a local domain you have to add the add-host option with the IP of your Docker network.
Xdebug Postman Vscode
Conclusion
This blog post has shown how to setup a complete development environment with Docker. It's not very complicated but you have to figure out a few things. It's almost a native feeling and has so many benefits, such as: Run different versions of same application. The best thing is, that you not bloat your host system with other software.
Debugging: Configure VS Code + XDebug + PHPUnit
I've lost track of how many hours I have spent trying to configure and use Xdebug. The process usually begins with me noticing how often I've been using dd() while re-running my PHPUnit tests. I think to myself, 'There has to be a better way.' The next thing I know, I'm researching Xdebug blog posts, reading the documentation, and getting frustrated that I still can't get it to work. Hours later, I end up closing my open browser tabs and going back to littering my codebase with dd(). Except now, with a bruised ego.
Don't get me wrong, dd() is a wonderful tool that I will continue to use. However, there are instances where a real debugging setup can improve my efficiency tenfold. Using Xdebug, I can step through code while watching values change without having to add a single dd() entry and without the need to run the tests multiple times. The cost and time savings add up quickly! There have also been occasions where, in the process of stepping through client code, I find myself in Laravel's core code. I am usually enlightened with the inner workings of Laravel, which is an added benefit.
Why don't more developers use Xdebug in their development workflow?
From my experience, many developers don't fully understand the Xdebug architecture and its use cases. Xdebug is incredibly powerful and has many underutilized features. (You can read about all of the Xdebug features here.) In this post, though, I'm focusing on one specific feature called Remote Debugging (a misleading name since we can debug just fine without a remote system).
You can trigger Remote Debugging in two ways:
- Via the Browser
- Via the Command Line
Almost all of the resources I have come across for using Xdebug cover the first use case, via the browser. However, I want to use it in the terminal by running PHPUnit tests. After many hours of stumbling around, I found the configuration that works to use Xdebug Remote Debugging with one of the more popular editors out today, Visual Studio Code.
If you're using Laravel Homestead to develop locally, you may want to read this post to get started.
Getting Configured: Let's Do This!
We will need to configure the Xdebug PHP Extension, Visual Studio Code, and your Terminal for this to work. These steps assume that you are running tests on the same machine that you are editing with.
Xdebug
1. Install the Xdebug PHP Extension.
For MacOS users, you can easily install the Xdebug extension for your version of PHP using Homebrew. If you're using PHP 7.1, you can run:
For other platforms, you can read about how to install Xdebug here.
2. Find the path to your ext-xdebug.ini file by running:
The output should look like this:
3. Open ext-xdebug.ini to make sure the extension is loaded, and enabled.
It should look like this:
For CLI Remote Debugging, these are all the configuration settings we need in the ext-xdebug.ini file.
Visual Studio Code
1. Install the PHP Debug plugin.
2. Open the debug panel.
3. Click on the 'config' button (the cogwheel) and select PHP.
There is no need to modify the default launch.json file.
4. Open a PHPUnit test file and set a breakpoint using the debugger plugin.
5. Set the debugger to Listen for Xdebug.
6. Start Debugging by clicking on the green arrow button.
This doesn't actually start the debugging process, but it starts a listener that will be triggered once you run the PHPUnit test.
You should now see a step toolbar with the blue arrow buttons greyed out:
Terminal
Create an environment variable for XDEBUG_CONFIG and set the value to 'idekey=VSCODE'.
This variable flag will inform the Xdebug listener that the script is running. You can do this in one of two ways:
Export Command
Running this export command will create an environment variable for the current terminal session. It will revert once the session is complete.
- or - Modify your .bashrc/.zshrc file. (Preferred)
This is a more permanent solution for setting terminal environment variables:
- open
~/.bashrcor~/.zshrc. - insert the line
export XDEBUG_CONFIG='idekey=VSCODE'. - save and close the file.
- run
source ~/.bashrcorsource ~/.zshrcto pick up your changes.
Debug!
You're now ready to run your test:
Visual Studio Code should display the first breakpoint and the toolbar will allow you to step through your code.
This is just scratching the surface.
Xdebug is a powerful tool that can be intimidating to use at first—hopefully, this post will help reduce the barrier to entry for proper debugging. By doing so, you can harness a small sliver of Xdebug's power, become a more efficient developer, and gain the confidence to delve deeper into Xdebug if you choose to do so.
A quick note: If you are using the VSCode-PHPUnit plugin to run your tests, the debugger may be set to hit more breakpoints than you expected. To resolve this, you can uncheck the 'Everything' option in the debug panel:
Xdebug Postman
Happy Debugging!!
We'd love to hear your feedback! Tweet @JoseCanHelp and @TightenCo.