Debugging with PhpStorm

Build a solid foundation for diving deeper into the nuanced world of debugging in PhpStorm. In this episode, you’ll learn how to start a debugging session, set breakpoints, and step over or into code using Xdebug.

See transcriptTo episodes

Other episodes from this series

Two shortcuts to get started

Reduce the learning curve and enhance your productivity in PhpStorm from day one. In this episode, we highlight two essential keyboard shortcuts that you need to know.

Understanding PHP

Explore how PhpStorm's robust autocompletion, automatic class importing, error detection capabilities, and navigation shortcuts can streamline your workflow.

Error detection

Learn how to navigate and fix errors using intuitive keyboard shortcuts, scan your entire project for issues, and fine-tune inspection rules to match your coding standards.

Refactoring

Learn how to call the Refactor This menu, preview changes, and apply them, dramatically simplifying tasks that would otherwise be time-consuming and error-prone.

Testing

Learn how to run test suites directly within the IDE, analyze test results, leverage watch mode for automatic reruns, and generate test files effortlessly.

Transcript

One of PhpStorm’s most powerful features is its debugger. The name “debugger” goes as far back as the 1940s and literally means “something that removes bugs or faults from a program”. A debugger will allow you to pause your code while executing it, enabling you to inspect the program’s memory, follow which path the code takes, and much more. The goal of a debugger is to make it easier to find out where things go wrong and remove bugs from your code.

PhpStorm comes with a lightweight debugger built in, but by far, the most popular debugger for PHP is Xdebug, which you’ll need to install separately. Luckily, however, PhpStorm will perform the installation for you. So, let’s take a look at how to set up Xdebug with PhpStorm and how to get started with debugging.

Let’s say you don’t have Xdebug installed. What happens when you start debugging a PHP script –a test, for example? Instead of running the test normally, you can press the Debug button. As you can see, PhpStorm lets us know that there’s no debugger installed, but it can also fix it for you. Just press Update Interpreter Info, then Download and install Xdebug extension, and give the IDE a moment to set Xdebug up for you.

When it’s done, PhpStorm will automatically re-run your test with the debugger enabled – but, not much happens. That’s because we haven’t told the debugger to pause anywhere yet. To do that, we’ll need to use something called “breakpoints”.

A breakpoint is a place in your code where the debugger will stop executing for a second allowing you to inspect what’s going on.

For example, let’s add a breakpoint on this line here. Click the line number in the gutter, and you’re set. Now, let’s rerun our test.

This time, you’ll notice that some things have changed. The program is paused, and PhpStorm is showing a bunch of information.

On the left, you see everything that happened before we arrived at this breakpoint. We got here via these method calls. You can click through them, and PhpStorm will show you the path through the files.

On the right, you see all the variables currently available at the breakpoint. There’s a $this variable referencing the test class; you can open it and see what’s in it. Then, there are other variables like the global $_ENV variable, for example. PhpStorm will show you its contents, and you can see how the list of variables changes whenever we move to one of the previous method calls.

The debugger is now moving backward in our program flow, which can be very useful if you need to know the things that happened before something else happened. But what about moving forward?

You can unpause the debugger by pressing the Resume button, but then the test will just finish.

So, let’s go back to our breakpoint, and instead of pressing Resume, we can press the Step over or Step into buttons. And these two are very powerful.

“Stepping over” means the debugger will move to the next statement and pause again. “Stepping into” means the debugger will go a level deeper and debug what’s happening within a function call.

Now, these two buttons together are super powerful. You can essentially navigate the flow of your program with them, while keeping an eye on how variables change, why conditions match or don’t, how many times something is looped over, and much more.

But debugging is not just powerful; it’s also intimidating. There’s a lot going on, and it’s difficult to give examples without context that make sense. It’s also something that needs practice to get comfortable with, just like playing an instrument, for example.

So, here’s what we’re going to do. I’ve shown you the basics of getting started with the debugger: how to start a debugging session, breakpoints, and stepping over and into code. You’ll need to get comfortable with it, and the only way to do that is by practice. The next time you write a var_dump or dd statement, try to use the debugger instead; there will be some friction the first time you do, but it will get easier over time, and it will pay off in the long run.