WPCLI
This module should be used in acceptance and functional tests to setup, or verify, tests pre and post conditions using WP-CLI commands. This module allows invoking WP-CLI commands, refer to the official site for more information.
The module will use its own version of WP-CLI, not the one installed in the machine running the tests!
By default, wp-browser will only include the wp-cli/wp-cli package; this package contains the basic files to run WP-CLI and does not contain all the commands that come with a typical wp-cli installation. If, in your tests, you require all the commands that usually come installed with WP-CLI, then you should require the wp-cli/wp-cli-bundle package as a development dependency of your project, see below.

Fixing "not a registered command" issue

To keep the conflicts at a manageable level, the wp-browser project does not include all the commands WP-CLI usually comes bundled with. Running, in the context of an automated test, a WP-CLI command that would work on your machine, e.g. wp plugin list --status=active, will not work on a default installation of wp-browser and you will get the following error message:
1
[ModuleException] WPCLI: wp-cli terminated with status [1] and output [Error: 'plugin' is not a registered wp command. See 'wp help' for available commands.]
Copied!
To resolve the message just add the package you require as a development dependency or add the whole WP-CLI bundle:
1
composer require --dev wp-cli/wp-cli-bundle
Copied!
The package will make all the default WP-CLI commands available to the WP-CLI version used in tests.

Module requirements for Codeception 4.0+

This module requires the codeception/module-cli Composer package to work when wp-browser is used with Codeception 4.0.
To install the package run:
1
composer require --dev codeception/module-cli:^1.0
Copied!

Detecting requests coming from this module

When it runs this module will set the WPBROWSER_HOST_REQUEST environment variable. You can detect and use that information to, as an example, use the correct database in your test site wp-config.php file:
1
<?php
2
if (
3
// Custom header.
4
isset( $_SERVER['HTTP_X_TESTING'] )
5
// Custom user agent.
6
|| ( isset( $_SERVER['HTTP_USER_AGENT'] ) && $_SERVER['HTTP_USER_AGENT'] === 'wp-browser' )
7
// The env var set by the WPClIr or WordPress modules.
8
|| getenv( 'WPBROWSER_HOST_REQUEST' )
9
) {
10
// Use the test database if the request comes from a test.
11
define( 'DB_NAME', 'wordpress_test' );
12
} else {
13
// Else use the default one.
14
define( 'DB_NAME', 'wordpress' );
15
}
Copied!

Configuration

    path required - the absolute, or relative, path to the WordPress root folder. This will be mapped to the --path argument of the wp-cli binary.
    throw - defaults to true to throw an exception when a wp-cli command does not return an exit status of 0; if set to false then the exit status of the commands will be returned as is.
    timeout - defaults to 60 (seconds) to set each process execution timeout to a certain value; set to null, false or 0 to disable timeout completely.
Additionally the module configuration will forward any configuration parameter to wp-cli as a flag or option. In the example configuration below the allow-root flag and the some-option option will be passed to wp-cli directly and prepended to the command as global options.
Note: these extract configuration flags and options will be prepended to all commands executed by wp-cli!

Environment configuration

These environment variables can be set on the commands ran by the WPCLI module using the optional env array in the module configuration. The example configuration below shows all of them with some example values. Most of the times you won't need any of these, but they are there for more fine-grained control over the module operations.
The module is not validating the environment variables in any way! Those values will be evaluated by wp-cli at runtime and might generate errors if not correctly configured.

Example configuration

1
modules:
2
enabled:
3
- WPCLI
4
config:
5
WPCLI:
6
path: /Users/Luca/Sites/wp
7
throw: true
8
timeout: 60
9
# This will be prepended to the command, `wp --allow-root <command>`.
10
allow-root: true
11
# This will be prepended to the command, `wp --some-option=some-value <command>`.
12
some-option: some-value
13
env:
14
# Any one of these, if provided, will be set as environment variable for the the cli command process.
15
# See https://make.wordpress.org/cli/handbook/config/#environment-variables for information.
16
# Equivalent to `WP_CLI_STRICT_ARGS_MODE=1 wp <command>'.
17
strict-args: true
18
# Equivalent to `WP_CLI_CACHE_DIR=/tmp/wp-cli-cache wp <command>'.
19
cache-dir: '/tmp/wp-cli-cache'
20
# Equivalent to `WP_CLI_CONFIG_PATH=/app/public wp <command>'.
21
config-path: '/app/public'
22
# Equivalent to `WP_CLI_CUSTOM_SHELL=/bin/zsh wp <command>'.
23
custom-shell: '/bin/zsh'
24
# Equivalent to `WP_CLI_DISABLE_AUTO_CHECK_UPDATE=1 wp <command>'.
25
disable-auto-update: true
26
# Equivalent to `WP_CLI_PACKAGES_DIR=/wp-cli/packages wp <command>'.
27
packages-dir: '/wp-cli/packages'
28
# Equivalent to `WP_CLI_PHP=/usr/local/bin/php/7.2/php wp <command>'.
29
php: '/usr/local/bin/php/7.2/php'
30
# Equivalent to `WP_CLI_PHP_ARGS='foo=bar some=23' wp <command>'.
31
php-args: 'foo=bar some=23'
Copied!

Public API

buildFullCommand

Builds the full command to run including the PHP binary and the wp-cli boot file path.
1
// This method is defined in the WithWpCli trait.
2
// Set the wp-cli path, `$this` is a test case.
3
$this->setUpWpCli( '/var/www/html' );
4
// Builds the full wp-cli command, including the `path` variable.
5
$fullCommand = $this->buildFullCommand(['core', 'version']);
6
// The full command can then be used to run it with another process handler.
7
$wpCliProcess = new Process($fullCommand);
8
$wpCliProcess->run();
Copied!
Parameters
    \Codeception\Module\array/string $command - The command to run.

cli

Executes a wp-cli command targeting the test WordPress installation. minus wp. For back-compatibility purposes you can still pass the commandline as a string, but the array format is the preferred and supported method.
1
// Activate a plugin via wp-cli in the test WordPress site.
2
$I->cli(['plugin', 'activate', 'my-plugin']);
3
// Change a user password.
4
$I->cli(['user', 'update', 'luca', '--user_pass=newpassword']);
Copied!
Parameters
    string/string/\Codeception\Module\array $userCommand - The string of command and parameters as it would be passed to wp-cli

cliToArray

Returns the output of a wp-cli command as an array optionally allowing a callback to process the output. minus wp. For back-compatibility purposes you can still pass the commandline as a string, but the array format is the preferred and supported method.
1
// Return a list of inactive themes, like ['twentyfourteen', 'twentyfifteen'].
2
$inactiveThemes = $I->cliToArray(['theme', 'list', '--status=inactive', '--field=name']);
3
// Get the list of installed plugins and only keep the ones starting with "foo".
4
$fooPlugins = $I->cliToArray(['plugin', 'list', '--field=name'], function($output){
5
return array_filter(explode(PHP_EOL, $output), function($name){
6
return strpos(trim($name), 'foo') === 0;
7
});
8
});
Copied!
Parameters
    string/string/\Codeception\Module\array $userCommand - The string of command and parameters as it would be passed to wp-cli
    \callable $splitCallback - An optional callback function to split the results array.

cliToString

Returns the output of a wp-cli command as a string. minus wp. For back-compatibility purposes you can still pass the commandline as a string, but the array format is the preferred and supported method.
1
// Return the current site administrator email, using string command format.
2
$adminEmail = $I->cliToString('option get admin_email');
3
// Get the list of active plugins in JSON format, two ways.
4
$activePlugins = $I->cliToString(['plugin', 'list','--status=active', '--format=json']);
5
$activePlugins = $I->cliToString(['option', 'get', 'active_plugins' ,'--format=json']);
Copied!
Parameters
    string/\Codeception\Module\array $userCommand - The string of command and parameters as it would be passed to wp-cli

dontSeeInShellOutput

Checks that output from last command doesn't contain text.
1
// Return the current site administrator email, using string command format.
2
$I->cli('plugin list --status=active');
3
$I->dontSeeInShellOutput('my-inactive/plugin.php');
Copied!
Parameters
    string $text - The text to assert is not in the output.

seeInShellOutput

Checks that output from last command contains text.
1
// Return the current site administrator email, using string command format.
2
$I->cli('option get admin_email');
Copied!
Parameters
    string $text - The text to assert is in the output.

seeResultCodeIs

Checks the result code from the last command.
1
// Return the current site administrator email, using string command format.
2
$I->cli('option get admin_email');
3
$I->seeResultCodeIs(0);
Copied!
Parameters
    int $code - The desired result code.

seeResultCodeIsNot

Checks the result code from the last command.
1
// Return the current site administrator email, using string command format.
2
$I->cli('invalid command');
3
$I->seeResultCodeIsNot(0);
Copied!
Parameters
    int $code - The result code the command should not have exited with.

seeShellOutputMatches

Checks that output from the last command matches a given regular expression.
1
// Return the current site administrator email, using string command format.
2
$I->cli('option get admin_email');
Copied!
Parameters
    string $regex - The regex pattern, including delimiters, to assert the output matches against.
This class extends \Codeception\Module
Last modified 8mo ago