管理画面を開かずに、コマンドでWordPressを操作するのが WP-CLI です。プラグインの一括更新、URLの一括置換、DBのバックアップ、ログインできなくなったときのパスワード再設定。管理画面だと詰む場面が、だいたい片づきます。
自分はプラグインを作って配っているので、テスト環境を毎日のように作り直します。手でやっていた頃と比べて、時間の使い方が変わりました。
この記事は、必要なときに開いて、該当箇所をコピーして帰るための一覧として書いています。上から読む必要はありません。目次から探してください。
先に、いちばんよく使う10個だけ置いておきます。ここだけで足りることも多いです。
wp --info # 動作確認
wp core version # WordPressのバージョン
wp plugin list # プラグイン一覧
wp plugin update --all # プラグイン全部更新
wp user list # ユーザー一覧
wp user update admin --user_pass='新パスワード' # パスワード再設定
wp db export backup.sql # DBバックアップ
wp search-replace '旧URL' '新URL' --dry-run # URL置換（まず確認）
wp cache flush # オブジェクトキャッシュ削除
wp rewrite flush # パーマリンク再構築
先に、危ないコマンドを書いておきます
順番として、こちらを先に読んでください。取り消せない操作があります。
# ❌ 確認なしで実行しない
wp db reset --yes # DBを空にする。サイトが消える
wp db import dump.sql # 現在のDBを上書きする
wp search-replace 'a' 'b' # --dry-run なしは即座に本番を書き換える
wp post delete 123 --force # ゴミ箱を経由せず完全削除
wp plugin delete --all # プラグインを全部消す
対策は3つです。
破壊的な操作の前に、必ず wp db export を取る。 数秒で終わります。
search-replace は --dry-run を先に付ける。 何件変わるかだけが表示されて、実際には書き換わりません。
--yes を癖で付けない。 確認プロンプトは、事故を止めるためにあります。
自分は一度、テスト環境のつもりで本番に search-replace を打ちかけたことがあります。--dry-run で気づきました。付ける習慣がなかったら、と考えるとひやっとします。
インストール
一般的なサーバー / ローカル
# 1. 実行ファイルをダウンロード
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
# 2. 動くか確認
php wp-cli.phar --info
# 3. 実行権限をつけて、パスの通った場所へ
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
# 4. 確認
wp --info
wp --info で、PHPのバージョン、WP-CLIのバージョン、設定ファイルの場所が出ます。ここまで出れば入っています。
sudo が使えない共有サーバー
/usr/local/bin に置けない環境もあります。その場合はホームディレクトリに置いて、パスを通します。
mkdir -p ~/bin
mv wp-cli.phar ~/bin/wp
chmod +x ~/bin/wp
echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
wp --info
エックスサーバーなど、国内のレンタルサーバーには最初から入っていることもあります。まず wp --info を打ってみて、動けばインストールは不要です。
更新
wp cli update # 最新の安定版へ
wp cli update --nightly # 開発版（普段は不要）
wp cli version
コマンドの形
wp <コマンド> <サブコマンド> [引数] [--オプション]
たとえば wp plugin install akismet --activate なら、コマンドが plugin、サブコマンドが install、引数が akismet、オプションが --activate です。
どこで実行するか
WordPressがインストールされたディレクトリ（wp-config.php がある場所）で実行するのが基本です。別の場所から実行するなら --path を付けます。
wp --path=/var/www/html/wordpress plugin list
よく使う共通オプション
| オプション | 何をするか |
|---|---|
--path=<dir> |
WordPressの場所を指定 |
--url=<url> |
マルチサイトで対象サイトを指定 |
--allow-root |
root で実行するとき（本来は非推奨） |
--skip-plugins |
プラグインを読み込まずに実行 |
--skip-themes |
テーマを読み込まずに実行 |
--skip-packages |
WP-CLIの追加パッケージを読み込まない |
--quiet |
余計な出力を抑える |
--format=<型> |
出力形式（table / csv / json / yaml / ids / count） |
--field=<名> |
指定した列だけ出す |
--fields=<名,名> |
複数列を指定 |
--debug |
詳細なログを出す |
--skip-plugins は、あとで出てくるトラブル切り分けで効きます。覚えておくと得です。
出力形式を変える
スクリプトに組み込むときに使います。
wp plugin list --format=json
wp plugin list --format=csv
wp post list --format=ids # IDだけをスペース区切りで
wp post list --format=count # 件数だけ
wp plugin list --field=name # 名前だけを1行ずつ
wp plugin list --fields=name,status,version
--format=ids は、他のコマンドに流し込むときに使います。
# 全リビジョンを完全削除する（先にバックアップを）
wp post delete $(wp post list --post_type=revision --format=ids) --force
コア（WordPress本体）
wp core version # バージョン確認
wp core version --extra # DBリビジョンなども表示
wp core check-update # 更新があるか
wp core update # 本体を更新
wp core update --version=6.9 # バージョンを指定して更新
wp core update-db # DBスキーマの更新（本体更新後に必要なことがある）
wp core verify-checksums # 改ざん・破損チェック
wp core download --locale=ja # 日本語版のファイル一式を取得
wp core install \
--url=https://example.com \
--title="サイト名" \
--admin_user=admin \
--admin_password='パスワード' \
--admin_email=you@example.com
wp core verify-checksums は、覚えておくと安心なコマンドです。本体ファイルが公式の配布物と一致しているかを照合します。改ざんが疑われるとき、まずこれを打ちます。
新規構築を1行でやるなら、こうなります。
wp core download --locale=ja && \
wp config create --dbname=wp --dbuser=root --dbpass=pass && \
wp core install --url=localhost --title="test" \
--admin_user=admin --admin_password=pass --admin_email=a@b.c
設定ファイル（wp-config.php）
wp config create --dbname=wp --dbuser=root --dbpass=secret
wp config get # 定数の一覧
wp config get DB_NAME # 特定の定数
wp config set WP_DEBUG true --raw # true を文字列でなく真偽値として書く
wp config set WP_DEBUG_LOG true --raw
wp config delete WP_DEBUG
wp config has WP_CACHE # 存在確認（スクリプトで使う）
wp config shuffle-salts # 認証キーを再生成（全ログアウトされる）
--raw を付けないと、'true' という文字列として書き込まれます。真偽値や数値を設定するときは必ず付けます。
wp config shuffle-salts は、乗っ取りが疑われるときに打つコマンドです。全セッションが切れるので、ログインし直しになります。
プラグイン
wp plugin list # 一覧
wp plugin list --status=active # 有効なものだけ
wp plugin list --update=available # 更新があるものだけ
wp plugin install akismet # インストール
wp plugin install akismet --activate # インストールして有効化
wp plugin install ./my-plugin.zip --force # ローカルのzipから（上書き）
wp plugin install https://example.com/p.zip # URLから
wp plugin activate akismet
wp plugin deactivate akismet
wp plugin deactivate --all # 全部無効化（切り分けで使う）
wp plugin update akismet
wp plugin update --all # 全部更新
wp plugin delete akismet # 削除（無効化されている必要はない）
wp plugin status akismet
wp plugin search cache --per-page=5 # 公式ディレクトリを検索
wp plugin verify-checksums --all # 改ざんチェック
wp plugin is-active akismet && echo "有効" # スクリプト用（終了コードで判定）
実務でよく使う組み合わせ
# 更新があるものだけ一覧にして、目で見てから更新する
wp plugin list --update=available --fields=name,version,update_version
# 全部更新してから、サイトが生きているか確認
wp plugin update --all && curl -sI https://example.com | head -1
# 有効なプラグインの一覧をファイルに残しておく（切り分けの前に）
wp plugin list --status=active --field=name > active-plugins.txt
# ファイルの一覧から、まとめて有効化し直す
xargs wp plugin activate < active-plugins.txt
テーマ
wp theme list
wp theme install twentytwentyfive
wp theme install twentytwentyfive --activate
wp theme activate twentytwentyfive
wp theme update --all
wp theme delete oldtheme
wp theme mod list # テーマの設定値
wp theme mod get custom_logo
wp theme mod set custom_logo 123
wp theme mod remove --all
テーマを切り替えると表示が壊れることがあるので、切り替え前に現在のテーマを控えておきます。
wp theme list --status=active --field=name
投稿・固定ページ
wp post list # 一覧
wp post list --post_type=page # 固定ページ
wp post list --post_type=post --post_status=draft
wp post list --format=ids # IDだけ
wp post list --fields=ID,post_title,post_date --format=csv
wp post get 123 # 1件の詳細
wp post get 123 --field=post_content # 本文だけ
wp post create --post_title="タイトル" --post_content="本文" --post_status=publish
wp post create ./article.md --post_title="記事" # ファイルから本文を読む
wp post update 123 --post_status=draft
wp post delete 123 # ゴミ箱へ
wp post delete 123 --force # 完全削除
wp post generate --count=20 # ダミー記事を作る（テスト用）
メタ（カスタムフィールド）
wp post meta list 123
wp post meta get 123 my_key
wp post meta update 123 my_key "値"
wp post meta delete 123 my_key
wp post meta add 123 my_key "値"
一括操作の例
# 下書きを全部ゴミ箱へ
wp post delete $(wp post list --post_status=draft --format=ids)
# リビジョンを全部完全削除（DBが太っているとき）
wp post delete $(wp post list --post_type=revision --format=ids) --force
# 特定カテゴリの記事IDを取る
wp post list --category_name=news --format=ids
$( ) で囲んだコマンドの結果が空だと、エラーになります。件数を先に確認しておくと安全です。
wp post list --post_type=revision --format=count
ユーザー
管理画面に入れなくなったとき、いちばん助かるのがここです。
wp user list
wp user list --role=administrator
wp user list --fields=ID,user_login,user_email,roles --format=table
wp user get 1
wp user create bob bob@example.com --role=editor --user_pass='パスワード'
wp user update admin --user_pass='新しいパスワード' # パスワード再設定
wp user update 1 --user_email=new@example.com
wp user add-role 5 editor
wp user remove-role 5 editor
wp user set-role 5 administrator
wp user delete 5 --reassign=1 # 投稿を ID=1 に引き継いで削除
wp user reset-password admin # リセットメールを送る
管理画面にログインできないとき
順番に試します。
# 1. 管理者が存在するか
wp user list --role=administrator
# 2. いなければ作る
wp user create rescue rescue@example.com --role=administrator --user_pass='一時パスワード'
# 3. いるならパスワードを再設定
wp user update admin --user_pass='新しいパスワード'
# 4. それでもだめならプラグインが原因の可能性
wp plugin deactivate --all
自分は、テスト環境でパスワードを忘れるたびに3番を打っています。メールが飛ばない環境だと、これしか方法がありません。
オプション（設定値）
wp option get siteurl
wp option get home
wp option update blogname "新しいサイト名"
wp option update blogdescription "説明"
wp option list --search="myplugin_*" # プラグインの設定を探す
wp option delete myplugin_settings
wp option add my_key "値"
wp option get myplugin_settings --format=json # 配列の中身を見る
サイトURLを変える
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'
ただし、これだけでは記事本文の中のURLは変わりません。そちらは後述の search-replace です。
表示が重いときに見る場所
WordPressは、autoload が有効なオプションを毎回のリクエストで全部読みます。ここが太っていると、全ページが遅くなります。
# autoload されているオプションを、大きい順に見る
wp db query "SELECT option_name, LENGTH(option_value) AS size
FROM $(wp db prefix)options
WHERE autoload='yes'
ORDER BY size DESC LIMIT 20"
数百KBのオプションが autoload='yes' で居座っていることがあります。プラグインが残した設定や、肥大化したキャッシュが多い。犯人が分かったら、そのプラグインの設定を見直すか、値を autoload='no' に変えます。
wp db query "UPDATE $(wp db prefix)options
SET autoload='no' WHERE option_name='重いキー'"
変更前にバックアップを取ってください。 プラグインが autoload を前提にしていると、動かなくなることがあります。
transient（一時データ）
wp transient list
wp transient get my_key
wp transient delete my_key
wp transient delete --all # 全部消す
wp transient delete --expired # 期限切れだけ消す
期限切れのtransientはDBに残り続けます。定期的に --expired を打つだけで、DBが少し軽くなります。
データベース
wp db export backup.sql # バックアップ
wp db export - | gzip > backup.sql.gz # 圧縮しながら
wp db import backup.sql # 復元（現在のDBを上書き）
wp db check # 整合性チェック
wp db optimize # 最適化
wp db repair # 修復
wp db size # DBサイズ
wp db size --tables --human-readable # テーブルごとのサイズ
wp db prefix # テーブル接頭辞
wp db tables # テーブル一覧
wp db query "SELECT COUNT(*) FROM $(wp db prefix)posts"
wp db cli # MySQLクライアントに入る
wp db reset --yes # ⚠️ DBを空にする
どのテーブルが太っているか
wp db size --tables --human-readable
postmeta や options が突出していることが多いです。postmeta が太っているなら、削除したプラグインのメタが残っている可能性があります。
URLの一括置換（サーバー移転・SSL化）
WP-CLIでいちばん価値があるコマンドが、これだと思います。
# 1. まず必ずバックアップ
wp db export before-replace.sql
# 2. 必ず dry-run で確認
wp search-replace 'http://old.example.com' 'https://new.example.com' --dry-run
# 3. 問題なければ実行
wp search-replace 'http://old.example.com' 'https://new.example.com'
なぜ手作業のSQLではだめなのか
WordPressは、設定値をシリアライズした文字列としてDBに保存します。この文字列には長さの情報が含まれています。
a:1:{s:21:"http://old.example.com";}
↑ この 21 が文字数
phpMyAdminなどで単純に置換すると、URLの長さが変わっても数字が21のままになります。結果、そのデータは読めなくなって、設定が丸ごと消えたように見えます。
wp search-replace は、シリアライズを解いてから置換し、正しい長さで書き戻します。これが手作業との決定的な差です。
よく使うオプション
wp search-replace 'old' 'new' --dry-run # 確認のみ
wp search-replace 'old' 'new' --all-tables # 接頭辞外のテーブルも対象
wp search-replace 'old' 'new' --precise # PHPで厳密に処理（遅いが確実）
wp search-replace 'old' 'new' --recurse-objects # 入れ子のオブジェクトも
wp search-replace 'old' 'new' --skip-columns=guid # guid は変えないのが定石
wp search-replace 'old' 'new' wp_posts wp_postmeta # テーブルを限定
wp search-replace 'old' 'new' --export=changes.sql # 適用せずSQLに書き出す
guid は、フィードの識別子として使われる値で、変更しないのが慣例です。変えると、フィードリーダーが全記事を新着として再配信することがあります。移転のときは --skip-columns=guid を付けておくと安全です。
移転の実務手順
# 旧サーバーで
wp db export dump.sql
tar czf files.tar.gz wp-content/
# 新サーバーで
wp db import dump.sql
tar xzf files.tar.gz
wp search-replace 'http://old.example.com' 'https://new.example.com' \
--skip-columns=guid --dry-run
wp search-replace 'http://old.example.com' 'https://new.example.com' \
--skip-columns=guid
wp cache flush
wp rewrite flush
メディア
wp media import ./photo.jpg # ファイルをメディアに追加
wp media import ./photo.jpg --post_id=123 # 記事に紐づける
wp media import ./photo.jpg --featured_image # アイキャッチにする
wp media import 'https://example.com/a.jpg' # URLから
wp media regenerate # サムネイル再生成
wp media regenerate --yes # 確認なしで
wp media regenerate 123 456 # 指定IDだけ
wp media regenerate --only-missing # 欠けているものだけ
テーマを変えて画像サイズが変わったときは wp media regenerate です。枚数が多いと時間がかかるので、--only-missing から試すと速く終わります。
キャッシュ・パーマリンク
wp cache flush # オブジェクトキャッシュを消す
wp cache type # 使われているキャッシュの種類
wp transient delete --all # transient を全部消す
wp rewrite flush # パーマリンクを再構築
wp rewrite flush --hard # .htaccess も書き直す
wp rewrite list # ルールの一覧
wp rewrite structure '/%postname%/' # パーマリンク構造を変更
「404になる」の多くは wp rewrite flush で直ります。 移転直後、パーマリンク変更後、カスタム投稿タイプを追加した直後。まずこれを打ちます。
Cron（予約実行）
WordPressの wp-cron は、誰かがサイトにアクセスしたときに動く疑似cronです。アクセスが少ないサイトでは、予約した処理が遅れます。
wp cron event list # 予約されている処理の一覧
wp cron event list --due-now # 実行時刻を過ぎているもの
wp cron event run --due-now # 期限が来たものを実行
wp cron event run my_hook # 指定したフックを実行
wp cron event delete my_hook
wp cron event schedule my_hook now hourly
wp cron schedule list # 使える間隔の一覧
wp cron test # wp-cron が動く状態か確認
実サーバーのcronに寄せる
アクセスに依存させたくない場合、wp-cron を止めて、サーバーのcronから叩きます。
# wp-config.php で疑似cronを止める
wp config set DISABLE_WP_CRON true --raw
# crontab -e に追加（5分おき）
*/5 * * * * cd /var/www/html && /usr/local/bin/wp cron event run --due-now --quiet
予約投稿が遅れる、定期処理が動かない、というときは、まず wp cron test と wp cron event list --due-now を見ます。
メンテナンスモード
wp maintenance-mode activate
wp maintenance-mode deactivate
wp maintenance-mode status
wp maintenance-mode is-active && echo "メンテ中"
更新作業を挟むときに使います。更新が途中で止まって .maintenance ファイルが残り、サイトがメンテ表示のままになることがありますが、deactivate で解除できます。
マルチサイト
wp site list
wp site list --field=url
wp site create --slug=blog2 --title="ブログ2"
wp site delete 3
wp --url=https://example.com/blog2 plugin list # サイトを指定して実行
wp plugin activate akismet --network # ネットワーク全体で有効化
wp user set-role 5 administrator --url=https://example.com/blog2
全サイトに同じ操作をするなら、ループします。
for url in $(wp site list --field=url); do
echo "--- $url"
wp --url="$url" plugin update --all
done
トラブルシューティング
Error: This does not seem to be a WordPress installation
実行した場所にWordPressがありません。
cd /var/www/html # WordPressのディレクトリへ
# または
wp --path=/var/www/html plugin list
プラグインが原因かどうかの切り分け
WP-CLIは、実行時にWordPressを読み込むので、壊れたプラグインがあるとWP-CLI自体が動かなくなります。そんなときに --skip-plugins が効きます。
# プラグインを読み込まずに実行
wp --skip-plugins plugin list
# テーマも外す
wp --skip-plugins --skip-themes option get siteurl
# 特定のプラグインだけ外す
wp --skip-plugins=heavy-plugin post list
これで動くなら、原因はプラグインかテーマです。あとは半分ずつ有効化して絞り込みます。
wp plugin deactivate --all
wp plugin activate プラグインA プラグインB # 半分ずつ戻す
PHPのメモリ不足
php -d memory_limit=512M "$(which wp)" media regenerate
wp の前にPHPの設定を差し込みます。wp はPHPスクリプトなので、この形で実行できます。
root で実行すると怒られる
wp --allow-root plugin list
ただし、これは本来避けるべきです。ファイルの所有者がrootになって、あとでWordPressがファイルを書けなくなることがあります。可能なら、Webサーバーと同じユーザーで実行します。
sudo -u www-data wp plugin list
出力を静かにする
cronやCIから呼ぶときに使います。
wp plugin update --all --quiet
wp cron event run --due-now --quiet
そもそも何が起きているか見たい
wp plugin list --debug
読み込まれている設定ファイルや、実行の詳細が出ます。
設定ファイルで楽をする
プロジェクトのルートに wp-cli.yml を置くと、毎回のオプション指定を省けます。
# wp-cli.yml
path: wordpress
url: https://example.com
# コマンドごとの既定値
core config:
dbuser: root
dbpass: secret
dbname: wp
post list:
format: csv
これがあると、wp --path=wordpress --url=... plugin list が wp plugin list で済みます。
別のサーバーを、手元から操作する
@エイリアス を定義すると、SSH越しに実行できます。
# ~/.wp-cli/config.yml
@prod:
ssh: user@example.com/var/www/html
@stg:
ssh: user@staging.example.com/var/www/html
@all:
- @prod
- @stg
wp @prod plugin list # 本番のプラグイン一覧
wp @stg db export dump.sql # ステージングのバックアップ
wp @all core version # 両方のバージョンを確認
複数サイトを管理しているなら、これがいちばん時間を返してくれる機能だと思います。
便利な組み合わせ
毎朝の状態確認をひとまとめに
#!/usr/bin/env bash
set -euo pipefail
cd /var/www/html
echo "== バージョン"
wp core version
echo "== 更新があるもの"
wp core check-update --format=count
wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available --fields=name,version,update_version
echo "== 期限切れのcron"
wp cron event list --due-now --format=count
echo "== DBサイズ"
wp db size --human-readable
更新の前後でバックアップを取る
#!/usr/bin/env bash
set -euo pipefail
cd /var/www/html
STAMP=$(date +%Y%m%d-%H%M%S)
wp db export "backup-${STAMP}.sql"
wp plugin update --all
wp theme update --all
wp core update
wp core update-db
wp cache flush
wp rewrite flush
# 生きているか確認（200が返らなければ失敗として扱う）
curl -fsSI https://example.com > /dev/null && echo "OK" || echo "要確認"
set -euo pipefail を付けておくと、途中で失敗したときにそこで止まります。更新スクリプトでは、これがあるかないかで安全性が変わります。
テスト環境を作り直す
自分がプラグインを作るときに、毎回打っている形です。
#!/usr/bin/env bash
set -euo pipefail
wp db reset --yes
wp core install --url=localhost:8080 --title="dev" \
--admin_user=admin --admin_password=admin --admin_email=dev@example.com
wp plugin install ./dist/my-plugin.zip --force --activate
wp post generate --count=30
wp option update permalink_structure '/%postname%/'
wp rewrite flush
数十秒で、まっさらな環境が手に入ります。手作業でやっていた頃は10分かかっていました。
追加パッケージ
WP-CLIは、コマンドを追加できます。
wp package install wp-cli/doctor-command
wp doctor check --all # 設定やDBの健康診断
wp package install wp-cli/profile-command
wp profile stage # どの段階が遅いかを計測
wp profile hook --all # フック単位で計測
wp package list
wp package uninstall wp-cli/doctor-command
wp profile は、サイトが遅い原因を探すときに使います。テーマなのか、プラグインなのか、DBなのかを、段階ごとの時間で見られます。推測で高速化を始める前に、これを一度打つと無駄が減ります。
PHPを直接実行する
wp eval 'echo get_option("siteurl");'
wp eval 'var_dump(is_multisite());'
wp eval-file script.php
wp shell # 対話モード
wp shell は、WordPressが読み込まれた状態の対話環境です。関数の挙動を確かめたいとき、テスト用のプラグインを書くより速いことがあります。
wp> get_option('blogname');
wp> $p = get_post(1); echo $p->post_title;
早見表
用途から引く形でまとめます。
| やりたいこと | コマンド |
|---|---|
| 動作確認 | wp --info |
| WordPressのバージョン | wp core version |
| 本体を更新 | wp core update && wp core update-db |
| プラグイン全部更新 | wp plugin update --all |
| 有効なプラグイン一覧 | wp plugin list --status=active |
| プラグイン全無効化（切り分け） | wp plugin deactivate --all |
| プラグインを読まずに実行 | wp --skip-plugins <コマンド> |
| パスワード再設定 | wp user update admin --user_pass='新' |
| 管理者を新規作成 | wp user create x x@ex.com --role=administrator |
| DBバックアップ | wp db export backup.sql |
| DB復元 | wp db import backup.sql |
| DBサイズをテーブル別に | wp db size --tables --human-readable |
| URL一括置換（確認） | wp search-replace 'old' 'new' --dry-run |
| URL一括置換（実行） | wp search-replace 'old' 'new' --skip-columns=guid |
| 404が出る | wp rewrite flush |
| キャッシュを消す |
wp cache flush / wp transient delete --all
|
| サムネイル再生成 | wp media regenerate --only-missing |
| 予約処理を今すぐ | wp cron event run --due-now |
| 期限切れの予約処理 | wp cron event list --due-now |
| リビジョン削除 | wp post delete $(wp post list --post_type=revision --format=ids) --force |
| 重いオプションを探す | wp db query "SELECT option_name, LENGTH(option_value) FROM $(wp db prefix)options WHERE autoload='yes' ORDER BY 2 DESC LIMIT 20" |
| 別サーバーを操作 | wp @prod plugin list |
| メンテ表示の解除 | wp maintenance-mode deactivate |
| 改ざんチェック |
wp core verify-checksums / wp plugin verify-checksums --all
|
覚えておくと事故が減ること
最後に、実務で効いた注意点を並べます。
破壊的な操作の前に wp db export を打つ。 数秒です。この習慣があるかどうかで、事故が「やり直し」で済むか「復旧作業」になるかが変わります。
search-replace は --dry-run から。 そして --skip-columns=guid を付ける。
--yes を癖で付けない。 確認プロンプトは、止めるためにあります。
WordPressが壊れているときは --skip-plugins。 WP-CLI自体が動かないときの逃げ道になります。
cronやCIから呼ぶときは --quiet と set -euo pipefail。 失敗が黙って通り過ぎるのが、いちばん怖い形です。
rootで実行しない。 ファイル所有者が変わって、あとで別の問題になります。
自分は、テスト環境の作り直しでWP-CLIを使い始めて、いまは更新もバックアップも移転も、ほぼこれで済ませています。管理画面を開く回数が、はっきり減りました。役に立ったらストックして、必要なときに開いてください。
公式のコマンド一覧は、こちらで全部見られます。
ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。