Debugging in WordPress Studio

Debug log

Sometimes you just need to see what WordPress is logging. WordPress Studio makes that easy with a dedicated debug log toggle that configures WP_DEBUG and WP_DEBUG_LOG for your site automatically.

Enabling the debug log

1. Open the site’s settings: choose Settings from the site menu (click the Site menu button, which shows the site’s name, at the top left of the site’s header, or right-click the site in the sidebar).
2. Select the Debug page.
3. Turn on Debug log.
4. Click Save at the top of the dialog.

When the debug log is enabled, your site will capture PHP errors, notices, and warnings to wp-content/debug.log. Once the file exists, an Open log file button appears on the Debug page, so you can jump directly to the file without hunting for its path.

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 ) );

Show errors in browser

The Debug page also includes a Show errors in browser toggle, which sets WP_DEBUG_DISPLAY. When enabled, PHP errors and warnings are printed inline in the page output rather than captured silently in the log file — useful when you want immediate feedback during active development.

Keep in mind:

• Show errors in browser works best alongside the debug log, not as a replacement for it.
• Turn it off on any site you share with clients — it can expose internal path information or other implementation details in the page output.

Script debug and environment type

The Debug page also includes:

• Script debugging, which sets SCRIPT_DEBUG. WordPress then loads the development versions of core CSS and JavaScript instead of the minified files, which is useful for reading React errors in the block editor.
• Environment, which sets the value returned by wp_get_environment_type(): Local (the default), Development, Staging, or Production. Plugins and themes use it to vary their behavior between environments.

Using AI agents to interpret debug logs

Once your debug log is active, you can point an AI agent directly at it. Tell your agent — whether you’re using Claude Code, Cursor, or another tool — 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 without breaking your flow.

Database access with phpMyAdmin

Inspecting or editing your local database used to mean a separate tool and a separate setup. WordPress Studio includes phpMyAdmin access directly in the app — so you can query tables, check data, and debug schema issues without leaving the app or configuring anything.

To open phpMyAdmin for a running site, select the site and use either of these:

• Click New tab (+) above the site preview and choose Database, or choose Tools → Database from the site menu. phpMyAdmin opens in a tab of the preview.
• Choose Open in → phpMyAdmin from the site menu to open it in your browser.

Step-through debugging with Xdebug

For deeper investigation, WordPress Studio includes Xdebug support. Instead of scattering debug output through your code, you can set breakpoints, step through execution line by line, and inspect variables in real time — all from your editor.

Xdebug is available for all WordPress Studio sites and requires no system-level installation. When a request runs, Xdebug connects out to your editor or IDE on port 9003, so your editor needs to be listening for debug connections on that port.

For full setup instructions, including how to connect VS Code and PhpStorm, see Xdebug in WordPress Studio.