Viewer architecture

The WP Debug Toolkit (WPDT) standalone viewer is an independent web application that reads your WordPress error logs and debug data without loading WordPress. This design exists for one reason: WordPress plugins cannot help you when WordPress is the thing that is broken.

Why standalone

A traditional WordPress admin plugin requires WordPress to be running. If your site hits a fatal error, a white screen, or a database connection failure, an admin-based log viewer goes down with it. The standalone viewer avoids this problem entirely by operating outside of WordPress.

The viewer is deployed to your site’s web root as its own directory (default: /wpdebugtoolkit/). It has its own PHP API, its own authentication system, and its own settings storage. None of these depend on WordPress being functional. If the web server is running and PHP can execute, the viewer works.

Technical components

The viewer directory contains the following components:

React application

The front-end is a compiled React app (HTML, CSS, JavaScript) that runs in the browser. It provides the log viewer interface, Query Viewer, crash recovery panel, and settings. The React app makes requests to api.php for all data — it never contacts WordPress directly.

api.php

The standalone PHP API. Handles all data operations: reading log files, parsing error entries, managing debug constants in wp-config.php, listing plugins and themes for crash recovery, and managing viewer settings.

This file uses plain PHP only. It does not include wp-load.php, does not call any WordPress functions, and does not connect to the WordPress database. All file operations use standard PHP functions (file_get_contents, fopen, scandir, etc.).

config.php

Generated during viewer setup. Stores the paths WPDT needs to locate your WordPress installation:

• Path to debug.log (or your custom log path)
• Path to wp-config.php
• Path to wp-content/
• Viewer directory name

When you change log paths or reinstall the viewer, config.php is regenerated with the updated values.

auth.php

Contains the password hash for viewer authentication. The password is set during viewer setup and stored as a PHP password hash — not in the WordPress database. This keeps authentication functional even when the database is down.

rate-limiter.php

SQLite-based brute-force protection. Tracks failed login attempts per IP address and enforces progressive lockout delays. Falls back to file-based rate limiting when the PDO SQLite extension is unavailable. See Viewer authentication and security.

settings-manager.php

SQLite-based settings storage for the viewer. Stores viewer preferences (theme, auto-refresh interval, slow query threshold, etc.) independently of the WordPress options table.

Data flow

The React app sends HTTP requests to api.php. The API reads files from the filesystem and returns JSON responses. No WordPress code executes at any point in this flow. Authentication and rate limiting are handled by auth.php and rate-limiter.php before any data operation proceeds.