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.

npc01

NPC Maintenance Inspector performs 9-point health diagnostics on your WordPress site directly from the admin dashboard:
<ol>
<li>WordPress core updates — Detect missing core updates.</li>
<li>Plugin updates — List plugins with available updates.</li>
<li>Site Health issues — Extract critical issues from WP standard Site Health API.</li>
<li>PHP version — Warn on end-of-life PHP versions.</li>
<li>Error log analysis — Summarize debug.log entries and save a one-click backup to uploads/ for safe review.</li>
<li>File integrity — Detect suspicious code patterns in core files (eval / base64_decode / etc.) by comparing checksums against the WordPress.org Checksum API.</li>
<li>Suspicious files — Find unexpected PHP files in wp-content/uploads/, with built-in whitelist for known legitimate plugin files (Ajax Load More templates, WP STAGING index.php, AIOS firewall rules, etc.).</li>
<li>SSL certificate — Check days until expiration (warn under 30 days, critical at 0).</li>
<li>File permissions — Check critical files like wp-config.php, .htaccess, wp-content/.</li>
</ol>
Operational features:
<ul>
<li>History — Keep the last 10 diagnoses as a custom post type.</li>
<li>Scheduled auto-check — Run daily, weekly, or monthly via WP Cron.</li>
<li>Email notifications — Send alerts only on critical issues.</li>
<li>One-click debug.log clear — Truncate the log while preserving file permissions.</li>
<li>Optional AI report — Generate maintenance suggestions via Anthropic Claude API. Disabled by default; opt-in via a wp-config.php constant.</li>
</ul>
The plugin is locked to the user who activated it and to the original site URL, so it stays inert after backup restores to a different domain.
<h3>External services</h3>
This plugin can optionally connect to the Anthropic Claude API (<code>https://api.anthropic.com/v1/messages</code>) to generate AI-powered maintenance reports. This is the only external service the plugin ever contacts.
When is data sent?
<ul>
<li>When you manually click the “Generate AI Report” button in the admin.</li>
<li>When an automatic scheduled diagnosis detects a critical issue and notifications are enabled. In that case the AI report is generated once per critical run and attached to the notification email.</li>
</ul>
What data is sent?
<ul>
<li>The diagnosis result text only:
<ul>
<li>Site URL, site name, WordPress version, theme name</li>
<li>Counts of plugin updates / Site Health issues / error-log entries</li>
<li>PHP version, memory limit, max upload size</li>
<li>SSL expiration date and days remaining</li>
<li>File-permission status of critical files</li>
<li>Suspicious code patterns detected (function names like <code>eval</code>, <code>base64_decode</code>)</li>
</ul>
</li>
<li>No login data, no post content, no personal data of site visitors.</li>
</ul>
Is the data sent unconditionally?
No. The AI feature is completely disabled unless you define <code>NPCMI_API_KEY</code> in <code>wp-config.php</code>. Without that constant, no external connection to Anthropic is ever made.
Anthropic’s terms and privacy policy:
<ul>
<li>Consumer Terms of Service: https://www.anthropic.com/legal/consumer-terms</li>
<li>Privacy Policy: https://www.anthropic.com/legal/privacy</li>
<li>Commercial Terms of Service (if you use a paid API plan): https://www.anthropic.com/legal/commercial-terms</li>
</ul>
By enabling the AI report feature (i.e. by defining <code>NPCMI_API_KEY</code>), you agree to Anthropic’s applicable terms.

NPC Maintenance Inspector

WordPress maintenance health-check tool with 9-point diagnostics, history tracking, and optional AI-powered reports.

RHJ4 Diagnostics vs NPC Maintenance Inspector