You get a bug report: the checkout page shows the wrong total, and you already have var_dump() calls sprinkled across five files with no answer in sight. PHP debugging with a real step debugger fixes that, because you can pause the code and see exactly what every variable holds. In this post I’ll show you how to set it up, connect your IDE, and use breakpoints and stack traces to fix bugs faster.

Why a debugger beats var_dump()

A debugger lets you stop your PHP code at any line and look around: variable values, the execution path, and the runtime conditions at that exact moment. That’s why it saves so much time. Without proper tools, finding the root cause of a bug is slow and frustrating, and even experienced developers lose hours to it.

With a debugger, you spot the problem sooner, fix it sooner, and ship sooner. I’d suggest setting it up once on your machine, even if you only need it a few times a month.

Install Xdebug for PHP debugging

Xdebug is the PHP extension that adds step debugging, and most IDEs talk to it out of the box. On Ubuntu or Debian, install it with:

sudo apt install php-xdebug

Then check that PHP loaded it:

php -v

You should see a line that says with Xdebug. If you’re on an older PHP version, my guide on upgrading PHP 7.4 to PHP 8.4 on Ubuntu is worth a look first.

Enable step debugging

Xdebug needs a few settings before your IDE can connect. To find which ini files PHP reads, run:

php --ini

Open the Xdebug file it lists (on Ubuntu it’s usually /etc/php/X.Y/mods-available/xdebug.ini, where X.Y is your PHP version) and add:

zend_extension=xdebug
xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_host=127.0.0.1
xdebug.client_port=9003

This tells Xdebug to start a debug session on every request and send it to your IDE on port 9003. If every request feels slow, change start_with_request to trigger and start sessions only when you need them.

To apply the change with PHP-FPM, restart the service:

sudo systemctl restart phpX.Y-fpm

Replace X.Y with your version. If you use Apache with mod_php, restart apache2 instead.

Connect your IDE

Modern IDEs plug into Xdebug, so you can set breakpoints, step through code and inspect variables without leaving your editor. In PhpStorm, click “Start Listening for PHP Debug Connections”. In VS Code, install the PHP Debug extension and add this to .vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug",
      "type": "php",
      "request": "launch",
      "port": 9003
    }
  ]
}

Start the “Listen for Xdebug” configuration, reload your page, and your IDE should jump to the first breakpoint. Still picking an editor? I compared two good options in Zed vs Neovim on Ubuntu 24.04.

Step through code and inspect variables

Stepping through code line by line is the fastest way to catch logic errors and bottlenecks. Set a breakpoint by clicking next to a line number, trigger the request, and use these controls:

• Step over runs the current line and stops at the next one.
• Step into follows a function call so you can see what happens inside it.
• Step out finishes the current function and returns to the caller.
• Continue runs until the next breakpoint.

While paused, the variables panel shows live values, function return values and the current call path. That real-time view gives you a clear picture of how the app behaves, so you change the code based on what’s actually happening instead of guessing.

Trace exceptions back to the root cause

A stack trace is the list of function and method calls that led to an error, and it’s often the quickest route to the real bug. Read it from the top: the first frame is where the exception was thrown, and each line below shows who called it.

To log the full trace while still letting the error bubble up, wrap the risky code like this:

<?php
try {
    $order->calculateTotal();
} catch (Throwable $e) {
    error_log($e->getMessage());
    error_log($e->getTraceAsString());
    throw $e;
}

Check your PHP error log for the sequence of calls that led to the failure. In the debugger, you get the same call stack in a panel, and you can click any frame to see the variables at that point. Once you get comfortable with stack traces, complex bugs stop feeling scary.

Debugging improves code quality, too

Debugging doesn’t just fix bugs; it helps you write better code. When you catch problems during development, your codebase ends up more reliable and easier to maintain, and fewer bugs reach your users.

The time you save also matters. Less time hunting bugs means more time building features you actually enjoy working on.

Hope this saves you a few hours of var_dump() archaeology. 🐛 Next up, check out the developer essentials you need to succeed.