WordPress には標準で最近の投稿を表示できるウィジェットが用意されていますが、アイキャッチを表示することができません。アイキャッチが表示できるウィジェットのプラグインなどもありますが、もっと柔軟にフォーマットを変更できると便利だなと思ったので Latest Posts Template Widget というプラグインにしてみました。ついでにどの投稿タイプの新着を出すかも選択できるようになっています。

使い方

管理画面のプラグイン新規追加画面から「Latest Posts Template Widget」で検索してインストール、有効化してください。すると、ウィジェットの管理画面にでてきますので、適当な場所に配置してください。

Latest Posts Template Widget 設定画面

「テンプレート」の部分に任意のHTMLが記述できます。$post のプロパティが取得できるようになっていて、例えば {post_title} と記述すれば画面上では投稿のタイトルが表示されます。また、{permalink} でリンクURLを、{thumbnail} でアイキャッチ画像が表示できます。{thumbnail サイズ} でサイズも指定できます（例：{thumbnail medium}）。

このテンプレートで記述したHTMLは画面上では. latest_posts_template_widget ul liの中に配置されることになるので適当のCSSを当ててください。

僕は普段 MacBookAir の 128GB を使っているのですが、最近 Vagrant でローカルに開発環境を作るようになり、複数の VM が容量を圧迫するようになっていました。調べてみると Vagrant の環境を外付けHDDなどに移すことができるようだったので、手持ちのポータブルHDDに移してみました。

ここでは下記の構成で移動させました。

• ファイルディレクトリ
  /Volumes/data/htdocs/www.example.jp/vccw/Vagrantfile
• Vagrant データ
  /Volumes/data/htdocs/vagrant_home/
• VirtualBox データ
  /Volumes/data/htdocs/vagrant_vms/

VirtualBox

Vagrant の環境を外付けに移すには、まず VirtualBox の設定を変更する必要があります（僕は Vagrant の VM を管理するのに VirtualBox を使っているので、VMWare の場合は別途ググってください…。）。はじめはよく分からずにまず Vagrant のデータディレクトリを外付けに移して試してみたのですが、VirtualBox のデータを移してからでないと Vagrant のデータディレクトリがローカルに復活してしまうようでしたので注意してください。

デフォルトの仮想マシンフォルダー

VirtualBox > 環境設定 > 一般 > デフォルトの仮想マシンフォルダー を開き「/Volumes/data/vagrant_vms」に変更します。

デフォルトの仮想マシンフォルダーの設定

既に存在しているデータを移動させる場合は下記コマンドでデータを移動して

# VM を移動
mv ~/VirtualBox\ VMs/xxxxxxxxxxx /Volumes/data/vagrant_vms/

VirtualBox マネージャーで対象の VM を「除去」>「除去のみ」。

VMの除去

これでマネージャー上からは消えるので、VirtualBox > 仮想マシン > 追加 で「/Volumes/data/vagrant_vms/xxxxxxxxxxx/xxxxxxxxxxx.vbox」を選択して外付け上の VM を追加します。

Vagrant

Vagrantのデータが外付けに生成されるようにするには、環境変数 VAGRANT_HOME を設定します。次のコマンドで設定できます。

# VAGRANT_HOME を設定
export VAGRANT_HOME=/Volumes/data/vagrant_home

既に存在しているデータを移動させる場合は下記のコマンドでデータを移動させます。

# Vagrant データの移動
mv ~/.vagrant.d/* /Volumes/data/vagrant_home/

これで vagrant up すれば外付け上で Vagrant 環境が使用できます。

# Vagrant を起動
cd /Volumes/data/htdocs/www.example.jp/vccw/
vagrant up

僕の MacBookAir は USB2.0 なので速度的にきついかなと心配していましたが、特に問題なく使えました。Modern.IE の環境2つと、Vagrant の環境2つを移動させて 30GB の容量を確保できました。とりあえずこれで容量問題は一安心…。

昨日、「MacBookAir の容量がきついので Vagrant 環境を外付けに移した話」という記事を書きましたが、WordPress のテーマ・プラグインは Subversion で管理する必要があり、これまでは Subversion で WordPress の公式ディレクトリにだけアップしていたのですが、プルリクなどもらいやすいように GitHub にも公開するようにしたいと思っていたので、ついでに Grunt でその辺の環境も整えてみました。

下記のコマンドで開発環境のディレクトリから Subversion 用のディレクトリ、GitHub 用のディレクトリにファイルがコピーされるようになっています。

# GitHub 用のディレクトリにファイルをコピー
grunt github
# Subversion 用のディレクトリにファイルをコピー
grunt svn

Grunt の準備

この Grunt の設定は複数の WordPress テーマ・プラグインの開発環境で共通に使えるようにしたかったので、簡単にインストールできるようにシェルスクリプトにしました。

vi gruntinit.sh

npm init
npm install --save-dev grunt grunt-contrib-clean grunt-contrib-copy

Gruntfile.js は下記のような感じです。GitHub 用、Subversion 用のディレクトリの中身を一旦全て削除して、開発環境から必要なファイルをコピーするようにしています。テーマ・プラグインを構成するファイルが追加される場合は特に問題無いと思いますが、ファイルが削除される場合は別途 git rm とか、svn delete したほうが良いかもしれません（ちょっとこの辺詳しくないです…）。

module.exports = function( grunt ) {
	// load task
	grunt.loadNpmTasks( 'grunt-contrib-clean' );
	grunt.loadNpmTasks( 'grunt-contrib-copy' );

	// Project configuration.
	grunt.initConfig( {
		dir: {
			// Gruntfile.js から見た WordPress ルートへの相対パス
			develop: 'vccw/www/wordpress',
			// プラグインディレクトリ名
			plugin: 'mw-wp-form',
			// GitHub 用ディレクトリパス
			github: '/PATH/TO/github/<%= dir.plugin %>',
			// Subversion 用ディレクトリパス
			svn   : '/PATH/TO/svn/<%= dir.plugin %>/trunk'
		},

		copy: {
			github: {
				expand: true,
				cwd: '<%= dir.develop %>/wp-content/plugins/<%= dir.plugin %>/',
				src: '**',
				dest: '<%= dir.github %>/'
			},
			svn: {
				expand: true,
				cwd: '<%= dir.develop %>/wp-content/plugins/<%= dir.plugin %>/',
				src: '**',
				dest: '<%= dir.svn %>/'
			}
		},

		clean: {
			options: { force: true },
			github: {
				src: [
					'<%= dir.github %>/*/',
					'<%= dir.github %>/*.*'
				]
			},
			svn: {
				src: [
					'<%= dir.svn %>/*/',
					'<%= dir.svn %>/*.*'
				]
			},
			noneed: {
				src: [
					'<%= dir.github %>/.DS_Store',
					'<%= dir.svn %>/.DS_Store'
				]
			}
		}
	} );

	grunt.registerTask( 'github', [ 'clean:github', 'copy:github', 'clean:noneed' ] );
	grunt.registerTask( 'svn', [ 'clean:svn', 'copy:svn', 'clean:noneed' ] );
};

実際のところ、仮想環境内のテーマフォルダやプラグインフォルダをそのままローカルリポジトリにしてしまって git-svn で Git と Subversion 同時に管理したほうが効率的だと思いますが、WordPress の公式ディレクトリにはリリース版だけあげて GitHub のほうには途中の物でもある程度こまめにあげるようにしたかったので、このような構成にしてみました。僕はあまり環境構築は詳しくないので、もっと効率の良い方法があるのかもしれませんが…。

WordPress プラグイン「MW WP Form」と現在公式ディレクトリに申請中のテーマ 「Kotetsu」を GitHub に上げたので、翻訳ファイルやパッチなどのプルリクお待ちしております^^;

複数人で記事を執筆するようなブログの場合（会社ブログとかメディアとか）、執筆者の一覧のアバターがバーっと表示されていると良い感じですよね。WordPress 標準のウィジェットにはそのようなものが無いようだったのでプラグインをつくりました。

ダウンロード

使い方

プラグインをインストールしてウィジェットの設定画面にいくと、「Profile」と「Authors List」という2つのウィジェットが追加されています。「Profile」は記事のページでそのページの著者のプロフィールを表示できるウィジェット、「Authors List」は著者のアバター一覧を表示するウィジェットです。

Profile ウィジェット

Profile ウィジェット

そのページの著者のプロフィールを表示できるウィジェットです。アーカイブページではウィジェット自体表示されず、シングルページでのみ表示されるようになっています。どのようにプロフィールを表示するかはテンプレートで記述できるようになっています。

{プロパティ名}とすることで、the_author_meta 関数 からそのプロパティの値を取得して表示できます。アバターを表示する場合は{avatar} で表示できます。{avatar 95} のようにサイズを指定することも可能です。

Authors List ウィジェット

Authors List ウィジェット

著者のアバター一覧を表示するウィジェットです。サイズ、並び順のキーを何にするか、昇順・降順、除外するIDの指定ができます。並び順のキーは一般的なものの他に、独自に「Order」というキーを加えています。これは固定ページの「順序」と同じように数字を入力して順番を制御することができるものです。ユーザーのプロフィールページに「Order」という入力欄が追加されていますので、そこから設定できます。このキーは get_users 関数 の orderby でも指定できます。

// Order の昇順でユーザー一覧を取得
$users = get_users( array(
    'orderby' => 'order',
    'order'   => 'ASC',
) );

こんな感じで表示されます。

シングルページでの表示例

ダウンロード

普段、ローカルは Vagrant（ VCCW ）で開発を行っていて、WordPress の各ディレクトリ・ファイルは Vagrant の共有フォルダ機能があるので良い感じに別環境に複製したりテスト環境、本番環境にアップロードしたりできるのですが、データベースの内容はローカルと共有できず、Vagrant 環境の中にある形となるので、インポート、エクスポートがとっても面倒だなと思っていました。

ということで、Grunt から WordPress データベースのインポート、エクスポートが良い感じにできるようにしてみました。

実際どのような環境にしたのか

対象サイトの開発環境のルートで grunt とコマンドを打つだけで Vagrant の起動、sql ファイルが存在したらそれをインポート（無ければ無視）、grunt halt でデータベースのエクスポート、Vagrant の終了が行われるようにしました（実際には、終了時に開発用の不要なファイルなどを除去したリリース用のデータをまとめて別ディレクトリに出力するようにもしていますが、ここでは省略します…）。

こうすることで何が便利かというと、僕はデスクトップ PC とノート PC、もしくは会社と自宅と復数の環境で開発を行っているので、例えば

1. デスクトップ PC で開発して終了時に自動的にデータベースをエクスポート（各ファイルは Git で共有）
2. 別の場所でノート PC にデスクトップ PC からエクスポートしたデータベースファイルをコピー
3. Vagrant を起動するだけで自動的にデータベースをインポート = デスクトップ PC の開発環境と同じ状態を復元

便利すぎる！！

本番環境のデータをローカルにインポート、開発してエクスポート、本番にインポートなんていうのもとても楽にできるようになりました。

ディレクトリ構成

VCCW を使って、下記のような構成で環境を用意しました。

/Users/hoge/htdocs/www.example.com（特定のサイトの開発環境のルート）
┣ Gruntfile.js
┣ vccw（vccw を clone したディレクトリ）
┗ mysql（データベースのインポート・エクスポート用ディレクトリ。自動で生成）

WP-CLI、MySQL のインストール

WP-CLI を使って WordPress データベースのインポート・エクスポートを行いますので、WP-CLI が入っていない場合はインストールします。「Grunt + Sass + Compassでつくるナウいフロントエンド開発環境」を参考にすると簡単です。

また、ホストマシンから Vagrant 上のデータベース（MySQL）のインポート・エクスポートを行うにはホストマシンで MySQL が動いている必要があるそうです。homebrew でインストールすると簡単です（Windows はわからないのでググってください…）。

# インストール
brew install mysql

# インストールすると次のコマンドで初期化してね的なメッセージがでるので従う。
# ここでしなくても、brew info mysql でまた見れます。

# 起動
mysql.server start

Grunt の準備

下記のコマンドで、必要な grunt プラグインをインストール。

npm init
npm install --save-dev grunt grunt-exec

で、下記が Gruntfile.js。

module.exports = function( grunt ) {
	grunt.loadNpmTasks( 'grunt-exec' );

	grunt.initConfig( {
		dir: {
			root       : '/Users/hoge/htdocs/www.example.com', // 開発環境のルート（フルパス）
			vagrantroot: '<%= dir.root %>/vccw',
			develop    : '<%= dir.vagrantroot %>/www/wordpress',
			mysql      : '<%= dir.root %>/mysql' // データベースインポート・エクスポート用ディレクトリ
		},
		mysql: {
			database   : 'wordpress', // データベース名
			user       : 'wordpress', // ユーザー名
			password   : 'wordpress'  // パスワード
		},

		exec: {
			up: {
				cwd    : '<%= dir.vagrantroot %>',
				command: 'vagrant up'
			},
			halt: {
				cwd    : '<%= dir.vagrantroot %>',
				command: 'vagrant halt'
			},
			wp_export: {
				cwd    : '<%= dir.develop %>',
				command: [
					'rm -rf <%= dir.mysql %>',
					'mkdir <%= dir.mysql %>',
					'wp db export "<%= dir.mysql %>/<%= mysql.database %>.sql"'
				].join( ';' )
			},
			wp_import: {
				cwd    : '<%= dir.develop %>',
				command: function() {
					var importfile = grunt.template.process( '<%= dir.mysql %>/<%= mysql.database %>.sql' );
					if ( grunt.file.exists( importfile ) ) {
						return 'wp db import "' + importfile + '"';
					}
					return 'echo no import file. ' + importfile;
				}
			}
		}
	} );

	grunt.registerTask( 'default', ['exec:up', 'exec:wp_import'] );
	grunt.registerTask( 'halt', ['exec:wp_export', 'exec:halt'] );
};

これで、下記ができるようになります。

• grunt … Vagrant の起動、sql ファイルが存在したらそれをインポート（無ければ無視）
• grunt halt でデータベースのエクスポート、Vagrant の終了

本来は Vagrant のほうをいじってやるのが良いのかもしれませんが、そちらには疎いので Grunt でやってみました。複数人作業だとデータベースの共有は問題があるかもしれませんが、一人作業の方はものすごく便利だと思うので、同じことで悩んでいる方の参考になれば嬉しいです！

先週の土曜日、第7回目となる WordBench 長崎を開催しました。直前まで運営の3人のみの申し込みという悲しい状況でしたが、当日は+2名の方にご参加いただきました。

今回はプラグイン・テーマをつくってあわよくば公式ディレクトリに申請してしまおうという内容でしたが、人数も人数でしたので内容自由のもくもく会という感じとなりました。

最後にはやったことの発表を行っていただきまして、初めてWordPressのプラグインを作ったとか、Bootstrapを組み込んだテーマを作ったとか、おもしろい内容でとても良かったです。僕はと言いますと、スーパープログラマーな方々に悩んでいるところを相談できたりして、ためになることは発表できませんでしたがプラグインの開発がをぐぐっと進めることができました。WordPressのプラグインを作って実現したいことがあるけどうまくコードにできずに悩んでいる方は多分いると思うので、今後そのようなことを相談できる場にしていけたら良いなーと思いました。

今回は公式ディレクトリに申請する的なことはできなかったので、また次回もその内容でいくか、個人的にコードレビューしてもらいたいという願望があるので、同じような方がいればそんな感じの内容でも良いなーとか思っています。

WordPress の公式テーマディレクトリ掲載の申請をしていたテーマ「Kotetsu」がやっと掲載されました。

Kotetsu はちょっと実験的なテーマになっていて、下記のような特徴があります。

• Sass を使用。Sass ファイルと minify された CSS が入っています。
• functions.php の内容を Class 化
• レスポンシブデザイン
• 管理画面から色の変更とロゴのアップロードが可能。
• もちろん日本語対応

公式テーマディレクトリにテーマを掲載するまでのあれこれ

公式ディレクトリにテーマを掲載させるには、かなり厳しいコードレビューがあるという噂を聞いていたので、どのようなことに注意する必要があるか事前にかなり調べました。ですが、日本語の情報はほとんど見つかりませんでした。プラグインに比べ、テーマの日本人の開発者はかなり少ないのかもしれません。

WP-D に、公式ディレクトリでテーマを複数公開されているネイビーさんが書いた「できる！WordPressの公式ディレクトリにテーマを登録」という記事は何度も熟読しました。また、Twitter では Chocolat 開発者の @mignon_style さんに何度も助言をいただきとても助かりました。ありがとうございます！

英語版 Codex の Theme Review ページには詳しくレビューの基準が書いてあるので、ここも何度かチェックしました。ですが、英語はそんなに得意ではないので、ざっと目を通した感じです。基本的には、必須テンプレートタグや必須 CSS class をきちんと入れるとか、基礎的な部分を抑えておけばそんなにレビューで指摘されることはないかなという気がします。

公式ディレクトリへの掲載申請については下記の記事が参考になりました。

テーマのチェック、レビュアーとのやりとりは ticket という掲示板のようなところで行われます。ticket にはステータスがあり、

1. new（申請を受け付け）
2. reviewing（レビュー中）
3. approved（レビュアーによる承認）
4. live（管理者に最終チェックされ掲載）

という流れで掲載されることになります。僕の場合は approved になったあと管理人の方から修正が入り、通常であればその修正はレビュアーさんがまたチェックするのですが、レビュアーさんがいなくなっちゃった？みたいで管理人さんがチェックして live になる、という流れになりました。ちなみに、僕の ticket は以下。

テーマレビュアーは人不足らしく、レビューしてもらうには結構時間がかかります。基本的にはticket に書き込みがあってからの順番待ちになるので、無駄に ticket に書き込みをしないほうが良いようです（僕は approved になってから2週間くらいたったときに痺れを切らして一度書き込みしてしまったため、そこからさらに数週間待つことになりました…）。ticket の待ち状況は下記で確認できます（こちらも @mignon_style さんに教えていただきました！）

Kotetsu は functions.php を Class 化したりちょっと変わったことはしていますが、テーマ自体には多くの機能を持たせていないので、心配していたほど修正がたくさん入らず、待ち時間を除けば案外すんなり掲載してもらうことができました。公式テーマディレクトリに掲載したいけど大変かも…と躊躇されている方は、まずはテーマオプション等のない簡単なテーマから挑戦されると良いかもしれません。

あと、公式ディレクトリ掲載テーマの開発者の方の知り合いはあまりいないので、いろいろと情報交換したいなーと思いました。

WordPress には記事作成画面を拡張できるカスタムフィールドの機能があります。しかし、デフォルトのカスタムフィールドの UI は使いづらく、そのまま利用するのはなかなか大変です。そんな WordPress のカスタムフィールドを簡単・便利に利用できるようにするプラグインも公開されていて、Advanced Custom Fields なんかはその操作性の高さから多くのサイトで利用されています。

僕もいつも Advanced Custom Fields を利用していたのですが、実はこのプラグイン、ちょっとおかしな作りをしていて、複数選択項目の値をシリアライズして持っていたり、後方互換性の配慮が甘くて、メジャーバージョンアップの際にデータが消えるというバグがあったりなどの問題もありました。

そのような問題をクリアするために、Advanced Custom Fields をフォークして作成された Custom Field Suite というプラグインもありますが、操作性がちょっと気に食わなかったのと、今後手元で変更が効いたほうが便利かなーということで、独自に Smart Custom Fields というプラグインを作り始めました。

こんな感じです

本題

独自のカスタムフィールド UI は add_meta_box などの標準の関数で簡単に追加できて、今までもよっとしたメタボックスは作ったりしていたので、結構簡単にできるかな、と思っていたのですが、やってみるとあるところで大きくはまってしまいました。

それは、複数選択項目の扱いについてです。WordPress はひとつのキーで複数の値を保存できるので、複数選択項目の場合も問題なく保存できるのですが、全ての値が並列に保存されるため、繰り返しグループ内にチェックボックスを用意して、そのグループを複数繰り返した場合に、そのチェックボックスのどの値がどのグループのものか判断できず、大変困りました。

しょっとわかりにくいですが…

上記の例の場合、カスタムフィールドの値を保存する wp_postmeta テーブルには次のような感じでデータが保存されます。

| meta_id | post_id | meta_key      | meta_value
|    xxxx |    1234 | loopmikantest | イチロー
|    xxxx |    1234 | loopmikantest | 松井
|    xxxx |    1234 | loopmikantest | 高橋
|    xxxx |    1234 | loopmikantest | イチロー
|    xxxx |    1234 | loopmikantest | 松井

という感じで、全ての値が並列に保存されているので、どちらの複製されたグループに保存された値か判別するための情報が必要になります。拙作の Smart Custom Fields の場合は、別途判別用の隠しメタデータも一緒に保存して判別するように実装しました。しかし、これだと、せっかくシリアライズせずに WordPress 標準の方法でデータを保存しているのに、別のプラグインに乗り換えると判別ができずに複数選択項目の値が大変なことになってしまう可能性があります。。

Custom Field Suite の場合

いろいろ調べていると、「Custom Field Suite は Advanced Custom Fields と違い、WordPress 標準の方式でデータを保存するためもし他のカスタムフィールド系プラグインがでても乗り換えができる」という情報があったりしましたが、ざっと見た感じ Custom Field Suite も同様の問題がある？ようで、こちらの場合は独自テーブルで判定しているのかな？という感じでした。

カスタムフィールドの値を並列ではなく階層的に保存する良い方法があれば良いのですが…良い方法をご存知の方がいらっしゃいましたら、こっそり教えていただくと、とてつもなく嬉しいです。

また、もし暇で暇で誰かの作ったプラグインをテストしたいなーという欲求にかられている方がいらっしゃいましたら、ぜひぜひテストにご協力いただけると嬉しいです。まだ GitHub 等にはあげていないので、ご連絡いただければプラグイン差し上げます…。

既に似たようなプラグインはいくつかあって、Advanced Custom Fields、Custom Field Suite、Custom Field Template などが有名です。

僕は Advanced custom Fields を良く使っておりまして、このプラグイン、とにかく使い勝手が良くて「独自のフィールドを追加する」という点においてはものすごく便利です。しかし、複数の値を持てるフィールド（チェックボックスなど）の値をシリアライズして保存する、という仕様であるため、Meta Query したいときやカスタムフィールドの検索をしたいときなどにちょっと問題がでてしまったりしていました。

また、多機能過ぎて設定画面が肥大化しており操作がちと面倒だったり、ちょこちょこ WordPress プラグインの作法に沿っていないような部分があったり、設定データを飛ばしてしまったりしたので、もういっそ自分でメンテナンスしやすいようにオリジナルのプラグインを作ってしまったほうが良いのではないか、ということで作ってしまいました。
（特に Advanced Custom Fields のヘビーな感じがしっくりきていなかったので、Advanced Custom Fields ほど多機能ではありません。）

Smart Custom Fields の特徴

Smart Custom Fields の主な特徴は以下の通り。

• Advanced Custom Field では有料の「繰り返し機能」が標準装備！
• メタデータのリビジョンに対応
• メタデータのプレビューに対応
• メタデータを簡単に取得するための便利メソッド

Advanced Custom Field では有料の「繰り返し機能」が標準装備！

Smart Custom Fields には標準で繰り返し機能を使用することができます。また、繰り返すのは一つのフィールドだけでも良いし、複数のフィールドを一つのグループとしてそれを繰り返すこともできます。

メタデータのリビジョンに対応

WordPress のリビジョン機能は、基本的にタイトルと本文のみしか保存しません。Smart Custom Fields を使えば、メタデータもリビジョンデータとして保存するので、メタデータだけ変更を繰り返した場合でも任意のポイントに戻すことが可能です。リビジョン対応は有名プラグインであれば恐らく対応しているのではないかと思います。確認はしていませんが^^;

メタデータのプレビューに対応

WordPress の標準ではプレビューにメタデータは反映されませんが、Smart Custom Fields を使えばプレビューにもメタデータの変更が反映されるようになります。恐らくこの機能についても有名プラグインは抑えているのではないかなーと思います。こちらも確認はしていません^^;

メタデータを簡単に取得するための便利メソッド

下記のメソッドでメタデータを良い感じに取得できます。

// 特定のフィールドのデータを取得（例：メタキーが product-id の場合）
$product_id = SCF::get( 'product-id' );
echo esc_html( $product_id );

// 特定のグループのデータを取得（例：グループ名が repeat-group の場合）
$repeat_group = SCF::get( 'repeat-group' );
foreach ( $repeat_group as $field_name => $field_value ) {
    // 適当な処理
}

// 全てのデータを取得
$all_data = SCF::gets();

// 投稿IDを引数として指定することもできます。
$product_id = SCF::get( 'product-id', 110 );
$all_data = SCF::gets( 110 );

使用可能なフィールドの種類

• Text
• Textarea
• Radio
• Select
• Checkbox
• Wysiwyg editor
• Image
• File
• Relation（任意の投稿タイプの投稿と関連付け）

今後の開発予定

とりあえず最低限欲しかった実装できたので、後はぼちぼち下記の機能をつけていければなーと。（やり方がわからなかったり大変そうなものもあるので半分妄想…。プルリクお待ちしております。）

• 編集画面でのメタボックスの表示をajax化して、カテゴリー選択時やタクソノミー選択時に動的に適切なメタボックスに切り替える。
• カテゴリー編集画面、ユーザー編集画面へもカスタムフィールドが設置できるように。
• リレーションフィールドの種類を増やす（現在は記事のみなので、タクソノミーとかユーザーとか）
• カスタムフィールド検索ボックス

ダウンロード・インストール

下記からダウンロードするか、管理画面で「Smart Custom Fields」と検索してください。

おまけ：プラグインへのロックインを回避する場合

メタデータの保存方法について

Advanced Custom Field でフィールドの設定を行ってメタデータを保存した場合、データがシリアライズされて保存されてしまう場合があることは前述しましたが、これは WordPress 標準のメタデータの保存方式ではないため、Advanced Custom Field の使用をやめると保存したメタデータが使えなくなってしまいます。Smart Custom Fields はなるべく WordPress の標準のメタデータの保存方法に沿うようにしているので、この点はクリアすることができます。

繰り返しフィールド内における複数値を持ち得るフィールドの使用について

Custom Field Suite の場合はなるべく WordPress の標準に沿うようになっていますが、繰り返しフィールド内で複数値を持ち得るフィールドを使用した場合、保存した値がどの繰り返しグループに所属するものかの情報を保存しておく必要があるため、その情報を独自テーブルに保存するようになっています。なので、Custom Field Suite の使用をやめるとどの繰り返しグループに所属するデータなのかの情報が失われてしまうため、別のプラグインに乗り換えた場合に管理画面上でただしくデータを表示することができません。

この点については僕の Smart Custom Fields も同様の問題があり、こちらの場合はテーブルではなくメタデータにどの繰り返しグループに所属するデータなのかの情報を保存しています。本当はそのような余分なメタデータなしで実現したかったのですが、WordPress のメタデータ機能自体に繰り返し機能というかメタデータを階層化する仕組みがないため、この点については妥協せざるを得ませんでした…。いつでも他のプラグインに乗り換えることができるようにしておきたい場合は、繰り返しフィールド内では複数値を持ち得るフィールドを使用しないようにしたほうが良いかと思います。

便利メソッドについて

Advanced Custom Field にはget_field()、Custom Field Suite にはCFS()->get()のようなメタデータを簡単に取得したり出力したりするための便利メソッドが用意されています。これらのメソッドはテンプレートに記述することになりますが、プラグインの使用をやめた場合、当然これらのメソッドは使用できなくなるので、PHPの関数・メソッドの未定義エラーが発生しページが見れなくなってしまう可能性があります。Smart Custom Fields にも同じような便利メソッドを用意していますが、いつでも他のプラグインに乗り換えることができるようにしておきたい場合は WordPress 標準のget_post_meta()などを使用したほうが良いかと思います。

10月26日に行われたWordBench大分 第10回勉強会に参加・登壇させていただきました。きっかけはFacebookで、長崎ではあまり見かけないWebデザイン系の勉強会がWordBench大分で行われるというのを見かけ、しかもあのよつばデザインの後藤さんが登壇される！ということで参加するか迷っていたところ、WordBench九州連合総会でお会いした、WordBench大分主催者の渡邊さんから「いらっしゃるのであればプラグインの宣伝の時間をとりますよ」とお誘いいただいたので、これは何かのご縁と思い参加させて頂くことにしました。

いざ大分へ！

大分にはこれまで電車旅行で2度行ったことがあり、1度目は天ヶ瀬、2度目は宇佐〜別府（九州満喫切符の旅　大分別府編）です。大分市は行ったことがないと思っていましたが2度目の旅行のときに宿泊だけしていました。

今回は車で移動しました。長崎から休憩いれて約4時間。ここ最近はWordVolcano番外編とかWordBench九州連合総会とかWordPressの勉強会絡みでちょいちょい車で遠出することが増えたので、「4時間？普通に車だな」という感覚になってきました^^;

お昼は別府湾サービスエリアで「とり天ビーフカレー」を食べました。このサービスエリアは別府湾を一望できるきれいなところで、ご飯もテラスで食べることができてとても良かったです。

WordBench大分 第10回勉強会

WordBench大分 第10回勉強会は、ホルトホールの和室で開催されました。参加者は16人。直接Webのお仕事をしていない方の参加、フリーランスの方・事業主の方の参加が多い、初参加の方もあり、ということにとても驚きました。長崎では僕の力不足もあってか新規の方はあまりおらず参加者も減るばかり…な感じなので。自分でWebサイトを立ち上げたい、仲間がほしいという方々が多いのかなーという印象を持ちました。

一目会ったその日から・・・ WordPressとの付き合い方

1人目の発表者は今回の主催者、遠藤さん。大分県臼杵市の観光PRキャラクター「ほっとさん」を作られた方です。WordPressの基礎的な説明を紹介されていました。セッションの中で紹介された、遠藤さん作のプラグインのUIに感動。今度参考にさせてもらおうと思いました。アルパカかわいい。

これが長崎生まれ長崎育ち！スーパーお問い合わせフォーム MW WP Form だ！＋α

2人目は僕。拙作のプラグイン、「MW WP Form」と「Smart Custom Fields」の紹介をさせていただきました。皆さんWordPressでWebサイトを制作していて、お問い合わせフォームも設置している前提でスライドを作ってしまっていたのですが、WordPressをあまり使ったことがないという方もいらっしゃって、伝わりにくい内容にしてしまったかなぁーと…。発表もたどたどしかったと思います、すみません。。開発中のプラグインの紹介もさせていただきました。早く公開できるように頑張ります。

プログラマーだってデザイナーになりたいじゃん？

3人目は今年になってWebデザイナーとして独立された安達さん。なんと元ゲームプログラマー！プログラマーからデザイナー、しかもゲーム業界からWeb業界に転身された上での思ったことや考えられた事を発表されていました。元プログラマーさんということで非常に論理的で説得力のある視点からのお話で興味深かったです。僕よりも年下とのことでさらに驚きました。

[ 設計とデザインは同時進行 ] プロトタイプ時代の
WordPressテーマの作り方・考え方

そして4人目はよつばデザインの後藤さん。WordPressに関する書籍を複数冊執筆されていて、様々なイベントにも登壇されている凄腕Webデザイナーさんです。長崎のWebデザイナーというと、（あくまで僕の観測範囲の話ですが…）結構DTP出身の方や、コードは書かないという方も少なくないのですが、後藤さんのお話にはコードに関することもばりばり含まれていてすごいなーと。それに、サイトの設計・構成に非常に力を入れられていることが伝わる内容で、Webデザイナーの仕事というのは単なる見た目のデザイン・装飾だけに力を入れていれば良いというわけではないんだと改めて思いました。僕はWebデザイナーともWebプログラマーとも言いがたい中途半端なスキルしか持っていませんが、後藤さんのようなスキルを持たないといけないと強く思いました。

あと、後藤さんから、今年のWordCamp東京でも話題になっていたっぽい「WordPress プロフェッショナル 養成読本」をじゃんけん大会の景品として頂きました。この本の中の「Webサイトの設計・運用」に関する章も後藤さんが執筆されています。今回のお話と共通する部分も多々記載されおり、本の内容がセッションで強化される感じで、ただ読むよりもわかりやすくなって良かったです。

「5年後のITまわりの技術はどうなりますか？」

最後は「5年後のITまわりの技術はどうなりますか？」というテーマでグループディスカッションを行いました。Webのことだけではなく技術系の話題なら何でもありという感じで、僕のいたグループでは「グーグルが開発しているGPSカーが実現したらどうなるか」というテーマでディスカッションを行いました。みなさんいろいろな知識をお持ちで驚きました。僕は結構仕事で直接やること以外は疎いので…。グループディスカッションという形をとると、全員が少しでも話す必要がでてきますし、いろいろな方とお話ができるのでテーマによってはどんどん取り入れるのも良いのではないかと思いました。

サングラスありは大分、なしは長崎なのです。サングラスはWordCampのグッズ。

懇親会！

勉強会の後は懇親会に参加させて頂きました。何と何と3,000円で飲み食い放題！しかも時間制限無し！！凄すぎる！大分名物の唐揚げ、焼きそば、鶏皮ポン酢などなど頂きました。ハイボールもガンガン頂きました。懇親会では勉強会よりもっと突っ込んだお話を聞かせて頂き、いろいろな方とたくさんお話しできてとても刺激的でした。仕事にプライベートに、いろいろ考えることあり…。皆さん長崎からいきなり現れた見ず知らずの坊主にすごく親しく接して頂き本当にありがとうございました。

水族館「うみたまご」

翌日は仕事はお休みを頂いていおり、せっかくなので水族館「うみたまご」に行きました。ちょうどセイウチショーやイルカショーを待ち時間無しで見ることが出きてラッキーでした。平日だけで結構な数のお客さん。ショーも凄いし展示も大きく綺麗でそれは人気でるだろうなーと。お昼はお隣の高崎山自然動物園側の食堂で頂きました。水族館側のレストランより割安でおすすめです。

アシカ

いないいないばーに驚き倒れる演技をみせるセイウチ

近くで見たり、少しなでたりもできます。

イルカ

県外の普段会えない方とお会いして深いお話ができる機会はなかなか無いので、参加できるときはなるべく参加するようにしたいなと改めて思いました。参加したときに誰だこいつとならないように、もっと頑張らないといけないなーとも思いました^^; とてもとても刺激的で楽しかったです。本当にありがとうございました。

WordPress で記事を書いて公開した後にタイポがあったりアイキャッチ設定し忘れたりして、すぐ修正したりすることが結構あるんですけど、修正して Facebook で告知しようとするとアイキャッチが出なかったり修正前の文章がシェアされたりということも、もれなくついてきちゃったりします。これは Facebook に更新前のページのキャッシュが残っているからで、これを更新するには下記のツールで当該 URL を入力してキャッシュを更新する必要があります。

前はこれワンクリックで更新できてたんですけど、現在はワンクリック目でキャッシュの確認、ツークリック目でキャッシュの更新という流れに変わっています。面倒くさい。自動化したい。ということでプラグインが無いか探してみましたが、現在の URL Linter の仕様に対応していないものがいくつかあったくらいだったので自作してみました。下記のコードを functions.php に貼り付けるだけで動作します。

class my_facebook_debugger {
	private $api = 'https://graph.facebook.com?id=%s&scrape=true';

	public function __construct() {
		add_action( 'transition_post_status', array( $this, 'debugger' ), 10, 3 );
	}

	public function debugger( $new_status, $old_status, $post ) {
		if ( $new_status === 'publish' ) {
			$t = wp_remote_post( sprintf( $this->api, get_permalink( $post->ID ) ) );
		}
	}
}
new my_facebook_debugger();

記事の公開時、更新時（ステータスが publish のとき）に Facebook のキャッシュを更新します。更新した後に URL Linter でチェックするとキャッシュが更新されていることが確認できるかと思います。

後日「WordPressでの開発をちょっと楽にするプラグイン MW WP Hacks を公開しました。」のプラグインにも機能追加しようと思います。

ちょっと前ですけど、下記の記事が話題になっていましたね。

反応をウォッチしていると「WordPress を導入する場合、セキュリティを考えると当然システム保守契約を結んで保守することが必要」という意見がちらほらあって、僕としてもそれは当然のことでむしろやっていない人は作成した後えらいことになってないのか少し心配になったりしてしまうのですが、じゃあクライアントと保守契約を結べたとしてどういうことに気をつけたほうが良いかということを少し書いてみたいと思います。

コア・プラグインのアップデートは必ず実施する

大前提すぎてあれなのですが、セキュリティを維持して攻撃を防ぐためにお客様にシステム保守契約を結んでいただくわけなので、コアやプラグインのバージョンアップは必ず行わないといけません。企業さんのサイト制作の場合だとテーマはオリジナルのことが多いと思いますが、テーマも自作でないのであればきちんとアップデートするべきです。

「コアの自動アップデートをとめる方法」なんて記事が結構目について愕然とするのですが、これは絶対にやめたほうが良いです。そもそも WordPress の自動アップデートはマイナーアップデートだけで、これは軽微な修正とかセキュリティアップデートが主になるので、自動アップデートしたからといってサイトがおかしくなるということはほとんど無いと思います。むしろ、わざわざ手動でアップデートする必要が無いなんてすごく素敵なことだと思います。もちろん、メジャーアップデートもきちんと動作検証してから適用しましょう（僕は結構えいやっとやりますが…）。

プラグインも自動アップデート

プラグインは標準では自動アップデートがオフになっています。プラグインについてはアップデートすると不具合が発生してしまう場合が無いとも言えないので、テスト環境でアップデートして問題なければ本番環境に適用という形をとるほうが良いかと思いますが、なるべく自動化したほうが手間が少ないので可能であれば自動化したほうが良いと思います。自動化するにはwp-config.phpに下記のコードを追加すれば良いです。

// wp-config.php に追加
add_filter( 'auto_update_plugin', '__return_true' );

信頼できるプラグインを使用する

WordPress の魅力の一つに「膨大なプラグインが存在すること」があると思いますが、残念ながら全てのプラグインが問題なく正常に動くわけではありません。一見すると正常に動いているように見えても、裏ではエラーログを吐きまくっているプラグインも少なくありません。上で「プラグインも自動アップデート」と書きましたが、自動アップデートするためにはアップデートしても恐らく問題が起こらないであろう信頼できるプラグインを使う必要があります。これについてはプラグイン本の著者でもある @miya0001 さんが先日記事を書いていたので読まれることをオススメします。

ちなみに僕は使っているプラグインのうち半分くらいは自作のものです。これらのプラグインはほぼ全て公式ディレクトリで公開しています。そうしておくと何かバグを見つけたり機能を追加したくなったときにすぐに全てのサイトに反映させることができてすごく便利です。みなさんも、どのサイトにも使いまわしているようなコードがあればプラグイン化して公式ディレクトリに申請してみることをオススメします！

「機能」はなるべくテーマに持たせない

WordPress のテーマレビューチームが下記のような記事を出しています。

恐らくテーマはユーザーさんが着せ替え感覚で切り替えて使うものなので、テーマを切り替えたときに何か「機能」が失われたり作成したコンテンツが見えなくなったりしてはいけない、だから「機能」はプラグインの領域でテーマはそれらを含んではいけない、ということだと思います。企業サイトの制作においてはテーマを切り替えるということはあまり無いと思うのですが、例えば Google Analytics や Facebook の埋め込みタグなんかはちょこちょこ仕様が変わり新しいコードを埋め込んでください、みたいなことが起こります。このときテーマにハードコーディングしてしまっていると、一つ一つ確認して修正し、手作業で更新作業を行っていかなければいけません。このようなものをプラグインとして独立させておけば、プラグインをアップデートするだけで全サイトに修正を反映できます（過去にこれをやっていなくて現在ハマり中…）。

バックアップも自動化する

システム保守契約ということは、「データの消失」からもシステムを守る必要があると思うので、必ず定期的にバックアップもとったほうが良いと思います。バックアップ系のプラグインもいろいろありますが、同一サーバー内にデータを保存したりするものはあまり意味が無いと思いますし、それらのプラグインにはだいたい良い思い出がないので、僕は自分でシェルスクリプトを組んで Amazon S3 にバックアップをとるようにしています。バックアップも手動でやるのは大変手間のかかる作業なので、何かしらの方法で自動化したほうが良いです。シェルスクリプトを書いてcronで自動実行させても良いですし、AWS ならスナップショットとれますし、VaultPress などのサービスを使うのも良いと思います。

ということで、こちらからは以上です。

@inc2734 @Toro_Unit それだ！ブログに書いてーｗ

— Takayuki Miyauchi (@miya0001) December 8, 2014

ということだったので、VCCW + Wordmove でさくらのレンタルサーバーに一発で簡単デプロイする方法を書きたいと思います。@Toro_Unitさんがすでに記事をかかれているので良いかなとも思ったのですが、僕は公開鍵認証を使った方法でやってて、紹介されている方法と少し違うようでしたので、公開鍵認証を使った方法をご紹介します。

なぜ公開鍵認証？

公開鍵認証の設定を行っていれば、sshでログインしたりWordmoveでデータのアップロード・ダウンロードするときにパスワードを入力する必要がなくなります。本当はパスワードログインも禁止したいのですがさくらのレンタルサーバーで方法あるのですかね？

鍵を作成してさくらのレンタルサーバーに公開鍵認証でログインできるようにする

僕はMacを使っているのでMacでの方法になりますが、コンソールに下記のコマンドを打って、さくらのレンタルサーバーと通信するための鍵を生成します。既に別のサーバーとの通信用で鍵の生成をされている方は、ここを飛ばしてそれを使っても大丈夫です。

# Mac
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/inc/.ssh/id_rsa): # そのままエンター
Enter passphrase (empty for no passphrase): # パスフレーズを入力
Enter same passphrase again: # もう一回

# 鍵が生成されているか確認
$ ls ~/.ssh/id_rsa
id_rsa # 秘密鍵
id_rsa.pub # 公開鍵

# 秘密鍵に、自分しか見れないように権限を設定
$ chmod 600 ~/.ssh/id_rsa

生成した公開鍵をさくらのレンタルサーバーに保存します。

# さくらのレンタルサーバーに公開鍵を保存するために公開鍵の中身をコピー
$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3N... # ドラッグしてコピー

$ ssh さくらのアカウント名@さくらのアカウント名.sakura.ne.jp
さくらのアカウント名@さくらのアカウント名.sakura.ne.jp's password: # さくらのパスワードを入力

# ここからさくらのサーバ内
# コピーした公開鍵の内容を下記にコピペ
% vi ~/.ssh/authorized_keys

# 保存したら公開鍵が見られないように権限を設定
% chmod 400 ~/.ssh/authorized_keys

# ログアウト
% exit

VCCWでローカル環境を作成

ここについては公式サイトが詳しいのでそちらを参照してください。

ssh-agentに秘密鍵を登録する

これをすることで下記のようになり（多分）、とても便利です。

• Mac（ホスト）の鍵をVCCW（ローカル環境）でも共有できる（さくらのレンタルサーバーにローカル環境の鍵を送る必要が無い）
• 秘密鍵に設定したパスフレーズを毎回入力必要がない

# Mac
$ ssh-add -K ~/.ssh/id_rsa

Movefileに接続情報を記述する

Vagrant upをするとvccwディレクトリ内にMovefileが作成されていますので、それを編集します。MovefileはYAMLという形式で記述する必要があって、インデントが重要な意味を持っています（コメント行も含め。多分）。僕はそれが良くわかっていないくて大変苦労したので、不要なコメント行は全部消しちゃったほうが楽だと思います…。

# Mac
$ vi /PATH/To/vccw/Movefile

local:
  vhost: "http://wordpress.local" # ローカルのURL
  wordpress_path: "/var/www/wordpress" # ローカルのWordPressのパス

  database:
    name: "wordpress"
    user: "wordpress"
    password: "wordpress"
    host: "192.168.33.10"

staging:
  vhost: "http://example.com" # さくらのレンタルサーバーのURL
  wordpress_path: "/home/さくらのアカウント名/www" # さくらのレンタルサーバーのWordPressのパス

  database:
    name: "データベース名"
    user: "データベースのユーザー名"
    password: "データベースのパスワード"
    host: "mysqlxxx.sakura.ne.jp" # さくらのホスト名
    charset: "utf8" # さくらはDBをdumpするとujisになっちゃうのでcharsetを指定

  exclude:
    - ".git/"
    - ".gitignore"
    - ".sass-cache/"
    - "bin/"
    - "tmp/*"
    - "Gemfile*"
    - "Movefile"
    - "wp-config.php"
    - "wp-content/*.sql"
    - ".DS_Store"

  ssh:
    host: "さくらのアカウント名.sakura.ne.jp"
    user: "さくらのアカウント名"

あとはWordmoveでコマンド一発！

慣れていないとここまで手間だと思いますが、ここまでくればWordmoveのコマンド一発でサーバーのデータをまるっと持ってきたり、ローカルのデータをまるっとアップロードできるようになるので、この後の構築・保守作業が超便利になります。

# wordmoveコマンドはローカルサーバー内で実行しないといけないので注意
# VCCW（ローカル環境）起動
$ vagrant up

# ローカル環境にログイン
$ vagrant ssh

# ここからローカル環境
# wordmoveのディレクトリに移動
% cd /vagrant

# サーバーのデータ（ファイル、データベース）をまるっとダウンロード
% wordmove pull -e staging --all

# まるごとじゃないパターンもできます（pull、push両方で）
# サーバーのコアファイルのみダウンロード
% wordmove pull -e staging -w
# サーバーのプラグインのみダウンロード
% wordmove pull -e staging -p
# サーバーのテーマのみダウンロード
% wordmove pull -e staging -t
# サーバーのuploadsのみダウンロード
% wordmove pull -e staging -u

# サーバーにデータ（ファイル、データベース）をまるっとアップロード
% wordmove push -e staging --all

デフォルトではwp-config.phpはやりとりされないので、ローカルで作成したデータを空のサーバーにアップロードした場合はサーバーにもwp-config.phpを作成する必要があります。普通にブラウザでアクセスすれば自動作成画面になるので、特にFTPなどでアップロードしなくても大丈夫です。

上の例ではwordmoveやりとりするホストに「staging」を指定しています。これはMovefileを編集したときに記述しているホストのアダ名みたいなもので、これはいくつでも増やすことができます。例えば「stating」にステージングサーバー（テスト環境）の接続情報を記述し、「production」にプロダクションサーバー（本番環境）の情報を記述みたいな感じです。

Wordmoveはrsyncをつかってデータの送受信をするので、FTPよりかなり高速です。データベースもまるっと送受信できるのでphpMyAdminを開くこともなくなりました。FTPやphpMyAdminでバックアップをとったりデプロイするのは何度もやるとかなり時間の無駄なので、最初の設定は面倒かもしれませんがWordmoveを使うことをオススメします！

ちょっと注意点など

WordmoveはローカルとサーバーのWordPressをまるごとやりとりするためのツールなので、うまいこと差分を適用するといったことはできません。そのため、

1. サーバーからデータをダウンロード（pull）
2. ローカルで編集
3. →クライアントがサーバーでブログを更新
4. ローカルのデータをアップロード（push）

なんてことになると、(3)でクライアントが更新したデータは消えてしまうので注意が必要です。一応、pull、push したときはローカルの wp-content ディレクトリにデータベースのバックアップが作成されますので、もしやってしまったときはそれを使って復旧できます。ただし、ファイルについてはバックアップは作成されませんので、Gitなどを使って更新前に戻せるようにしていたほうが安全です。

Webサイトを持ちたい初心者の方向けに「2日間でWordPressでWebサイトを作れるようになろう」という講習会のご依頼があり、初めて東京に行ってきました（と言いつつこの記事はまだ東京で書いているのですが^^;）。お仕事以外にもWordPress系の勉強会など参加させていただきましたので記事にまとめたいと思います。

第17回ゼロから始めるWordPress勉強会「年末LT大会」

お仕事が13日、14日の2日間だったので、前日入りで東京へ。先日参加させていただいた「第10回 WordBench 大分」のときに、東京・大分の2拠点で活躍されているよつばデザインの後藤さんから、その日に「年末LT大会」を行うのでよろしければぜひ、とお声が掛け頂き、それではということで参加させて頂くことに。

その前にちょっと寄り道…

その前に少し時間がありましたので、僕と一緒にWordBench長崎のモデレーターをしてくれていた @mayoibi さんがお勤めのプライム・ストラテジーさんにお伺いしました。ちょうどお忙しい時期で、@mayoibi さんと知り合いとは言え、いきなり長崎から誰だこいつ状態でお伺いするのは気が引けたのですが、皆さん快く迎えてくださって、日本でも指折りのWordPress技術者の黄色い方とも色々とお話ができて楽しかったです。

最近発売された「WordPressによるWebアプリケーション開発」も献本頂きました。普段本はあまり読まないのですが、ぜひ読ませて頂きます！ありがとうございます！

コワーキングスペース茅場町 Co-Edo

第17回ゼロから始めるWordPress勉強会「年末LT大会」は「コワーキングスペースについて 『今』いちばん熱く語る男」こと田中さんが運営されているコワーキングスペース茅場町 Co-Edoで開催されました。だいたい20人強くらいの方が参加されていたのではないかと思います。

Photo by Yoshinori Kobayashi

ついて早々、公開中のWordPressプラグインに強烈なバグを見つけてしまったため、順序を後ろにずらしてもらいました。。ご迷惑をおかけしてすみません。。

今年作ったプラグインの紹介をして良いとのことだったので、カスタムフィールド系プラグイン「Smart Custom Fields」の宣伝紹介をさせて頂きました。

左からCo-Edoオーナーの田中さん、よつばデザイン後藤さん、僕、大原さん。みんな服が地味だとイジられました…。

LT大会の後はそのままCo-Edoで懇親会でした。ちょうど東京に来られていた、月間50万PV超えの人気ブログを運営している関西の大原さんも駆けつけられ、仕事のことなど色々とお話を聞かせて頂きました。WordCamp Kansai 2014 のときに初めてお会いして、その後もちょくちょくネット上ではやりとりさせて頂いていたのですが、あまり真面目な話はできずにいて(^.^; でもこの日は大原さんが結構酔っていたせいか込み入った話もできたりして、とても刺激になりました。あざます！

Co-Edoオーナーの田中さんは、先日「コワーキング Advent Calendar 2014」で「コワーキングスペースを世代別に考えてみて想うこと」というすごく良い記事を書かれていて、この日もそのことについて少しお話を聞くことができて、やっぱり経営者は考えていることの深さが違うなーというのと、僕はまだまだだなーということと、色々考えさせられました。参加できて良かったです！

お仕事について

初めのほうにも書きましたが、2日間でWordPressでWebサイトを作ろう、という講習会を行わせて頂きました。ドメイン・レンタルサーバーの契約、データベースを作ってWordPressをインストール、テーマ・プラグインの選定、などから詰め込んでしまうと流石に2日間では収まりきれないので、弊社でそのあたりはババっと代行して、初心者の方でもわかりやすい専用のテーマ作成、編集するだけである程度Webサイトとして完成できるように仮ページの作成などを行って、それを編集していって、足りない分は自分で作成してみましょう、という感じで進めました。このとき使ったテーマはWordPressテーマ配布サイト「FLAT」で後日配布予定です。

WordPressどころかWebページを作ったことがないという方も多かったのですが、受講者の皆さんはとても意欲的で、拙い説明で申し訳なかったのですが、理解しようと必死に取り組んで下さり、一つ一つの説明に頷いたり反応をくださって、僕もとてもやりやすかったです。講習会後の感想も好意的なものばかりで、やる前はうまくできるか不安でしたが、やって良かったなーと思いました。

テーマはレスポンシブデザインになっていて、スマホでも見やすく見れるということと、トップページはウィジェットエリアを自由に定義できるようになっていて、ブロックを組み立てる感じでページが作れるようになっている点が概ね好評だったと思います。初心者の方がそれになりのWebサイトをなるべく簡単に作れるように狙って実装していた部分なので、そこが評価されて嬉しかったです。

WordBench東京12月勉強会

講習会の最終日にちょうどWordBench東京12月勉強会が開かれていました。WordPress.tv という、世界各国のWordCampで行われたセッションの動画が閲覧できるサイトがあって、そこで公開されている動画に字幕をつける、という勉強会を行ったそうです。僕は講習会があったので勉強会は参加できなかったのですが、懇親会が行われるということだったので、そこだけお邪魔しました。

先日僕が書いた「さくらのレンタルサーバーにWordPressをデプロイするのはVCCW + Wordmoveが最高に捗る」という記事をさくらインターネット広報さんがリツイートしてくれるという事件が起こったのですが、何とこの勉強会にその中の人が参加されていました！この日のためにわざわざ大阪から参加されたということで、運命のようなものを感じましたw

ここでも色々な方と色々なお話ができてとても楽しかったです。

LIGさんが運営する、いいオフィス

で、今日なのですが、帰りの飛行機まで時間があったので、LIGさんが運営するシェアオフィス＆コワーキングスペース「いいオフィス」に行ってみました。そしてこの記事を書くなど。

上野駅から徒歩2分。とのことですが、僕のレベルになると上野駅を出るのに2分以上かかります。。

いいオフィス、今風のオシャレ空間で、とても落ち着いた雰囲気でした。シェアオフィスのほうはまだまだ空いているらしいので、ご興味のある方はお問い合わせされてみては。

ということで、何だか取り留めの無い記事になってしまいましたが、仕事とは関係ないところで積極的に活動されている方とたくさんお会いして、最近活動休止中のWordBench長崎でもまた何か活動したいなーというのと、仕事の一環でもあるFLATのテーマがあまり使われていないので、興味のある方はぜひ使ってみてください。

それにしても東京はどこに行っても人が多いですね…。長崎のバスや電車でも僕は辛いと思っていましたが、東京の電車はレベルが違いすぎです。でも本当にぎゅうぎゅうに満員だと、倒れたりしないので意外にきつくないということを学びました。

1月10日に行われたWordBench鹿児島に参加してきました。鹿児島を訪れるのはニ度目。一昨年に行われたWordVolcano番外編以来の鹿児島です。前回は長崎から車で行きましたが、今回も懲りずに車で行きました。会場はコワーキングスペース301。良い感じでこじんまりしていて、居心地が良い感じのコワーキングスペースさんです。

今回のWordBench鹿児島は「網元ハンズオン」と「[初級]WordPress.comでビジネスサイトを作る・[初級]WordPressの子テーマを作る」が同時並行で行われどちらかに参加するという形でした。どちらも参加したかったのですが、今回は「網元ハンズオン」に参加しました。

網元とは

網元は株式会社デジタルキューブが提供しているAMI（AWSで使えるOSのイメージ）のことです。AWS（SSD）+ Nginx + WordPress の構成で、秒間320リクエストに耐えることができる超高速サーバーです。網元はAmazonマーケットプレイスで無料で配布されており、自由に使用することができます。また、ホスティングサービスも提供されているので、自分で管理するのが面倒な場合はそちらを利用することもできます。

網元ハンズオン

網元はAWSで利用するのでAWSのアカウントが必要となります。で、AWSのアカウントの取得は電話認証が必要なのですが、この日泊まるホテルに携帯を忘れてきてしまったためアカウントの取得ができない事態に！なんたる不覚！諦めて皆さんがハンズオンされるのを眺めていたのですが、僕はスマホと携帯の2台持ちでして、スマホは持ってきていたことを思い出し、すぐに自宅の妻とラインで連絡を取り、妻の携帯で電話認証することでとりあえずアカウントを取得することができました。2台持ちで助かりました^^;

ということで本題。ハンズオンは下記の資料にそって進められました。

 資料が少し古く？一部違うところがありますが、ほとんど資料通り進めれば大丈夫でした。VPSとかだと自分で各種インストールや設定を行わなければならず、立ち上げまでにすごく時間がかかってしまいますが、網元はWordPressを使うためのもろもろのソフトや設定がすでにパッケージ化されているので、ボタンをポチポチっとやるだけですぐに使用できるようになります。そんなものが無償で公開されているなんて太っ腹ですね！

このブログも網元と同じくNginxを利用していますが、表示速度のレベルが全く違いますね！計測はしていませんが静的ページばりにページ表示されます。また、AWSということでスナップショットの機能を使って丸ごとバックアップを一瞬でとったり、サーバー（インスタンス）の立ち上げもすぐなので複数立ち上げて切り替えたりということもすごく簡単に行うことができます。今のサーバーはいくつかサイトが入っていて移行が面倒で躊躇しますが、いつかは移行したいですね…。VPSちまちま管理し続けるの面倒ですし。

カルタ大会！

ハンズオンの後はカルタ大会が行われました。普通のカルタではなくHTML5カルタ！しかも優勝者にはHTML5&CSS3ポケットリファレンスが贈呈されるとのこと！HTMLを勉強中の初心者の方もいらっしゃる中、ついついマジになっちゃいまして、優勝して本いただいちゃいました…。うーん、なにか申し訳ない…。ただ、HTML5はXHTMLのときからの流れで何となく書いていたので本を読んでみると結構知らないことがあって勉強になりました。拙作のフォームプラグインMW WP FormもHTML5のフォームタグを追加していきたいので、その辺りにも活かしていきたいと思います。ありがとうございます！

HTML5&CSS3ポケットリファレンス
森 史憲 藤本 壱
技術評論社 2014-05-21

HTML5カルタの後はWordPressカルタ大会も行われました。WordBench鹿児島主催の鶴田さんがWordCamp東京のカルタ大会で勝って持ち帰ってきた品とのこと。どんなものかと見せていただくと、何とMW WP Formの札を発見！うひょー！ウレタナー！

カルタにのっとる！

@inc2734が投稿した写真 – 1月 10, 2015 at 12:22午前 PST

 こちらもマジでやって勝ってやろうと思いましたが、鶴田さんには勝てず…。流石です…。

懇親会！

勉強会後の懇親会にも参加させていただきました。昨年末の長崎の忘年会では序盤から記憶を飛ばして皆々様方に心配され、ひどい二日酔いに苦しむという失態をおかしてしまいましたが、この日は無事に楽しく過ごせました^^; 地元のときだけ飛ぶのかも…。その後もWordBench鹿児島の元管理人である@marushuさんに遅くまでいろいろ相談にのっていただいたり、貴重なお話をお聞きできたりして、とても濃い時間を過ごすことができました。遅くまでお付き合いいただいてありがとうございました！！

翌日、家で待つ妻に「黒豚の鼻くそ」というお菓子をお土産に買って帰ったところ大ウケでした(^^;
しばらくお休み中のWordBench長崎も今月末に開催します（また参加申込みページを用意できておりませんが…）。今回参加させていただいたWordBench鹿児島は、初心者の方も詳しい方も、立場も色々な方が参加されており、雰囲気もとても良い感じで、長崎もそんな風な感じにできたら良いなーと改めて思いました。

Gulp はフロントエンドまわりのあれこれを自動化してくれるタスクランナー、ビルドツールです。同じようなツールとして Grunt がありまして、僕はいつも Grunt のほうを使っていたのでこれまでにもいくつか記事を書いています。

どうも最近 Grunt よりも Gulp のほうが軽くて良いぞという声をちらほら聞いていたのでちょっと試してみました。

準備など…

僕はVCCWでローカルの WordPress 環境を作成しており、Gulp を含めたファイルの配置は以下のようになっています。

- /PATH/TO/DIR
  - vccw/
    - www/
      - wordpress/
        - wp-content/
          - themes
            - mytheme
              - scss/
                - style.scss
              - style.css
  - gulpfile.js
  - mysql/ < gulp でデータベースをエクスポートしたときに自動的に作成される

Sass のコンパイルや Gulp の使用には node.js や Sass などのインストールが、VCCW 環境の WordPress データベースのエクスポートには wp-cli も必要なので、ちょっと古い記事ですが下記を参考に適当にインストールしてみてください。

Gulp のインストール

とりあえず公式サイトに書いてあるとおりインストールしましょう。グローバル領域と、実際に使用するディレクトリにそれぞれインストールが必要なようです。

# グローバルに Gulp をインストール
$ npm install --global gulp

# 作業ディレクトリに Gulp をインストール
$ npm init
$ npm install --save-dev gulp gulp-watch gulp-ruby-sass gulp-shell del gulp-combine-media-queries gulp-minify-css

上記のgulp-watch gulp-ruby-sass gulp-shell del gulp-combine-media-queries gulp-minify-cssは自分が使うプラグインのインストールを指定する部分になります。僕は Sass を監視してコンパイル、かつ Media Query の記述を自動的にまとめたいのと、ローカルの WordPress のデータベースをダンプさせたかったので、それらの動作に必要なものを指定しています。

gulp -vとコマンドをうって下記のようにグローバルと現ディレクトリの2つの gulp が表示されればインストール完了です。

$ gulp -v
[02:39:28] CLI version 3.8.10
[02:39:28] Local version 3.8.10

gulpfile.js の作成

インストールが完了したら、gulpfile.jsという、Gulp に自動化させたいタスクを記述するファイルを作成します。gulpfile.js は下記のような内容で作成しました。パスの設定をお使いの環境に合わせれば、コピペでいけるのではないかと思います。

// プラグインのロード
var gulp   = require( 'gulp' );
var watch  = require( 'gulp-watch' );
var sass   = require( 'gulp-ruby-sass' );
var cmq    = require( 'gulp-combine-media-queries' );
var cssmin = require( 'gulp-minify-css' );
var shell  = require( 'gulp-shell' );

// 各ディレクトリパスの設定
var dir     = {};
dir.root    = '/PATH/TO/DIR';
dir.vagrant = dir.root + '/vccw';
dir.develop = dir.vagrant + '/www/wordpress';
dir.theme   = dir.develop + '/wp-content/themes/mytheme';
dir.mysql   = dir.root + '/mysql';

// WordPressデータベースの設定
var mysql      = {};
mysql.database = 'wordpress';
mysql.user     = 'wordpress';
mysql.password = 'wordpress';

// Sass の設定
// Sass で /scss/*.scss のファイルをコンパイル > Media Query の記述をまとる > minify
gulp.task( 'sass', function() {
    return sass( dir.theme + '/scss' )
        .pipe( cmq() )
        .pipe( cssmin() )
        .pipe( gulp.dest( dir.theme ) );
} );

// WordPress データベースのエクスポート
gulp.task( 'wp_export', shell.task(
	[
		'rm -rf ' + dir.mysql,
		'mkdir ' + dir.mysql,
		'wp db export "' + dir.mysql + '/' + mysql.database + '.sql' + '"'
	],
	{
		cwd : dir.develop
	}
) );

// /scss/*.scss を監視し、変更があったら Sass タスクを実行
gulp.task( 'watch', function() {
	gulp.watch( dir.theme + '/scss/*.scss', ['sass'] );
} );

gulp.task( 'タスク名', 実行する関数 )のような感じで実行するタスクを記述していきます。実際に実行させるには、Gulp をインストールしたディレクトリ内で下記のコマンドを実行します。

# WordPress データベースをエクスポートする場合
$ gulp wp_export

# /scss/*.scss を監視して変更があったら sass タスクを実行
$ gulp watch
# この後で監視状態に入り、変更があったら自動的にコンパイルが走ります。
[22:40:38] Using gulpfile /PATH/TO/DIR/gulpfile.js
[22:40:38] Starting 'watch'...

パフォーマンス

Grunt も Gulp も、watch 中に Sass のコンパイルが走ると秒数が表示されるのですが、Grunt の場合、同等の内容で平均して1回あたり2sくらいかかっていたのですが、Gulp だと15msくらいと表示されていたので、かなり速くなったみたいです。Grunt の場合は「詰まる」感じがいつもあったのですが、Gulp だとスッといく感じで、体感的にもかなり速く感じました。

2015年、新年一発目のWordBench長崎08を開催しました。もともと月1回は開催しようと思って始めたWordBench長崎でしたが、気づけば前回の7回目を開催したのは昨年の8月…約半年ぶりの開催となってしまいました。全く気づかなかった…

今回は僕と、いろいろな方にスピーカーお願いしてお話をしていただきました。久しぶりなのでしっかり写真を撮ろうとデカい一眼を持っていたのにSDカードを家に忘れるという失態をおかしてしまったため、不本意ながらスマホで写真撮りました…。残念すぎる。

2014年の振り返り – WordPress関連の動向・コミュニティ活動など -

まずは僕。僕がわかる範囲でのWordPressコミュニティ関係のことや、技術的に話題になったトピックについてお話させていただきました。

VCCW、Wordmoveは本当にこれまでのやり方が大きく変わるぐらい便利で楽ちんなものなので、ぜひデモでお見せしたかったのですが、デモ環境を作り忘れていたのと、なぜか今まで使っていた自サイトの環境も動かないという状況で、便利さをちゃんとお伝えできなかったことが悔やまれます…。なんかいつもこんな感じだな(TT

昨年はいろいろな勉強会・イベントに参加させていただいて、いろいろな方とお知り合いになり、いろいろなお話が聞けて、また、いろいろと相談もさせていただいたりと、勉強会・イベントがあるおかげでそのような刺激的な体験ができたので、WordBench長崎も今度こそはなるべく月1で定期開催して、そのような場を提供していけたらなと思っています。

WordPressに興味がある、Web制作に興味があるという方、何か話しても良いよという方、ぜひぜひWordBench長崎にご参加ください。スピーカー、運営のお手伝いをしてくださる方、切実に募集中です！（といっても僕自身特に運営的なことをやっていないので、本当にそんなに大変なこととか無いです。できてなだけとも言えますが…@@;）

WordPressのうごかしかた。

次は@hideAki76さんによる「WordPressのうごかしかた。」のお話。DebOps、Immutable Infrastructureのお話を起点に、pagoda BOXでのWordPress立ち上げのデモを実演いただきました。はじめからGitと連携していてpushで更新でいたり、pushしたら別の環境が自動的に立ち上がったりするのはすごく良いなと思いました。最近無料枠の内容が変わったようで、今後はHerokuもおすすめのようですよ。

ゆるふわブログ更新術

次は@exit_rmさん。タイトルをメモしていなかったので間違ってるかも。。IFTTTといういろいろなWebサービスを連携できるサービスを利用して、何かのアクションをしたときにWordPressの更新をする、というお話をしていただきました。

「Twitterでつぶやいたら更新する」「Foresquareでチェックインしたら更新する」「iPhoneで写真を撮ったら更新する」「Yoしたら更新する」「Squareで決済したら更新する」など実用性のあるものからないものまで、いろいろな更新法をご紹介いただきました。チェックインしたら更新や写真を撮ったら更新は、どの場所にいるときに、と限定することもできるみたいですごく便利そうだなーと思いました。下書き投稿もできるようなので、とりあえず撮った写真を下書きにためといて後でブログを書くとか、業務においてはブログを書いたら自動的にTwitterとFacebookに流したいという要望もちらほら頂きますので、そのあたりにも活用できそうですね。

実録 飲食店のWeb & リアルマーケティング奮闘記

次は@easyhomejpさんによる、WordBench長崎初のWeb＆リアルマーケティングのお話。正直今回はこのお話を聞くためだけにみたいなところがあるくらいとてもおもしろく勉強になる内容でした。参加者さんからもこのお話だけで丸々やっていただきたいという声が上がっていました。

僕はマーケティング方面にそんなに明るくないので、ずっと本格的にマーケティング業務をされている方にスピーカーをしていただきたいなと思っていて、毎回ご参加くださる@easyhomejpさんにいつかお願いしないとと狙っておりました(^^;
今回はお忙しいのに快く引き受けてくださったので本当に良かったです。ありがとうございました！

カスタム投稿タイプを使ってワンページデザインのサイトを作る

最後は@t__kumaさん。最近ワンページデザイン（トップページ1ページだけの構成）のサイトが流行っていますが、普通に固定ページで作ろうとすると1ページの内容が長いため複雑なHTMLを1つのエディタ内に記述することになるので管理が難しくなってきます。そこで、そのページ内の各セクションをカスタム投稿タイプで管理して、管理しやすくしようというお話でした。

僕もページ中の各セクションやパーツをカスタム投稿タイプで管理するというのはよく妄想していて、実際にデモで見せて頂いてやはりアリだな…と。ワンページデザインの場合、デザイン的に「カラム分け」がどうしても必要になってきて、そこはHTMLでやるしかないので、そのあたりをクリアできる仕組みまで作れれば、プラグイン化するとおもしろいことになりそうだなと思いました。

次回予告！

次回は一月空きまして、3月21日に開催予定です！今のところまだ内容は決めていませんので、「こいういうことがやりたい」「こういう話が聞きたい」「こういう話をしたい」という方がいらっしゃいましたらぜひぜひお知らせください！

• WordBench 長崎
• WordBench 長崎 Facebookグループ

3月7日に開催された、「WP-D Fes #03 in GMO Yours 大阪会場 $ wpd –update webdev」に参加してきました。イベント名にもあるように「Web制作の環境をアップデートしよう！」というテーマのイベントでした。

長崎から飛行機（Peach）で行ったのですが、1日1便夕方のみしか便が無いので前日入り。飛行機の待ち時間にFacebookを見ていたら、イベントを主催されるWP-Dのメンバーの皆さんが飲み会をされるというのを発見、飛び込みOKとのことでしたので参加させていただきました。このとき初めて会場である GMO Yours に入ったのですが、巨大複合商業施設グランフロント大阪の23階、ガラス張りから見える都会の夜景、それで普段は社員さんの休憩室と、なかなかこんなところにお邪魔できることはありませんのでいろいろ驚きました。ホテルからグランフロントまでも迷いましたが、グランフロントに入ってからも20分くらい迷いましたし…。で、なんやかんやで当日スタッフもやることに。

会場案内をやる私 photo by @webboyjp

なんか見覚えのある人が僕にカメラ向けてるなーと思っていたらいつもの大原さんでした(^^;

これで大丈夫。Web制作で使うコマンドラインツールの名前と役割をざっくり理解する

まずはWP-D発起人の大串さん。最近よく目にするコマンドラインツールについてのお話でした。「黒い画面こわい」な感じでなるべく触らないようにしてきたのですけど、最近は情報も充実しているし使うだけならコピペで済んじゃいますので、僕もざっくりとした理解で使っています。でも大串さん、ざっくりといいつつ詳しく説明されていて、ディレクターさんなのにすごいなーと思いました。

プロトタイプとWebサイト設計のワークフロー

「後藤プロ」こと、よつばデザイン後藤さんのセッション。モバイルファースト・コンテンツファーストになってきている中で、これまでの制作フローを見直し、デザインカンプを作らずにプロトタイプを作るという方法がありますよという内容のお話でした。僕自身、Web制作を行っていて、マルチデバイス対応が当たり前になってきた中でPC用のデザインカンプをきっちり作って他のデバイスはよしなに、みたいなやり方が非効率的というか従来のようにハマらなくなってきているかな…というのは感じていたので、機会があればなるべくプロトタイプを使ったやり方でやっていきたいなと思いました。今は WordPress に限らず Bootstrap のテーマなんかもオープンなライセンスでたくさん配布されたりしているので、そのあたりでプロトタイプを作って調整していくというのはアリではないかなと。

制作ツールとしてのCMSを改めて考える

コンクリートファイブジャパン株式会社代表の菱川さんのセッション。CMS とはなんぞや、制作者ツールとして考えたときに重要なものは何か、というお話でした。

CMS というとサーバーサイドで動的に動くものというイメージでしたが、コンテンツを管理するだけであれば Git と組み合わせて Jade や Grav というローカルで HTML を生成するツールを使う手もあると。確かに権限管理とかサーバーサイドでいろいろやる必要があるサイトでなければ、そういうのも良いなと。僕はほぼ WordPress 専門で、WordPress が不要そうなときは普通に HTML 書いたり Dreamweaver 使ったりって感じでしたが、Grav なんかは Markdown で簡単に書けるそうなので案件によってはこのあたりを使うとすごく良い感じでできるのではないかと思いました。

それ以上なものが必要な場合には、ということで October CMS という Laravel 製の CMS の紹介もありました。管理画面の UI もモダンな感じで、管理画面から API の実装ができたりいろいろすごそうな感じでした。僕にはちょっと難しそうに感じましたが、バリバリのプログラマーな方には今後良い選択肢になるのではと感じました。

High Performance Gulp

ファンタラクティブ株式会社代表の井村さんのセッション。Gulp をバリバリ使って開発を超効率化させようというお話でした。「東京でこの内容をやったときは中盤からお客さんが？？？状態になってしまったので、その点前置きしておきます。」ということで始まったセッションでしたが、僕も途中から？？？状態になってしまいました（@□@;）

僕も Gulp 自体は少し使ったりしているのですが、Sass をコンパイルさせたりちょっとファイルをコピーさせたりするくらいで、まぁそれで済んじゃうくらいのことしかしてないのでアレなんですけれども、井村さんは scss ファイルからスタイルガイドを生成したり、すごくナウい感じで JavaScript の結合をされていたりしていて、とにかく凄いなーと思いました。GitHub でもろもろ公開されていらっしゃるとのことなので、時間ができたら研究して自分なりのものを用意したいですね。

デザイナーのワークフローを変えるAdobeモバイルアプリの実力。

TIMING代表の北村さんのセッション。昨年秋に多数発表された Adobe モバイルアプリをいかに活用するかというお話でした。iPad で動画を撮影してちゃちゃっと加工してサイトに埋め込んだり、iPad のカメラで撮影したデータがそのままパスデータで読み込めたり、また、撮影した文字をフォントに変換して読み込めたりとデモを交えて紹介されていました。ちょっと前ならすごくお金と手間がかかったことが、iPad やアプリの登場で複雑でないものならすごく簡単に早くできてしまうのだなと驚きました。

2015年のサバイバル学習術 「Web開発技術の税引後利益」を最大化しよう！

破滅派の高橋さんのセッション。高橋さんのブログには他ではあまり載ってないニッチな Tips を掲載されており、以前から困ったときなどに良く拝見していて、勝手に親近感を抱いていたのでお会いできて嬉しかったです。セッションの内容は、流行りの技術やツールはいずれ廃れるけど、何か資産を残すことでそうなった時でも資産を活かせるようにしよう、というものでした。Flash や Grunt を例に挙げ、すごくおもしろいお話で、文章がおもしろい人は話してもおもしろいのだなーと。僕のブログは語彙が少なくて自分で読んでてアホに思えるときがあるので文章もしっかり書けるようにならなければと改めて思いました。

なんかちょっとズレちゃいましたけれども、実際ツールとかは理解することを放棄してただ使っているだけだと、それが無くなったときに本当に0になっちゃうので、ツールの使い方だけではなくて、概念だとかざっくりとした仕組みだとかぐらいは学ぶようにしたほうが絶対に効率的なので、このあたりは面倒でも放棄してしまわないように注意していかなければいけませんね。

今度こそ失敗しない。プロジェクトを円滑に進めるタスク管理とGitの連携の方法

最後は2度目の大串さんのセッション。ディレクターさん + コードも触る大串さんならではのお話でした。やりとりの管理は Backlog で、コードの管理は Git でやる、粒度を間違わない、言った言わないを防ぐためにこまめに残す、記録されていないものはやらないこと、などなど。ディレクターあるあるのときは特に賑わっていて、会場にはフリーランスの方も多くディレクションも制作もご自身でやられている方が多いからかなーと思いました。

Backlog に議事録を残したりやりとりをするとなるとクライアントにも Backlog を使ってもらうことになるかなと思うのですが、僕の周りの間隔だとちょっとハードルが高いかな？という感じもあるので、その辺りのノウハウもまた今度お伺いしたいなと思いました。

懇親会＆LT大会

この後は同じ会場でそのまま懇親会＆LT大会でした。僕もせっかく大阪まで行くのだから何かやろうと思ってLTに申し込んでいたのですが、あまりに早く申し込んでしまってLTの参加権をいただいたときにはどういう内容で申し込んだのか忘れてしまい主催の大串さんに聞く、という失態をおかしてしまいました^^;

内容が薄いので2、3分で済んじゃうのではないかと思いましたが、会場の盛り上がりと僕のテンパり具合が重なって時間ピッタリのLTとなりました。他にも3名の方とWP-Dの方々もLTをされていましたが、皆さんスラスラと本当に上手くて盛り上げ上手で。そんな中で僕一人だけスベり倒したらどうしようかと思っていましたが会場の皆さんとスタッフの皆さんのお陰で何とか無事？LTをやることができました。改めてありがとうございます。

地方にいると中々会ってみたい方がいても機会が無かったりするので、今回はお会いしたかった方にたくさんお会いできて楽しかったです。あまり時間がなくて皆さんとじっくりお話できなかったのが心残りですが、夏には WordCamp Kansai 2015 の開催も予定されているそうですので、またそこでいろいろお話ができればと楽しみにしています。WP-Dの皆さん、参加された皆さんありがとうございました！

大原さん、BizVektor作者の石川さんと。photo by @webboyjp

Smart Custom Fields をバージョンアップして、コードベースでカスタムフィールドの定義ができるようになりました。smart-cf-register-fieldsフックを使い、SCF::add_settingでメタボックスを定義、$Setting->add_groupでグループを定義して、その引数で各カスタムフィールドを定義します。コードベースで定義できるようになったので、functions.php などでカスタムフィールドを定義しておいて Git で管理すれば、管理画面で管理するよりも簡単に別の環境に移したり、以前定義していた定義にもどしたりすることができますね。

カスタムフィールドを定義する配列で使える項目はまとめるのが面倒なので…プラグインのコードを直接確認してみてください（/plugins/smart-custom-fields/classes/fields/*）。Smart Custom Fields の管理画面で適当にグループとフィールドを作ってブラウザの Developer Tool とかで入力項目をのぞいてもらっても何となくわかるかなと思います。

今回は @Toro_Unit さんに色々とプルリクをいただきまして、独自のカスタムフィールドを追加できるようになったり、管理画面がちょっとオシャレになったりしました。自分が何もしてなくてもプラグインがパワーアップしていく感じがとてもおもしろいと思いました。ありがとうございます！

また、@tekapo さんに日本語の翻訳ファイルを作って頂きました。面倒で日本語化するの放置していたのですごく助かりました。ありがとうございます！

その他の主な変更点

Datepicker、Colorpicer が定義画面でも同じ UI でデフォルト値の指定ができるようになりました。

これまでは単純なテキストフィールドで記事作成画面のカスタムフィールドのように Datepicker、Colorpicker の UI で指定できないのが不便でしたが、今回からは同じ UI で指定できるようになりました。WYSIWYG は難しそうだったのでまだ対応できてません…。

リビジョン表示の不具合を修正

どのバージョンからかはわかりませんが、カスタムフィールドのリビジョンが最新のものしか見れないようになっていました。今回のバージョンからは当初のとおり、全てのリビジョンが見れるように修正しました。

プロフィールページへのカスタムフィールドの設置

Smart Custom Fields をバージョンアップして、プロフィールページにもカスタムフィールドを設置できるようになりました。

プロフィールページのカスタムフィールドの例

プロフィールページで設定したカスタムフィールドのデータは次のメソッドで取得できます。もちろん、WordPress 標準のユーザーメタ取得関数でも取得できます。

// 現在の記事の著者IDを取得
$user_id = $post->post_author;

// 'カスタムフィールド名' のデータを表示
echo SCF::get_user_meta( $user_id, 'カスタムフィールド名' );

// 全てのメタデータを表示
var_dump( SCF::get_user_meta( $user_id ) );

累積的なバグフィックス

これまでもテストコードは書いてはいたのですが、かなり限定的な箇所しか書いておらず、広範囲を網羅できていたわけではなかったのでいくつか不具合がたまってきていました。また、潰したはずのバグがまた復活してしまったりしていたので、全体的なリファクタリングを行ってテストコードも倍くらいに増やしました。恐らくこれで不具合はだいぶ無くなったのではと思います…。

アイキャッチ画像のプレビュー

@mypacecreatorさんから、プレビュー時にアイキャッチ画像が反映されないという報告をいただきました。

プレビューのアイキャッチ画像は全く動作確認できていなかったのでご報告いただいて助かりました。アイキャッチ画像もカスタムフィールドと同様、「リビジョンにデータが紐付いていてプレビューの投稿IDを渡せばプレビューのアイキャッチ画像が表示できる」と勝手に思い込んでいたのですが、アイキャッチ画像は「更新」ボタンをおした時ではなく「アイキャッチ画像を設定」したときに元記事に直接設定されるみたいで、プレビュー時に元記事のアイキャッチ画像を取得するようにすることで解決することができました。

まだまだ知らないことがあるなーと思ったのと、オープンソースとして公開することでユーザーの方からそのようなご報告をいただける機会が多くあり、ありがたいなーと改めて思いました。