WP-CLI: manage WordPress from the terminal

WP-CLI lets you query and manage WordPress from the terminal. Use it with the account's user and in the correct installation: many commands can change data without showing a confirmation form.

Installing WP-CLI

Connect via SSH and first check whether it is available:

command -v wp
wp --info

If it is missing, follow the official installation with a compatible PHP. To install it through Composer in your account, use the full bundle:

composer global require wp-cli/wp-cli-bundle
composer global config bin-dir --absolute

The second command shows the executables folder. If wp is not found, add it to the PATH and check wp --info again. The terminal PHP may differ from the web PHP; do not ignore Composer requirements to force the installation.

Before running commands that change data

Move to the correct root and check its identity:

pwd
wp core version
wp option get home
wp option get siteurl

Prepare a backup of files and database. This example exports SQL to a private directory outside the public root; replace the path before running it and do not reuse an existing backup name:

umask 077
wp db export /RUTA_PRIVADA_FUERA_DEL_WEBROOT/wp-antes-del-cambio.sql
sha256sum /RUTA_PRIVADA_FUERA_DEL_WEBROOT/wp-antes-del-cambio.sql

Keep the file and checksum outside the hosting and test recovery. The checksum lets you detect changes to the file; it does not prove the backup is complete or restorable.

Rehearse changes on a clone, use --dry-run when available and review the scope before removing it. If there are continuous writes, plan how to avoid losing them in a rollback.

Installing WordPress

In an empty, protected destination, download the core:

wp core download

First create a dedicated SQL database and user. Replace the example values and enter the password at the prompt:

wp config create --dbname=base_datos \
  --dbuser=usuario \
  --dbhost=localhost \
  --dbprefix=wp_ \
  --prompt=dbpass

Set up the site with its own administrator account:

wp core install --url=https://dominio.example \
  --title=Site \
  --admin_user=administrador_ejemplo \
  --admin_email=administrador@dominio.example \
  --prompt=admin_password

The domains and users are examples. Do not put passwords in arguments or publish them in logs. Check HTTPS and access before removing the destination's protection.

Reinstalling WordPress

A reinstall must keep the version and language if you only want to repair files. Replace the checked placeholders:

wp core download --version=VERSION_INSTALADA --locale=LOCALE_INSTALADO --skip-content --force
wp core verify-checksums --include-root

--force overwrites the package's files, but does not remove every stray file. Without an explicit version you may download a different one. This does not by itself clean up an intrusion in plugins, users or the database.

Change the main WordPress URL

For a single-site installation where WordPress and the public website share a root, these commands change the values in the database:

wp option update home 'https://nuevodominio.example'
wp option update siteurl 'https://nuevodominio.example'

If the core is in another subdirectory, the two values may differ. Also review constants in wp-config.php, Multisite, DNS and certificates. Changing options does not replace every reference inside the content.

Listing plugins

wp plugin list

Check the slug, status and version. If a plugin prevents WordPress from starting, some queries accept --skip-plugins; mu-plugins may still load. It is not a repair of the component.

Installing plugins

Find the official slug and check compatibility before installing:

wp plugin search 'search term'
wp plugin install SLUG_DEL_PLUGIN

Installing and activating are separate actions. Add --activate only when you want to activate that component and have checked its dependencies. For a commercial ZIP, use the vendor's verifiable package; do not expose download keys in the history.

Deactivating one or more plugins

wp plugin deactivate SLUG_DEL_PLUGIN

Replace the placeholder with the real slug. --all affects every plugin in scope: it can stop payments, security or forms. In Multisite, also check network activation. Do not bulk-deactivate on an open shop to test a hypothesis.

Updating plugins

wp plugin update SLUG_DEL_PLUGIN --dry-run

Review the proposed updates, prepare the backup and rehearse the change. To apply it, run it again without --dry-run only within the tested procedure. Check that the plugin works afterwards; a successful output does not prove the business process.

Bulk search and replace in the database

WP-CLI can handle serialised data, but the scope is still decisive. This example limits the dry run to two tables; replace their names if the prefix is different:

wp search-replace 'https://antiguo.example' 'https://nuevo.example' wp_posts wp_postmeta \
  --skip-columns=guid --precise --report-changed-only --dry-run

Review the report and samples before running it again without --dry-run. It is not a complete migration: options, plugin tables and a Multisite network may need other handling. GUIDs should not be changed as a matter of routine when moving the site. See the search-replace reference.

Regular expressions and HTML content

--regex accepts patterns, but it does not turn a regular expression into an HTML parser. The old example for removing iframes could match other blocks or miss variants; do not run it in bulk without a checked selection.

To remove a specific iframe, first identify the posts and the field, and change the exact block through the application's API or editor. If you need to automate variable HTML, prepare a script that recognises the element and its URL and compares before and after on samples, including cases that must not change. A count of matches is not enough.

Importing and exporting the database

wp db export and wp db import work with the configured connection. An import can replace tables or mix data. Test the restore on a new database, from a clone that explicitly points to it; check schema, content and features before the final switchover.

Keep the previous database intact during the recovery period and keep SQL files outside public directories. Do not import an old backup over a shop that is still receiving orders.

Listing wp-cron events

wp cron event list

Shows scheduled events, next run and recurrence. It is not a history of completed runs and does not prove a task finished successfully. Compare overdue events with the cron mechanism and the application's logs; running tasks manually can send emails or perform other actions.