When WP Toolkit reports “Unable to get site administrator settings” and the stack ends in WP_User_Query, the Toolkit login button is usually the messenger, not the cause. WP Toolkit invokes WordPress through WP-CLI to list users and identify an administrator. WordPress loads, something supplies an object where core expects an integer or array offset, and PHP stops the user query.
Do not edit wp-includes/meta.php or class-wp-user-query.php merely because those files appear in the trace. Those are the points where invalid data reaches a strict operation. Editing core hides the symptom, complicates upgrades, and rarely identifies who produced the bad value.
Read the Stack as a Data-Flow Clue
A representative trace follows this path:
WP Toolkit → WP-CLI user list → get_users() → WP_User_Query → fatal TypeError
WordPress documents that WP_User_Query accepts integers for parameters such as blog_id and arrays of integer user IDs for include and exclude. It also exposes the pre_get_users hook, which lets plugins change the query before core parses it. A plugin, must-use plugin, drop-in, stale object-cache value, or damaged runtime can therefore break a query that WP Toolkit itself constructed correctly.
The trace alone does not prove corrupt usermeta. Treat that as one hypothesis among several.
Preserve Evidence First
Create a full account backup or a tested files-and-database backup before changing anything. Record the error, PHP version and handler, WordPress version, WP Toolkit version, active plugins, must-use plugins, drop-ins, and the time of the failed attempt. Keep the original stack because line numbers change between WordPress releases.
Run commands as the cPanel account that owns the site, from the correct document root. Running WP-CLI as root can create wrong file ownership and can load a different environment.
Start with read-only checks:
wp core version
wp core verify-checksums
wp plugin list
wp theme list
wp user list --fields=ID,user_login,roles
If the normal user list reproduces the fatal error, the problem is independent of WP Toolkit’s button.
Isolate Plugins and Themes
Repeat the query without ordinary plugins and the active theme:
wp user list --fields=ID,user_login,roles --skip-plugins --skip-themes
If this succeeds, restore components selectively in a staging copy or a short maintenance window until the failure returns. Begin with plugins that alter users, roles, membership, security, multisite, object caching, or WP-CLI behaviour.
WP-CLI’s --skip-plugins option does not make every custom execution path disappear. Must-use plugins and drop-ins can still load. Inspect wp-content/mu-plugins, object-cache.php, db.php, and other drop-ins. Rename or disable them only with a backup, a rollback path, and knowledge of what service depends on them.
If both commands fail identically, move to core integrity, cache, database evidence, and site configuration instead of blaming a random active plugin.
Verify Core Without Patching It
Checksum failure can indicate incomplete updates, corruption, or unexpected modifications. cPanel’s support guidance for corrupted WordPress core recommends backing up first and then using WP Toolkit’s integrity check and core reinstall facility. A core reinstall replaces WordPress program files; it should not be used as a substitute for investigating a plugin that will immediately recreate the error.
Confirm that wp-config.php points to the intended database and table prefix and that required files exist. If the site was cloned, verify that WP Toolkit is attached to the correct document root and database.
Inspect User Data Read-Only
If the failure persists with optional code skipped and core verifies correctly, inspect user records without deleting anything. First confirm that user IDs are numeric and that each administrator account has a corresponding user row. On multisite, verify the site ID and per-site capability keys.
Use database tools in read-only mode to review suspicious rows and serialised values. Export the exact rows before any correction. WordPress metadata can legitimately contain serialised arrays and objects, so the presence of a serialised value is not by itself corruption.
Look for evidence that connects a value to the failing query: a plugin-specific user option, malformed site identifier, invalid cache entry, or a filter that reads an object and assigns it to an integer query variable. A blind DELETE FROM wp_usermeta risks removing roles, capabilities, session tokens, or application state while leaving the original defect intact.
Test the Object Cache
A persistent object cache can retain values after a database repair or migration. Determine whether the site uses Redis, Memcached, or another object-cache.php drop-in. Flush only the affected site’s cache through its supported mechanism and during a safe window; a server-wide flush can disrupt unrelated sites.
Then rerun the same WP-CLI user query. A temporary success after cache clearing is evidence, but the producer of the malformed value still needs to be found.
Restore WP Toolkit Access
Once wp user list works in the same site context, ask WP Toolkit to rescan or refresh the installation and retry administrator login. Confirm that the selected administrator still exists, is not blocked by a security plugin, and has the expected role.
The Toolkit’s separate reputation or SEO-related interfaces do not repair this PHP fatal. They analyse online presence or search-related data; they are not part of WordPress user-query execution.
The safe repair sequence is evidence, reproducibility, isolation, integrity, cache, and targeted data correction. It avoids the two most damaging shortcuts: modifying WordPress core at the reported line and deleting user metadata without proving which value is invalid.
