This comprehensive guide covers exactly what WP-CLI is, how to install it, essential WP-CLI commands to manage WordPress from the command line, automation techniques, and security best practices.
As a complete WP-CLI command reference, this guide includes every command category you will use in real WordPress work (plugins, themes, users, databases, multisite, automation, CI/CD, security, and troubleshooting), with example commands and a full cheat sheet at the end.
Bookmark this page and return whenever you need a command.
Reading time: ~38 minutes
Level: Beginner to Advanced
Last updated: June 2026
Part 3 of 4 in the WP-CLI series
Table of Contents
This is Part 3 of the WP-CLI series. Before running any command in this guide, make sure you have read Part 1 and Part 2, which will help you understand what WP-CLI is and how to install it on different operating systems.
Now, confirm if WP-CLI is installed. To do so, open a terminal window and verify the wp command version details:
Sample output:
If you see version and system information, WP-CLI is fully installed and ready to use.
Every WP-CLI command follows the same pattern:
Here are the core commands you will use most often.
To see which version of WordPress is currently installed, run:
Add –extra to see additional details about your installation.
To confirm WordPress is fully installed before running other commands, run:
This confirms whether WordPress is fully installed. It is especially useful inside scripts to prevent errors from running on an incomplete install.
Download the latest WordPress using command:
Sample output would be:
To download a specific version of WordPress (E.g. WordPress 6.7) in a specific language (E.g. English), run:
Replace 6.7 with the version you need, and en_US with your locale code (for example en_GB, fr_FR, or de_DE). Leave both flags out to download the latest version in English.
Generate the wp-config.php file using your database credentials:
Replace my_database, my_user, and my_password with your own values in the above command.
Run the WordPress installer and create the admin account:
Replace the following with your actual values:
This sets up a complete WordPress install in one command. No browser needed.
To see whether a newer version of WordPress is available, run:
To update WordPress to the latest available version, run:
To apply any database structure changes that come with a new WordPress version, run:
Always run this after updating core. It applies any database structure changes the new version requires.
Check every WordPress core file against the official checksums and detect any modifications:
This checks every core file against the official WordPress checksums. Run it if you suspect your installation has been tampered with.
To read or change WordPress settings stored in the options table, use:
Replace “My New Blog Name” with the actual name you want to set.
To read or change constants in your wp-config.php file without opening it manually, use:
Plugin management is one of the most popular uses of WP-CLI. Furthermore, it is significantly faster than the dashboard, especially when you manage multiple sites.
Install a plugin from the WordPress.org plugin repository:
Add –activate to install and activate in one step:
Install a plugin from a ZIP file you have already downloaded (for example, a premium plugin):
This is particularly useful for premium plugins you have downloaded locally.
Install and activate several plugins in a single command:
This removes the plugin files completely, not just deactivates it.
Search WordPress.org for plugins without leaving the terminal:
View the version, description, author, and status of a specific plugin:
Just like plugins, you can fully manage themes from the command line.
To install a theme from WordPress.org and set it as the active theme in one step, run:
View all installed themes and their current status:
Replace twentytwentyfive with the slug of the theme you want to activate. The theme must already be installed.
Update every installed theme to its latest version:
Permanently remove a theme’s files from the server:
Navigation menus are part of your site’s structure. WP-CLI lets you create, list, and populate them without touching the dashboard, which is useful when scripting a full site setup.
See all navigation menus and the theme location they are assigned to using command:
To create a new navigation menu, run:
Replace “Main Navigation” with your preferred menu name.
Add an existing page to a menu by its post ID:
Replace main-navigation with the menu slug (from wp menu list), 42 with the page’s post ID (from wp post list –post_type=page), and “About Us” with the link label.
Add a custom URL to a menu, for example, an external link:
Assign a menu to a registered theme location:
Replace primary with the theme location slug. Run wp menu location list to see all registered locations in your active theme.
To permanently remove a menu and all its items, run:
WP-CLI gives you full control over WordPress users. As a result, you can create, update, delete, and manage roles and passwords without touching the dashboard.
Add a new user to WordPress with a specific role and password:
Replace senthil with the username, senthil@mysite.com with the user’s real email address, and editor with the desired role (administrator, editor, author, contributor, or subscriber).
View all registered users on the site:
Change an existing user’s role:
Replace senthil with the username or user ID, and editor with the new role.
Set a new password for a user:
This is extremely useful when a client loses access and needs a quick password reset. No need to log into the dashboard at all.
Remove a user and reassign their content to another user using command:
The –reassign flag moves that user’s posts to another user ID before deletion. Without it, their posts become unassigned.
Create a batch of dummy users for testing membership plugins or user-based features:
Replace 10 with how many users you need, and subscriber with the role to assign them.
This creates dummy users instantly. It is great for testing membership plugins or user-based features during development.
View every capability assigned to a specific user:
The database is the heart of every WordPress site. WP-CLI makes it easy to query, export, import, and repair the database, without ever opening phpMyAdmin.
Save a full backup of your WordPress database to a .sql file:
Always run this before making major changes. It saves your entire database to a .sql file that you can restore at any time.
Restore a database from a backup file or migrate a site from another server:
Use this to restore a backup or migrate a site from one server to another.
Execute any SQL command directly against the WordPress database:
You can run any valid SQL command directly through WP-CLI.
To find and replace a string across the entire database, for example when migrating to a new domain, run:
This is one of the most powerful commands in WP-CLI. It correctly handles serialized data, something a plain SQL find-and-replace cannot do. Always preview changes first with –dry-run:
To replace across all database tables including custom plugin tables:
Run optimize periodically to keep your database lean and fast. Run check after a server crash to look for corruption.
See how much disk space your database uses:
To wipe all data and drop every table in the WordPress database, run:
Warning: This permanently deletes everything (posts, pages, users, settings, and all content). There is absolutely no undo. Always export your database first with wp db export before running this command.
Clear all cached data stored by WordPress’s object cache (or a caching plugin like Redis or Memcached):
Run this after making changes that should immediately appear on the frontend.
Regenerate WordPress’s URL rewrite rules after changing permalink settings or registering new post types:
Run this after changing your permalink structure or registering new post types.
Remove temporary cached data stored in the database.
Use –expired for routine cleanup. Use –all only when you need a complete cache reset.
Run this after switching themes or adding new image sizes to regenerate all existing images.
WordPress Multisite lets you run a network of sites from one WordPress installation. WP-CLI handles multisite tasks very well, and most operations simply need a small addition to standard commands.
To convert an existing single WordPress install into a multisite network, run:
Apache users: After running this command, you also need to update your .htaccess file with multisite rewrite rules. WP-CLI adds the constants to wp-config.php but does not update .htaccess automatically. Review the WordPress multisite documentation for the correct rewrite rules.
Set up a brand new WordPress multisite installation from scratch with command:
Replace https://your-network-domain.com with your real domain. Do not use example.com – that is a real website. Replace My Network, admin, StrongPassword123, and admin@your-domain.com with your own values.
See every site in your multisite network:
Add a new site to your multisite network:
Replace news with the URL slug for the new subsite (e.g. shop, blog, client1). Replace “News Site” with the site’s display name, and the email with a real address.
Remove a subsite from the network:
Replace 3 with the blog_id of the site you want to delete. Get the correct ID by running wp site list first.
Activate a plugin on every site in the network at once:
The –network flag is the key difference in multisite. Without it, the command only affects the current site.
Use –url to run any command on a specific site within the network:
Replace https://your-network-domain.com/news with the full URL of the subsite you want to target. Get the correct URL from wp site list.
When you onboard a new client to your multisite network, this script handles the full setup in seconds:
To replace the old network domain with a new one across every site in the network, run:
Automation is where WP-CLI truly shines. When you combine it with shell scripts and cron jobs, you can put routine maintenance on complete autopilot.
Create a file called weekly-wordpress-maintenance.sh:
Make it executable:
Test it manually before scheduling:
Open your crontab editor:
Add this line to run every Sunday at 3 AM:
The > /var/log/wp-maintenance.log 2>&1 part saves all output to a log file so you can review it later.
If you frequently set up new sites, this script saves you enormous time:
WP-CLI integrates naturally with the tools modern developers already use. It bridges the gap between WordPress and contemporary DevOps practices.
Docker is one of the best environments to practice WP-CLI safely. You can spin up a disposable WordPress site, run every command you want, and tear everything down without touching a live site.
The docker-compose.yml below uses tmpfs (RAM-only) volumes. As a result, all data wipes automatically the moment you stop the containers. No cleanup needed!
Start the environment:
Run WP-CLI commands:
Tear everything down when you are done:
All containers stop, all data disappears. It is a completely clean slate every time.
You can integrate WP-CLI directly into a GitHub Actions pipeline. This example sets up WordPress, installs your plugin, and runs verification checks on every push:
Source: https://github.com/shivammathur/setup-php
WordPress Studio is a free desktop application for local WordPress development. It comes with WP-CLI pre-configured and ready to use, which is perfect if you want to avoid the command line entirely for local setup. You can download it from: https://developer.wordpress.com/studio/.
wp-cli.yml is a configuration file that sits in your project root and lets you define default values and environment aliases. Instead of typing –path, –url, and –allow-root on every command, you set them once in this file and WP-CLI picks them up automatically.
Create a file called wp-cli.yml in your WordPress root directory:
Now wp plugin list automatically targets that path and URL without any flags.
The most powerful feature of wp-cli.yml is environment aliases. You define @local, @staging, and @production once, then run any command against any environment from your local terminal. No SSH session needed.
To use an alias, prefix your command with @environment:
The wp-cli.yml file should be committed to version control. If it contains sensitive SSH credentials, use wp-cli.local.yml instead. WP-CLI reads both files, and .local.yml is ignored by Git if you add it to .gitignore.
WP-CLI’s functionality does not stop at built-in commands. You can extend it with community-created packages that add entirely new capabilities.
Packages are third-party command sets for WP-CLI, similar to plugins for WordPress itself. The official package index lives at https://wp-cli.org/package-index/.
Doctor: site health diagnostics:
This runs comprehensive health checks covering file permissions, core integrity, and common configuration issues.
Profile: performance profiling:
This identifies slow plugins, themes, and database queries. It is extremely useful when you need to find what is slowing a site down.
Login Command: instant magic login links:
This generates a one-time login URL that logs you in without a password. It is perfect for quick admin access during development.
Dist-Archive: create distribution ZIP files:
Find: advanced content search:
Only install packages from trusted sources. Packages have full access to your WordPress files and database. Packages from the official index are generally safe, but always review the source before installing anything you do not recognize.
Beyond packages, you can write custom commands directly inside your theme or plugin. Custom commands are especially valuable for agencies that manage many client sites with similar requirements.
Custom commands are useful for:
Add this to your theme’s functions.php or a plugin file:
Use your new commands:
Use it:
For long-running operations, a progress bar keeps the user informed:
For the complete command creation guide, visit: https://make.wordpress.org/cli/handbook/guides/commands-cookbook/.
wp scaffold generates boilerplate code for plugins, themes, and other WordPress components. Instead of copying a starter template manually, you run one command and get a correctly structured starting point instantly.
To generate a plugin with a standard file structure, readme, and PHPUnit test setup, run:
Replace my-plugin with your plugin slug and fill in the other details. WP-CLI creates the folder, the main PHP file, readme.txt, and a basic test directory. Add –activate to activate it immediately after scaffolding.
To generate a child theme based on an existing parent theme, run:
Replace my-child-theme with your slug and twentytwentyfive with the installed parent theme’s slug.
Generate the code for registering a custom post type inside a plugin or theme:
WP-CLI outputs the registration code directly to the terminal. Copy it into your plugin or theme file. This saves writing the register_post_type() boilerplate by hand and ensures the arguments follow WordPress standards.
Generate the code for registering a custom taxonomy:
WP-CLI is a powerful tool, and with that power comes real security responsibility.
Running WP-CLI as root creates files that the web server cannot modify later. It also poses a serious security risk. Instead, find your web server user and run commands as that user:
Only authorized users should have SSH access to servers where WP-CLI runs. WP-CLI has full access to your WordPress files and database, so a compromised SSH account means a compromised site. Use SSH keys instead of passwords for all authentication.
WP-CLI reads database credentials from wp-config.php automatically. Do not hardcode passwords into your shell scripts. Instead, use environment variables or rely on wp-config.php directly.
Set strict permissions on your config file so only the web server user can read it:
Test dangerous commands before you commit to them:
This shows exactly what would change without actually changing anything.
Run a database export before any of these operations:
Do this before search-replace operations, WordPress version updates, plugin updates on production, and any database structure changes.
When you redirect WP-CLI output to log files, use –no-color to keep the logs readable:
WP-CLI is powerful, but it is also unforgiving. Understanding its limitations helps you avoid costly mistakes.
Command-line operations are permanent. Unlike the WordPress dashboard, there is no trash bin or revision history. For example, wp db reset deletes your entire database after just one confirmation. A single typo can cost you all your data. Because of this, always back up before running any destructive command.
WordPress stores some data in serialized PHP format. A naive string replacement breaks it and causes silent failures – plugins stop working, widget settings disappear, and theme options reset, even though the site still loads.
WP-CLI handles serialized data correctly when you use it properly. However, always use –dry-run first and test on a staging site before running on production.
If you run WP-CLI as root or the wrong system user, it creates files your web server cannot read or write. As a result, WordPress cannot upload media or update its own files. Always run as www-data, apache, or whichever user your web server runs under.
New plugin versions sometimes introduce bugs or compatibility issues. Moreover, updating 50 plugins at once makes it impossible to identify which one caused a problem. Because of this, always test updates on staging before running them on production. On high-traffic production sites, update plugins one at a time.
WP-CLI trusts you completely. It executes whatever command you give it. For instance, wp post delete $(wp post list –format=ids) deletes every post on your site with only one confirmation prompt. Double-check every command, especially those using subshell substitution, before you press Enter.
Search-replace on a multi-gigabyte database takes a long time. If your SSH connection times out mid-operation, the database ends up in an inconsistent state. To prevent this, wrap long-running commands in a screen or tmux environment:
If your connection drops, reconnect with screen -r wp-migration and the command keeps running.
Symptom: “Permission denied” errors in WordPress. Cannot upload media or update plugins through the admin.
Fix:
Symptom: Data loss after search-replace or database reset with no way to recover.
Fix: Make this a habit. Backup first, and then make changes:
Symptom: “Error: This does not seem to be a WordPress install.”
Fix: Navigate to the WordPress root directory first, or use –path:
Symptom: Plugin settings break, widgets disappear, theme options reset after a search-replace.
Fix: Always preview first:
Symptom: Later commands in a script run against a broken state because an earlier command failed silently.
Fix: Add error handling to every script:
Symptom: Site breaks after a plugin update at 3 AM.
Fix: Use a staging-first workflow:
Symptom: Automated scripts appear to run but nothing actually changes.
Fix: Always redirect output to a log file and review it:
You are not in the WordPress root directory. Navigate there, or use –path:
Your wp-config.php has incorrect credentials. Verify them:
WordPress is not fully installed. Run the full install command:
Install the missing extensions:
Run WP-CLI as the web server user, or fix file ownership:
Increase the PHP memory limit for that single command:
Or increase it permanently in your php.ini:
Every WP-CLI command has detailed built-in documentation:
WP-CLI is not always the right tool. Use the WordPress admin dashboard when:
A: Yes. WP-CLI is completely free and open source, maintained under the MIT license by the WordPress community. You can use it on unlimited sites without any cost.
A: It depends on the host. Kinsta, WP Engine, Cloudways, and Pressable all support WP-CLI through SSH. However, some budget shared hosts block SSH entirely. Always check your hosting documentation before assuming it works.
A: SSH is the connection protocol that gives you terminal access to your server. WP-CLI is the tool you use inside that terminal to manage WordPress specifically. You need SSH to reach your server, then you use WP-CLI to interact with WordPress.
A: Yes, if you misuse it. Commands like wp db reset, wp post delete –all, or an incorrect search-replace can cause permanent data loss. Because of this, always take a database backup before running commands that modify data, and use –dry-run to preview destructive commands first.
A: Not for most tasks. The majority of WP-CLI commands follow a simple, readable pattern and are easy to learn within a day. That said, basic shell scripting knowledge helps if you want to build automation scripts. Creating custom commands requires PHP knowledge.
A: WP-CLI requires PHP 7.2.24 or later. Always verify your PHP version with php –version before installing.
A: Yes. Docker is actually one of the best environments to practice WP-CLI safely. The official wordpress:cli Docker image makes setup simple, and using tmpfs volumes means everything disappears automatically when you stop the containers. No leftover test data anywhere.
A: Yes. Use the –ssh flag to run commands on a remote server directly from your local machine:wp plugin update –all –ssh=user@yourserver.comNo need to SSH in first. WP-CLI handles the connection itself.
A: Check for updates monthly with wp cli check-update and apply them with wp cli update. Staying current ensures you get bug fixes and compatibility with the latest WordPress versions.
A: Yes. Use cron jobs for scheduled automation and shell scripts for complex multi-step workflows. This combination is one of the most powerful aspects of WP-CLI.
WP-CLI is one of the most valuable tools in any WordPress developer’s toolkit. Whether you manage one site or a hundred, WP-CLI makes the work faster, cleaner, and more reliable. Moreover, when you combine it with shell scripts, cron jobs, and CI/CD pipelines, you build a WordPress workflow that practically runs itself. Once you start using it, going back to clicking through dashboards feels slow and inefficient.
The most important habits to build from day one are simple: back up before major changes, use –dry-run before destructive commands, and always run as the web server user. Do those three things consistently, and WP-CLI becomes genuinely indispensable.
Start small. Pick three or four commands from this guide and practice them on a test site, ideally a Docker environment so you can experiment freely without risk. After a short time, you will reach for the terminal naturally, and tasks that used to take minutes will take seconds.
Found this guide helpful? Share it with a fellow WordPress developer. And if you have a favourite WP-CLI tip not covered here, drop it in the comments below. We will review and update the guide.
WP-CLI Official Resources:
Senthilkumar Palani (aka SK) is the Founder and Editor in chief of OSTechNix. He is a Linux/Unix enthusiast and FOSS supporter. He lives in Tamilnadu, India.
Save my name, email, and website in this browser for the next time I comment.
Δdocument.getElementById(“ak_js_1”).setAttribute(“value”,(new Date()).getTime())
This site uses Akismet to reduce spam. Learn how your comment data is processed.
About The Author
