GridPane stores WordPress debug constants in a separate file called secure-debug.php rather than directly in wp-config.php. The wp-config.php file includes this secure-debug.php file, which contains the actual debug constant definitions.WP Debug Toolkit (WPDT) detects this automatically and adjusts its behavior to work alongside GridPane’s configuration structure. You do not need to implement any special setup; all WPDT features work on GridPane.
On a GridPane server, wp-config.php includes a line at the top that loads a separate file:
php
// Example: wp-config.php on a GridPane server
require_once '/var/www/example.com/secure-debug.php';The secure-debug.php file holds the actual define() statements for WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY. GridPane’s control panel reads and writes this file when you toggle debug settings through its dashboard. This structure prevents accidental overwrites of debug settings during WordPress updates or wp-config.php edits.
For GridPane’s own documentation on this setup, see WordPress Debug and Query Monitor and Do I Leave Secure Debug On?.
WPDT detects a GridPane environment using a three-step check in this order:
GRIDPANE PHP constant is defined and set to truesecure-debug.php exists in the same directory as wp-config.phpwp-config.php contains a reference to the string 'secure-debug.php'; that is, the include line is presentOn a real GridPane server, step three is the one that typically triggers detection, because secure-debug.php lives in a server-level directory outside the WordPress root rather than as a direct sibling to wp-config.php.
Once GridPane is detected, WPDT targets wp-config.php for all debug constant reads and writes. Because secure-debug.php is loaded via an include statement at the top of wp-config.php, its constants are already defined before WPDT’s entries are reached. To avoid triggering PHP “constant already defined” errors, WPDT writes new constants in a guarded format on GridPane environments:
php
// WPDT writes constants to wp-config.php in this format on GridPane:
if ( ! defined( 'WP_DEBUG' ) ) {
define( 'WP_DEBUG', true );
}This means GridPane’s secure-debug.php settings take precedence over WPDT’s wp-config.php entries for any constant both have defined. Constants that GridPane has not set in secure-debug.php are controlled entirely by WPDT.
All WPDT features function on GridPane without any special configuration:
WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, SAVEQUERIES) via the admin dashboard toggle, the Viewer App’s Debug Constants panel, and wp dbtk debug on/off/status via CLIdb.php drop-inUninstalling WP Debug Toolkit resets the debug settings it manages in wp-config.php, either restoring a backup of the file or removing the constants it added. On GridPane, this reset leaves WP_DEBUG enabled in wp-config.php after uninstall completes.
secure-debug.php is never touched during this process. It isn’t one of WPDT’s own files, so uninstall has no reason to remove it. This matters because GridPane’s wp-config.php depends on secure-debug.php staying in place: removing it would break the include statement and take the site offline.
⚠️ Warning: After uninstalling WP Debug Toolkit on a GridPane site, check your WP_DEBUG setting in GridPane’s dashboard. Uninstall leaves it enabled.
WPDT’s File Viewer blocks access to secure-debug.php. The file contains server-level configuration data that should not be exposed through the viewer interface. If you try to open it in the File Viewer, access will be denied. You should keep in mind that this is an intentional security behavior and not a bug.
Both GridPane’s control panel and WPDT’s admin dashboard can update debug constants. They write to separate files: GridPane writes to secure-debug.php, and WPDT writes to wp-config.php. Because secure-debug.php runs first, any constant GridPane has set there takes precedence at runtime. There is no file-level conflict, as both tools operate independently on their own. For predictable results, use one tool as the primary source of truth for debug constant values on a given site.
GridPane may store debug logs at a non-standard path. WPDT checks for a GridPane log file at /logs/debug.log, one directory level above your WordPress installation, automatically. If the log file exists there, WPDT uses it without any configuration from you.
If WPDT still does not find your log file, you will need to configure the path using one of these two options:
Admin UI: Navigate to WP Debug Toolkit › Settings › Viewer Settings › File Paths Configuration and enter the full absolute path to your log file. When you save this setting, WPDT automatically regenerates the Viewer App’s config.php without any manual setup repair process.
Constant: Define DBTK_LOG_PATH in wp-config.php. Placing it relative to the secure-debug.php include does not affect how WPDT resolves the path, since PHP constants are fully defined before any plugin code runs.
php
// wp-config.php: placement relative to the include line does not matter
define( 'DBTK_LOG_PATH', '/var/www/example.com/logs/debug.log' );When using the DBTK_LOG_PATH constant rather than the admin UI, reinstall the Viewer App afterward to sync the new path to the Viewer App’s config.php. Repairing the Viewer App does not sync the log path; repair only restores file permissions and reports status.
✅ What You Should See: After configuring your log path, the Viewer App loads your log file. If it still shows an empty viewer, confirm the path is correct and that the file exists at the specified location.
How to Automatically Enable WordPress Debug Mode – See exactly how WPDT’s debug toggle writes constants to wp-config.php on GridPane, and what the guarded format looks like in practice.
Custom Log Paths – If WPDT isn’t finding your GridPane log file automatically, start here to configure a custom path and understand the full resolution order.
Environment and Hosting Detection – Learn how WPDT identifies GridPane and other non-standard environments, and how that detection shapes file path resolution across the plugin.
