WP-CLI and deployment

The dashboard is convenient while there is one site. Updating twenty plugins, creating a hundred test posts, moving a site from your machine to a server is faster from the terminal. WP-CLI — a program for managing WordPress with commands — exists for that.

The main commands

wp core version
wp core update
wp plugin list
wp plugin install query-monitor --activate
wp plugin update --all
wp theme activate mytheme
wp user create anna anna@example.com --role=editor
wp cache flush

Commands are run in the site folder.

Posts and options

wp post create --post_type=book --post_title="A new book" --post_status=publish
wp post list --post_type=book --fields=ID,post_title
wp post generate --count=50
wp option get blogname
wp option update blogdescription "A site about books"

wp post generate creates test posts — handy for checking the layout and pagination.

The database

wp db export backup.sql
wp db import backup.sql
wp db query "SELECT COUNT(*) FROM wp_posts"

Your own commands

A plugin can add a command of its own:

// books.php
 
if (defined('WP_CLI') && WP_CLI) {
    WP_CLI::add_command('books recount', function () {
        $count = wp_count_posts('book')->publish;
 
        update_option('books_total', $count);
 
        WP_CLI::success("Books: $count");
    });
}

wp books recount

Moving a site

A WordPress site is files plus a database. The order of a move:

Copy the files to the server: Git for your own theme and plugins, the rest as an archive or with rsync.
Export the database (wp db export) and import it on the server (wp db import).
Create a wp-config.php on the server with its database details.
Replace the old site address with the new one in the database.
Flush the cache and the rewrite rules.

Replacing the address

The site address is written in the database in hundreds of places. One command changes it:

wp search-replace 'http://blog.test' 'https://example.com' --skip-columns=guid
wp rewrite flush
wp cache flush

It is useful to see first what would change by adding the --dry-run flag.

Production settings

// wp-config.php
 
define('WP_ENVIRONMENT_TYPE', 'production');
 
define('WP_DEBUG', false);
define('DISALLOW_FILE_EDIT', true);
define('WP_POST_REVISIONS', 10);
define('DISABLE_WP_CRON', true);

Setting	Why
`WP_DEBUG`	Errors are not shown to visitors
`DISALLOW_FILE_EDIT`	The dashboard has no code editor for themes and plugins
`WP_POST_REVISIONS`	The database does not swell with revision history
`DISABLE_WP_CRON`	The system cron runs the tasks

The security keys (AUTH_KEY and the others) must be the server's own — the wp config shuffle-salts command issues them.

After the move

Check the site against a list: inner pages open, images load, the dashboard login works, emails are sent, HTTPS is on. And set up regular backups of the files and the database — before the first failure, not after.

Common mistake

The site address must not be replaced with a plain find-and-replace in the SQL file. WordPress stores some options in serialized form, which records the length of every string: s:16:"http://blog.test". The new address has a different length, and such records become unreadable — widgets and theme settings vanish. wp search-replace recalculates the lengths correctly.

Thanks for reading!