WordPressでプラグインを入れたり、テスト用の記事を増やしたりするとき、管理画面で同じ操作を何度も繰り返すことはありませんか。
そんな作業を、短い命令文でまとめて進められるのが「WP-CLI」です。「コマンド」と聞くと難しく感じるかもしれませんが、Localで作ったテストサイトがあれば、専用の画面を開いて、情報を表示する操作から試せます。
本記事では、Localの「Site shell」を開くところから、プラグイン一覧の確認、データベースの書き出し、ダミー記事の作成など5つの基本操作を紹介します。まずはサイトの内容を書き換えないコマンドから始めましょう。
WP-CLIとは？WordPressを文字で操作するツール
WP-CLIは、WordPressをコマンドで操作するためのツールです。管理画面でボタンを押す代わりに、命令文を入力してEnterキーで実行します。命令文は通常「wp」で始まり、その後に作業の内容や条件を指定します。
| 操作方法 | 向いている作業 |
|---|---|
| 管理画面 | 記事の執筆、画像の配置、見た目を確認しながらの調整 |
| WP-CLI | 一覧の取得、同じ処理の繰り返し、データの一括操作 |
管理画面をすべて置き換える必要はありません。繰り返しの多い作業に使うと、操作の手間を減らせます。この記事の例はLocalのテストサイトで使うもので、本番サイトにそのまま実行するための手順ではありません。
LocalでSite shellを開く
LocalにはWP-CLIが用意されています。テストサイトを起動し、サイト名の下にある「Site shell」（①）を押します。
OSに応じたターミナル等が開き、対象サイトでコマンドを使う準備が整います。通常のターミナルを開く方法とは異なり、Localがそのサイト向けのPHPやデータベース接続の環境を用意してくれます。
最初は、次のコマンドを1行入力し、Enterキーを押してください。
wp --version使用しているWP-CLIのバージョンが表示されます。今回のLocal 10.1.2環境では「WP-CLI 2.12.0」と表示されました。別の環境では表示される番号が異なる場合があります。
続いて、操作対象のサイトURLを確認します。
wp option get home意図したテストサイトのURLが表示されたことを確認してから、次へ進みます。この2つは、サイトのデータを書き換えるコマンドではありません。
Localでのサイトの作り方は、次の記事で解説しています。
Localで新しいWordPressサイトを1つ作るのに、入力するのはサイト名とユーザー名、パスワードの3つだけです。あとは「Continue」を3回押し、「Add Site」を押せば、自分のパソコンの中でWordPressが動き始めます。 サーバーやドメインの契約はいりません。テーマやプラグイン...
Localで試すWP-CLIの基本操作5つ
以下は、今回のテストサイトで試した操作を中心にした例です。記載した所要時間は今回の環境での参考値で、記事数・通信速度・プラグイン等によって変わります。
1. プラグインの一覧を表示する
まず、インストールされているプラグインを確認します。
wp plugin list「name」はプラグインの名前、「status」は有効・無効などの状態、「update」は更新の有無です。「update」に「available」と出ていれば、更新があることを示します。このコマンドは、一覧を表示するだけで更新は行いません。
知らないコマンドは、実行する前にヘルプを確認できます。
wp help plugin list確認するコマンドと、データを変更するコマンドを区別することが、最初のポイントです。
2. データベースを書き出す
次の例からはファイルやデータに変更が加わります。まず、変更前のデータベースを保存しておきます。
wp db export ../before-cli-practice.sql標準的なLocalのSite shellは、サイトの公開フォルダ「app/public」で開きます。「../」は1つ上のフォルダという意味で、この例では「app」側にSQLファイルを書き出します。異なる場所から実行している場合は、保存先も変わるので確認してください。
ファイル名には日付や作業名を入れ、前回のバックアップと区別すると管理しやすくなります。同じ名前のファイルがある場合は上書きしないよう、別の名前を使ってください。今回の検証では、データベースの書き出しに0.7秒かかり、約1.8MBのファイルができました。
3. プラグインをまとめてインストールする
WordPress.orgのプラグインは、スラッグを並べてまとめてインストールできます。スラッグは、公式プラグインページのURL末尾にある識別用の名前です。
wp plugin install query-monitor classic-editor --activateこの例は、Query MonitorとClassic Editorをインストールし、「–activate」で有効化まで行います。今回の検証では、2つの処理に8.5秒かかりました。インストールだけでなく、有効化も実行するコマンドであることに注意してください。
実行後は「wp plugin list」と管理画面で状態を確認します。すでに入っているプラグインや、他のプラグインとの組み合わせによって、実行結果は異なります。
4. テスト用の記事をまとめて作る
一覧ページやページ送りを確認したいときは、ダミー記事を作れます。
wp post generate --count=100今回の検証では、100本の記事が1.4秒で作成されました。元の1記事と合わせて投稿一覧が101本（①）、6ページ（②）になっています。
このコマンドは、既定で「公開済み」の投稿を作ります。Localのテストサイト専用の例として使ってください。本番で実行すると、ダミー記事が公開されます。
下書きとして作りたい場合は、公開状態を指定します。
wp post generate --count=100 --post_status=draft投稿者を指定しない場合の表示は、今回の画像では空欄でした。公開状態や投稿者などの条件は、用途に応じて指定できます。
テスト後に作成前へ戻す場合は、保存しておいたDBを読み込む方法があります。
wp db import ../before-cli-practice.sqlこれはダミー記事だけを消す操作ではありません。バックアップ後に変更した記事・設定等も、DB側は保存時点へ戻ります。ほかの作業を続けたサイトや本番サイトで、気軽に実行しないでください。
5. URLの置換対象を変更せずに調べる
サイト移転等では、データベース内の旧URLを新URLに置き換える作業が必要になる場合があります。まず「–dry-run」を付け、書き換えずに対象件数を調べます。以下のURLは例なので、自分の移転元・移転先に置き換えてください。
wp search-replace "http://test.local" "https://example.com" --skip-columns=guid --dry-run --report-changed-only| 指定 | 意味 |
|---|---|
--dry-run |
置換結果を確認するだけで、DBを変更しない |
--skip-columns=guid |
記事等の識別に使うguid列を置換から除外する |
--report-changed-only |
置換対象がある列のみを結果に表示する |
今回のテストでは、guidを除外した確認で7か所が対象になりました。siteurl・homeの2か所、メニューに保存したリンク4か所、ユーザーのWebサイト欄1か所です。これは今回のデータでの結果で、サイトによって件数は変わります。
WP-CLIはPHPのシリアライズ形式を考慮して置換します。ただし、それだけであらゆる独自データ形式への対応や、サイト全体の動作を保証するものではありません。
また、既定の対象はWordPressの「$wpdb」に登録されたテーブルです。プラグイン独自テーブルやマルチサイトを含む場合は、対象範囲の確認が必要です。データベース内の全テーブルを、無条件に置換するコマンドではありません。
この例では、実際の置換は行いません。「–dry-run」を外すとhomeやsiteurlも変わり、Localの元のURLで開けなくなる場合があります。移転先での実行は、バックアップ・対象範囲・URLの設定を確認したうえで行います。
次に覚えたいコマンドと注意点
| コマンド | 用途・注意点 |
|---|---|
wp core check-update |
WordPress本体の更新があるか確認する |
wp option get blogname |
サイト名を表示する |
wp plugin update --all |
すべてのプラグインを更新する。先にファイルとDBの復元手段、互換性を確認する |
wp rewrite flush |
リライトルールを再生成する。既定では.htaccessの書き換えを伴う処理とは異なる |
wp media regenerate |
サムネイルを再生成する。対象数やファイルへの影響を確認する |
wp cache flush |
オブジェクトキャッシュを消去する。ブラウザキャッシュ等をまとめて消す操作ではない |
wp help |
ヘルプを開く |
使い方は「wp help plugin update」のように確認できます。コマンドによって、即時に変更するものや確認を求めるものがあります。名前だけで判断せず、オプションも含めて確認してください。
ユーザー作成時の出力にも注意する
WP-CLIにはユーザーを作成するコマンドもありますが、この記事の5つの操作とは別に、権限と認証情報の扱いを理解して使います。
「wp user create」でパスワードを指定しなければ、既定ではランダムに生成されます。「–porcelain」は新規ユーザーIDだけを出力する指定で、ログインを無効にするものではありません。自動生成されたパスワードを出力しないため、利用者がログインするための設定・再設定の手段を別途考える必要があります。
同じ「記事を書く人」でも、WordPressの「投稿者」は画像をアップロードできて、「寄稿者」はできません。寄稿者には、ファイルをアップロードする権限（upload_files）が初めから付いていません。 WordPressのユーザーには、管理者・編集者・投稿者・寄稿者・購読者の5つの権限グループ...
本番サイトで使う前に確認すること
今回紹介したのはLocalのテストサイトでの操作です。本番で使う場合は、レンタルサーバーの提供条件やWP-CLIの導入状況、実行するPHP・ユーザー権限も確認します。一般的なサーバー上の操作ではSSH等で接続します。
コマンドを実行できることと、変更後に問題なく運用できることは別です。本番を変更する場合は、少なくとも次を確認します。
- 接続先・対象ディレクトリ・サイトURLが正しいか
- 変更するデータやファイルの範囲を理解しているか
- ファイルとDBを復元できるバックアップがあるか
- 検証環境で同じ操作と動作確認を済ませたか
- 更新後の表示、投稿編集、フォームなどを確認できるか
SQLの書き出し先も、本番ではサーバー構成に合わせて確認します。公開ディレクトリの外へ保存し、復元に必要なバックアップは適切に保管しつつ、作業用の不要なコピーを残さないようにします。
まとめ
WP-CLIは、WordPressの情報確認や一括処理を短いコマンドで進めるためのツールです。LocalならSite shellから始められます。
まずは「wp –version」「wp option get home」「wp plugin list」で、対象サイトと現在の状態を確認してみてください。慣れたら、使い捨てのテストサイトでバックアップやダミー記事の作成へ進むと、操作の違いをつかみやすくなります。
WordPressテーマ集
コメント