WordPress には自動アップデートという機能があって、WordPress 本体やプラグイン、テーマの最新版がリリースされるとダッシュボードに通知が表示され、ダッシュボードでボタンをクリックするだけで最新版にアップデートできます。
この自動アップデートを使用するには、プラグインやテーマが公式ディレクトリ上に登録されている必要がありますが、先日 GitHub API を使用してこの自動アップデートを発火させることができました。
そこで、そのための処理を Composer のライブラリ化しましたので、使用方法を解説します。
ぜひ GitHub で Star をつけてください！
はじめに
この記事が想定しているユースケースは、自分の顧客のためにプラグインを開発し、それを自動アップデートを使用してデプロイすることです。
たとえば、不特定多数の人に使ってもらいたいのならこの方法を使用せずに公式ディレクトリに登録すべきです。
また、第三者が開発したプラグインを使用する際も、公式ディレクトリ以外のところにあるプラグインを使用することはやめましょう。
しつこく書きますが、皆さんご自身のクライアント、つまり特定少数向けにプラグインを開発する際に、デプロイを自動化するためのものとしてご理解ください。
あと、そのプラグインに対して Travis CI 等を使用した CI が行われていることも重要です。
もし、ユニットテストや CI について経験がない場合は、この先はあまりにもハードルが高い上に楽にもなりませんし、メリットも感じないと思いますので、それらを身につけてから挑戦してください。
動作環境
このライブラリは WordPress の最新版と次のバージョン（ナイトリーバージョン）でテストしています。
また、PHP は 5.6 と 7.0 でテストをしています。
あと、Composer を使用しています。
とりあえず試したい
とりあえず試したい方は以下のプラグインを WordPress で有効化してください。
WordPress の最新版の有無のチェックは12時間おきなので、すぐにチェックしたい人は、以下のコマンドを実行してください。
$ wp cron event run --all
その後、管理画面内のプラグインのページに移動する等の操作で最新版の通知がでることが確認できると思います。
アップデート通知の詳細をクリックすると以下のように README.md や Changelog を GitHub API 経由で取得し表示されていることも確認できると思います。
WP-CLI で実際にアップデートを実行すると以下のような感じです。
$ wp plugin update --all
Enabling Maintenance mode...
Downloading update from https://github.com/miya0001/self-hosted-wordpress-plugin-on-github/releases/download/2.0.0/self-hosted-wordpress-plugin-on-github.zip...
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Plugin updated successfully.
Disabling Maintenance mode...
+----------------------------------------+-------------+-------------+---------+
| name | old_version | new_version | status |
+----------------------------------------+-------------+-------------+---------+
| self-hosted-wordpress-plugin-on-github | 1.0.0 | 2.0.0 | Updated |
+----------------------------------------+-------------+-------------+---------+
Success: Updated 1 of 1 plugins.
導入方法
Composer を使用して、以下のようにインストールしてください。
composer require miya/gh-auto-updater
2/7 現在、まだ Stable なバージョンはリリースしておりませんので、composer.json に以下の記述が必要です。
"minimum-stability": "dev"
現時点でテストはそれなりにしており、複数のプラグインで期待通りに動作していることも確認できていますが、もしトラブルがあるといろいろめんどくさいことになるかもしれません。
次にプラグイン内に以下のような記述をいれてください。
まずは、オートロード。
require_once( dirname( __FILE__ ) . '/vendor/autoload.php' );
次に、init フックで自動アップデート用のクラスを発火させます。
add_action( 'init', 'activate_autoupdate' );
function activate_autoupdate() {
$plugin_slug = plugin_basename( __FILE__ ); // e.g. `hello/hello.php`.
$gh_user = 'miya0001'; // The user name of GitHub.
$gh_repo = 'gh-auto-updater-example'; // The repository name of your plugin.
// Activate automatic update.
new Miya\WP\GH_Auto_Updater( $plugin_slug, $gh_user, $gh_repo );
}
Miya\WP\GH_Auto_Updater() クラスは、3つの引数が必要です。
- プラグインの名前。プラグイン本体のファイルに記述する場合、このままコピペで大丈夫です。
- GitHub のユーザー名。
- GitHub 上のリポジトリ名。
これらの3つのパラメータが適切に指定されていれば、プラグインでやるべきことはこれだけです。
Composer のライブラリは定期的にアップデートしてください。
プラグインのアップデートをする
プラグインにアップデート機能を実装できたら、実際に最新バージョンをリリースして動作確認をしてみましょう。
この作業は慣れてしまうとほいほいってできますし、かなりの部分を自動化できるのですが、文字にして書くとめんどくさいですね。笑
プラグイン本体のバージョン番号を修正する
WordPress プラグインは、プラグイン本体でバージョン番号を指定できます。
まず、そのバージョン番号をアップデートしてください。
/*
Plugin Name: My Plugin
Version: 2.3.4
*/
このバージョン番号の修正を忘れるといつまでたってもアップデート通知がでてしまうので注意してください。
（後述しますが、これ自体を自動化することもできます。）
タグをつける
プラグイン本体の修正がおわって、すべてのコミットが完了したら、git tag でタグをつけてください。
タグはバージョン番号と同じであるべきなので、以下のようになります。
$ git tag 2.3.4
$ git push origin 2.3.4
ここで注意なのですが、本来 composer install された時に生成される vendor というディレクトリは、リポジトリにコミットすべきではありませんが、自動アップデートを使用する際には、これらのファイルがないとエラーになってしまいますので、たとえば stable というブランチをつくってそちらに vendor もコミットするなどの工夫が必要です。
僕の場合は、後述する自動リリースを使用して、vendor はコミットせずに配布用のパッケージを生成してそちらに同梱するようにしています。
Travis CI？ なにそれ？という感じの方は、このあたりかなり煩雑な作業になる気がします。
GitHub のリリース機能で新バージョンをリリースする
GitHubにはリリースという機能がありますので、その機能を使用して、新バージョンをリリースします。
まず、リポジトリの Releases というメニューでリリースのページに移動してください。
そして、「Draft a new release」というボタンをクリックすると、以下のような画面になります。
ここでまず 「Tag version」という項目に先ほど指定したタグを入力してください。つぎに、右隣のプルダウンで必要に応じてブランチを指定してください。
上述した vendor ディレクトリをコミットするためのブランチを作った場合は、ここでそのブランチを指定する必要がありますので間違えないようにしましょう。
あとは、リリースのタイトルや Changelog 等を入力して「Publish release」というボタンをクリックすれば最新版がリリースされます。
これは編集することもできますし、削除することもできますので、ご自身のクライアント向けにこの機能を使用する程度なら、実際にアップデートさえしなければ問題ありません。
以上がおわったら、WordPress サイトのほうで最新版の通知が出ているかどうかを確認してください。
WP-CLIでさっさと確認するなら以下のような感じです。
$ wp cron event run --all
$ wp plugin list
+----------------------------------------+----------+-----------+---------+
| name | status | update | version |
+----------------------------------------+----------+-----------+---------+
| akismet | inactive | none | 3.2 |
| self-hosted-wordpress-plugin-on-github | active | available | 1.0.0 |
| hello | inactive | none | 1.6 |
+----------------------------------------+----------+-----------+---------+
update の列に available というのが表示されていれば成功です。以下のコマンドで実際にアップデートできます。
$ wp plugin update --all
自動リリースを使用する
Travis CI を使用して自動リリースを導入すると、新バージョンのリリースに必要な作業は以下のようにタグをプッシュするだけです。
$ git tag 2.3.4
$ git push origin 2.3.4
自動デプロイはだいたい以下のような手順を自動化します。
- Travis CI 上でテストを実行する。
- テストが通ったらプラグインの .zip ファイルを生成するシェルスクリプトを実行。
- シェルスクリプトで生成された .zip ファイルを GitHub の Releases API を使用して新バージョンとしてリリース。
これらの処理は以下のプロジェクトの .travis.yml に記述していますので、そちらをご覧になってください。
- https://github.com/miya0001/self-hosted-wordpress-plugin-on-github
- https://github.com/miya0001/miya-gallery
この一連の処理の中で、GitHub API を使用して新バージョンをアップロードする必要がありますが、これは、Travis Client を使用すれば以下のコマンドで必要な記述を .travis.yml に追加できます。
$ travis setup releases
詳細は公式ドキュメントをご覧になってください。
Travis CI を使っている方にとってはそれほど難しくはないと思いますが、僕はパッケージング用のシェルスクリプトをいい感じにするのに時間がかかってしまいました。
最後に
実はこの方法をやろうと強く思ったきっかけが、WP-CLI のエイリアス機能が想像以上に便利だったからです。
$ wp @all core update
$ wp @all plugin update --all
$ wp @all theme update --all
$ wp @all verify-checksums
これで管理してるサイト全部がアップデートできたら最高ですよね。実際そういう運用をしていまして、小ネタプラグインのメンテナンスだけ手動なのでめんどくさくなったんです。