フリーランスのフロントエンドエンジニア、WordPress エンジニアです
いろいろ更新しました。
結構いろいろ直したりしたんですが、register_post_type のパラメーターで、 rewirte が false になっているものに対してパーマリンクの変更が行われるバグを修正しました。
また、タクソノミーについても同様に、register_taxonomy のパラメーターで rewirte が false なものについては処理をスキップするようにしました。
Github: torounit/custom-post-type-permalinks
こちらは、結構大規模にがっつり直してます。
%year%, %monthnum%, %day%, %hour%, %minute%, %second%, %author% に対応。WordCamp Kansai 2016 でもこんなセッションがありました。
WordPress 本体やプラグイン・テーマを Composer で管理すると様々なメリットがあります。WordPress + Git でサイト制作するときの悩みだった「どのディレクトリをGitで管理するの？」 という話がかなりすっきり片付くのはとても大きいんじゃないかと。また自動デプロイなどもかなり簡単に行えるようになったり。
こんな感じで、WordPressを用いたプロジェクト管理がかなり簡単になったりします。
WordPress Packagist もありますし、あまり苦労はしませんが、それでも、プラグインやテーマを Composer に対応させておくといろいろ便利で楽しいです。npm でやるのと、同じようなノリでプラグインを使ったり、フォークしたりが出来ます。開発版とかを使ったりも簡単にできるので、テストとかにも便利だったり。
プロジェクトのディレクトリに入った後に、
$ composer init
とすると、いろいろ聞いてくるので、名前や説明などを入れつつ、Package Type を聞かれるので、プラグインであれば、
Package Type []: wordpress-plugin
テーマであれば、
Package Type []: wordpress-theme
としてやればOKです。もし、composer.json が既に存在する場合は、そこに一行、
"type": "wordpress-plugin",
と足してあげればOKです。参考：Automattic/jetpack
ここまで出来たら、あとは、ライブラリ | Composer ドキュメント日本語訳 のチュートリアルのように WordPress のテーマやプラグインを Composer で管理出来るようになります。
ここまで来たら Packagist にもついでに登録しましょう。composer.json にいろいろ書かなくても一行追記するか、コマンドを叩くだけで取ってこれるようになります。
Packagist にログインした後、Submit を開いて、レポジトリのURLを入れるだけです。めちゃくちゃ簡単です。
こういったエコシステムをうまいこと使えるとなかなか楽しいですよー
先日の WordCamp Kansai 2016 で登壇させて頂きましたが、それとは別に、WordPress プラグイン作成のハンズオン の世話役も担当させて頂きました。といっても内容はほとんど一緒に世話役をやった宮崎さんに丸投げしたような記憶があります。
WordCamp Kansai 2016 プラグイン作成のハンズオンで進行役などをしてきました！ ｜ memocarilog
当日の資料はこちら。wckansai2016/plugin-hands-on
「この記事は○分で読めます」みたいなプラグインを作ると言うことで、自分は話のネタ用のプラグインを作りました。
wckansai2016/plugin-hands-on-sample
とりあえず、add_action・add_filter・add_shortcode の3点セットの話が出来れば良いかなーということで作ったので結構ガバガバです。なのでおかしいところを発見したらプルリクエストくださいー。
三好さんも指摘していたことですが、WordPressのプラグインやテーマは普通に実行中に include されるので、一般的な名前を使うと関数名、アクションフック、フィルターフック等が衝突したりします。関数名の衝突が起こると、画面真っ白になりますしフックが衝突するとよからぬ挙動が発生します。
なので、必ずプレフィックスをつけることをオススメします。今回のプラグインだったら、
function plugin_hans_on_sample_func()
みたいな感じですかね。すべての関数にこれを付けたりするのが面倒だという場合は、クラスを活用したりするという手があります。
もしくは PHP 5.3 以前をサポートしないならば、名前空間を使うという手もありますが、WordPress 本体が PHP 5.2 を現状サポートしているので、使うならば、古い PHP の場合に白い画面にならない工夫や、エラーメッセージの表示など、気をつけないといけないことがいろいろ出てきます。
当日の質問で時間が足らずにお答え出来なかったのですが、この話をやり出すと時間が1時間以上かかってしまう気がするので、とりあえず サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル
また、megumiteam/hatamoto を使って開発を始めるのもアリでしょう。シンプルな管理画面がはじめから付いているので、CSRF対策の具体的な方法を勉強するにはちょうど良いサンプルかなと。具体的な使い方は宮内さんの記事を参考にどうぞ。
https://firegoby.jp/archives/5604
あとこれとは別に、Settings API なんてものもあります。既存の管理画面に項目を追加したりする場合に用います。
ちゃんと使うと値の保存とかバリデーションとかも出来るようですが、結構大変だったりします。使いこなすとめちゃくちゃ強力だと思いますが、まずは普通にプラグイン専用の管理画面を作れるようになれば十分かなと思ったりします。
WordPressの管理画面に独自のオプション保存をするためのSettings APIの使い方 – Shinichi Nishikawa’s
公式ディレクトリへの登録や配布などを考えたときにプラグインを翻訳を考える必要が出てきたりします。やっぱり公開するとフィードバックが欲しくなるもので、そうなると国際化ってとても大事なテーマかなと思います。
今回のハンズオンでは取り扱いませんでしたが、Codex に詳しい資料があるので興味のある方は見てください。
I18n for WordPress Developers – WordPress Codex 日本語版
また、サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル
本題とずれまくるので今回は説明しなかったことをつらつらと。
このプラグインは、WP-CLI 使ってプラグインのひな形を作成しています。
$ wp scaffold plugin plugin-hans-on-sample
地味ですがすっごい便利だったりします。そこから生成されたファイルにコードを書いてます。
また、PHPUnit によるテストも書いています。
ここら辺の環境構築をサクッと行いたい場合は、VCCW が便利です。
プラグインそのものを作るのはホントに簡単です。コメントを書いたPHPを用意して、せいぜいreadme.txt を用意するだけでOKです。Hello Dolly や Nothing Much のような何もしないプラグイン、Hello Kushimoto といった完全にネタとしか思えないもの（実はそんなこと無いんですが･･･w）もあったりします。
ですが、WordPress が用意している API も山ほどありますし、本当に出来ることも多いです。WooCommerce や、BuddyPress など WordPress サイトにかなり大幅な機能追加をするプラグインもあったりします。
MySQL の知識や、高度な PHP や、JavaScript の知識が必要なカスタマイズなども様々です。
とりあえず、バイブル や Codex を読みつつ、自由な発想でプラグインを作れば良いんじゃ無いかと思います。
プラグインとか作ると楽しいよーってセッションもしたのでこちらもどうぞ。
先日行われた WordCamp Kansai 2016 に参加してきました。今年は初めて実行委員として、主にセッションチームの仕事を、またセッションとハンズオンをそれぞれスピーカーとして担当させて頂きました。
懇親会で飲み過ぎて二日酔いだったり、そもそも移動の疲れや大阪の蒸し暑さで体力ゼロでした。そんな体が悲鳴を上げる中で、ワクワクしてセッションを聞きに行ったり、「裏番組のセッションとかハンズオンも絶対面白いじゃん！どうして体が2つ無いの！」って思いながら当日過ごして居たので、それはとても良かったのかなーと思う次第です。おかげさまで昨日は熱出して寝込みました。
WordPress.tv に後日動画がアップロードされるので、ゆっくり見ようと思います。
実行委員・スピーカー・そのほか支えてくれた皆様お疲れ様でした。ありがとうございました。
実行委員としての話はながーくなるので、とりあえず、自分の担当セッションのフォローアップ的なものを。
自分のオープンソースへの取り組み、というと大げさですが、そういったことに関わったことでの個人的な感想・体験などを共有出来ればと思いました。
オープンソースにすることやコントリビューションすることで発生するコミュニケーションってのは楽しいですし、また、いろんな人の小さなコントリビューションの積み重ねでいろんなものが便利になっていくってのは、とってもステキなんじゃ無いかと思ったりするわけです。
今回だと、GitHub と Travis CI で WordPress テーマをテスト、ビルド、そして自動化 というテーマで今回登壇して頂いた羽野さんの amethyst というテーマにプルリクエストを送ったりしていたんですが、めちゃくちゃ勉強になりました。また、当日初対面だったのですが、その件でいろいろ話し込んだりすることが出来たのがすっごい楽しかったです。
去年の WordCamp Kansai でも実は初対面だったキタジマさんと飲みに行ったり。
初対面の人に話しかけたりすること等が苦手で、テレビとかに出てくるナンパ師みたいなコミュ力お化けみたいな人からは全力で逃げるタイプの人間ですが、そんな僕とってのコミュニケーションの方法がオープンソースなのかなと、終わってみて改めて気づいた今回の WordCamp Kansai でした。
プラグインを公開したときの記事があったのでそちらもどうぞ。
Composer WordPress Development Kit という、Composer と PHP のビルトインサーバーを使って、WordPress 環境をサクッと立ち上げるものを以前作ったんですが、バージョンアップしました！
使ってみていろいろ気になったところなどが出てきたのでかなり大幅に変更しました。
ドキュメントルートをディレクトリ直下に変更しました。なので、サーバー上 で WordPress を立ち上げるときも同じコードをそのまま使えるようになりました。Git の Webhook を使って、レポジトリが変更されるたびに、自動デプロイ出来るようになったりしてます。デプロイ自動化などは、第2回 Gitリポジトリからテスト環境への自動デプロイ – CPIエバンジェリストコラム 等を参考にすれば良いんじゃ無いかなと。
WordPress を丸ごと composer で管理出来るといろいろ便利ですね。
$ composer import-theme-unit-test
で、テーマユニットテストがコマンド一発でインポートできるようにしてあったりしてます。
$ composer provision
でWordPressのインストールをするように変更したり、
$ bash ./bin/server.sh
でビルトインサーバーの起動をするように変更しました。
そのほか、サーバ上で運用するために、config.php ファイルというのも新しく作ったり、config.json を local-config.json って名前に変えたりしてます。
詳しい使い方はドキュメントを参照してください。
以前、WordPress Packagist を使うと、WordPress のプラグインも Composer で管理出来ることは知っていたのですが、プラグイン側の composer.json に、
"type": "wordpress-plugin"
と書いておいて、Packagist に登録しておくと、ちゃんと WordPress のプラグインとしてインストール出来るようです。
https://github.com/Automattic/jetpack とかもちゃんと書いてありますね。
使うには、composer.json にディレクトリの指定を書いたりする必要があります。こんなかんじ。ベータ版などを試すときとか地味に便利そうです。
WordPress でも PHP のエコシステムをうまいこと使っていければ、かなり便利に開発を進めていけそうですね。
何かあれば issue とかプルリクとかくださいー。
先週の土曜日に行われた、WordBench 山梨 Vol.2 で、ナツミーヌさんに「LTしないとお前もベジェ曲線にするぞ」とデーモン閣下風に脅されたので（嘘）LTしてきました。
とろゆにっとさんは非常にまじめな人間です。ですので当然、まじめなLTをやるはずだったのに、芸人枠と紹介されたのは非常に心外です。抗議も辞さない！
というわけで当日のスライドです。
カスタムフィールドの便利さと、技術的負債、そして愛について熱くしゃべってきました。WordPress をただ使うのでは無く、いろんな選択肢の中から WordPress を「選択する」ためのヒントになれば良いなーと思います。
ウケたかどうかは良く解りませんがなんとかやりきりました。実はLTってあんまりやったこと無かったりするので、楽しかったです。
ほかにも、たぬきさんや、なま＆はげのはげの人（はげてない）や、人狼の人など、全般的に妙な方向に濃かった会だった気がします。
http://www.slideshare.net/endohshingo/wordpress-58811284
http://www.slideshare.net/GOUTEN/ss-58786247
質問コーナーなどもあってそれも妙に濃い話になってたのが僕的には面白かったです。割とかみ砕いて話したつもりなんですけど、実際どうだったんでしょうかね。
とりあえず、懇親会も楽しかったです。WordBench 長野も頑張ろうと思いました。ナツミーヌさんありがとうございますー。
カスタムフィールドの闇は深い。
管理画面から、カテゴリー・カスタム投稿・タクソノミー等のアーカイブの表示件数を、管理画面から変更できるプラグイン Powerful Posts Per Page (PPPP) をバージョンアップしました。
最新版でテストをしたり、PHP 5.3 でテストしたり、ついでにカバー画像を変えたりしました。
たぶんコーポレートサイトで製品紹介とかやるときとか、ギャラリーをやったりするときとかで使えるんじゃ無いかなーとか思ったりしてます。
プルリクくださーい。
普段は VCCW を好んで使っているんですが、ちょっとお手軽環境もほしいなぁとか、Composer をもっと積極的に WordPress に導入する方法は無いんだろうかとかいろいろ考えてた訳ですが。
というわけで、Composer WordPress Development Kit なるものを作りました。
まぁ名前通りそのまんまですが、Composer で WordPress の開発環境作ったよ的な奴です。WordPress Packagist を使うと、WordPress のテーマやプラグインも Composer で管理出来ます。
プラグイン・テーマの検証とかフォーラム回答とかで、さくっと起動してさくっと使い捨てる環境ほしいときに便利です。たぶん。
また、WordPress と外部の PHP ライブラリや、JS フレームワークを組み合わせたアプリケーションのひな形的なものとして使えれば良いなーと思って作りました。
とりあえず、php・mysql・jq・composer を動くようにしてください。OS X の人は homebrew を使えば楽です。別に composer は phar をダウンロードして使っても大丈夫です。
$ brew install mysql jq composer
その後、適当なディレクトリに、composer create-project をすると、ひな形が作成されます。
$ composer create-project torounit/composer-wp-dev-kit path/to/project
その後、config.json を編集し ./bin/provision.sh 実行すると、PHPのビルトインサーバーで、WordPress 環境が立ち上がります。
$ cd path/to/project $ atom config.json $ ./bin/provision.sh
また、ディレクトリ構成を通常の WordPress からいじってあります。本体は、www/wp にインストールされますが、wp-content は www/wp の外側に出してあります。テーマとかプラグインをレポジトリに突っ込んで管理するにはやりやすいのかなーとは思います。
また、Composer でインストールされたものは、 mu-plugins に突っ込んで有り、autoload されるようになってるので、Composer で適当なライブラリをゴリゴリ放り込んでつかうのも有りかなとは思っています。
また、これを使ってると、WP-Cli で PHP のビルトインサーバーが起動するんですが、パーマリンクの設定画面を見ると、index.php が入ってしまうんですよね。
これをどうにかするためのプラグイン、Built-in Server Helper を作成しました。プラグインディレクトリにも公開してありますし、Composer WordPress Development Kit にも同梱してあります。
一応 PHP -S のほうでのビルトインサーバーのほうにも対応してますが、ルータースクリプトが無いので、URLに拡張子がついていると、そのファイルへのアクセスになります。そうすると 404 になるので、その場合は index.php 付きの URL をセットします。まぁ、WP-CLI 使えばいいと思います。
とりあえず、WordMove にも申し訳程度に対応してますが、mu-plugins を使っているので、preバージョンの 1.4 からの対応です。
とりあえず、プラグインの検証とJS フレームワークと REST-API を組み合わせたアプリケーションのひな形として使っていこうかなと思ってます。
何かあれば issue とかプルリクとかくださいー。
今更ですが、このブログのテーマはGithubに公開されています。
レポジトリ: torounit/torounit2015
当然、開発とかも GitHub 上で行っているのですが、とにかくデプロイが面倒くさいんです。
正直 Typo の修正程度で、FTPとか、rsync とか VCCW を立ち上げて WordMove とかってしたくないんですよね。FTP とかをアプリからやったりすると、たまに間違ったサーバーにつないでるのに気づかないで別の環境を上書きするなんて事故も起きかねない。
というわけで、デプロイ自動化というのは人類共通の課題だったりするわけです。
Sass を使ったり、ES6 でバベったりしていたりもするので、単純に GitHub で Webhookして git pull すれば良いということでもない。。。。サーバー側で node.js とか gulp とかインストールするのも面倒ですし。
というわけで、Travis CI と WP Pusher を使って、テーマの自動ビルド・自動デプロイ環境を構築しました！
図にするとこんな感じです。
処理の流れとしては、
となります。
設定さえしてしまえば、GitHub 上のレポジトリに push するだけで、テーマの更新が反映されます。とても楽ちん。便利。
何はともあれ、まずは gulp でテーマをビルドするタスクを作成します。テーマファイルの直下に、dist という名前のディレクトリにビルド済みのテーマファイル一式が展開されるようにします。
bulid:dist タスクで、CSS とか JS は assets/dist の中にコンパイルされるものとします。ここら辺は環境や好みで書き換えてください。
'use strict';
var gulp = require('gulp');
var runSequence = require('run-sequence');
gulp.task('copy', function() {
return gulp.src(
[
'./**/*.php',
'./assets/dist/**',
'./style.css',
"!./dist/**",
"!./node_modules/**/*.*"
],
{ base: './' }
)
.pipe( gulp.dest( 'dist' ) );
} );
gulp.task('build:dist',function(){
/* ここで、CSS とか JS をコンパイルする */
});
gulp.task('dist', function(cb){
return runSequence( 'build:dist', 'copy', cb );
});
これで、 dist ディレクトリにテーマの一式がコピーされました。
また、これを、package.json に指定しておくと、gulp が グローバルにインストールされていなくても
$npm run dist
で実行できるようになります。便利。
{
"scripts": {
"dist": "gulp dist"
}
}
Travis CI の CI は Continuous Integration の略で、和訳すると、継続的インテグレーションといいます。
継続的インテグレーション、CI（英: continuous integration）とは、主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。
自動ビルドとかテスト自動化などはこの取り組みの一つです。
Travis CI はそれをサポートするサービスです。似たようなサービスに Circle CI とか Magnum CI なんかがあります。
インストール型だと、Jenkins がめちゃくちゃ有名ですね。
これを使うと、GitHub のコミットを監視して、指定したコマンドを自動的に実行することができます。めちゃくちゃ便利。
https://travis-ci.org にアクセスして、Sign Up をクリックして、その後は手順に従っていけばサインインできます。
サインインできたら、右上のユーザーメニューのなかに Accounts という画面がでてきますので、そこで、レポジトリと Travis CI の連携をセットアップします。といっても1クリックで終わります。レポジトリを選択してボタンを押すだけです。
その後、レポジトリ直下に .travis.yml というファイルを作ってください。そこに以下のような内容を記述すると、コミット時にタスクが実行されます。
language: php
sudo: false
php:
- "5.6"
before_script:
- nvm install 4.2
- npm install
script:
# Search for PHP syntax errors.
- find . \( -name '*.php' \) -exec php -lf {} \;
after_success:
# Run npm build task.
- run npm dist
実行状況は、https://travis-ci.org/ユーザー名/レポジトリ名 で確認できます。要は、GitHub のレポジトリのURLのドメインが、travis-ci.org になったやつです。
torounit/torounit2015 – Travis CI で僕のレポジトリは確認できます。
Travis CI でビルドタスクが自動実行されるようになりましたが、実行後にデータが破棄されてしまうので、これをどこかに保存する必要があります。今回は、GitHub Pages みたいに、空のブランチを作成して、そこに push するようにします。
レポジトリのあるディレクトリに移動して以下のコマンド実行してください。
git checkout --orphan dist git rm -rf . touch .gitkeep git add . git commit -a -m "dist branch init" git push origin dist
参考：Creating Project Pages manually – User Documentation
その後、GitHub でレポジトリを確認すると、dist ブランチが作成されているはずです。
GitHub のレポジトリへのコミットをするのですが、当然ながら認証が必要です。なのでアクセストークンを使って認証します。
Github の Personal Access Tokens にアクセスして、「Generate access token」をクリックしてください。 適当な名前をつけて、「Generate token」をクリックすると、トークンが表示されますので、とりあえずどこかにコピーでもしておいてください。
ページ遷移したり、更新したりすると、2度と表示されないので気をつけてください。また、外部に漏れないように厳重に管理してください。
僕は管理するのが面倒なので、アプリケーションごとに生成しています。
このアクセストークンを使うと、
git push "https://${トークン}@github.com/${オーナ名/レポジトリ名}" dist
みたいな感じで push がデキるようになります。
トークンを厳重に管理しろと言いましたが、これだと平文で .travis.yml に記述することになって大変まずいことになります。そこで、travis には、変数を暗号化する仕組みがあるのでそれを使います。公式の gem がありますのでそれをインストールしてください。Ruby が入ってない Windows の人は頑張ってRuby を入れましょう。
gem install travis
それができたら、以下のコマンドを適宜読み替えて、暗号化して下さい。
travis encrypt -r オーナ名/レポジトリ名 "GH_TOKEN=トークン"
実行すると、
secure: "なんか文字列いっぱい"
みたいな格好でこれを .travis.yml に記述してくださいと言われるので、以下のような感じで記述します。
ついでに Git で使うパラメーターも追記します。
language: php
sudo: false
php:
- "5.6"
env:
global:
- GIT_COMMITTER_NAME=travis-ci
- GIT_COMMITTER_EMAIL=Githubに出るメールアドレス
- GIT_AUTHOR_NAME=travis-ci
- GIT_AUTHOR_EMAIL=Githubに出るメールアドレス
- secure: "なんか文字列いっぱい"
before_script:
- nvm install 4.2
- npm install
script:
# Search for PHP syntax errors.
- find . \( -name '*.php' \) -exec php -lf {} \;
after_success:
# Run npm build task.
- run npm dist
また、
travis encrypt -r オーナ名/レポジトリ名 "GH_TOKEN=トークン" --add
のように –add オプションをつけると勝手に .travis.yml に追加してくれます。
このまま、after_success にコマンドを追記していくと面倒なので、bin/deploy.sh というファイルを作成して、そこで コミットをするようにします。
after_success: - bash ./bin/deploy.sh
bin/deploy.sh の中身はこんな感じ。
#!/usr/bin/env bash
set -e
git clone -b dist --quiet "https://github.com/${TRAVIS_REPO_SLUG}.git" dist
npm run dist
cd dist
git add -A
git commit -m "Update from travis $TRAVIS_COMMIT"
git push --quiet "https://${GH_TOKEN}@github.com/${TRAVIS_REPO_SLUG}.git" dist 2> /dev/null
$TRAVIS_REPO_SLUG で オーナー名/レポジトリ名 が取得できます。https://github.com/torounit/torounit2015.git であれば、torounit/torounit2015 が取得できると言うことですね。また、最後の 2> /dev/null とかを忘れると、見えちゃいけないものが公開されたりで偉いことになります。
これで完成！と言いたいところですが、このままだと、開発中の機能のブランチも勝手に反映されたり、プルリクエストも反映されてしまったりといろいろ地獄です。
そんなわけで、プルリクエストの場合と、master ブランチ以外へのコミットの場合を除外します。
#!/usr/bin/env bash
set -e
if [[ "false" != "$TRAVIS_PULL_REQUEST" ]]; then
echo "Not deploying pull requests."
exit
fi
if [[ "master" != "$TRAVIS_BRANCH" ]]; then
echo "Not on the 'master' branch."
exit
fi
git clone -b dist --quiet "https://github.com/${TRAVIS_REPO_SLUG}.git" dist
npm run dist
cd dist
git add -A
git commit -m "Update from travis $TRAVIS_COMMIT"
git push --quiet "https://${GH_TOKEN}@github.com/${TRAVIS_REPO_SLUG}.git" dist 2> /dev/null
これで自動ビルドの完成！
自動ビルドの設定が終わったので後はもう一息！ GitHub の WebHookを利用して、dist ブランチに変更があったときに、WordPressのテーマを更新させましょう。
今回は、WP Pusher というプラグインを使います。ちなみに Giploy というプラグインでも同じようなことは出来るはず。
WP Pusher のページに飛んで、Try WP Pusher のボタンをたたいて、Download のボタンを押すと、メールアドレスを聞かれるので、おとなしく入力するとダウンロードリンクがメールで飛んできます。
それをダウンロードしてインストールしてください。
すると、サイドバーにWP Pusher というメニューが出来ます。レポジトリ名とブランチを正しく入力すればOKです。Push-to Deploy にチェックを入れると自動デプロイ機能が有効になります。
こんな感じです。その後 Install theme をクリックすると、テーマがインストールされます。
このままでも、管理画面からテーマが更新できるようになります。
WP Pusher の Themes メニューを開くと、現在このプラグインが管理しているテーマが表示されます。そこの、 Push-to-Deploy URL に表示されている URL をコピーしてください。
そして、GitHub の レポジトリの Settings 内にある Webhooks & Services から Add Webhook してください。
そしたら、Payload URL という項目があるので、先ほどの Push-to-Deploy URL を入力して、保存して下さい。
以上で、自動デプロイの設定は完了です。お疲れ様でした。
プラグインとかも同じ流れでデプロイできるので、これでよりよい CI 環境がWordPressでも簡単に構築できます！
テーマの自動デプロイなどが出来ると FTP などのアップロード作業から解放されるので、かなり快適に開発を進めることが出来ますよー。Typo とかは GitHub 上から直したり出来るので、スマホから直したりとかもできて非常に便利。
ただ、面倒なのは WP Pusher が公式ディレクトリにないのでそれがちょっと面倒です。
プライベートレポジトリとかの機能を削ったバージョンを上げてくれないかなぁ。。。。
WordPressでスターウォーズネタやろうと思ったんですが、正直全く面白いことが思いつかなくて断念しました。
WordPress Advent Calendar 2015に参加したかった人達の Advent Calendar 2015ということで、今年一年をざーっと振り返ってみようかと思います。
WordPress 4.3, 4.4 のコアにパッチを送ったら採用され、コアコントリビューターになりました。
特に4.4のコードは実際に案件でトラブルに遭遇したところを直したので、嬉しかったのを覚えてます。報告されてたけど埋もれていたチケットだったので、ちょっとどうしたものかと思いましたが、テストコードもつけてパッチを投げたらすんなりマージされました。
テストコードを書く方が伝わりやすいこともあるのかな、と思うので今後もパッチを送るときは可能な限りテストコードも一緒に送ろうかと思います。英語で「変数の型が変わってる」みたいな話をするのはちとつらい。というか日本語でもバグの説明をするのは容易ではなかったりするので、そのための言語としても良い手段だなとは思いました。
なんだかんだで、一番大きい出来事は WordCamp Kansai 2015、WordCamp Tokyo 2015で登壇させてもらったことですね。あの規模で登壇して話すのはなかなか緊張しました。
特に関西は実はあったこと無い方々と話せる機会が多く、いろいろ楽しいきっかけがもらえたように思います。それがあったから東京でも登壇しようと思ったので、いろいろな転機になったように思います。
WordBench 山梨、大阪、京都や、WordFes Nagoyaにも参加しました。
山梨では、某フルスタック小説家の秘密基地に拉致されたり、大阪では、まさかの2時間トークショーをしたり、京都ではかの有名なWordPressミュージシャンの口タイポを生で聞くことができました。
WordFesでは酔っ払い生放送をして心身ともにボロボロになったりもしました。何にも覚えてないんですけど。。。。。。。
基本的に、どこに行っても酒飲んで二日酔いになってる気がします。これはまずい。
やっぱり実際に会うのは良いなぁと思いました。別に、リモート勤務などありますし、実際に会わなくても仕事が出来たり、SNS等でコミュニケーションができる時代ですが、だからこそ会いに行くのは重要かなと思いました。
さすがにリモートで焼肉食ったりは出来ないですし、お酒とか飲むにも味見とかしたい。酔っ払ってアホになってる人見るのは現場で見ないと面白くないですしね！！！
特にこれからも地方でやっていこうとしている僕にはとても重要なテーマかなと感じました。
そんなわけで、まぁ抱負というか、松本市のコワーキングスペースのKnowersさんでとりあえず、週一くらいで、もくもく会とかやらせていただけることになりそうです。
そんなわけで、WordBench長野も頻繁に行えるようになるかなーと思います。京都、大阪くらいのペースでやれたら良いなとは思っていますが、そこら辺はやりながらうまいペースを見つけていけたらと思います。
片付けとかがすごい苦手なんですが、人が泊まれる程度には綺麗にしようと思うので、県外からも観光ついでに来てもらえるくらいには頑張りたいと思います。
そのほか、現在細々と作ってるテーマとかも公式にあげたり、AWSをもう少し勉強したりとやらなきゃいけないことは尽きないですがいろいろがんばりまーす。よろしくおねがいしまーす！！
http://www.slideshare.net/Toro_Unit/wordpress-54602891
先日の WordCamp Tokyo 2015 でいろいろお話させて頂きましたが、本体のテストや、そこら辺のリソースのまとめです。
WordPressのテストコードは、WordPressの開発レポジトリから取得できます。subversion が必要なので、Xcodeとか、Windowsの人は TortoiseSVN とかインストールすればいいと思います。
んで、こんな感じで取得できます。
$ svn mkdir wordpress-develop $ cd wordpress-develop $ svn co https://develop.svn.wordpress.org/
サブバージョンのチェックアウトは、現在のディレクトリに直接行われるので、適当にディレクトリを作ってそこで行います。ホームディレクトリとかでやると結構悲惨です。
全部取得すると結構な時間（10分弱？）がかかるので、その場合は最新の開発版が入ってるtrunkだけ取ってくればとりあえずいいかなと思います。
その場合は、先のコマンドの最後の1行を
$ svn co https://develop.svn.wordpress.org/trunk
こんな感じに変更すればいいです。
ex: Using Subversion « WordPress Codex
ちなみに、読むだけなら、https://core.trac.wordpress.org/browser/ とかでも読めますが、開発時に補完とかあるといろいろ捗るので、チェックアウトしておくことをおすすめします。
チェックアウトできたら trunkや 適当なバージョンのディレクトリに入って、testsディレクトリを覗いてみるととテストコードがあります。
phpunitとqunitがありますが、基本的にはPHPUnitを扱います。Qunit はJSのテストです。テーマカスタマイザーとかビジュアルエディタのテストが入ってます。
また、PHPUnitのソースコードをGithubあたりから引っ張ってきて、IDEとかエディタで読み込むようにするとかなり楽になります。
$ git clone https://github.com/sebastianbergmann/phpunit
とりあえず、全部読もうとするとパニクるので、比較的自分が取り扱ってるところから中心に読んでみるのがいいです。どこに書いてあるか解らない場合は、とりあえず関数名・クラス名で検索をかければだいたい見つかります。
よくわからないという人は、trunk/tests/phpunit/tests/rewrite.php を読んでみましょう。ひとつひとつのテストがかなり短めなので、わかりやすいかなと思います。だまされたと思って、 Tests_Rewrite:: test_url_to_postid あたりを読んでみましょう。
class Tests_Rewrite extends WP_UnitTestCase {
/* 省略 */
function test_url_to_postid() {
$id = $this->factory->post->create();
$this->assertEquals( $id, url_to_postid( get_permalink( $id ) ) );
$id = $this->factory->post->create( array( 'post_type' => 'page' ) );
$this->assertEquals( $id, url_to_postid( get_permalink( $id ) ) );
}
/* 省略 */
}
投稿を作ってそのIDと、生成されたパーマリンクから逆算した投稿IDが一致してるかどうかを検査してるだけです。読んでみるとこんなもんだったりします。
長いテストでも、製品のコードとは違って、複数の関数が絡み合ったりとかがないので、結構読みやすいです。
テストコードを読んでいくと、
$id = $this->factory->post->create();
とか
$blog_id = $this->factory->blog->create( array( 'path' => '/example' ) );
みたいな奴がいますが、$this->factoryが、WP_UnitTest_Factory というClassのインスタンスになっています。これが便利で適当にパラメーターを突っ込むと、不足分のパラメーターを補って、投稿とか、マルチサイトのブログとか、カテゴリーとかその他もろもろを作ってくれます。
一応プロパティとして存在するのはこれだけあります。
networkとかよくわからんです。が基本的には、create, create_and_get, create_many さえ知ってれば全部使えます。
先ほど上げた、WP_UnitTest_Factory::$post 等の親クラスです。create 等はここに実装されています。
テストコード内の
$id = $this->factory->post->create();
等の親玉です。第1引数に、配列でパラメーターを突っ込めばいいです。パラメーターは、wp_insert_postとか、wp_insert_attachment とか、wp_insert_term などそのオブジェクトを生成する関数のパラメーターを渡せばいいです。生成した後、ID が返ります。
WP_UnitTest_Factory_For_Thing:create() とそんなに変わらないですが、返値が IDではなくオブジェクトが返ってきます。get_postで返ってくる奴だったり、get_termで返ってくる奴だったり。
オブジェクトを大量に生成するときに使います。
第1引数に生成するオブジェクトの個数、第2引数にパラメーターを設定すればその分だけ投稿とかタームとかが生成されます。戻り値はIDの配列です。
まだまだテスト周りはいろいろクラスや関数がいたりするのですが、とりあえずダミーデータの生成が簡単にできるし、簡単に再現可能というだけでもテスト書く意義ってあると思うのでとりあえず書けばいいと思います。
あと、テストコードを読むことで、ドキュメントやソースを読むのとはまた別の角度で実装の理解が出来たりします。また、「こういう感じでテストすればいいのかー」みたいなのが解ってくると、WordPress 以外でも使えるアイデアがあったりします。
テストコード入門編にいかがでしょうか？
プラグインとか書きながらいろいろ読むと、意外な発見とかもあるのでおもしろいですよー。
WordCamp Tokyo 2015 2日目はコントリビューターデイでした。
僕はプラグイン班のところにいたのですが、「初心者でよくわからないんです」っていってた人がプラグインを書いて、公式に申請を出していたのがとてもうれしかったです。実はWordPressの公式プラグインはハードルが低いのでぜひぜひ皆さんもやってみましょう。
まぁ、そんな中僕も新しいプラグインを作り、先ほど承認されたので公開しました！
Hello Kushimoto というただのプラグインでは無い、超すごいプラグインつくりました。
これを有効にすると、管理画面の右上にあの有名なエンジニアのMさんの名言がランダムで表示されます。また、[[kushimoto]] というショートコードを使うことで、記事本文にいつでもMさんの名言を表示することが出来ます！
かの有名なただのプラグインではないプラグインのフォークでは無いので、同時に有効化しても大丈夫です。非常にシュールです。
カバー画像は、すぴかあやかさんに書いてもらいました。あの雑な発注でこんな素敵なイラストが納品されるとは…
Githubで開発しています。 https://github.com/torounit/hello-kushimoto
もちろんTravis-CIで自動テストも行っています！
https://travis-ci.org/torounit/hello-kushimoto
じゃんじゃんプルリクエストください。アイコンなどは assets ブランチにどうぞ。
表示するキーワードを生成するインスタンスを変更できます。ここで返すインスタンスは Hello_Kushimoto_Speaker インターフェースを継承する必要があります。
ショートコードの名前を変更できます。
https://twitter.com/motchi0214/status/660996910363185152
たかが Hello Dolly でも大まじめに作ると実は勉強になることが多いので、なんでもいいから作ってみるってのはとても有意義だなぁと思いました。（小並感）
共犯者を作ろうと思ってたら本人からもプルリクエスト来たので良く解らないことになってますが、復讐されないように気をつけてプルリクエストは投げましょう。Githubなので犯行記録がしっかり残ります。
記事書いてる間にプルリクエストが飛んできたので、早速マージして更新しようと思います。