Description
Debug Manager Pro is a powerful developer tool for managing WordPress debugging without ever touching wp-config.php.
Visit the official website for more information:
https://lyzerslab.com/wordpress-products/lyzers-debug-manager-pro
Features
- Toggle Debug Constants — Enable/disable WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, SCRIPT_DEBUG, SAVEQUERIES via a modern UI.
- Emergency Recovery Mode — Access a standalone recovery dashboard to disable broken plugins, switch to a default theme, or restore a stable configuration when wp-admin is inaccessible.
- Error Collector — Capture PHP errors, group them, and store them with stack traces and timestamps.
- Log Viewer — View, search, filter, download, and clear debug.log.
- Performance Metrics — Monitor memory usage and execution time.
- Safe Mode — Restrict debug visibility to admins or specific IPs.
- Auto-Disable — Automatically turn off debug mode after a set time.
- Email Notifications — Get alerts for critical PHP errors.
- Snapshot Export — Export debug data as JSON for developers.
- Modern UI — Clean dashboard with real-time updates.
Security
- All actions require proper capability checks and nonces.
- wp-config.php is backed up before modification.
- OPcache is cleared after updates.
- Debug output is restricted from public users.
Installation
- Upload the plugin folder to /wp-content/plugins/
- Activate the plugin via the Plugins menu in WordPress
- Open Debug Manager from the admin menu
FAQ
-
Will this break my site?
-
No. All changes are reversible and backups are created before modifications.
-
Can I recover a broken site?
-
Yes. Use the Emergency Recovery Mode to regain admin access and disable faulty plugins or themes.
Reviews
There are no reviews for this plugin.
Contributors & Developers
“Debug Manager Pro” is open source software. The following people have contributed to this plugin.
ContributorsTranslate “Debug Manager Pro” into your language.
Interested in development?
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
Changelog
1.2.4
- Fix: Replaced direct CSS output with the WordPress style enqueue system.
- Fix: Removed the error_reporting() call.
- Fix: Removed all automatic wp-config.php modifications. Configuration is now read-only with manual setup instructions.
- Fix: Removed automatic debug constant changes during deactivation and auto-disable.
- Fix: Updated the admin UI and AJAX responses to reflect the new manual configuration workflow.
- Fix: Cleaned up deprecated configuration and scheduling logic.
1.2.3
- Fix: Replaced inline
<style>blocks in RecoveryMode.php with<link rel="stylesheet">references to the plugin’s static CSS files — avoids embedding CSS via PHP string output entirely, and doesn’t depend on any WordPress hook having fired (needed since these pages can render from a shutdown handler before WP_Styles is even loaded) - Fix: Corrected a
phpcs:ignoresniff code in ErrorCollector.php that referenced a non-existent rule and wasn’t actually suppressing the intended warning for the documented zero-argumenterror_reporting()read - Fix:
wp-config.phpbackup files created before each write in WpConfig.php are now deleted immediately after a successful write instead of accumulating indefinitely in the web root; backup creation failure now aborts the write instead of proceeding without a rollback copy
1.2.2
- Fix: Wired
apply_php_limits()intoSnapshot::generate()andLogViewer::raw_content()— the memory limit / max execution time values configured in Settings are now actually applied, scoped only to those two heavy operations and never called globally oninit/admin_init - Fix: Confirmed and re-verified Contributors field, Plugin URI reachability, and sanitization of
error_types_to_collectin Ajax.php per WordPress.org plugin review feedback
1.2.1
- Fix: Added direct file access guard (
if ( ! defined( 'ABSPATH' ) ) { exit; }) to ErrorCollector.php, Installer.php, and Timeline.php - Fix: Frontend error reporter in Ajax.php now respects the
log_request_contextprivacy opt-in before storing IP address, request URL, and user ID — consistent with backend ErrorCollector behaviour - Fix: Replaced raw
$_SERVER['REMOTE_ADDR']read inreport_frontend_error()withErrorCollector::resolve_client_ip()for proxy-aware, privacy-gated IP resolution - Fix: Replaced
md5()withErrorCollector::generate_hash()inreport_frontend_error()for consistent error fingerprinting and PHPCS compliance
1.2.0
- Fix: “You do not have sufficient permissions” error when accessing the recovery URL from a browser with no active WordPress session. The capability check now uses is_user_logged_in() && ! current_user_can(…) so unauthenticated recovery sessions are not incorrectly blocked — the recovery key remains valid as a bearer token for emergency access, matching the behaviour of WordPress core’s own recovery mode.
1.1.9
- Fix: Replaced inline output in RecoveryMode.php with proper CSS asset handling using external stylesheet files (admin/css/recovery-prompt.css, admin/css/recovery-dashboard.css) and loaded them via safe tags in a controlled recovery context where wp_enqueue_style() is unavailable (shutdown/wp_die environment)
- Fix: Improved asset handling strategy for recovery screens to ensure compatibility with WordPress coding standards while preserving functionality during fatal-error states where normal enqueue hooks are not available
- Fix: Updated recovery UI rendering to avoid inline CSS output directly inside PHP templates and ensured all style references are safely escaped using esc_url() before output
- Fix: Removed misuse concerns around error_reporting() by explicitly documenting and constraining its usage to the zero-argument read-only form only, ensuring it is used strictly for checking the current error reporting bitmask and NOT modifying runtime configuration in ErrorCollector.php
- Fix: Confirmed no production-level modification of global error reporting state; behaviour now fully aligned with PHP set_error_handler() expectations and @-suppression compatibility
- Fix: Hardened input handling in RecoveryMode.php by ensuring all $_GET and $_POST values used for recovery actions are processed only through validated nonce checks combined with current_user_can() capability verification
- Fix: Strengthened recovery action security flow to prevent unauthorized execution by ensuring recovery key alone cannot grant destructive plugin/theme actions without authentication context
- Fix: Improved separation between recovery dashboard access and privileged recovery actions to ensure capability checks are enforced independently of recovery key presence
- Fix: Enhanced general input validation and sanitization across recovery request handlers to ensure all user-supplied values are safely escaped using WordPress sanitization APIs (sanitize_text_field, wp_unslash, esc_url_raw, absint)
1.1.8
- Fix: Moved inline CSS out of PHP string returns and into dedicated asset files (assets/css/recovery-prompt.css, assets/css/recovery-dashboard.css) in RecoveryMode.php; loaded from disk via file_get_contents() and escaped with wp_strip_all_tags() — wp_enqueue_style() is unavailable in the shutdown/wp_die context where these pages render
- Fix: Escaped CSS output with wp_strip_all_tags() at the echo site in both render_recovery_prompt() and render_dashboard() in RecoveryMode.php
- Fix: Expanded inline comment on error_reporting() in ErrorCollector.php to clarify it is the zero-argument read-only form used to honour the @ suppression operator per PHP set_error_handler() documentation, not a production error level change
1.1.7
- Fix: Updated debug.log path to use trailingslashit( WP_CONTENT_DIR ) in LogViewer.php
- Fix: Added explanatory comments to dirname( ABSPATH ) fallback in WpConfig.php to clarify intentional wp-load.php parity
- Fix: Added phpcs:ignore comments with explanations to inline CSS output in RecoveryMode.php (rendered in shutdown context where wp_enqueue is unavailable)
- Fix: Clarified that error_reporting() in ErrorCollector.php is a read-only call to honour the @ suppression operator, not a production error level change
- Fix: Replaced json_encode() with wp_json_encode() in Timeline.php
- Fix: Added wp_unslash() to all $_SERVER input reads before sanitization
- Fix: Extracted interpolated table name SQL strings to suppress InterpolatedNotPrepared sniff correctly in ErrorCollector.php
- Fix: Added $wpdb->tables( ‘all’ ) whitelist check before all direct database queries
- Fix: Renamed unprefixed variables in uninstall.php to use wpdmp_ prefix
- Fix: Replaced DROP TABLE interpolated query with esc_sql() + backtick pattern in uninstall.php
1.1.6
- Fixed unescaped $plugin_count variable passed to printf() in active plugins badge
- Wrapped printf() integer argument in absint() at call site for PHPCS static analysis compliance
1.1.5
- Fixed recovery dashboard CSS not rendering when accessed via recovery URL
- Removed broken wp_register_style() approach that silently dropped inline CSS on false-src handles
- Replaced dual primary/fallback style branching logic with clean private CSS getter methods
- Fixed unescaped bloginfo( ‘charset’ ) and bloginfo( ‘language’ ) output in recovery pages
- Added missing lang attribute to HTML element on both recovery prompt and dashboard pages
- Added viewport meta tag to both recovery pages for mobile compatibility
- Replaced all hardcoded strings with i18n-compatible esc_html_e() and esc_html__() calls
- Added translators comment to parameterised plugin disable button label
- Fixed count() output rendered without absint() escaping in plugin badge
- Removed all inline style attributes from HTML and moved to named CSS classes
- Changed handle_actions() visibility from public to private
- Changed render_dashboard() visibility from public to private
- Added PHPDoc visibility comments to public callbacks explaining why they must remain public
- Fixed phpcs:enable placement in handle_actions() to correctly close the full suppressed scope
- Corrected Yoda condition in disable_plugin() array search check
- Added twentytwentyfive to default theme fallback list in revert_theme()
- Added full PHPDoc blocks to all methods
1.1.4
- Fixed duplicate shutdown handler conflict in RecoveryMode class
- Improved safe handling of fatal error recovery rendering flow
- Fixed early WordPress loading issues in nonce and style rendering
- Strengthened fallback CSS rendering when WP style API is unavailable
- Improved database error detection handling in wpdb recovery path
- Hardened plugin activation tracking and stable state storage logic
1.1.3
- Fixed wp_enqueue_style issues in RecoveryMode files
- Fixed Ajax file error_types_to_collect issues.
- Fixed Plugin file ini_set issues.
- Fixed Read me txt file contributor issues
1.1.2
- Fixed plugin check warnings in admin, recovery mode, and AJAX handlers
1.1.1
- Fixed plugin check warnings across admin, recovery, and AJAX handlers
- Fixed security issues by improving nonce verification, input unslashing/sanitization, and output escaping
- Added direct file access protection guards to plugin include files
- Replaced unsafe redirect usage with safe WordPress redirect handling
- Updated translation/language files for the latest release
1.1.0
- Fixed WordPress.org compatibility issues
- Updated headers and version consistency
- Improved recovery mode stability
1.0.0
- Initial release