The WP Debug Toolkit (WPDT) Viewer App is a standalone PHP application installed separately from the WordPress plugin. It does not bootstrap WordPress, rather, it runs from its own directory with its own configuration and authentication, and stays accessible when WordPress is fully down. Developers can read error logs and trigger Crash Recovery after a fatal error, white screen, or database crash, without FTP or SSH access.
The Viewer App is a self-contained PHP application that lives in its own directory on your server and is accessible through a dedicated URL; for example, example.com/wpdebugtoolkit/.
It is not part of the WPDT WordPress plugin. You install it separately using the installer that WPDT provides. Once installed, it runs with its own configuration file, authentication layer, API, and PHP execution context, outside the WordPress request cycle entirely.
Standard WordPress diagnostic tools only function when WordPress functions. The Viewer App breaks that constraint. This article explains why that architecture matters and what it enables.
The Viewer App’s crash-resilience follows from one architectural decision: it shares no runtime dependencies with WordPress.
Before any WordPress plugin can render output, WordPress must complete its bootstrap sequence: opening the database connection, executing wp-settings.php, and initializing active plugins.
The catch is that you need a diagnostic tool the most when that sequence cannot complete. A plugin conflict, a fatal PHP error, or a database failure can all halt bootstrapping mid-process.
When that happens, every tool that depends on WordPress also fails to load. Developers are left with a blank browser window and no path forward except FTP or SSH to read raw server logs on the server.
WPDT resolves this with a two-part design. WordPress hosts the control side: the admin installer, REST API endpoints, and license management.
The Viewer App lives in a separate directory with its own files: index.php as the entry point, api.php for its standalone REST API, config.php for configuration, auth.php for authentication, rate-limiter.php for brute-force protection, settings-manager.php for runtime settings, and an assets/ directory containing the application’s built JavaScript and CSS. Neither half requires the other to be online.
Authentication is entirely file-based at runtime. When you set or change the viewer password, WPDT reads the password hash from the WordPress database and bakes it directly into auth.php as a PHP value, setting the file to 0600 permissions with exclusive write locking.
From that point forward, the Viewer App reads auth.php directly and never touches the WordPress database to verify a login. The HMAC signing key for sessions is written into config.php at install time through the same principle: the value is baked into a file on disk, with no database access required at runtime. Both files exist on disk independent of WordPress.
The Viewer App remains fully accessible in common crash scenarios, including a White Screen of Death (WordPress fails to return any output), a fatal PHP error (an unrecoverable error terminates the WordPress PHP process before bootstrap completes), and a database crash (WordPress cannot connect to the database at all).
A fatal PHP error in a WordPress plugin terminates that specific request. A new request to /wpdebugtoolkit/ starts a fresh PHP process that loads only the viewer’s own files with no WordPress code involved. A database crash leaves the viewer unaffected because its config, auth, and rate-limiting all run from files, not from the WordPress database.
WPDT writes query logs to disk as encrypted log files, not to the WordPress database. The decryption key is stored in the viewer’s config.php, so the Viewer App can read them directly even when the database is down.
The recovery path this enables is concrete. When a fatal error occurs, WPDT sends a notification email containing a direct link to the Viewer App. You open the link, authenticate with your standalone viewer password, read the error log, and use Crash Recovery to deactivate the offending plugin or theme. You do not need any FTP, SSH, or server credentials for this.
✅Key Guarantees
auth.php file at install time and rewritten on every password change; as such, a database crash does not prevent login.config.php, making the logs readable even when the database is down.| Term | What It Means |
|---|---|
| Standalone viewer | A self-contained PHP application installed separately from the WPDT WordPress plugin. It runs from its own directory with its own files and does not load WordPress to operate. |
| WordPress bootstrap | The startup sequence WordPress runs on every request: opening the database connection, executing wp-settings.php, and initializing active plugins. Any tool that depends on WordPress cannot display data until this sequence completes. |
| Dependency paradox | The condition where diagnostic tools that require WordPress to function fail at the same moment WordPress fails. The Viewer App’s separate installation is the direct solution to this problem. |
| File-based authentication | The Viewer App’s password hash is written into auth.php at install time and rewritten on every password change, using exclusive file locking. Login verification reads the file, so no database query is involved. |
| Encrypted log files | WPDT writes query logs to disk as encrypted .log files rather than to the WordPress database. The decryption key is baked into the viewer’s config.php, so the logs remain accessible during a database outage. |
Yes. The Viewer App does not load through WordPress. Its authentication, configuration, and rate limiting all run from files on disk. A White Screen of Death, a fatal PHP error, and a database crash all leave the Viewer App accessible at its direct URL. You can read WordPress error logs and trigger Crash Recovery without any WordPress access. PHP must still be running on the server, but a WordPress crash does not affect the viewer’s separate PHP execution context.
Yes. The WordPress plugin and the Viewer App are two separate installations. The plugin provides the installer, settings, REST API, and license management. The Viewer App is a separate PHP application that installs into its own directory on your server. Its independence from WordPress requires it to live entirely outside the WordPress plugin architecture. See Setting Up the Viewer App for the installation walkthrough.
Viewer Architecture – Go deeper on how the auth file, config, and rate limiter fit together, and why that structure keeps the viewer running when WordPress cannot bootstrap.
Setting Up the Viewer App – Complete the separate install that gives the viewer its own directory, auth file, and password. This is the step that makes everything described here actually work.
How to Recover from a Site Crash Using the Standalone Viewer – Put the architecture into practice: open the viewer after a fatal error, read what broke, and use Crash Recovery to restore site access without touching the server.
