WP-CLI Core

Yes. Pass the full URL including the path to wp core install –url=. Download and config steps stay the same; only the site URL changes.

No. WordPress needs database credentials in wp-config.php before installation. Without config, WP-CLI cannot connect to MySQL and the install will fail.

Yes, and it is recommended for automated pipelines. The –minor flag restricts updates to the current major branch (e.g. 6.x → 6.x patch), skipping major version jumps.

Only when the database named in wp-config.php does not exist yet. On shared hosting the database is often pre-created — then skip this step. On local dev, create it with WP-CLI.

No. Step 4 accepts both git pull and tar -xzf. If the server has Git, pull the branch. If not, upload a tar archive via SFTP and extract it. All other steps are identical.

Run wp plugin update --all --dry-run. This shows which plugins have updates available and what versions they would move to, without making any changes.

For the WordPress object cache, yes. But it does not clear page-level caches (WP Rocket, W3 Total Cache, Varnish, or CDN edge). After the deployment, also purge those separately — otherwise visitors may see the old theme from cache for hours.

For most installs, use the latest stable release without –version. Pin a version only when you intentionally need parity with production or a legacy environment.

Always update core first. Plugin updates frequently declare a minimum WordPress version requirement. Updating plugins against an outdated core can trigger PHP errors if the plugin expects functions added in the newer core version.

Use an empty directory for a fresh site. WP-CLI downloads core files into the current working directory. Mixing with existing files can leave stale plugins or themes from an old project.

It flushes the WordPress object cache — Redis, Memcached, or the built-in transient store, depending on your server setup. It does not clear browser cache or CDN cache. After major updates, also purge your CDN or page cache plugin separately.

wp core install fails because MySQL cannot connect to a database that does not exist. The error looks like a credentials problem but the fix is creating the database first.

WordPress enters maintenance mode at the start and exits on success. If the update fails, the .maintenance file may remain and lock the site. Delete it with wp maintenance-mode deactivate or remove .maintenance from the root. Then restore from the database export you made in step 2.

If the plugin files are in wp-content-old (not on the active path), WP-CLI may error. Use wp plugin deactivate js_composer --skip-plugins to bypass the missing-file check, or update the active_plugins option directly with wp option get active_plugins and wp option update.

Download core (wp core download), create configuration (wp config create), create the database (wp db create), then install (wp core install). Each step depends on the previous one.

After at least one week of stable production traffic. Bugs in a new deployment often surface days later — broken checkout flows, edge-case 404s, plugin conflicts. Keep the backup directory on the server until you are confident, then remove it and move the database dump off-server.

WordPress core updates sometimes include changes to database table structure. wp core update-db applies these schema migrations. Skipping it can cause undefined behavior — WordPress expects a schema version that does not match what is in the database.

Moving preserves the entire old site — themes, plugins, uploads — at a known path. If anything in the new version is broken, you can restore in two commands: mv wp-content wp-content-broken && mv wp-content-old wp-content, then import the database backup. Deleting removes that option.

Updates modify core files and sometimes the database schema. If the update fails or causes incompatibility with a plugin, restoring from a wp db export dump brings the site back to its pre-update state in seconds.

The active theme reads options and postmeta on activation. If those still contain staging URLs, the theme may write them into new records. Fixing URLs first means the theme starts with clean data.

WP-CLI is scriptable and repeatable — the same commands work on local, staging, and CI pipelines. No browser clicks, no upload limits, and easy to document as code.