Jetpack等のプラグインのWP-CLIコマンドと、WP-CLI開発に関するWordCamp動画

この記事はWP-CLI Advent Calendar 2014 – Adventarの23日目の記事です。1日遅れてしまい、スミマセン…

1つの記事にするほどでもないので(汗)、今回は2つを1つにしました。

  • プラグインに含まれているコミュニティ・コマンド
  • A Journey To The Center Of WP-CLI

プラグインに含まれているコミュニティ・コマンド

WP-CLIのコミュニティ・コマンドを追加するには、コミュニティ・パッケージをインストールして追加する方法と、プラグインを有効化することによって追加する方法の2通りがあって、両方ともすでに今回のAdvent Calendarで取り上げられています。

既存のプラグインの場合、すでにWP-CLIコマンドに対応しているプラグインがあり、WP-CLIのGitHubページで確認できます。

List of community commands · wp-cli/wp-cli Wiki

Advanced Custom FieldsやBackWPup、Jetpack、WP Super Cache、W3 Total Cacheなど、すでに対応しているポピュラーなプラグインが幾つかあります。WP Migrate DB Pro のように、有料版でのみ対応している場合もあります。

JetpackのWP-CLI

その中から、JetpackのWP-CLIコマンドを見てみました。wp jetpack helpで確認すると下記コマンドがあることが分かります。

  • wp jetpack disconnect [blog|[user <user_id>]]

  • wp jetpack module [list|activate|deactivate|toggle [<module_name>]]

  • wp jetpack status

statusはこんな感じ。

$ wp jetpack status
Success: 現在 Jetpack は WordPress.com アカウントに連携済みです
Jetpack バージョンは 3.3 です
WordPress.com blog_id は 1076823 です

残念ながら、サブ・サブコマンド([~]の中)がバグで使えなくなっています。周知のバグでfixする予定ではあるみたい。

$ wp jetpack module list
<span style="line-height: 1.6471;">Warning: The `wp jetpack module` command has an invalid synopsis part: [list|activate|deactivate|toggle
</span><span style="line-height: 1.6471;">Warning: The `wp jetpack module` command has an invalid synopsis part: [&lt;module_name&gt;]]
</span><span style="line-height: 1.6471;">Error: Too many positional arguments: list

A Journey To The Center Of WP-CLI

WordCamp.tvに、現在リポジトリをメインテインしているDaniel BachhuberさんのWCNY2014の時のセッション動画を見つけたので紹介。

Daniel Bachhuber: A Journey To The Center Of WP-CLI | WordPress.tv

内容は、DanielさんがWP-CLIを使い、プルリクを送るようになったきっかけから、ユニットテストなどを用いたWP-CLIそのものの開発について語っています。

WP-CLIとCronの合わせ技でテーマの有効を予約設定する

この記事はWP-CLI Advent Calendar 2014の16日目の記事です。

WP-CLIのwp theme activateをCronと組み合わせて、テーマの有効を予約設定してみました。

Cron設定の仕方

Cronの設定については下記などを参照。

Cronを設定するには2通りの方法があるということを、実は今回知りました。crontab -eでCrontab画面を立ち上げて指定する方法と、/etc/crontab を直接編集する方法です。今回はcrontab -e方法だとうまくいかなかった(※)ので、vi /etc/crontabで直接編集しました。

※たぶんコマンドが間違えてたとかそういうのだと思われ。とはいえ、/etc/crontabを直接編集する方が分かりやすいと思いました。

例えば、12月16日13時45分に設定をするには下記の様に記述。user-nameには実行するユーザー名が入ります。

45 13 16 12 * user-name 何かの処理

なお、これだと実際は毎年12月16日13時45分に処理を行うという設定なので、1回だけであれば実行された後に手動で削除する必要があります。

VCCWを使ったローカル環境で試してみる

まずはローカルのVCCWで試してみました。VCCWは現在の日付・時刻をdateで確認するとUS時間でした。なぜだろう…en_US設定だからかな。ともかく、今回はテストなのでその時間に合わせてCronを設定。下記は12月15日17時14分にTwenty Fifteenを有効化する設定です。

47 17 15 12 * vagrant /usr/local/bin/wp --path=/var//var/www theme activate twentyfifteen

なお、vagrantユーザーでは/etc/crontabの編集はできなかったで、suする必要があります。実行するユーザー名はvagrantでも問題なかったです。

本番環境で試してみる

ローカルでうまくいったので、実際に本番環境、つまりこのブログ、で試してみました。

“`0 2 16 12 * /usr/local/bin/wp –path=/path/to/wordpress theme activate wilson

1 2 16 12 * root /usr/local/bin/wp –path=/path/to/wordpress nginx flush“`

これも問題なく有効化。2行目はNginx Cache ControllerのWP-CLIコマンドで、Wilsonというテーマをactivateした1分後にNginxのキャッシュをフラッシュしています。

/usr/local/bin/wpはWP-CLIの場所。/path/to/wordpressはWordPressのインストール場所。環境/サーバーによって違うので、正しく設定する。ここが一番注意するところかもしれません。僕も何回か間違えて設定し直しました。また、path=〜パラメータは wpの直後に記述する必要がありました。下記のように記述するとうまくいきません。

0 2 16 12 * /usr/local/bin/wp theme activate wilson --path=/path/to/wordpress

12月16日に試したこと

テストがうまくいったので、12月16日(つまりAdvent Calendar16日目…)にこういう設定をしておきました。

0 8 16 12 * root /usr/local/bin/wp --path=/path/to/wordpress theme activate highwind
0 13 16 12 * root /usr/local/bin/wp --path=/path/to/wordpress theme activate wilson
0 19 16 12 * root /usr/local/bin/wp --path=/path/to/wordpress theme activate twentyfifteen
1 8,13,19 16 12 * root /usr/local/bin/wp --path=/path/to/wordpress nginx flush

8時にHighwindを、13時にはWilsonを、そして19時にはTwenty Fifteenが有効化されるように設定し、さらにそれぞれその1分後にはキャッシュをフラッシュ。

それぞれの時間に職場からアクセスしてチェックしてみたのですが、うまくいっていたようです。

実際に仕事で使える?

サイドバーやウィジェットの設定はテーマを変更するとそのテーマに合わせて設定し直す必要があるので、いきなり新しいテーマを予約設定するのは現実的ではないかもしれません。良いデベロッパーならば、ステージングですべてテストしている上に、ファイルとDB(もしくはそれらの差分)を簡単にデプロイできるようにしているでしょうから、実際にはそのデプロイをスクリプトにしてCron設定しますよね。

WordPressのありとあらゆる設定がWP-CLIから変更できるようになると…

WP-CLIの(特に初めての人向け)紹介でよく目にするwp theme activateですが、「1行のコマンドで新しいテーマを有効化できて便利ですよ〜」と解説しても、日常的に黒い画面を使っていない人であれば「テーマの有効化なんて管理画面からできるし、GUIで楽」ってなるかと思うんです。でも、CLIでWordPressの設定変更ができるようになることのミソは「1行で便利〜」ではなく、コマンドという文字列(スクリプト)に書き出せることです。スクリプトにさえできれば活用の幅が広がります。

たとえば、今回のようにCronと組み合わせることで、いろいろな「予約」ができるようになります。WP-CLIを使わない場合、デフォルトでできるのは投稿の予約ぐらいです。ローカル開発用にWordPressを立ち上げる時に毎回行っている設定などはスクリプトとして保存しておき、必要な時に実行すると、あとはパソコンがすべて処理してくれます。たとえばMemo: wp-cli commands for the theme reviewers. | Days in Thailand

そんなワクワク感がいいなと思ってます。

VersionPress:ファイルもDBもWordPressサイト全体をバージョン管理するプラグイン

WordPressサイト全体をGitなどのバージョン管理下におく場合、いっそのことメディアファイルとDBも併せてバージョン管理したい、と思ってしまいます。そんな要望に応えてくれそうなプラグインが先日WP Tavernでピックアップされていたので紹介。

VersionPressのサイトには開発中のキャプチャが。リビジョンのIDとコメント、"Undo" リンクに注目。

VersionPressのサイトには開発中のキャプチャが。リビジョンのIDとコメント、”Undo” リンクに注目。

チェコのデベロッパー2人が現在開発中&クラウドファンディングで資金集め中のVersionPressというプラグインです。Version Pressはインストールして有効化するだけで、後は自動的にサイト上の全ての変更をバージョン管理してくれます。全ての変更、というのは投稿や固定ページの公開、変更、削除はもちろん、設定変更など全てです。バージョン管理されているので特定のリビジョンまでロールバックしたり、リビジョンを指定しての削除もできます。更に差分だけローカル、ステージング、プロダクション間で同期もしてくれるとか…

バージョン管理に使われるのはGitです。WP Tavernのポッドキャストに開発者の1人がゲスト出演しているのですが、その中ではDBの差分を出力してGitで管理する、と言っていました。また開発者ブログの方には、初期のリリースではリモートサーバーにGitがインストール済みであることが動作条件になるが、多くのホスティングサービスはGitをサポートしていない為、できる限り早い段階でPHP版のGitを実装すると書いています

まだ開発が発表されたばかりなので、ライセンスはどうなるのか?(後日100%GPLを発表)、調達した資金は具体的に何に使われるのか?仕様は?販売形態は?など多くの疑問が飛び交っていますが、期待通りの出来に仕上がっていればとても注目されるプラグインになりそうです。

先日の登壇後にコンテンツのデプロイメントに関する質問を受けました。コードのみではなく、DBを含むコンテンツも併せた包括的なバージョン管理+デプロイメントができないだろうか?デザイナーでも扱える仕組みで何かないだろうか?ー日本でも需要がありそうですね。

リリースは2014年の後半を予定しているそうです。気になる方は定期チェックしておいては?

「WordPressサイト制作におけるデプロイメントを考える」フォローアップ #wckansai

先の投稿でも書いたとおり、6月7〜8日開催されたWordCamp Kansai 2014に参加し、公募枠で登壇してきました。

セッションを聞いてくださった皆様、ありがとうございました。

セッションのタイトルは「WordPressサイト制作におけるデプロイメントを考える〜Gitとデプロイメントサービスの活用〜」です。概要はというと、WordCamp Kansaiのサイトからの引用になりますが:

現在WordPressサイトの構築や更新には、FTPもしくはSFTPソフトを利用したデプロイメントが主流です。サイト全体の引っ越しであれば、あるいはrsyncやscpといったコマンドを使う場合もあるでしょう。しかし手動で行う作業や、不慣れなコマンドを使うことにより、ミスしたり、時間が掛かったりしませんか?

一方で、最近は開発にGitを用いたVCを実践している、あるいは検討、勉強しているという方も少しずつ増えてきている反面、実務でわざわざ使う利点をイマイチ見いだせていない…という方もいるはず。

そこでGitとデプロイツール(サービス)を組み合わせたテーマ、プラグイン、サイト全体の、より効率的かつスピーディーなデプロイとその自動化を提案します。また、WordPressサイトにこのワークフローを導入する際の注意点も考えます。

まだまだ、個人と職場両方の場で模索しながらこのワークフローを試しています。実績に基づく「これをやっておけばよい」という正解をシェアできるものではありませんが、同様に模索している方や興味ある方と現在のノウハウをシェアしあい、インスパイアしあえるきっかけになればと思います。

副題に「デプロイメントサービス」とありますが、ツールも紹介しています。アウトラインはこんな感じ。

  • What is Deploy/Deployment?
  • Today’s Agenda
  • Where should I git init?
  • Code Deployment
  • Contents Deployment
  • More Advanced Deployment Tools
  • Towards a Full Stuck WordPress Development Tools
  • Managed WordPress Hosting
  • Message

このうち、「Contents Deployment」と「Managed WordPress Hosting」は時間が足りなく飛ばしましたが、Slideshareにアップしたスライド(下記)に入っています。

伝えたかったこと

ツールやサービスなど難しいことを駆け足で話しましたが、もっとも伝えたかったことは3つの「Message」です。

  1. 何はともあれGit。
  2. よりストレスフリーなデプロイメントを目指してデプロイメントのツールやサービスを使ってみよう(車輪の再発明はしない)。
  3. Full Stack方向を意識しつつ、情報のアンテナを張り、手を動かしてみる。

特に3つめなのですが:

20140607_wpkansai-slide_ver6-Final-128

紹介したデプロイメントツールとサービスも、手を動かして使ってみないと理解しづらいと思いますし、実戦投入できるかどうか?するのであればどんなプロジェクトでできそうなのか?判断が付けづらいかと思います。しかし、WordBench Osakaを始め、関西のコミュニティではGitや翻訳など、手を動かして何かproductiveなことをしよう!と挑戦されている印象があります。Gitで一歩、いや、数歩進み始めた方が「次の挑戦に検討してみる題材の1つになれるのでは?」とは今回応募した理由の1つです。皆さんどうでしょうか?

スライドのフォローアップ

登壇後に頂いた質問では、飛ばしたContents Deploymentに関わる内容もありましたので、そのあたりを中心に下記に補足しておきます。

Contents Deployment

コンテンツ、つまりDBと/uploads/ディレクトリをローカル、ステージング、プロダクションのサーバー間で簡単にデプロイする方法ですが、選択肢はほとんどありません。更に、サーバー間で同期する方法も多くはありません。

真っ先に考えられるのはrsyncやmysqldump等のコマンドを使ったスクリプトを作成し、サーバーに置いておき、手動またはCronを使って自動で実行する手法です。URLの置換にはシリアライズされた値にも対応する必要がありますが、WordPressのDBのURL置換用のスクリプトが既に存在するのでそれらを使うと簡単です。もう既に何かしらの自動処理を独自で行ってらっしゃる方はおそらくこの方法ですよね?

WP-CLIがインストールされていれば、WP-CLIのwp dbwp search-replaceを使うのも手でしょう。wp search-replaceはシリアライズされた値にも対応しています。

より簡単に、であればプラグインの出番です。しかしこれも選択所はほとんどなく、WP Migrate DB Proと、RAMPという2つの有料プラグインぐらいしかありません。

WP Migrate DB Proはローカル、ステージング、プロダクション、それぞれのサーバーに構築したWordPress全てにインストールし、ボタン1つでDBを指定のサーバーへ、URLを適切に置換した上でアップしてくれます。Developer以上のライセンスであれば、メディアファイル(/uploads/にアップした画像など)も差分だけ転送してくれるアドオンや、WP-CLIに対応するアドオン(現在beta)も用意されています。公式サイトにはキャプチャ動画がアップされているので興味のある方は見てみてください。

RAMPは、ステージングサーバーのコンテンツをプロダクションサーバーへ差分デプロイする為のプラグインです。使用している人は少ないのか、あまり情報はありません。

Notes

注意点、もしくは要検討するべき点を3つスライドの中で挙げましたが、他にもあります。

WordPressのメンテナンスモード

デプロイ中にサイトへアクセスすると、もちろん、うまく表示されません。デプロイ内容にもよるとは思います。ですので、デプロイ中の処理も考えなければいけません。個人ブログやアクセスが少ない時間があり、差分が発生するファイルも少なければ、アクセスが少ない時間を狙いデプロイする方法がありますね。しかし、サイト全体をGitの管理下に置いているサイトや、アクセス数が多いサイトではWordPressのメンテナンスモードを使いましょう。ベストプラクティスとして知っておいて損はしない機能でもあります。詳しくは下記のサイトを参照してください。

Managed WordPress Hosting

スライドの中では海外の Managed WordPress Hostingサービスしか紹介していませんが、日本のホスティングサービスでも同様のステージング+デプロイ機能を備えているサービスがあることを後で知りました。

WordCamp Kansaiのスポンサーでもあるアイティーエー株式会社さんが運営しているWordPress専用レンタルサーバーでは、「2つの環境をセットで用意」と「2つの環境の同期」の2つ機能を実装してらっしゃるそうです。気になる方は試してみてはどうでしょうか?

VersionPress(2014-06-22 22:46追記)

コードをGitでバージョン管理するのであれば、コンテンツ(メディアファイル+DB)も何とか併せてバージョン管理できないもんだろうか?とやはり皆考えるようで、先日VersionPressというプラグインの開発が発表されていましたので記事にしておきました

WordCamp Kansai 2014でWordPressのデプロイメントについて話します #wckansai

当日朝の投稿になりましたが、今日開催されるWordCamp Kansai 2014に公募枠で登壇します。タイトルは「WordPressサイト制作におけるデプロイメントを考える」で、12時15分からです。(UST中継もされるのかな?)

20140607_wpkansai-slide_ver5.001

FTP/SFTPクライアントソフトや、Dreamweaver、Codaといった開発ツールのファイルアップロード機能などを使いデプロイしている方が多いと思いますが、Gitでファイルをバージョン管理するのであれば、Gitを活かしたデプロイ方法に挑戦してみてはどうでしょう、という話です。

Git前提の話なので、対象は主にWordPressサイトの開発においてGitを使っている方になりますが、Gitはかじったけれどあまり有効活用を見出せてない方(例えば、1人で開発してるので、とか…)にも有用な内容だと思います。

WordCampのサイトにも書いてありますが、僕自身もGitは昨年、今回紹介するデプロイは2〜3ヶ月前に実践し始めたばかりです。しかしシェアすることで皆さんと一緒に学べると考え公募に応募しました。(ブログに書けよという突っ込み置いておき…)

また、関西のWordPress勉強会はGitのワークショップや翻訳デーを開催し、手を動かすことを比較的多くやってらっしゃる印象です。今回の話は特に、手を動かすことで消化できる内容だと思うので、継続して手を動かしていくネタになれば、とも思っています。

WordCampはこれまでスタッフや実行委員長として多く関わってきましたが、登壇するのは初めてなので、もう既にめっちゃ緊張しています。ですが、出身地の大阪での登壇は楽しみでもあります。