このブログではひとまず特に問題はなさそうですが、まずはローカルやテスト環境でアップデートしてから、本番環境をアップデートしてください。

日本語の言語ファイルのアップデートはまだのようです。

「地味だけど改めてお世話になったプラグイン」は以前から知っている、または使ってるけど、仕事の中で今年改めてお世話になったプグインです。その中から、日本のコミュニティではあまり聞かない地味〜なプラグインを紹介しました。「2017年に向けて試したいプグイン」は、まだローカルで試した程度ですが、比較的信頼のおける情報源からだったので紹介しました。

2016年、地味だけど改めてお世話になったプラグイン（と、その作者たち）

Public Post Preview

Public Post Previewは、サイトに未登録のユーザーでも投稿のプレビュー確認を可能にしてくれるプラグインです。投稿毎に一時利用のURLを作成することで実現しています。いわゆる「このURLを知ってる人のみアクセスできるリンク共有」です。

プラグインを有効化すると、投稿編集画面の「公開」ボックスに「外部許可を確認する」という設定が追加されます。これにチェックを入れるとURLが生成されて、表示されます。チェックを外すとURLが破棄されて外部許可が閉ざされます。なお、post_type=post以外でも、publicに設定されているpost_typeであれば機能を適用できます。

公開前の最終確認を第三者に取らなきゃいけない時などに便利です。例えば、公開前の最終確認で上長にリンクを送る、とか…。確認をするためだけのユーザーを追加するという無用なセキュリティリスクを避けれますし、確認する側もログインの手間が減ります。社外の人の確認が必要な時にも便利ですね。

ドミニク・シリング

このプラグインの作者はドミニク・シリング（Dominik Schilling）という方で、Ocean90というハンドルネームの方です。彼はWordPressプロジェクトの貢献開発者の一人で、4.6のリリースリードも努めています。

WP Migrate DB

WP Migrate DBはDBをエクスポートしてくれるプラグインですが、よくある「定期的なバックアップ」ではなく、「別の場所へ引っ越すためにDBをエクスポートする」という方向性のプラグインです。

特徴的な機能として、エクスポート時にURL、フルパス、その他指定したい文字列の置換を行ってくれます。シリアライズされたデータにも、もちろん対応済みです。更に、置換の設定をプロファイルとして保存しておくことができるので、引っ越し先が複数ある場合に便利です。例えば：テスト環境、本番環境、同僚Aさんの環境、外部Bさんの環境、の計4つ、とか。

何別のプラグインやWordmove、何かのスクリプト等が使えると便利なのですが、諸事情によりエクスポートしたDBでなければダメって時に便利です。まぁ、いろいろとそういう状況ありますよね…。

ちなみにこのプラグインは有料のPRO版があります。僕の中ではここ数年ずっと「使ってみたい有料プラグイン」のトップなのですが、今の仕事で管理しているWordPressのインストール数に対してなかなか納得が見いだせない価格なので、なかなか機会が無く。

ブラッド・タナー

このプラグインを作っているのブラッド・タナー（Brad Touesnard）、プラグインデベロッパーです。Delicious Brainsという会社を作って有料プラグインを売ってます。有名なのはWP Migrate DB PROですが、最近ではメディアとアセットをAmazon S3とCloudFrontに移動すふプラグイン等も出してます。会社では毎月1回「WordPressコア・コントリビューション・デー」を設けているらしい。

Delicous Brainsはここ2年ほどブログに力を入れており、中級〜上級者向けの技術ネタが満載です。また、後述するピピン・ウィリアムソンと共同でApply Filtersっていう開発系（たまに、有料WordPressプラグインなどでどうやって食っていくか〜とかも）のポッドキャストをやってます。どちらも英語ですがオススメです。

Transients Manager

Transients Managerは、transientsを管理、編集する、開発者向けのプラグインです。今年は仕事で新しく構築したニュースサイトでtransientsキャッシュを設定してたので、その際デバッグに役立ちました。また、公開後も強制的にTransietsを削除したい時に役立ってます。

このプラグインを有効化すると管理画面から現在保存されているtransientsキャッシュを一覧できます。そして特定のtransientsキャッシュの削除、編集が行えます。編集できるのはName、Expires in、valueです。

ピピン・ウィリアムソン

作者はピピン・ウィリアムソン（Pippin Williamson）、プラグインデベロッパーです。WordPress.orgの公式プラグインレポジトリのプラグインレビュアーとしても活躍されています。先ほどのブラッドと同じく、会社（Pippin’s Plugins）を作って有料ブラグインを開発・サポートなどを生業にしている人です。

一番有名なのはEasy Digital Downloadsという、デジタルデータを売ることに特価したE-コマースプラグインです。プラグイン自体は無料で、アドオンが有料です。WooCommerceと同様のビジネスモデルですね。他にもたくさん無料・有料プラグインを出している他、有料の記事コンテンツも販売しています。開発系の話題が多く、オススメです。ここ数年は更新されていないのですが、彼がプラグインをレビューした際に出会ったダメダメなコードを綴っているCrappy Code（＝ひどいコード）というブログを個人的にはよく読んでいました。

“Disable Plugins when doing local dev”

“Disable Plugins when doing local dev”はローカル開発環境（や、ステージングサーバー）と本番サーバーのそれぞれで、強制的に有効化、無効化するプラグインを指定できるプラグインです。例えば、開発時に使いたいDebug Barとその関連プラグインは開発環境では有効化し、本番環境では無効化する。逆に、スパム対策のAkismetは開発環境では無効化し、本番環境では有効化する…などです。

このプラグインの背景と使い方は作者のブログに書かれているのでそちらを参照してください。ポイントは：

• mu-pluginとして使う
• LOCAL_DEV（等）を定義する必要がある

あたりです。

なお、gistのコメント欄を読むと分かりますが、フォークしてマルチサイト対応版を書いた人や、更にそれをインクルードしてプラグイン化した人がいますのでそちらも参考に。

このプラグインの難点というか、割り切ってるところですが、強制的に有効化・無効化するプラグインの設定はプラグインファイル内にハードコードされるため、設定されたプラグインは管理画面のプラグイン画面から手動で有効化・無効化ができなくなる点です。例えば、本番環境で強制敵に無効化するよう設定したプラグインを緊急時などに有効化する必要性が生じた場合、まずはこのプラグインのコードを編集しなければなりません。ちょっと面倒くさい…ことになります。

なおプラグイン名ですが、たぶん、とりあえずとってつけたって感じだと思います（笑）。

マーク・ジャクイース

作者はマーク・ジャクイース（Mark Jaquith）。WordPressのリード開発者であり、現在6名いるプロジェクトリードの1人です。つまりコア開発者の中で最も強い権限を持っている人の1人であり、コアのコードを最もよく熟知している人（…はず）の一人です。彼のブログ、最近は更新頻度が低いのですが、昔に投稿された記事を今でも検索して見返すことがあります。

そういう人たちに学んだ、2017年に向けて試したいイイ感じのプラグイン

Tailor Page Builder & Pootle Pagebuilder

Tailor Page BuilderとPootle Pagebuilderは両方ともページビルダー系のプラグインです。ページビルダー系のプラグインについてはよつばデザイン後藤さんのブログ記事等を参考に。

ピピン・ウィリアムソンのブログ記事で知った

この2つのプラグインを知ったのはピピン・ウィリアムソンがブログに書いた記事です。海外のコミュニティでは今年かなり話題になってました。13のページビルダー系プラグインを検証し、「これなら許せる」という3つのプラグインが最後に書かれています。

この記事の反響が大きかった理由の1つが、開発者（特にプラグイン開発者）目線でレビューされている点です。彼が特に重視したのは下記の3点。どれもこれも「そうそう！そのへんをちゃんとしてくれてないと困るんだよねぇ」という点ばかりです。

• プラグインを使用することに「ロックアウト」されないかどうか
• the_contentフィルターの使用は適切か
• UIがWordPressコアのUIに準拠しており、大きく逸れていないか（ぶっ飛んでないかw）

上に書いた通り、ピピンと彼の会社はプラグイン開発をしているのですが、「動かない」や「壊れた」といった類いの報告の多くは、調べてみるとページビルダー系プラグインが絡んでいるそうです。堪忍袋の緒が切れたピピンがTwitterで不満をぶちまけつつ、「ん、俺ページビルだー系プラグインは嫌いだから殆ど使ったことないな…」ということに気づき、「これじゃイカン！」と書いたのがこの記事です。

なお、3つのプラグインの残り1つはBeaver Builderです。こちらは日本でも紹介されていたりするので取り上げませんでした。また、Tailor Page BuilderはBeaver Builderと同じで、無料版と有料版（PRO版）があります。Pootle Pagebuilderは無料版のみです。

Asset Queue Manager & GitHub Updater

これはどちらも開発系のプラグインです。Asset Queue Managerはサイトへにロードされるためにenqueされているアセット（CSS、JS、画像、など）を管理できるようにするプラグインです。特定のファイルを読み込まないようにしたりすることができます。GitHub UpdatorはGitHubのレポジトリにアップされているテーマやプラグインを、WordPress.org公式テーマ・プラグインレポジトリにアップされているかのごとく、更新通知やアップデートを行うことができるようしてくれるプラグインです。開発中のテーマやプラグインをローカルではない環境に反映させたり、別の人が開発しているテーマ・プラグインをテストのためだけにインストールしたりしたい時に使えそうです。Githubのクローズドレポジトリに対応しているので仕事にも使えそうな他、BitbucketやGitLabにも対応しているようです。

WordPress Meetupでウルリッヒ・ポグソンから知った

秋に開催されたWordCamp Tokyo 2016で登壇したウルリッヒ・ポグソン（Ulrich Pogson）が2016年10月のWordPressMeetupにも登壇してくれました。その時に彼がオススメの開発系プラグインを幾つか教えてくれたのですが、その一つがAsset Queue Managerでした。GitHub Updaterは彼のテーマテスト環境に入っていたので見つけたプラグインです。

彼はWordPressを使ったサイトの制作やテーマの制作をしていますが、WordPress.orgの公式テーマリポジトリのキー・テーマ・レビュアーの一人です。テーマの作る側とチェックする側の両方にいる人なので、色々と参考になる話を聞けました。

なお、GitHub Updaterは理由あって公式プラグインリポジトリでは公開できないことになっているようです。このissueのスレッドあたりに書かれてます。

※GitHub Updaterの使用は、WordPress.orgの公式リポジトリではない、GitHub等のオープンリポジトリからアップデートが可能になると言う点において少なからずセキュリティリスクを伴うものです。知識とスキルが無ければ避けておくことをオススメします。

まとめ

• コアの開発で長年活躍している人やリスペクトされている人が作るプラグインには、知名度こそあまり高くないが、良質のプラグインがある。多機能さは無いかもしれないが、バグ修正やコアアップデートへの対応など、安定性には比較的期待できる。
• コアの開発で長年活躍している人やリスペクトされている人は、気の利いた便利なプラグインを知っている可能性がある。特にテーマ作成時やプラグイン開発時に便利なプラグイン。
• これからは、そういう「海外の人の文脈」経由でのプラグインとの出会いも狙っていっては？

スライド

最近はSpeaker Deckにアップしています。

セッション概要とスライドは下記。

大学のウェブサイトをインハウスで開発、運営しており、一部にWordPressを採用しています。これまでの開発経験の中から、主に機能追加の要望に対して「できなくはない」ケースや、「シングルサイトかマルチサイトかの選択」においての意思決定についてお話します。日々の更新業務を遂行しつつ、インハウス開発を行うヒントになればと思います。

「こういう話を共有したい」と自分から応募していながら、技術の話ではなく、正解もない話を、どのようにセッションとして纏めるか難しく、かなり悩みました。伝えたかったことがきちんと伝えられたか…終わっても不安だったりします。

スタッフの方によると、参加してくださった方は14名だったそう。皆さんの環境でも参考になりうる、何かしらのヒントを得た方がいらっしゃったら幸いです。ありがとうございました。

余談

WordCampの登壇は今回が3回目です。過去のスライドはSlideShareにアップしてましたが、今回を機に全てSpeaker Deckにアップし直しました。

• Native Fonts in 4.6 – Make WordPress Core
• Font Natively – Make WordPress Core

Open Sansからネイティブへ

3.8で管理画面のUIが一新された時からOpen Sansが指定されるようになりました。

body {
    font-family: "Open Sans", sans-serif;
}

しかし、幾つか問題点もあり、その1つがGoogle Fontsからフォントをロードせざるをえないことです。

<link rel="stylesheet" id="open-sans-css" href="https://fonts.googleapis.com/css?family=Open+Sans%3A300italic%2C400italic%2C600italic%2C300%2C400%2C600&amp;subset=latin%2Clatin-ext&amp;ver=5bf5a1af710ddc76d9b7fe8a90fede2c" type="text/css" media="all">

そこで、解決策として4.6からネイティブフォントが採用されることになりました。

body {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
}

ネイティブフォントの採用により：

• より速いロード時間（特にオフライン時）
• サードパーティー依存の解消
• より”ネイティブ感”（ウェブとネイティブアプリの境界がなくなってきている）

が期待されます。

日本語の環境で確認してみました

Mac OS (El Capitan) で、 左から下記の組み合わせです。

• 4.5.3 / Chrome
• 4.6 beta 2 / Chrome
• 4.6 beta 2 / Safari

どうでしょうか？El CapitanなのでSan Franciscoになっていると思います。日本語では違いをあまり感じないですね。むしろ英語の方がウェイトが若干違うような。Matt Miklicさんの記事で、彼がOpen Sans とシステムフォントの表示比較のページを作っているので、それも参考に。

一番気になるのはWindowsの方ですね。Segoe UIらしいですが、どうなんでしょう…キャプチャとれなかったので、とれる方はぜひシェアしてください。

好みではない気がする…

これはマイナスに露出補正しすぎたね。

α7は2年前に発売された機種でして、まだ併売されているとはいえ、後継のα7IIが発売されているので「1つ前の古いやつ」感が少し…でも個人的にフルサイズは使ったことがないのでなかなか楽しみ。加えて、カールツァイスのレンスが使える！という楽しみが…いや、ボディ以上にレンズの方が楽しみかもしれない。

そんなわけで、年末からずっとα7ばかり使っています。ほぼFE55mmがつけっぱの状態です。ひとまず、ここまで使ってみた感想を簡単に書き留めておきます。なお、画像は全て撮って出しです。

ともかく軽い。普段はK-5にSigmaの30mmをつけて、プラスしてDA Limitedを鞄に入れて持ち歩いているしているのですが、こちらの方が全然軽い。息子が生まれてからは外出時の荷物が増え、一眼を持ち出すのがおっくうになりつつも、頑張って持ち出しているのですが…

FE55mmもズッシリきそうな見た目とは違い、DA Limited 2個分くらいな感じ。

FE55mm、素晴らしい。絞り開放からかなりシャープ。ボケはとろける感じかな。Sigmaの33mm f1.4とも違う感じ。やばいなぁ。これK-5で使えないもんだろうかw

今のところα7で一番のマイナス点は操作性。

シャッターボタンの位置と角度。前後ダイヤルの位置と角度と重さ・軽さ。ファンクションボタンなど、シャッターボタン周りの他のボタンを手探りだけで押せるかどうか。背面十字キーの周りのボタンの配置。AFカーソルの移動に必要なボタンを押す回数。グリップが小さいのもマイナス点（が、そこは小型化のために多少は妥協）。

慣れの違いも少なからずあるかもしれない。けれどK-5（とそれ以降のK-3、K-3II）の操作性・操作周りのデザインはよく考えられているなぁと改めて思う。見た目よりも実用性重視？

気合い入れる時はPSかLightroomの出番ですが、追い求めるJPEGの出力がカメラ内で完結してくれると後々面倒くさくなくていいなぁ、とか最近思ってます。α7、カメラ内Raw現像の機能が無いんですね。ペンタックスを使っているので普通あると思ってしまってました。

WBの設定もK-5ほど細かくはできないよう。CTEはもちろん無いけれど、同様の、ソニー独自のWB設定も無いんですね。

解像度は「あぁーこれがフルサイズかぁ〜」と思わせる、さすがな感じ。大阪城の屋根や壁、金細工、虎の周りとか、ディテールと質感いいですね。

と同時に、やはりフルサイズだとそれ相応のレンズじゃないとダメだな、とも。FE55mmだからこそなのかも。

バッテリーの持ちはあまり良くないですね。K-5はミラーレスではないので直接な比較はできないですが、K-5の電池の持ちはかなり優秀なこともあって、α7はかなり悪い感じがします（苦笑）。1日持って出歩くと空になります。いや、1日持たないか。

その他には：

• EVFの切り替えセンサーがかなり反応良すぎて、腰あたりにカメラを構えた時にモニターからEVFに切り替わってしまう。
• ティルトモニターはやっぱり便利。カメラを縦位置にした時も使えたらいいのにね。
• ソニーのRawはARWというファイル形式なんですね。DNGを選択できたらなぁ。
• USB充電はできるにこしたことが無いけれど、やはり充電器もほしい。コンセントって一般的な家では壁ですよね。必ずしもカメラ本体＋レンズを長時間置いておくのに安定している場所ではないことが多い気が…（我が家だけ？）。充電もけっこう時間がかかる。

サイト

• Make WordPress – まずは公式サイトのここ。WordPress.org 関連の様々な分野の活動状況が報告されています。
• WPTavern – ニュース系のサイトではここ2年くらいWP Tavernが最も充実している感じです。内容もコア、テーマ、プラグインなどの技術系から、イベントや人の動きなどのコミュニティ系まで幅広く、また話題が記事になるのも早い。
• Post Status – こちらもニュース系サイトですが、有料セクション（$99/年）があり、対象としている層がより「WordPressで食ってる人向け」な感じです。無料の場合、記事数は月に2つ〜3つですが、1つ1つの記事が結構掘り下げられて書かれていることが多い。

メール

• wpMail.me – 1週間分のWordPress関連のニュースやチュートリアル、プラグイン、テーマなどをキュレーションして、おすすめの記事をまとめてメールで毎週1回（日本時間だと金曜日の早朝）送ってくれます。個人的には以前ほど重宝してないのですが…
• WordPress 日本語版作成チーム – メールではなくて、メーリングリストなんですが、日本語版作成チームの連絡用メーリングリストです。ログは一般公開されています。興味ある方は参加してみては？

Slack

さらにフレッシュな情報、というか現場のやりとりを見たい方は Slack に。両方とも公式です。

• WordPress + Slack
• WordSlackへの参加方法 – WordPress Codex 日本語版

ポッドキャスト

この1年〜2年くらい、海外ではWordPress関連のポッドキャストが大流行のようです。今おすすめなのは下記の3つ。すべて各記事にはエピソード内で取り上げたサイトなどへのリンクがあります。Apply Filtersのみ、書き起こし付きです（+Transcript をクリック）。

• WordPress Weekly – WPTavernのポッドキャストです。
• Draft – Post Statusのポッドキャストです。
• Apply Filters – WordPress Development Podcast – Pippins Pluginsのピピン・ウィリアムソンと、Delicious Brainsのブラッド・タナーという、かなり名が知られているプラグイン・デベロッパー2人による、開発よりの内容にフォーカスしたポッドキャスト。2人ともプラグイン開発で生計を立てていることもあって、マネタイズとかエコシステムとか、そういう話題も頻繁にでてきます。

最後に

ほぼ英語ばかりのリソースになってしまいましたが、日本語だと「ここ！」というサイトがないので、残念ですが仕方がありません。今年のWordCamp KansaiやWordCamp Tokyoで登壇された方や、新バージョン発表時に名前が挙がっているコントリビューターの方々が発信されているブログ、ソーシャルメディアをフォローしておくのが良いかと…

「半歩前」を少しでも「一歩前」に近づけるには、コードを書くしかありません（と最近特に思う）。

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

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

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

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

• わーどぷれすっ! | [WP-CLIアドベントカレンダー2014: 7日] PHP 5.4以上に備わっている開発用のビルトインサーバでWordPressの開発環境を構築するコマンドの紹介

• 11日目：自作のプラグインに wp-cli コマンドを追加しよう ( WP-CLI Advent Calendar 2014 11日目 ) | dogmap.jp

• 18日目：自作プラグインに追加した wp-cli コマンドの出力結果を整形しよう ( WP-CLI Advent Calendar 2014 18日目 ) | dogmap.jp

既存のプラグインの場合、すでに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のwp theme activateをCronと組み合わせて、テーマの有効を予約設定してみました。

Cron設定の仕方

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

• crontabの書き方 | server-memo.net
• cron力をつけよう！全てのcrontab入門者に贈る9個のテクニック – DQNEO起業日記
• cronの設定・実行 | Linuxで自宅サーバ構築
• プログラムの自動実行(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

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