The WP Debug Toolkit (WPDT) standalone error logs Viewer App is a separate web application that deploys to your site’s web root by default at /wpdebugtoolkit/. It reads error logs and debug data from the server filesystem using standard PHP file functions. No WordPress code runs at any point in that flow. This means the viewer remains accessible when WordPress is in a fatal error state, on a white screen, or in a database crash, because none of those conditions affects the PHP and web server stack that the Viewer runs on.
The Viewer is not a page inside wp-admin. It is a standalone PHP application installed separately in your site’s web root, with its own execution context, authentication system, and data storage. When you navigate to the Viewer URL, the web server serves it as it would any other directory. The WordPress plugin is not involved in that request.
Any diagnostic tool that depends on WordPress inherits its failure modes. When WordPress cannot load, either because a plugin conflict terminates the bootstrap sequence, the database is unreachable, or a fatal error fires before wp-settings.php completes, those tools fail too.
WPDT’s Viewer is designed so that the condition in which it is most needed cannot be the one that prevents it from loading.
The Viewer’s WordPress independence is not a configuration option but rather a structural constraint enforced at every layer of the application. Each component in the Viewer directory has a specific role that contributes to that independence.
WPDT deploys the Viewer to the web root as its own directory during setup. The installed directory contains PHP files; most copied from the plugin, two generated during setup, plus a compiled React asset bundle:
/wpdebugtoolkit/ # default install directory (customizable)
├── index.php # entry point; serves the React application to the browser
├── api.php # standalone PHP API; handles all data requests from the React app
├── config.php # generated at setup; stores log path, query-log encryption key, bearer-token HMAC key, module flags
├── auth.php # generated at setup; stores the viewer password hash
├── rate-limiter.php # SQLite-based brute-force protection with JSON fallback
├── settings-manager.php # SQLite-based viewer preferences, independent of wp_options
└── assets/ # compiled React JavaScript and CSS bundlesThe web server and PHP are the only runtime dependencies. WordPress does not need to be installed, running, or reachable for the Viewer to respond.
Every login attempt passes through two gatekeepers before api.php verifies credentials. rate-limiter.php checks the requesting IP against a SQLite record of failed login attempts and enforces progressive lockout delays, from five seconds after the first failure up to 24 hours after repeated violations. When PDO SQLite is unavailable on the server, the rate limiter falls back to JSON-based file tracking.
Once rate limiting clears, api.php reads auth.php with a standard PHP include and verifies the submitted password against the stored bcrypt hash using password_verify(). Already-authenticated requests bypass this path entirely and are validated against the active session instead. The hash lives in auth.php on the server filesystem.
The WordPress database is not involved in any part of that check, which matters because the database being unreachable is one of the primary scenarios where the Viewer is needed most.
The React application running in the browser sends HTTP requests to api.php. The API reads files from the server filesystem and returns JSON responses. There’s no WordPress code that executes at any point in this flow.
php
// api.php — standalone PHP, no WordPress dependencies
// Does NOT include:
// require_once 'wp-load.php'; // WordPress bootstrap
// global $wpdb; // WordPress database object
// get_option(), add_action() // WordPress functions
//
// Uses instead:
// file_get_contents(), fopen(), scandir() // standard PHP onlyBeyond error log reading and parsing, api.php handles query log retrieval, debug constant management in wp-config.php, crash recovery operations, including enabling and disabling individual plugins and themes, viewer settings management, and incremental log polling; returning new entries since a cursor position rather than streaming a persistent connection. The wp-config.php write path in api.php does not include the atomic write, automatic backup, or rollback protections that the WordPress plugin’s Debug Management feature provides.
All of these operations use standard PHP filesystem and session functions. None of them requires a database connection.
The Viewer and the WordPress plugin form a dual-layer architecture, in which each layer operates independently when the other is unavailable.
The WordPress plugin side manages the Viewer via a set of REST endpoints in the wpdebugtoolkit/v1 namespace, covering: viewer installation, password updates, IP binding configuration, and rate-limit settings. These endpoints are how changes made in wp-admin flow into the Viewer’s configuration files on disk.
The Viewer side runs its own PHP stack and continues operating when WordPress goes down. Neither layer requires the other for its core function: the Viewer serves log data during WordPress crash scenarios, and the WordPress plugin manages configuration during normal operation, regardless of whether the Viewer has been deployed yet.
✅ Key Guarantees
auth.php on the server filesystem. | Component / Term | What It Is and Why It Matters |
|---|---|
index.php | Entry point file in the Viewer directory. The web server executes this to deliver the React application to the browser. It is the only file a visitor’s browser requests when navigating to the viewer URL. |
api.php | Standalone PHP API. Handles all data requests from the React application: reading and parsing error logs, serving query log data, managing debug constants in wp-config.php, running crash recovery operations, and managing viewer settings. Uses only standard PHP file functions with no need for WordPress code at any point. |
config.php | Generated during Viewer setup. Stores the configured log file path (with fallback resolution), a query log encryption key, an HMAC signing key for bearer-token auth, licensed module flags, and trusted proxy IPs. WPDT regenerates this file when you change the Viewer URL, log path, or reinstall the Viewer. |
auth.php | Generated during Viewer setup. Stores the Viewer password hash (bcrypt) and whether password protection is enabled. Read by api.php directly from the filesystem. The WordPress database plays no role in any Viewer authentication check. WPDT sets this file to 0600 permissions, more restrictive than the 0644 used for all other viewer files, to limit read access to the web server process only. |
rate-limiter.php | SQLite-based brute-force protection. Tracks failed login attempts per IP address and enforces progressive lockout delays from five seconds up to 24 hours. Falls back to JSON file tracking when PDO SQLite is unavailable on the server. |
settings-manager.php | SQLite-based store for Viewer preferences, including theme (dark mode), auto-refresh settings, slow query threshold, query log display limits, and IP binding behavior. Stored in a cache directory on the filesystem, independent of the WordPress options table. |
| Dual-layer architecture | The design principle that separates the Viewer (which runs standalone) from the WordPress plugin (which manages configuration via REST endpoints). Each layer operates independently when the other is unavailable; the viewer during WordPress crashes, and the plugin during periods before the Viewer is deployed. |
| WordPress independence | The constraint that no file in the Viewer’s request path may load WordPress, call WordPress functions, or connect to the WordPress database. This structural guarantee is why the Viewer remains accessible during the failure scenarios where it is needed most. |
No. api.php does not initiate any connection to the database. auth.php and settings-manager.php use filesystem and SQLite storage, respectively. The Viewer reads all log data from files. No WordPress database call occurs at any point in the Viewer’s request handling, including during login.
The WordPress plugin manages Viewer installation, password configuration, and the REST API endpoints that push configuration changes to the viewer’s files. Deactivating the plugin leaves the Viewer files in place, and the Viewer continues to serve log data and authenticate requests normally. However, you cannot apply configuration changes like password updates, IP binding changes, or rate limit adjustments until you reactivate the plugin.
No, not with a single install. config.php stores the log path for the specific WordPress installation it was configured against during viewer setup. A single viewer instance is scoped to one site. To monitor multiple installations, each site needs its own viewer install in its own web root directory.
Viewer App Overview – Understand why a WordPress-dependent diagnostic tool fails the moment you need it most, and what the standalone architecture does differently.
Error Logs Viewer Authentication and Security – Dig into the full security model: progressive rate limiting, session management, IP binding, and the bearer-token fallback for cache-stripping environments.
Managing the WordPress Error Logs Viewer App – Install, remove, repair, or redeploy the viewer files in your web root without touching the WordPress plugin settings.
