Since I started with Delicious Brains last July, I’ve become a big fan of PhpStorm. It really is the bee’s knees. I won’t go over the full list of features, but some of the things I find helpful daily are:
- Cmd+clicking into method definitions
- VCS integration and color highlighting of code changes
- Code bookmarks
- And of course, Xdebug integration
Why Use the PhpStorm Debugger?
console.log() call at the point where I wanted to know a value, and fire up Chrome’s console to see what’s what.
Chrome does have a decent debugger built into the developer console. However, for me it always felt disjointed to use an external debugger not in my IDE. I’ve used the Chrome debugger in the past but I prefer the PhpStorm debugger for a few reasons.
The first advantage of the PhpStorm debugger is that it allows you to define tasks or scripts to run before debugging is started. If you have a grunt or gulp task that compiles your scripts this is a helpful addition.
The second advantage is having breakpoints reliably saved between page refreshes with the PhpStorm debugger. The Chrome debugger won’t save breakpoints between page loads if there is a cache busting string appended to the URL in a script tag. Removing the random string and/or setting up source maps for your scripts would help with this, but it’s not always possible.
The next thing you’ll want to do is make sure you’re using the Chrome web browser. Things seem to work best with Chrome, though there is a Firefox configuration as well. Then you’ll need to install the Jetbrains Chrome extension so that Chrome and PhpStorm can talk to each other.
For the purposes of this post, we’re going to go over Remote Debugging as my local dev sites all use separate local domains and to PhpStorm they are ‘remote’. It’s a little confusing, but I had the best success following the instructions for a remote server.
In this screen we’ll enter our name for this debug configuration and select a starting URL. I’m using the WP Migrate DB Pro admin page, but you could just as easily use a front-end URL for your own setup.
Furthermore, if the URL matches the PHPStorm project you’ve currently got open, that should be all you need to get up and running! Otherwise, you can map a domain or URL to your current project by using the “Remote URL” section of the debug configuration.
However, if you do use a build tool (like Grunt, Gulp or Webpack) you’ll have to make sure your breakpoints are in the files that are output by the build process. So, if you have a
/dist folder where your assets are stored, make sure the breakpoints are in these files, rather than in the source JS files.
It’s important to note that you’ll want to avoid minifying your built files locally during development and save minification for a final ‘build’ step.
In our case, with WordPress’
SCRIPT_DEBUG enabled, we’re able to load the unminified built files. That may be an option for you as well.
I should also mention that PhpStorm essentially takes over Chrome’s developer console when you’re debugging. This means that the debugger won’t work if the Chrome console is open on the tab you’re running the code. A small issue, but it’s caught me a few times.
Now that we know where to put our breakpoints, let’s add some. In PhpStorm it’s as simple as clicking in the margin on a line we want to break on. There are a few other options for breakpoints, but for our purposes we’re going to use a regular line breakpoint.
Once we’ve set up our breakpoints, we’ll click on the “bug” icon in the top menu bar, or under the “Run” menu > Debug. This should open up Chrome with a yellow bar across the top saying “JetBrains IDE Support is debugging this browser”. Once you do something in the browser that triggers the code flagged with a breakpoint, you’ll be booted back to PhpStorm with the debugger open.
In the debugging console, you’ll have all your favourite debugging tools you get with Xdebug PHP debugging, but also a new tool for debugging asynchronous code. This can be toggled with the ‘Async’ checkbox in debug panel. This little guy will let you step into asynchronous code. Clicking on this checkbox will give you access to the whole call stack from within the async callback, whether it’s AJAX or something like a
From there I was able to see how and when each segment of the
if statement was triggered.
Another handy tool is PhpStorm’s built in “watches” functionality. It allows you to set items in your code to be watched – meaning the debugger will display this item’s value in the watches pane. This is helpful for things you would normally output with a
console.log call as that’s essentially what it does, outputs the watched variable’s value as breakpoints are triggered. It’s helpful because it saves you time tracking down the variable in the debug panel each time you restart the debugger.
In the case of the above example, I was watching the
wpmdb global variable so that I had quick access to it when the breakpoints fired.
Another trick with the PhpStorm debugger that I use quite often is the “Evaluate Expression” tool. With this tool you can inspect and calculate values based on the currently paused code.
In the example above I saw that the AJAX call returned a
data variable in a jQuery AJAX success callback. However, the data returned was a JSON string and I wanted it to be nicely formatted. With the “Evaluate Expression” tool I could use the jQuery
Integration with Xdebug
To debug both your JS and PHP, you have to have Xdebug already enabled and setup with PHP and PhpStorm. I won’t go over that here, but here is a good post to get you up and running with MAMP.
Scratching the Surface