Bob Jones

RHJ4 Diagnostics captures diagnostic messages written in PHP and conditionally directs them to various different logging functions. The plugin can be enabled or disabled during page execution, and it can intercept and handle various classes of PHP errors, e.g. E_ERROR & ~E_NOTICE. The documentation includes numerous usage examples.
Diagnostics works closely with RHJ4 Notifications. Each uses functionality in the other plugin.
<h3>Usage</h3>
<h3>The Problem</h3>
Using trace statements is my preferred method of debugging when I am not 
exactly sure where the bug is coming from. A common method for implementing 
tracing is to use the PHP error_log function which writes a line of text 
into a specific file that is identified in the PHP.ini configuration file.
This method is simple and effective, but there are several problems that come 
along with it:
<ol>
<li>You have to go back through your code later and remove the error_log calls 
or they will slow the program down and fill the error log with what are now 
useless messages.</li>
<li>The log may also contain undesired “noise” in the form of PHP messages and 
stack dumps. Many of these you can control using the error_reporting (level) 
function, but some of these messages simply won’t go away.</li>
<li>Depending on your configuration, you may not have access to PHP.ini and you 
may not be able to see the generated log because you don’t have access 
rights to the location the log was written to.</li>
</ol>
<h3>RHJ4Diagnostics</h3>
Diagnostic problems can arise in the Javascript code executing in the browser 
or in PHP code executing in the server. In both cases, you want to be able to 
easily capture and report the condition.
RHJ4Diagnostics reports its messages in several places: on the Browser’s 
debugging console, in the PHP error_log, or to a function you specify.
Diagnostics can be turned on or off for an entire site or for a single section 
of code. Since the diagnostics are very lightweight, they don’t have to be 
removed from the code in order to be disabled.
<h3>PHP API</h3>
The PHP code is implemented as a class with the following functions:
<ul>
<li>
instance(): Return instance of plugin (does not initialize).
</li>
<li>
init($options = NULL): Initialize plugin
</li>
<li>
kill(): Kill current instance of plugin
</li>
<li>
options ($options = null): parse and set options for currently loaded page
</li>
<li>
set($options = NULL): parse and set options in wp_options table. NOTE: Multisite is supported. Options will be set in wp_$blog_id_options table.
</li>
<li>
reset(): reset all options to their defaults
</li>
<li>
diagnostic($message, $options = NULL): Capture a diagnostic message. NOTE: $if $options is a string, it will be treated as if it were: array(‘source’ -> ‘whatever:’).
</li>
<li>
set_error_reporting($level = null): Set PHP error_reporting_level
</li>
<li>
render_error_level($level): Translate integer error_level value to string
</li>
</ul>
<h3>OPTIONS</h3>
The following options may be used for all functions that accept $options:
<ul>
<li>enabled enables plugin (default: false). If not enabled, no diagnostic messages will be displayed.</li>
<li>threshold sets a threshold that determines which messages will be logged. Messages with a threshold above the current threshold will not be written to the log file.</li>
<li>output identifies output handler function (default: ‘rhj4_log’). Output may be a single function name or an array of function names. Function must exist to be set.</li>
<li>source identifies the body of code that diagnostics will be coming from. This string will be prepended to each message.</li>
<li>logfile identifies where output diagnostics will be saved (default: ‘rhj4_diags.log’).</li>
<li>level PHP error reporting level for PHP diagnostics (default: 71 = 64 + 4 + 2 + 1 = ERROR, WARNING, PARSE, COMPILE ERROR). PHP errors will be reported if WP_DEBUG is TRUE. RHJ4Diagnostics will be reported if plugin is enabled.</li>
</ul>
Option values are stored in the wp_options table using the key ‘rhj4_diagnostic_options’.
<h3>SHORTCODES</h3>
The shortcode format is:
<pre><code> [rhj4_diagnostics <code>=<value> [...]]
</code></pre>
The following code values are supported:
enable [true|false<- default] Enables logging on this page.
disable [true|false<- default] Disables logging on this page.
threshold [0 | integer value] Sets diagnostic threshold level. Only messages with this threshold or lower will be logged.
save [true|false<- default] Used with Enable, Disable and Threshold to save settings 
to database. To enable diagnostics for all pages:
<pre><code>[rhj4_diagnostics enable=true save=true]
</code></pre>
show [true|false<- default] Displays current log file contents.
clear [true|false<- default] Deletes current log file.
options [true|false<- default] Displays current option values on page.
demo [true|false<- default] Shows a demonstration of many ways of using this plugin.
test [true|false<- default] Performs some diagnostic tests on the code.
options [true|false<- default] Shows the current option values.
verbose [true|false<- default] Echos diagnostic information on the page.
log [true|false<- default] Writes a diagnostic to the log. Requires message. For example:
<pre><code> [rhj4_diagnostics log=true message='log this message']
</code></pre>
message = is used with notify and log to define the message to be sent.
notify [true|false<- default] Displays a notification popup using RHJ4Notifications. Requires message and uses sticky and type.
<pre><code> [rhj4_diagnostics notify=true message='show this message in popup' sticky=true, type=NOTIFICATION_TYPE_WARNING]
</code></pre>
sticky [true|false<- default] is used with notify to indicate whether the notification message is “sticky”, i.e. will stay visible on the screen until a page turn or the message is deleted.
type = (NOTIFICATION_TYPE_CONFIRMATION<- default) indicates the type of notification to be generated.
Example:
<pre><code> [rhj4_diagnostics enable=true show=true clear=true show_options=true]
</code></pre>
Will produce:
<h4>Options</h4>
<pre><code>array (size=6)
'enabled' => int 1
'threshold' => int 10
'output' => string 'rhj4_log' (length=8)
'source' => string 'DIAG: ' (length=6)
'logfile' => string 'rhj4_diags.log' (length=14)
'level' => int 71
Logfile: D:\ApacheHtdocs\bhamwpdev/wp-content/rhj4_diags.log

09/14/14 04:56:09->DIAG: Page Name [] User [bob_jones]
09/14/14 04:56:55->DIAG: Page Name [diags] User [bob_jones]

rhj4_diags.log deleted
</code></pre>
Example:
<pre><code> [rhj4_diagnostics notify=true message="this is a notification" verbose=true]
</code></pre>
Will generate a popup window containing the notification message.
NOTE: Use of the notify function requires the installation of the RHJ4 Notifications plugin.
DEMONSTRATION Page: Visit <a href="http://bellinghamwordpressdevelopers.com/diags" rel="nofollow ugc">http://bellinghamwordpressdevelopers.com/diags</a> for a demonstration of these shortcodes in action.
<h3>EXAMPLES</h3>
There are two basic ways to invoke this plugin:
<ol>
<li>
Call rhj4_diagnostic and pass in the message and (optionally) any options
</li>
<li>
Acquire an instance of the plugin and work with that:
$diags = RHJ4Diagnostics::instance();
$diags holds an instance of the diagnostics object and can be used to invoke methods in the object.
</li>
</ol>
These two lines are equivalent:
<pre><code> $diags->diagnostic('message','SOURCE: ');
 $diags->diagnostic('message', array('source' => 'SOURCE: '));
</code></pre>
Enable plugin for this page and print a message:
<pre><code> $diags->diagnostic('message', 
 array('source' => 'SOURCE: ', 'enabled' => true));
</code></pre>
This code:
<pre><code> rhj4_diagnostic('this is a message');
</code></pre>
Will produce this output in the current log file:
<pre><code>08/13/14 23:36:44->DIAGNOSTICS:this is a message
</code></pre>
This example:
<pre><code> $diags = RHJ4Diagnostics::instance();
 $diags = RHJ4Diagnostics::instance()->init(array (
 'enabled' => true,
 'threshold' => 10,
 'output' => 'rhj4_log',
 'source' => 'DIAGNOSTICS:',
 'logfile' => 'rhj4_diags.log',
 'level' => E_ALL & ~E_DEPRECATED & ~E_NOTICE & ~E_STRICT
 ));

 $diags->diagnostic($diags->plugin_slug.' enabled');
</code></pre>
Will:
<ul>
<li>Enable the plugin.</li>
<li>Set the message threshold to 10.</li>
<li>Set the output logging function (‘rhj4_log).</li>
<li>Identify the logging file (‘rhj4_diags.log’). </li>
<li>Tell the plugin to report all PHP errors except E_DEPRECATED, E_NOTICE and E_STRICT.</li>
<li>
Write a line in the output file like this:
08/13/14 23:36:42->DIAGNOSTICS:rhj4_diagnostics enabled
</li>
</ul>
<h4>Demo Code</h4>
Add this line of code (or uncomment the line in the plugin source):
<pre><code> add_action('init','rhj4_diagnostics_demo');
</code></pre>
and the plugin will execute code in the function rhj4_diagnostics_demo:
Get an instance of this plugin:
<pre><code> $diags = RHJ4Diagnostics::instance();
</code></pre>
Reset option settings to their defaults. The reset values are remembered in wp_options:
<pre><code> $diags->clear_log();
 $diags->reset();
 $options = $diags->options();
 var_dump($options);
</code></pre>
After reset, plugin will not be enabled, so this next message won’t show:
<pre><code> $message = rhj4_diagnostic('This message will NOT appear in the log.'); 
 var_dump($message);
</code></pre>
Enable plugin and change the source message:
<pre><code> $message = $diags->diagnostic('This message WILL appear in log', array(
 'enabled' => true,
 'source' => 'DEMO: '
 ));

 $options = $diags->options();
 var_dump($message);
 var_dump($options);

 $message = $diags->diagnostic('Turn on reporting of PHP Errors', array(
 'level' => E_ALL ));

 $options = $diags->options();
 var_dump($message);
 var_dump($options);

 rhj4_diagnostic('End of demo','THE END: ');
</code></pre>
<h4>Custom Output Handlers</h4>
You can write your own output handlers that will direct diagnostics to any file (or database table) that you want. Here is an example:
<pre><code> function my_diagnostic_test_output($message, $logfile = 'rhj4_diags_test.log') {
 $timestamp = date('m/d/y H:i:s',time());
 $file = fopen($logfile,"a+");
 fwrite($file, $timestamp.'->'.$message."\n");
 fclose($file);
 }
</code></pre>
<h4>Multiple Output Handlers</h4>
<pre><code>//
// This example writes the output to two log files 
//
 rhj4_diagnostic('more complex message', array(
 'source' =>'MULTIPLE FUNCTIONS: ',
 'output' => array(
 array( 'function' => 'my_diagnostic_test_output', 
 'logfile' => 'rhj4_diags_test.log'),
 array( 'function' => 'rhj4_log', 
 'logfile' => 'rhj4_diags.log')
 )));
</code></pre>
<h3>SUPPORT</h3>
I will attempt to answer your email as quickly as I can, but cannot promise immediate response.
I will entertain ideas for enhancements, especially if I hear the same request from multiple people.
Donations will encourage my support… and my thanks.
<h3>CONSULTING</h3>
I make my living by helping WordPress developers. If I can help you, please contact me.
Bob Jones
<a href="mailto:bob@rhj4.com" rel="nofollow ugc">bob@rhj4.com</a>
<a href="http://bellinghamwordpressdevelopers.com/" rel="nofollow ugc">http://bellinghamwordpressdevelopers.com/</a>

RHJ4 Diagnostics

RHJ4 Diagnostics supports program debugging by making it simple to write tracing information into several log files.

Foysal Zihak

Health Radar is a comprehensive WordPress plugin auditing and health monitoring tool for site administrators. Get a clear, real-time picture of their site’s plugin ecosystem—conflicts, performance bottlenecks, compatibility issues, and errors—without guessing or digging through logs.
Stop managing plugins blindly. Stop performance issues before they impact your users. Stop compatibility problems from becoming critical failures.
Core Features:
<ul>
<li>
🔍 Plugin Conflict Detector — Instantly detects duplicate script and style handles, identifies hook collisions between active plugins, and highlights which plugins are fighting for the same resources.
</li>
<li>
⚡ Performance Insight Panel — Measures total enqueued assets, calculates JS/CSS payload, counts database queries (when SAVEQUERIES enabled), audits wp_options autoload bloat, and generates a 0–100 health score with actionable recommendations.
</li>
<li>
🐘 PHP Compatibility Checker — Validates each plugin’s Requires PHP header against your server version, scans for deprecated WordPress function usage, and flags incompatible plugins before they break your site.
</li>
<li>
📋 Debug Log Analyzer — Intelligently parses wp-content/debug.log, categorizes errors as fatal, warnings, or notices, attributes errors to specific plugins via stack trace analysis, and shows trends over time.
</li>
<li>
🧬 Duplicate Asset Detector — Uses file fingerprinting (MD5) to identify identical JavaScript and CSS libraries loaded by multiple plugins (detects jQuery, Lodash, Moment.js, Chart.js duplicates, and more).
</li>
<li>
📄 Health Report Generator — Compiles a full site health snapshot into a single printable page; export as JSON for automation, or generate PDF from browser print dialog.
</li>
</ul>
WP-CLI Integration:
Automate plugin health audits and reporting via command line:
<ul>
<li><code>wp healthmonitor scan</code> — Trigger a full plugin health scan and display results.</li>
<li><code>wp healthmonitor score</code> — Get your current health score (0–100) instantly.</li>
<li><code>wp healthmonitor conflicts</code> — List all detected plugin conflicts and collisions.</li>
<li><code>wp healthmonitor report</code> — Generate a complete health report in table format.</li>
<li><code>wp healthmonitor report --format=json</code> — Export full report as JSON for programmatic access and dashboards.</li>
<li><code>wp healthmonitor log --last=50</code> — Display recent debug log entries (customizable number).</li>
</ul>
Perfect for scheduled audits, CI/CD integration, and headless WordPress monitoring.
Who Should Use Health Radar?
<ul>
<li>WordPress Site Administrators — Take control of your plugin ecosystem.</li>
<li>Web Hosting Providers — Offer health audits to your clients as a value-add service.</li>
<li>WordPress Developers & Agencies — Audit client sites, debug complex plugin interactions, optimize performance.</li>
<li>WP-CLI Power Users — Integrate plugin audits into automation workflows and monitoring scripts.</li>
</ul>
Security & Privacy First:
This plugin operates with zero external dependencies and complete data privacy:
<ul>
<li>✅ No external HTTP requests — All analysis happens locally on your server.</li>
<li>✅ No telemetry or tracking — We don’t collect usage data.</li>
<li>✅ No data transmission — Your plugin list, errors, and reports never leave your site.</li>
<li>✅ WPCS & Security Compliance — Follows WordPress Coding Standards and best practices.</li>
<li>✅ WP_Filesystem API — Uses WordPress’s secure file operations, never direct fopen/fread.</li>
<li>✅ Nonce-protected AJAX — All admin actions verified with WordPress security tokens.</li>
<li>✅ Capability Checks — Only administrators (manage_options) can run scans or view reports.</li>
</ul>
<h3>System Requirements</h3>
<ul>
<li>WordPress: 6.3 or newer</li>
<li>PHP: 8.1 or newer (object-oriented PHP with type hints)</li>
<li>Database: MySQL 5.7+ or MariaDB 10.2+</li>
<li>Recommended: WP_DEBUG enabled during audits for maximum visibility</li>
</ul>
<h3>Performance & Compatibility</h3>
Performance Impact: 
* Zero performance impact on front-end 
* Admin dashboard scans: 1–3 seconds (depending on plugin count) 
* Results cached for 1 hour 
* No background processes or cron jobs
Tested Compatibility: 
* ✅ WordPress 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 6.9+ 
* ✅ PHP 8.1, 8.2, 8.3, 8.4 
* ✅ All major hosting providers (Kinsta, WP Engine, Bluehost, SiteGround, etc.) 
* ✅ Multisite WordPress installations 
* ✅ WP-CLI compatible

Health Radar

Detect plugin conflicts, performance issues, PHP compatibility risks, and debug log errors from your WordPress dashboard.

RHJ4 Diagnostics vs Health Radar