1 Introduction

In previous articles (see:Home Data Center Series: Making WordPress Sites Static via the Simply Static Plugin), I introduced in detail how to use the Simply Static plugin on WordPress to export a dynamic website into pure static pages with one click. This solution is perfect for building a fully cached backup site, or deploying directly to platforms like Cloudflare Pages to achieve ultimate access speed and security.

Actually, if you only update the website occasionally, clicking the “Generate Static Files” button on the dashboard manually is not a big deal; in fact, for my current update frequency, this method is quite sufficient. However, the problem lies in the word "manual":

• Once the website update frequency is high—like for someone like me who modifies small things almost every other day—it is very easy to forget to click that button.
• Not to mention, if you want to export on a weekly schedule and then automatically sync to a GitHub repository to trigger a redeployment on Cloudflare Pages, it is completely impossible.

Although I still choose to export manually once a week for now, I have also been looking for apossibility of automation. If there is a need to enable a fully automated workflow in the future, then the WordPress command-line tool wp-cli, is undoubtedly the most suitable solution. With wp-cli, I can directly invoke Simply Static's export action via the command line without opening a browser, and even combine it with tools like Git, scheduled tasks, and Docker to build an automated pipeline from a dynamic site to a static site.

Even if you have no plans for automation for the time being, wp-cli itself is highly worth knowing. It is like a “command-line panel” for WordPress, helping us install plugins, update posts, manage users, and more in a faster way... very friendly for those who love using the command line.

Therefore, before diving into the hands-on practice, let's dedicate a separate chapter to talk about wp-cli, as this tool is truly worth mastering.

2 Introduction to the wp-cli Tool

1 What is wp-cli?

Simply put, wp-cli is the Command Line Interface (CLI) for WordPress. It allows you to manage and operate WordPress via the command line, replacing almost most of the work done in the backend dashboard. From an official perspective, the original intention of wp-cli was to improve the maintainability and automation capabilities of WordPress, allowing you to perform various batch operations without opening a browser, which is particularly suitable for the following scenarios:

• CI/CD Workflows: You can use it with GitHub Actions / GitLab CI to perform tasks during the deployment phase.
• Large-scale Multisite Management: A single line of script can execute operations on hundreds of sites.
• Automated O&M Scripts: Such as scheduled data exports, automatic cache clearing, and daily update checks.
• Including what I need to use this time — Invoking the Simply Static plugin for static export

You can think of it as the “script entry point” for WordPress. If your blog is a factory where you usually need to click backend buttons to queue up for processing, now with wp-cli, you can just type commands in the terminal, and the machine starts running immediately. It can be said that for those who pursue ultimate control and automation, wp-cli is an indispensable “superpower” tool for WordPress.

2 Two Deployment Methods for wp-cli

2.2.1 Method 1: Direct Deployment on the WordPress Host (or inside the Docker Container)

This is actually the most conventional way.

• If your WordPress is running directly on a Linux host (such as Debian), you only need to install wp-cli on the host via curl or apt.
• If your WordPress is running inside a Docker container, you can also install wp-cli into that container (usually via RUN curl ... in the Dockerfile).

This way, wp-cli can directly operate WordPress files and read/write the database on the same machine (or inside the same container) without any configuration, which is the most natural way.

The downside is: if the container only has a minimal PHP/FPM built-in, or if you want to keep the application container as “clean” as possible, you might not want to install wp-cli inside it.

2.2 Method 2: Separate Deployment Using the Official wp-cli Docker Image

A more elegant and decoupled way is to use the official wordpress:cli Docker image provided by WordPress. This image comes with: wp-cli and PHP + necessary extensions, without containing a Web service, and is only used to execute CLI commands.

Its principle is actually very simple:

• Start this container via docker run or docker-compose.
• Use -v to mount the WordPress directory from the host machine or another container into this CLI container, allowing it to access wp-config.php and wp-content.
• Then, connect to the same database through environment variables or the existing configuration in wp-config.php.

This satisfies two key points at the same time:

Able to operate WordPress files(such as generating static files, modifying themes, installing plugins)

Able to operate the WordPress database(because wp-cli will read wp-config.php or connect to the database using the --dbhost parameter)

Therefore, as long as the folder is mounted and the database address is reachable (for example, the network of the mysql/mariadb container is visible), wp-cli can work just as if it were running locally.

2.3 Summary

For my goal of “regularly executing Simply Static to generate a static site”, the second method is suitable: running wp-cli separately with a Docker image, which can both mount WordPress files and access the database through the network, making it a very elegant approach.

Although wp-cli provides very powerful command-line operation capabilities, supporting common functions such as plugin management, theme operations, database export/import, and post publishing, it is not a “universal remote control” for WordPress:
• Some plugin or theme settings rely on front-end page interactions or are stored in complex option structures, and wp-cli cannot always handle these configurations precisely.
• Certain features that require user authorization (OAuth) or graphical interface configuration cannot be covered by wp-cli either.
• In addition, when operating the database, wp-cli bypasses part of the logical validation process of the UI layer. Although highly efficient, it may cause data consistency issues or miss necessary side effects.

For example:
• The connection process of the Jetpack plugin involves OAuth authorization redirection from WordPress.com. wp-cli cannot complete the authentication binding via the command line; it can only be manually authorized in the admin dashboard.
• The page structures of visual builders like Elementor are often stored as complex JSON data fragments. Even if reluctantly modified using wp-cli, it is difficult to ensure the accuracy of the front-end layout.
• Some security plugins (such as Wordfence, iThemes Security) dynamically generate configuration files or firewall rules in the background after being enabled, and these mechanisms are likewise not controlled by wp-cli.

Therefore, it is more suitable as a powerful tool for scripting, batch operations, automated deployment, and other scenarios, rather than completely replacing the dashboard operation method.

3 Deployment of the wp-cli Tool

1 Method 1: Direct Deployment on the Host (or inside the Docker Container)

1.1 Installing wp-cli on the Host

If your WordPress is deployed on a server in the most traditional way, such as directly putting the source code in /var/www/html, serving it with nginx or apache, and the database is on the same machine or in the same local area network, then the simplest way is to install wp-cli directly on this host machine. The most common method is to use the official installation script:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info   # 测试一下能不能正常执行
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

php wp-cli.phar --info # Test if it can run normally

wp --info
wp core version

sudo mv wp-cli.phar /usr/local/bin/wp

wp --path=/var/www/html plugin list

1.2 Installing wp-cli inside the WordPress Container

wp --info

docker exec -it your_wordpress_container bash

If you deployed WordPress via source code, you only need to specify the path when executing, which will list your plugin list:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp

Similarly, if you are deploying WordPress using a general container method (such as starting WordPress + MySQL with docker run or docker-compose), you can also install wp-cli inside this WordPress container via apt install or curl. Since this container itself already comes with the PHP runtime environment and the WordPress file directory, as long as you can execute the php command, you can run wp-cli. For example, first enter the container:

docker exec -it your_wordpress_container bash

apt update && apt install curl wget less -y

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info

chmod +x wp-cli.phar

2 Method 2: Separate Deployment Using the Official wp-cli Docker Image

2.1 Deployment via docker-compose

mv wp-cli.phar /usr/local/bin/wp

This way, the wp command can be executed directly inside the container.

wpcli:
    image: wordpress:cli
    container_name: wpcli
    volumes:
      - ./html:/var/www/html
    entrypoint: tail -f /dev/null

apt update && apt install curl wget less -y
And what's more troublesome is that this method is only valid in the current container —
If you execute docker-compose down and then up later, or if a new image is pulled due to WordPress automatic updates, the previously installed tools will all be lost (unless written into the Dockerfile).
• No separate network, database, or other services are bound because most of our operations involve running wp commands to process static files locally or in conjunction with HTTP requests, which is sufficient if no database is involved.

Once this container is deployed, you can enter wp-cli like this:

docker exec -it wpcli bash

Then execute commands directly inside the container, for example:

wp --path=/var/www/html plugin list

The benefits of doing this are:
• Avoids modifying the environment inside the WordPress image;
• Avoids losing wp-cli due to container destruction or image upgrades;
• Easier to manage centrally, and convenient for subsequent automation script encapsulation.

If you want to go a step further, you can also write a dedicated Dockerfile to make some predefinitions, such as configuring parameters like default paths or default URLs. But for most scenarios, using the official image directly is already good enough.

2.2 Deployment via docker-run Command Format

In addition to using docker-compose, you can also use the more direct docker run command to run the official wp-cli image. This method does not require modifying the existing docker-compose.yaml file, nor does it affect the running state of the existing WordPress container, making it a safer choice in environments with high stability requirements.

For example, you can usecommand will also automatically pull the Llama 3.2 model file when Ollama finds it is not available locally, which is actually similar toDirectly execute wp-cli commandswp plugin list：

docker run --rm \
  --volumes-from your-wordpress-container \
  --network container:your-wordpress-container \
  -it wordpress:cli \
  wp plugin list

This command does the following things:
• –rm: Automatically clean up the container after it exits;
• –volumes-from: Reuse the persistent data volumes of the WordPress container;
• –network container:...: Directly join the network namespace of the WordPress container, ensuring that wp-cli commands can connect to the database used by WordPress;
• wordpress:cli: Use the official wp-cli image;
• wp plugin list: Run the example command to list the plugins.

This method is suitable for temporary operations or script calls. It exits immediately after execution, avoiding any changes to the wordpress docker-compose.yaml, keeping it clean, lightweight, and requiring no changes to the deployment structure.

If you need to run multiple wp-cli commands sequentially in the container and do not want the container to exit after each command, do not add the –rm parameter. You can start a persistent wp-cli container like this:

docker run --name wp-cli \
  --volumes-from your-wordpress-container \
  --network container:your-wordpress-container \
  -it wordpress:cli /bin/bash

If you need to enter the container again later to perform operations, you can choose one of the following two methods depending on the situation:

• docker exec -it wp-cli /bin/bash: Enter the container's shell, suitable for executing multiple commands;
• docker start -ai wp-cli: Re-enter the wp-cli container's main process (if the main process is an interactive wp command).

Note: If you stopped the container using docker stop wp-cli, docker start -ai can wake it up again; if the container is still running, it is recommended to use docker exec to enter directly.

If a warning like Undefined array key “HTTP_HOST” appears when executing wp commands, it is generally because some plugins/themes still try to read HTTP header information in CLI mode, which does not exist in the running context of wp-cli.
These warnings do not affect the actual results of the commands and can be ignored. If you need to suppress them, you can consider adjusting PHP's error reporting level by mounting a custom php.ini:

4 Introduction to Common wp-cli Commands

The following are common wp-cli commands and their descriptions, covering common operations such as plugin management, theme management, database, users, cache, etc.

Plugin management related:

Plugin and wp-cli extension support notes

wp plugin list can only display the installation and activation status of plugins, but cannot tell if a plugin provides extended commands for wp-cli. Some well-known plugins (such as WooCommerce, Jetpack, etc.) provide exclusive commands for wp-cli, supporting finer-grained management and operations.

To view all wp-cli commands supported by the current site, you can use:

wp help

Or query help for a specific plugin namespace:

wp help <plugin-slug>

If the plugin documentation or official website does not explicitly state it, you can try the above method to confirm support. This approach can help you discover more advanced command-line usages and improve O&M efficiency.

Theme management related:

User management related:

View site information:

Cache operations related:

Database operations related:

WP core operations related:

This is just the tip of the iceberg for wp-cli; it also has very powerful scripting capabilities. If you are maintaining multiple WordPress sites or planning to implement an automated deployment workflow, diving deep into wp-cli is highly worthwhile.

Note: Many commands support --allow-root 和 --path=/var/www/html and other parameters, which can be adjusted based on your running environment.

5 Using wp-cli to Implement Scheduled Export for Simply Static Pro

1 Overview

This is a live record of me jumping into a pit due to my habit of “researching while recording” as soon as I think of a goal: I originally thought of using wp-cli to regularly execute Simply Static export tasks, but just after excitedly writing a few commands, I found out that the free version doesn't support it at all.Does not support wp-cli：

So this left me hanging in mid-air... But since the pit has already been dug, I will still finish writing the research process, just to remind everyone:Only Simply Static Pro supports wp-cli commands, so free version users shouldn't waste their effort. If you really need free version support for wp-cli commands, you can only switch to a similar veteran plugin ”WP2Static“, though using this software is slightly more complex than Simply Static. I initially chose Simply Static just for simplicity~.

The key command to achieve Simply Static Pro export is:

wp simply-static run --update=true

The purpose of this command is to call the core logic of the plugin and trigger a complete static site export task. It will generate the entire site's HTML files based on the options you currently configured in the backend (such as export path, content to exclude, URL rewriting methods, etc.).

But when using this command, there is aneasy-to-fall-into pitfall, which is the uncertainty of the “export time”. When Simply Static executes an export, the time required for the export is affected by several factors:

• The performance of the host where WordPress is deployed (especially disk I/O and PHP execution efficiency);
• The volume of site content (number of pages, size of media resources);
• Whether certain time-consuming features are enabled in the export settings (such as URL replacement, including media files, etc.);
• Whether it is the first export (the first generation is usually much slower);

In some cases, the export time may only be around 10 minutes, but it could also extend totens of minutes or even several hours due to insufficient resources or too many pagesTherefore, you cannot simply use the “sequential execution” method in traditional shell scripts to run it all at once. For example, you cannot simply write:

wp simply-static run --update=true
git add .
git commit -m "auto update"
git push

This approach will cause subsequent commands to execute before the export is complete, and the final committed content may be incomplete or even empty. Therefore, if you want to automate the export task and chain subsequent operations, you must introduceasynchronous processing or polling detection mechanisms, which means the script needs to determine whether the export has completed before proceeding with subsequent Git commits or deployment operations.

2 Solution 1: Setting a Conservative Timeout

Suitable for:Knowing the approximate export time of your site, or being willing to set a sufficiently redundant waiting time.

Assuming you observed that a full export took 20 minutes during the first execution, you can set the script timeout to 30 minutes or even longer:

#!/bin/bash

# 触发 Simply Static 导出任务
docker run --rm \
  --volumes-from your-wordpress-container \
  --network container:your-wordpress-container \
  -it wordpress:cli \
  wp simply-static run --update=true

# 等待足够长时间，确保导出完成
sleep 1800  # 等待 30 分钟（1800 秒）
cd /your-export-path
git add .
git commit -m "auto update"
git push

Note: After executing the export task for the first time, you can observe the actual time taken and adjust the sleep time reasonably based on that.

3 Solution 2: Polling to Check Export Status (Suitable for Scenarios with Unstable Export Times and High Efficiency Sensitivity)

#!/bin/bash(docker run --rm \"status" | grep -q "completed" && break

Note: This solution is more flexible and reliable, as it can automatically detect whether the export has finished, making it suitable for production environments or sites with highly variable task durations.

4 Summary and Recommendations

For the automated workflow of export + push, there is actually no single correct way. The two solutions provided in this article each have their own applicable scenarios:

• Solution 1 is more suitable for small blogs with low resource usage and fewer plugins, offering simple configuration and sufficient stability;
• Solution 2 is more suitable for situations with complex site structures and numerous plugins, effectively avoiding uncertainties during the export process and being more reliable.

It is recommended to choose flexibly based on the scale and actual situation of your site.

In addition, if you are using Simply Static Pro, you can actually push the exported content directly to a GitHub repository. However, currently we are mainly implementing automation based on WP-CLI, and we are not very clear about the CLI support capabilities of this part of the Pro plugin (mainly because we are too lazy to research~). If its support can be verified in the future, you can also try to call its push logic directly in the CLI to further simplify the entire process.

6 Afterword

If you want to automate WordPress-related functions, wp-cli can play a very big role. For example, I currently export the WordPress database by directly using the docker exec command in the MariaDB container, but with wp-cli, you can directly export the database with a single line of command, for example:

wp db export /var/www/html/wordpress.sql

Compared to executing mysqldump via a database container, this usage of wp-cli is closer to the logic of WordPress itself, and the export path and permission issues are also more controllable.

In addition to database export, wp-cli can also be used to perform many common management operations, such as:

• Activating or deactivating plugins：

wp plugin activate simply-static
wp plugin deactivate akismet

• Installing and activating themes：

wp theme install twentytwentyfour --activate

• Updating plugins/themes/Core：

wp plugin update --all
wp theme update --all
wp core update

• Backend user operations：

wp user list
wp user create newadmin [email protected] --role=administrator

Not to mention the static site export task we mentioned above, which can also be fully scheduled via wp-cli.

Although the main thread of this article is to achieve automated deployment of Simply Static static sites, in fact, wp-cli can become the automation console for the entire WordPress system. Whether you want to back up the database daily, clear the cache, batch-enable plugins, or plan to build a CI/CD automated deployment workflow in the future, wp-cli is one of the most worthwhile tools to master. It is more like an “automation language” for WordPress, freeing you from tedious backend clicks and allowing you to truly manage your site with scripts.

If you are more interested in WordPress automation and operations, it is well worth taking the time to explore the capabilities of wp-cli.