Tracking down bugs in WordPress development often feels like looking for a needle in a haystack. Especially when you’re relying on var_dump() calls and manually scanning error logs.
WordPress Studio has two new debugging capabilities that make this process faster and more intuitive: Xdebug support and debug log access.
Xdebug is the gold-standard PHP debugging extension. Instead of scattering debug output throughout your code, you can set breakpoints, step through execution line-by-line, and inspect variables in real time — all from your editor.
This is now available for all Studio users and is powered by WordPress Playground’s WebAssembly version of PHP, which means there’s nothing extra to install or configure at the system level.
Studio will restart the site automatically with Xdebug active.

A couple of things worth keeping in mind:
Once Xdebug is enabled, you can connect your editor and start debugging to find the source of any issues — plugins, themes, or WordPress core. Studio listens for debug connections on port 9003.
For the full setup guide, see the Xdebug in Studio documentation.
Sometimes a full step-debugger is more than you need when you just want to see what WordPress is logging.
Studio now makes that much easier with a dedicated debug log toggle, which sets WP_DEBUG and WP_DEBUG_LOG for your sites automatically.
When the debug log is enabled, your local site will capture PHP errors, notices, and warnings to a log file at wp-content/debug.log. You’ll then see an Open log file link appear in the Settings tab, which opens the log directly — no need to hunt down the file path manually.
You can also write your own messages to the log using PHP’s error_log() function:
error_log( 'My value: ' . print_r( $my_variable, true ) );
This is especially handy when you need a quick look at what’s happening during a plugin activation, a hook callback, or a REST API request — without setting up a full debugging session.
Once your debug log is capturing errors and warnings, you can bring an AI agent directly into your debugging workflow. Instead of manually reading through log output and cross-referencing documentation, point your agent at the log and let it do the heavy lifting.
Whether you’re using Claude Code, Cursor, or Codex, the setup is the same: tell your agent that error logs are available at wp-content/debug.log. From there, it can read the output, identify what’s going wrong, and suggest fixes, all without breaking your flow.
The Debugging tab also includes a “Show errors in browser” toggle, which sets WP_DEBUG_DISPLAY and controls whether PHP errors are printed directly on the page rather than silently captured in the log.
When enabled, fatal errors, warnings, and notices appear inline in the HTML output — useful during active development so you don’t have to keep switching to the log file.
One important note: “Show errors in browser” is best used alongside the debug log, not as a replacement for it. It’s great for quick iteration in your own local environment, but you’ll want to keep it off on any site that’s shared with clients — it can expose sensitive path information or internal logic in the page output.
These two features address different parts of your local debugging workflow:
Together, they make Studio a more capable environment for developing and troubleshooting WordPress sites locally.
If you haven’t tried WordPress Studio yet, now is a great time to get started.
Original Post https://wordpress.com/blog/2026/03/11/wordpress-studio-debugging/






