Debugging a WordPress site has always been a bit of a rite of passage: you sprinkle var_dump() and error_log() calls around the codebase, refresh the page a dozen times, and hope the bug reveals itself before your patience runs out. With the latest update to WordPress Studio, Automattic is very clearly trying to move developers beyond that era by baking proper, modern debugging into its local development story.

WordPress Studio now ships with two big quality-of-life upgrades for developers building locally: native Xdebug support and a streamlined way to work with WordPress’ debug logs. On paper, that might sound like a small tweak, but in practice, it changes how you approach tracking down issues in themes, plugins, and even core itself.​

Let’s start with Xdebug. If you’ve ever done serious PHP work, you’ve almost certainly heard of it—it’s the de‑facto standard extension for step‑through debugging. Instead of turning your code into a crime scene full of var_dump() calls, Xdebug lets you pause execution at specific lines, step through the code line by line, and inspect variables in real time, all from inside your editor.

In Studio, Xdebug is wired into the environment that powers your local WordPress instance, which runs on the WebAssembly-based PHP used by WordPress Playground. The nice part is that there’s nothing extra to install or tweak at the OS level; you just flip a couple of switches in the app. From a workflow perspective, that’s a big deal for developers who don’t want to fight with PHP extensions or custom Docker configs just to get a breakpoint working.

Enabling Xdebug is basically a one-time setup per site. You pick the site in Studio, hop into Settings, hit “Edit site,” jump over to the Debugging tab, and check the “Enable Xdebug” box before saving. Studio automatically restarts that local site with Xdebug active in the background. After that, it’s about connecting your IDE—Studio listens on port 9003, so you point your editor’s Xdebug configuration to that port, set your breakpoints, and start browsing the site like you normally would.​

There are a couple of trade-offs worth knowing before you flip that toggle and leave it on forever. First, Xdebug can only be active for a single site at a time inside Studio, so if you’re juggling multiple local installs, you’ll need to choose which one gets the debugger. Studio actually helps here with a little bug icon in the sidebar to show which site currently has Xdebug enabled. Second, as any PHP developer will tell you, Xdebug does come with a performance cost—things slow down noticeably with it turned on, so you’ll generally want it enabled only when you’re actively debugging.​

Of course, not every problem calls for a full-blown step debugger. Sometimes you just want to see what WordPress is complaining about in the background. That’s where the second new capability comes in: much easier access to debug logs.

Instead of manually editing wp-config.php to define WP_DEBUG and WP_DEBUG_LOG, Studio now gives you a simple “Enable debug log” toggle in the same Debugging tab. Flip it on, hit Save, and Studio sets the necessary constants for you, then starts writing errors, warnings, and notices to wp-content/debug.log inside that site. Crucially, you also get an “Open log file” link right from the Settings UI, so you’re not digging through file paths or hunting around in your project tree every time something goes wrong.​

That alone makes log-driven debugging feel less like a chore. You can still pepper in your own error_log() calls for quick sanity checks—for example, dumping the contents of a variable during a tricky hook or inside a REST API callback—and know those messages will land in a predictable, one-click-away file. WordPress Studio essentially turns log-based debugging into a first-class workflow instead of an afterthought.​

Interestingly, the team also leans into how developers are actually working today by calling out AI-assisted debugging as part of this story. Once your debug log is active, you can feed wp-content/debug.log directly into AI coding agents like Claude Code, Cursor, or other IDE copilots and let them help interpret the errors, propose fixes, or even generate patches. In a world where many developers already run an AI assistant alongside their editor, this tightens the feedback loop between what WordPress is logging and how quickly you can act on it.

For those times when you want errors right in your face, Studio also exposes a “Show errors in browser” option. Under the hood, this controls WP_DEBUG_DISPLAY and determines whether PHP errors appear inline in the HTML output or stay tucked away in the log. It’s the kind of toggle that’s perfect during local development, where you want to see fatal errors, warnings, and notices directly on the page so you can iterate quickly.​

That said, the team is careful to flag the security and UX implications: showing errors in the browser can leak sensitive information like full file paths or snippets of internal logic, which is not something you want on a site shared with clients or stakeholders. The intended pattern is to use it in combination with the debug log for your own machine, then keep it off anywhere the environment might be visible to others.​

Put together, these two capabilities—Xdebug support and richer debug log controls—fill in some important gaps in WordPress Studio’s local development story. The debug log gives you a lightweight, always-on way to catch and review what PHP is complaining about in real time. Xdebug then steps in when you need to go deeper, pause execution, and really understand how data is flowing through your plugins, themes, or even core functions.

For developers who’ve been on the fence about trying Studio, this update nudges it closer to being a serious “all-in-one” environment for building WordPress sites locally, especially if you’ve been juggling separate tools for hosting, debugging, and log management. And if you’re already using Studio, these new toggles are the kind of features that don’t look flashy in screenshots, but quietly shave minutes (or hours) off the time it takes to find and fix the next weird edge case in your code.