PHP Error

Hi @espressivo,

Thanks for the detailed trace, that made this quick to pin down.

You’re right that user_count is reaching replace_tag() as an array, but the array is created upstream of the mailer, in ITSEC_Lockout::get_lockouts() (core/lockout.php). When the digest runs, send_daily_digest() asks for the lockout counts like this:

$user_count = $itsec_lockout->get_lockouts( 'user', array( 'after' => $last_sent, 'current' => false, 'return' => 'count' ) );

Inside get_lockouts(), the count path is guarded this way:

if ( $is_count && $results ) {
return $results[0]['COUNT'];
}
// ...falls through...
return $results;

A SELECT COUNT(1) query always returns exactly one row (with COUNT = 0) when it runs successfully, so under normal conditions you get a scalar 0 back. The only way $results comes back empty here is when that query fails to execute at all, which on this plugin means the lockouts table ({prefix}itsec_lockouts) is missing or damaged on the site. When that happens the count branch is skipped and the method returns an empty array() instead of 0.

That empty array then slips past the if ( $host_count > 0 || $user_count > 0 ) check in send_daily_digest() (in PHP an array compares as greater than 0), so add_lockouts_summary() runs with arrays, and they land in preg_replace() as the replacement value, giving you the PHP 8 TypeError at lib.php:983.

So the fatal is really a symptom: the digest is blowing up because the lockouts table isn’t returning data. To get the site healthy:

1. Check the table. Adjust the prefix if the site isn’t on wp_:
   SHOW TABLES LIKE 'wp_itsec_lockouts';
   and, if it exists:
   CHECK TABLE wp_itsec_lockouts;
2. If it’s missing or reports as corrupt, regenerate it. Deactivating and reactivating Kadence Security re-runs the schema setup and recreates any missing tables without touching your settings. If CHECK TABLE flagged corruption, run REPAIR TABLE wp_itsec_lockouts; first.
3. Let the digest run again (or trigger the cron event manually) and confirm the fatal is gone.

I’d take a quick database backup before the repair/regenerate step, just as standard practice.

If the table checks out clean and you still hit this, paste the output of the two SQL checks above and I’ll dig in further.

Best regards,

Pawel P.

Liquid Web Software Support