How to Fix WP-CLI Fatal Error with SQLite Object Cache

When running WP-CLI commands on a WordPress site that uses a SQLite-based object cache, you may get a fatal error inside:

wp-content/object-cache.php

This can happen when the website works normally in the browser, but WP-CLI fails from the command line or from cron.

Example Command

wp cron event run --due-now --path="$HOME/site/htdocs/clients/example-site"

Or with the normal wp binary:

wp cron event run --due-now --path="$HOME/site/htdocs/clients/example-site"

Example Error

You may see an error like this:

Fatal error: Uncaught Error: Call to a member function get() on null in /path/to/site/wp-content/object-cache.php:2883
Stack trace:
#0 /path/to/site/wp-includes/option.php(621): wp_cache_get()
#1 /path/to/site/wp-includes/option.php(164): wp_load_alloptions()
#2 /path/to/site/wp-includes/functions.php(7588): get_option()
#3 /path/to/site/wp-includes/formatting.php(1137): is_utf8_charset()
#4 /path/to/site/wp-includes/formatting.php(4690): wp_check_invalid_utf8()
#5 /path/to/site/wp-content/object-cache.php(648): esc_html()
#6 /path/to/site/wp-content/object-cache.php(2746): WP_Object_Cache::drop_dead()
#7 /path/to/site/wp-includes/load.php(897): wp_cache_init()
#8 /path/to/site/wp-settings.php(149): wp_start_object_cache()

The important part is this:

Fatal error: Uncaught Error: Call to a member function get() on null in wp-content/object-cache.php

Why This Happens

The file:

wp-content/object-cache.php

is not a normal WordPress plugin.

It is a WordPress drop-in file.

Drop-ins are loaded very early during WordPress bootstrap. This means WordPress loads object-cache.php before normal plugins are loaded.

Because of that, this will not disable it:

--skip-plugins=object-cache

Even though the correct WP-CLI flag is:

--skip-plugins

not:

--skip-plugin

--skip-plugins can skip normal plugins, but it does not skip the wp-content/object-cache.php drop-in.

So if the object cache drop-in itself cannot start, WP-CLI may fail before your command even runs.

The Real Cause

In this case, the object cache was using SQLite, but the required PHP extensions were missing from the CLI version of PHP.

The site may work in the browser because the web PHP environment has the required extensions.

But WP-CLI uses CLI PHP.

So you can have this situation:

Web PHP: SQLite/APCu installed
CLI PHP: SQLite/APCu missing

When WP-CLI starts WordPress, it tries to load the SQLite object cache drop-in. The drop-in cannot initialize correctly because the needed PHP extensions are missing. Then WordPress crashes during bootstrap.

Quick Fix

Install the missing PHP extensions:

apt install php-apcu php-sqlite3

If you are not running as root, use:

sudo apt install php-apcu php-sqlite3

That is usually enough on Debian/Ubuntu systems when using the default PHP version.

Version-Specific Fix

If your server uses a specific PHP version, install the matching packages.

For PHP 8.3:

apt install php8.3-apcu php8.3-sqlite3

For PHP 8.2:

apt install php8.2-apcu php8.2-sqlite3

For PHP 8.1:

apt install php8.1-apcu php8.1-sqlite3

If using sudo:

sudo apt install php8.3-apcu php8.3-sqlite3

Adjust the PHP version to match your server.

Verify the CLI PHP Extensions

After installing the packages, check that CLI PHP can see them.

Check SQLite:

php -m | grep -i sqlite

Check APCu:

php -m | grep -i apcu

You can also check directly with PHP:

php -r 'var_dump(extension_loaded("sqlite3"));'

Expected result:

bool(true)

Check APCu too:

php -r 'var_dump(extension_loaded("apcu"));'

Expected result:

bool(true)

You can also see which PHP binary WP-CLI is using:

wp --info

or:

owp --info

Test WP-CLI Again

Run a simple WP-CLI command first:

wp option get siteurl --path="$HOME/site/htdocs/clients/example-site"

Or with your wrapper:

wp option get siteurl --path="$HOME/site/htdocs/clients/example-site"

Then try the cron command again:

wp cron event run --due-now --path="$HOME/site/htdocs/clients/example-site"

If the missing extensions were the problem, WP-CLI should now load WordPress normally.

Important Note About --skip-plugins

The correct flag is plural:

--skip-plugins

Not:

--skip-plugin

Correct example:

wp cron event run --due-now --skip-plugins --path="/full/path/to/site"

You can also skip a specific normal plugin:

wp cron event run --due-now --skip-plugins=plugin-folder-name --path="/full/path/to/site"

But this does not skip:

wp-content/object-cache.php

because object-cache.php is a drop-in, not a normal plugin.

Important Note About Dashes

Use normal double hyphens:

--skip-plugins
--path
--due-now

Do not use typographic dashes, such as:

–skip-plugins
—skip-plugins

Those are not the same as -- and may break shell commands.

Important Note About $HOME

Avoid this:

--path='$HOME/site/htdocs/clients/example-site'

Single quotes prevent $HOME from expanding.

Use double quotes:

--path="$HOME/site/htdocs/clients/example-site"

Or use the full absolute path:

--path="/var/www/vhosts/example/site/htdocs/clients/example-site"

For cron jobs, the full absolute path is usually safer.

Cron Example

To run WordPress cron hourly through WP-CLI:

0 * * * * owp cron event run --due-now --path="/full/path/to/site" > /dev/null 2>&1

This part suppresses normal output:

> /dev/null

This part suppresses errors too:

2>&1

So the full ending:

> /dev/null 2>&1

means both stdout and stderr are discarded.

Safer Cron Example with Locking

If there is a chance one cron run could overlap with the next one, use flock:

0 * * * * flock -n /tmp/example-site-wp-cron.lock owp cron event run --due-now --path="/full/path/to/site" > /dev/null 2>&1

This prevents multiple WP-CLI cron processes from running at the same time.

Troubleshooting Checklist

If the error still happens, check these things:

1. Confirm CLI PHP has SQLite

php -r 'var_dump(extension_loaded("sqlite3"));'

Expected:

bool(true)

2. Confirm CLI PHP has APCu

php -r 'var_dump(extension_loaded("apcu"));'

Expected:

bool(true)

3. Confirm WP-CLI PHP version

wp --info

or:

owp --info

Make sure WP-CLI is using the PHP version you expect.

4. Check the object cache file

ls -la wp-content/object-cache.php

5. Check SQLite cache files

Depending on the plugin, the SQLite object cache file may be stored inside wp-content.

For example:

ls -la wp-content/.ht.object-cache.sqlite*

If the file exists but has wrong ownership or permissions, WP-CLI may not be able to read or write to it.

6. Temporarily disable the drop-in

If you need to urgently run WP-CLI, you can temporarily rename the drop-in:

cd /full/path/to/site/wp-content
mv object-cache.php object-cache.php.disabled

Then run WP-CLI again:

wp cron event run --due-now --path="/full/path/to/site"

After fixing the PHP extensions, restore the file:

mv object-cache.php.disabled object-cache.php

Final Solution

The fix for this specific issue was to install the missing CLI PHP extensions:

apt install php-apcu php-sqlite3

After that, WP-CLI could load WordPress correctly and the cron command worked again.

Summary

If WP-CLI crashes inside:

wp-content/object-cache.php

while using a SQLite-based WordPress object cache, the most likely cause is that CLI PHP is missing the required SQLite/APCu extensions.

The quick fix is:

apt install php-apcu php-sqlite3

Then verify:

php -m | grep -Ei 'sqlite|apcu'

Also remember:

--skip-plugins

is the correct WP-CLI flag.

But it does not skip wp-content/object-cache.php, because that file is a WordPress drop-in, not a normal plugin.

owp is from Orbisius. It's a useful wrapper to wp-cli
https://orbisius.com/store/product/owp/