Thursday, August 20, 2026

WordPress - Fixing the WP Activity (plugin) Log Fatal TypeError on PHP 8.x (class-wp-helper.php)

Fixing the WP Activity Log Fatal TypeError on PHP 8.x (class-wp-helper.php)

If you recently upgraded your WordPress environment to PHP 8.0, 8.2, or 8.3 and noticed a "There has been a critical error on this website" screen when loading the WP Activity Log viewer (/wp-admin/admin.php?page=wsal-auditlog), you are likely running into an unhandled scalar type mismatch in modern PHP runtimes.

Tracked on the WordPress Support Forums: Fatal error 5.6.5 with WP 7.1: strtolower receives integer callback id (View Forum Hotfix Reply)


The Error Breakdown

Checking the site's debug.log file reveals a fatal TypeError originating from the plugin's notice-suppression helper:

[20-Aug-2026 05:28:54 UTC] PHP Fatal error: Uncaught TypeError: strtolower(): Argument #1 ($string) must be of type string, int given in /var/www/html/wp-content/plugins/wp-security-audit-log/classes/Helpers/class-wp-helper.php:656
Stack trace:
#0 /var/www/html/wp-content/plugins/wp-security-audit-log/classes/Helpers/class-wp-helper.php(656): strtolower(1243)
#1 /var/www/html/wp-content/plugins/wp-security-audit-log/classes/Helpers/class-wp-helper.php(537): WSAL\Helpers\WP_Helper::remove_unrelated_actions('admin_notices')
#2 /var/www/html/wp-includes/class-wp-hook.php(353): WSAL\Helpers\WP_Helper::hide_unrelated_notices('')
#3 /var/www/html/wp-includes/class-wp-hook.php(377): WP_Hook->apply_filters(NULL, Array)
#4 /var/www/html/wp-includes/plugin.php(523): WP_Hook->do_action(Array)
#5 /var/www/html/wp-admin/admin-header.php(151): do_action('admin_print_scr...')
#6 /var/www/html/wp-admin/admin.php(244): require_once('/var/www/html/w...')
#7 {main}
  thrown in /var/www/html/wp-content/plugins/wp-security-audit-log/classes/Helpers/class-wp-helper.php on line 656

Why It Happens

To keep the activity log viewer interface clean, the plugin executes hide_unrelated_notices() on the admin_notices action hook. It scans registered callback functions and runs strtolower() against each callback identifier to determine whether the notice belongs to WP Activity Log or another plugin.

In PHP 7.x, passing non-string values (such as integer identifiers generated by dynamic hooks, anonymous functions, or closures) into strtolower() resulted in silent typecasting. In PHP 8.0+, scalar type checking is strictly enforced: passing an integer like 1242 or 1243 throws an uncaught TypeError and immediately crashes script execution.


The Workaround / Hotfix

Until an upstream update is released by the plugin developers, you can apply a one-line hotfix to cast the callback parameter explicitly to a string before evaluation.

Manual File Edit

Open /wp-content/plugins/wp-security-audit-log/classes/Helpers/class-wp-helper.php and navigate to line 656:

// Original line:
strtolower( $callback )

// Updated line:
strtolower( (string) $callback )

Quick Docker / Shell Command

If you manage your WordPress instance in Docker or have SSH terminal access, you can run a non-destructive in-place sed substitution:

# Inside a standard Linux server / webroot:
sed -i 's/strtolower(\([^)]*\))/strtolower((string)\1)/g' wp-content/plugins/wp-security-audit-log/classes/Helpers/class-wp-helper.php

# Or directly inside a running Docker container:
docker exec -it your-wordpress-container sed -i 's/strtolower(\([^)]*\))/strtolower((string)\1)/g' /var/www/html/wp-content/plugins/wp-security-audit-log/classes/Helpers/class-wp-helper.php

Once applied, refresh the WP Activity Log page in your admin dashboard. The activity audit log table will render immediately without triggering fatal errors.

Follow the community thread or submit further feedback on the official WordPress Support Forum topic.

GG-c1c4d41df18c3c5c

WordPress - Troubleshooting Blank Plugin Settings Pages After a Core Update

Troubleshooting Blank Plugin Settings Pages in WordPress After a Core Update

Following a recent WordPress core update to version 7.1, several plugin settings screens (such as Fluent Mail, User Role Editor, and Block Visibility) rendered completely blank in the WordPress admin dashboard. The outer administrative chrome—including the top toolbar, left sidebar, and version footer—loaded normally, but the inner content container failed to mount.

Initial Symptoms & Diagnostic Steps

  • Server-Side Execution: Enabling WP_DEBUG and checking wp-content/debug.log showed that PHP executed through to completion on page visits without throwing blocking fatal errors during the initial options page rendering.
  • Browser Console Exceptions: Opening Chrome DevTools (F12 → Console) revealed cascading JavaScript failures across core WordPress scripts:
    Uncaught SyntaxError: Invalid or unexpected token (at load-scripts.php:12)
    Uncaught SyntaxError: Invalid or unexpected token (at i18n.min.js:3)
    Uncaught ReferenceError: wp is not defined
  • Asset Inspection: Viewing core script files (such as wp-includes/js/dist/i18n.min.js) inside the DevTools Sources tab revealed lines filled entirely with null bytes (\0\0\0... / NULNULNUL).

Root Cause

During automated background core updates or uncompressed archive extractions, an interrupted write stream or volume buffer flush can cause the filesystem to pre-allocate zero-padded blocks without finalizing the script content. JavaScript parsers fail immediately upon encountering raw null bytes in source files, halting script execution before WordPress packages (like wp.i18n, wp.element, and wp.domReady) can initialize the React-based admin interfaces.

Standard in-place core reinstalls through the WordPress dashboard often write over existing file footprints without truncating trailing zero-padded blocks, leaving the corrupt null bytes in place while browsers aggressively cache the broken assets.


The Solution

To resolve the issue, the corrupted core JavaScript directories were completely cleared and replaced with clean source files from the official WordPress release archive, followed by resetting the asset cache.

1. Clean and Rebuild Core JavaScript Directories

Execute the following commands inside the container or server shell to wipe the corrupted asset folders and extract a fresh copy directly from WordPress.org:

cd /tmp
curl -sO https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
rm -rf /var/www/html/wp-includes/js/*
rm -rf /var/www/html/wp-admin/js/*
cp -rf wordpress/wp-includes/js/* /var/www/html/wp-includes/js/
cp -rf wordpress/wp-admin/js/* /var/www/html/wp-admin/js/
chown -R www-data:www-data /var/www/html/wp-includes/js /var/www/html/wp-admin/js
rm -rf latest.tar.gz wordpress

2. Clear Storage & Browser Caching

  • Server Cache: Clear any cached scripts in wp-content/cache/ if object or asset caching plugins are enabled.
  • Browser Cache: Open browser DevTools, enable Disable cache under the Network tab, and perform a hard refresh (Ctrl + Shift + R or Ctrl + F5).

Once fresh scripts are placed and the local cache is bypassed, core packages initialize cleanly, and all React and block-dependent plugin settings panels render immediately.

GG-c1c4d41df18c3c5c

Wednesday, July 22, 2026

Dahua Console for Remote Access to NVR/IPCs



WSL --> Debian --> Navigate to a specific folder for this environment.


Clone the repo:

    git clone https://github.com/mcw0/DahuaConsole.git

Create the virtual environment for the python script:

    cd DahuaConsole

    python3 -m venv venv
    source venv/bin/activate

Install the package's requirements:

    pip install -r requirements.txt


Help command for script:

    python3 Console.py -h

Remote connect to a machine or IPC camera:

    python Console.py --rhost 10.1.10.200 --proto dvrip --rport 37777 --auth userName:password


*Reboot command exists and can be helpful when the webui stops responding.




πŸ‘½