WordPress Studio shipped an update with Xdebug support and native debug log access. Until now, tracking down a race condition or a hook that quietly never fired meant scattering var_dump() calls around and reloading the page until something useful showed up.
I assumed a lightweight environment like this would always mean tailing logs by hand. Studio runs on WordPress Playground’s WebAssembly build of PHP, and the team has wired the debugger straight into it, so you never open a php.ini file yourself.
Enabling WordPress Studio Xdebug and debug logs
With a breakpoint you pause execution and read every variable in the current stack, instead of spraying output into the page and breaking the layout. That gap matters most on a WooCommerce checkout flow or a REST API endpoint, where there is no browser output to look at in the first place.
To switch on WordPress Studio Xdebug:
- Open your site in Studio and head to the Settings tab.
- Click Edit site and navigate to the Debugging tab.
- Check Enable Xdebug. The site restarts on its own with the extension loaded.
One catch: Xdebug runs on a single site at a time. Studio listens on port 9003, so point your VS Code or PhpStorm listener at that. I covered the rest of the automation story in the WordPress Studio CLI updates.
Getting at the dedicated debug log
Often you do not need a step debugger at all. You need to know why one function never runs. Studio has a “Dedicated Debug Log” toggle for that, and flipping it sets the WP_DEBUG and WP_DEBUG_LOG constants for you, so errors and warnings land in wp-content/debug.log.
You do not have to go hunting for the file either. There is an Open log file link in the UI. I lean on this while refactoring, when I want to see what a hook is actually being handed:
<?php
/**
* Debugging a filter hook payload in WordPress Studio.
*/
add_filter( 'woocommerce_add_to_cart_validation', 'bbioon_debug_cart_validation', 10, 2 );
function bbioon_debug_cart_validation( $passed, $product_id ) {
// Quick log to see what's actually coming through
error_log( 'Checking validation for Product ID: ' . $product_id );
return $passed;
}Pointing an AI agent at the log
The log also opens up a workflow that used to be clumsy: hand it to an agent. In Cursor or Claude Code, tell it to watch wp-content/debug.log and suggest a fix for any fatal error it sees. The agent reads the stack trace so you do not have to.
If your team’s environments keep drifting apart, WordPress Blueprints can pin these debugging settings so everyone gets the same setup.
If this kind of setup work is eating your dev hours, hand it to me. I have been building on WordPress since the 4.x days.
Worth the small speed hit
These two additions put Studio in the same bracket as the heavier local stacks for real work. Xdebug does slow site execution down a little, and I will take that over guessing why a Transient will not clear or why a WP-CLI command dies without a word. The official Studio Xdebug documentation has the rest of the details.
