Debug Manager Pro

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:ignore sniff code in ErrorCollector.php that referenced a non-existent rule and wasn’t actually suppressing the intended warning for the documented zero-argument error_reporting() read
• Fix: wp-config.php backup 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() into Snapshot::generate() and LogViewer::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 on init/admin_init
• Fix: Confirmed and re-verified Contributors field, Plugin URI reachability, and sanitization of error_types_to_collect in 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_context privacy opt-in before storing IP address, request URL, and user ID — consistent with backend ErrorCollector behaviour
• Fix: Replaced raw $_SERVER['REMOTE_ADDR'] read in report_frontend_error() with ErrorCollector::resolve_client_ip() for proxy-aware, privacy-gated IP resolution
• Fix: Replaced md5() with ErrorCollector::generate_hash() in report_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)