Common Issues Edit

Error: Can’t connect to the database

A few possibilities:

a) you’re using MAMP, but WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ is not using the MAMP PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. binary.

You can check which PHP WP-CLI is using by running wp --info.

If you need to specify an alternate PHP binary, see using a custom PHP binary.

b) it’s a WordPress multisiteMultisite Multisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core.https://codex.wordpress.org/Create_A_Network. install.

c) the database credentials in wp-config.php are actually incorrect.

Top ↑

Running wp --info produces HTML output

If you run wp --info on a server with Phar support disabled, you may see:

$ wp --info
Content-type: text/html; charset=UTF-8

When using the WP-CLI Phar, you’ll need to whitelist Phar support in your php.ini:

suhosin.executor.include.whitelist = phar

Top ↑

PHP Fatal error: Cannot redeclare wp_unregister_GLOBALS()

If you get this fatal error running the wp command, you may have moved or edited wp-config.php beyond what wp-cli supports:

PHP Fatal error: Cannot redeclare wp_unregister_GLOBALS() (previously declared in /var/www/foo.com/wp-includes/load.php:18) in /var/www/foo.com/wp-includes/load.php on line 33

One of WP-CLI’s requirements is that the line:

require_once(ABSPATH . 'wp-settings.php');

remains in the wp-config.php file, so if you’ve modified or moved it, put it back there. It gets matched by a regex when WP-CLI runs.

Top ↑

PHP Fatal error: Call to undefined function <WordPress function>

Before WP-CLI can load wp-settings.php, it needs to know all of the constants defined in wp-config.php (database connection details and so on). Because WP-CLI doesn’t want WordPress to load yet when it’s pulling the constants out of wp-config.php, it uses regex to strip the require_once(ABSPATH . 'wp-settings.php'); statement.

If you’ve modified your wp-config.php in a way that calls WordPress functions, PHP will fail out with a fatal error, as your wp-config.php is calling a WordPress function before WordPress has been loaded to define it.

Example:

$ wp core check-update
PHP Fatal error:  Call to undefined function add_filter() in phar:///usr/local/bin/wp/php/WP_CLI/Runner.php(952) : eval()'d code on line N

Modifying wp-config.php beyond constant definitions is not best practice. You should move any modifications to a WordPress mu-plugin, which will retain the functionality of your modifications while allowing wp-cli to parse your wp-config.php without throwing a PHP error, as well as preventing other errors.

See: #1631

Top ↑

PHP Fatal error: Call to undefined function cli\posix_isatty()

Please ensure you have the php-process extension installed. For example for Centos 6: yum install php-process

Top ↑

PHP Fatal error: Allowed memory size of 999999 bytes exhausted (tried to allocate 99 bytes)

If you run into a PHP fatal error relating to memory when running wp package install, you’re likely running out of memory.

WP-CLI uses Composer under the hood to manage WP-CLI packages. However, Composer is a bit of a memory hog, so you’ll need to increase your memory limit to accommodate it.

Edit your php.ini as a permanent fix:

# Find your php.ini for PHP-CLI
$ php -i | grep php.ini
Configuration File (php.ini) Path => /usr/local/etc/php/7.0
Loaded Configuration File => /usr/local/etc/php/7.0/php.ini
# Increase memory_limit to 512M or greater
$ vim /usr/local/etc/php/7.0/php.ini
memory_limit = 512M

Set memory_limit on the fly as a temporary fix:

$ php -d memory_limit=512M "$(which wp)" package install <package-name>

If your PHP process is still running out of memory, try these steps:

  1. Restart PHP.
  2. Check for additional php.ini files:
$ php -i | grep additional
Scan this dir for additional .ini files => /usr/local/etc/php/7.1/conf.d
# Edit the additional file(s) and increase the memory_limit to 512M or greater
$ vim /usr/local/etc/php/7.1/conf.d
memory_limit = 512M

Top ↑

Error: YIKES! It looks like you’re running this as root.

Running WP-CLI as root is extremely dangerous. When you execute WP-CLI as root, any code within your WordPress instance (including third-party plugins and themes you’ve installed) will have full privileges to the entire server. This can enable malicious code within the WordPress instance to compromise the entire server.

The WP-CLI project strongly discourages running WP-CLI as root.

See also: #973

Top ↑

PHP notice: Undefined index on $_SERVER superglobal

The $_SERVER superglobal is an array typically populated by a web server with information such as headers, paths, and script locations. PHP CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. doesn’t populate this variable, nor does WP-CLI, because many of the variable details are meaningless at the command line.

Before accessing a value on the $_SERVER superglobal, you should check if the key is set:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
  $_SERVER['HTTPS']='on';
}

When using $_SERVER['HTTP_HOST'] in your wp-config.php, you’ll need to set a default value in WP-CLI context:

if ( defined( 'WP_CLI' ) && WP_CLI && ! isset( $_SERVER['HTTP_HOST'] ) ) {
    $_SERVER['HTTP_HOST'] = 'example.com';
}

See also: #730

Top ↑

PHP notice: Use of undefined constant STDOUT

The STDOUT constant is defined by the PHP CLI. If you receive an error notice that STDOUT is missing, it’s likely because you’re not running WP-CLI by PHP CLI. Please review your server configuration accordingly.

Top ↑

PHP Parse error: syntax error, unexpected ‘?’ in … /php/WP_CLI/Runner.php … eval()’d code on line 1

If you get this error running the wp command, the most likely cause is a Unicode BOM at the start of your wp-config.php. This issue will be addressed in a future release of WP-CLI, but in the meantime you can solve the issue by running:

$ sed -i '1s/^\xEF\xBB\xBF//' $(wp config path)

or by manually removing the BOM using your favorite editor.

See also: wp-cli/search-replace-command#71

Top ↑

Can’t find wp-content directory / use of $_SERVER['document_root']

$_SERVER['document_root'] is defined by the webserver based on the incoming web request. Because this type of context is unavailable to PHP CLI, $_SERVER['document_root'] is unavailable to WP-CLI. Furthermore, WP-CLI can’t safely mock $_SERVER['document_root'] as it does with $_SERVER['http_host'] and a few other $_SERVER values.

If you’re using $_SERVER['document_root'] in your wp-config.php file, you should instead use dirname( __FILE__ ) or similar.

See also: #785

Top ↑

Conflict between global parameters and command arguments

All of the global parameters (e.g. --url=<url>) may conflict with the arguments you’d like to accept for your command. For instance, adding a RSS widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. to a sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. will not populate the feed URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org for that widget:

$ wp widget add rss sidebar-1 1 --url="http://www.smashingmagazine.com/feed/" --items=3
Success: Added widget to sidebar.
  • Expected result: widget has the feed URL set.
  • Actual result: widget is added with the number of items set to 3, but with empty feed URL.

Use the WP_CLI_STRICT_ARGS_MODE environment variable to tell WP-CLI to treat any arguments before the command as global, and after the command as local:

WP_CLI_STRICT_ARGS_MODE=1 wp --url=wp.dev/site2 widget add rss sidebar-1 1 --url="http://wp-cli.org/feed/"

In this example, --url=wp.dev/site2 is the global argument, setting WP-CLI to run against ‘site2’ on a WP multisite install. --url="http://wp-cli.org/feed/" is the local argument, setting the RSS feedRSS Feed RSS is an acronym for Real Simple Syndication which is a type of web feed which allows users to access updates to online content in a standardized, computer-readable format. This is the feed. widget with the proper URL.

See also: #3128

Top ↑

Warning: Some code is trying to do a URL redirect

Most of the time, it’s some pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme code that disables wp-admin access to non-admins.

Quick fix, other than disabling the protection, is to pass the user parameter: --user=some_admin

See also: #477

Top ↑

Cannot create a post with Latin characters in the title on Windows

Considering the following example:

wp post create --post_title="Perícias Contábeis"

Using UTF-8 in PHP arguments doesn’t work on Windows for PHP <= 7.0, however it will work for PHP >= 7.1, as it was fixed as part of Support for long and UTF-8 path. A workaround for PHP <= 7.0 is to use the --prompt option:

echo "Perícias Contábeis" | wp post create --post_type=page --post_status=publish --prompt=post_title

See also: #4714

Top ↑

The installation hangs

If the installation seems to hang forever while trying to clone the resources from GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, please ensure that you are allowed to connect to Github using SSLSSL Secure Socket Layer - Encryption from the server to the browser and back. Prevents prying eyes from seeing what you are sending between your browser and the server. (port 443) and GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. (port 9418) for outbound connections.

Top ↑

W3 Total Cache Error: some files appear to be missing or out of place.

W3 Total Cache object caching can cause this problem. Disabling object caching and optionally removing wp-content/object-cache.php will allow WP-CLI to work again.

See also: #587

Top ↑

The automated updater doesn’t work for versions before 3.4

The wp core update command is designed to work for WordPress 3.4 and above. To be able to update an older website to latest WordPress, you could try one of the following alternatives:

  1. Fully-automated: Run wp core download --force to download latest WordPress and replace it with your files (don’t worry, wp-config.php will remain intact). Then, run wp core update-db to update the database. Since the procedure isn’t ideal, run once again wp core download --force and the new version should be available.
  2. Semi-automated: Run wp core download --force to download all files and replace them in your current installation, then navigate to /wp-admin/ and run the database upgrade when prompted.

Top ↑

PHP Fatal error: Maximum function nesting level of ‘#’ reached, aborting!

You’re encountering a limitation associated with PHP Xdebug. Here are a few solutions to the problem:

  1. Temporarily turn off Xdebug while executing the CLI command: XDEBUG_MODE=off wp <command> ...
  2. Increase the value of xdebug.max_nesting_level in your php.ini file. You can learn more about it here – xdebug.max-nesting-level

If you’re looking for a quick fix while still retaining debugging tools, you can change the max_nesting_level value to execute the command just once:

php -d xdebug.max_nesting_level=512 wp <command> ...

If you’re not in the process of debugging code, it’s advisable to completely disable Xdebug. For instructions on how to permanently switch off Xdebug, please refer to the documentation of your local environment or your hosting provider.

You might experience similar issues with the alternate error message: Error: Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '#' frames

Last updated: