カスタムフィールド定義のデプロイ問題を解決する Advanced Custom Fields の Local/Synchronized JSON

カスタムフィールド製造業界のみな様、こんにちは!

「ACF ってすっごく便利なのだけど、フィールドの定義情報をデプロイするのが面倒くさい問題」が解決できる機能が、ちょっと前から追加されていたようです。

Advanced Custom Fields の、フィールドの定義情報を json 形式で保存でき、また、それをテーマに含めることができるというドキュメントにばったりと出会ってしまいました。みなさん知ってて僕だけが知らなかったのだとしたら、すみません。

簡単に言いますと、

  • ACF のフィールドグループを管理画面を使って定義すると、
  • テーマ内に json が生成されて、
  • git で管理できるし、
  • デプロイも簡単で、
  • json からデータベースへの逆同期(?)も可能

というものです。

みつけたきっかけは、マルチサイトで運用する多言語サイトで、全サイト同じフィールドを持たせたいのだけど、フィールドの定義を全部のサイトで変えるのは面倒くさすぎるのを何とかしたいと、「そういえば php を生成してそれを functions.php に含めれる」みたいな方法があったな、と思って検索していたのがきっかけでした。

この機能が使えるのは、ACF の Version 5 以降です。ドキュメントは以下です。

ACF | Local JSON

仕組み・使い方

スクリーンショット 2015-05-04 21.47.04

テーマの中に、acf-json というフォルダを作成して最低限の書き込み権限等を与えると、フィールドグループ(フィールド定義のセットのこと)を保存する度に json ファイルが生成されて、そのファイルがある場合にはそちらが読まれるとのこと。ドキュメントには、データベースにアクセスする回数が減りますよ、と書いてありました。

フィールドグループの編集画面ではデータベースの情報が読まれるそうですので、手動で更新した場合には、定義画面にはその変更は、そのままでは反映されません。
定義画面ではどんな場合にもデータベースの情報が読まれ、保存時に json ファイルが更新される。表側や入力画面( edit-post.php 系の画面とかオプションページとか)では、json があればそちらがロードされるということ。

json からデータベースへの反映は、以下のようなメニューが追加されていて同期が可能になっています。

スクリーンショット_2015_05_04_21_35

くわしくは、ACF | Synchronized JSON を読むと分かるのですが、

  • json 情報はあるけど対応する定義がデータベースがない場合に利用可能
  • json 情報もデータベース情報もあるけど更新時間が json の方が新しい場合に利用可能

という条件で、どっちが新しいんだっけ?という問題も起きないようになっているみたいです。

素晴らしい!

マルチサイトでの便利ポイント

ここまででも素晴らしいですが、マルチサイトでの運用時にも大変便利です。

  • マルチサイトで同じフィールドを使いたい場合、マスターになるサイトで定義をして json を生成してしまえば、同じテーマを利用する他のサイトでも同じフィールドが使える。
    • しかも、変更が全サイトに反映される
  • json さえバージョン管理されていれば、データベース側の情報が古くなってしまっていても大丈夫。
  • 本番の環境では書き込み権限を無くしてしまうと、なんとなくさらに安心感がある気がする

あとあと、WordPressのカスタムメニューが82個以上登録できねーおらおらーって時の対処方法 | Firegobyにあるような、フィールドが多くなりすぎてサーバで保存ができなくなって大変、というのもこの方法であれば(定義情報に限り)、プロダクション環境のセキュリティのレベルを下げることなく、事故がなくなり、その点も便利です。

ここ最近の案件用のプラグインにまつわる発見の中でも、すっごいびっくりしたのでした!

大きなプラグインは特にですが、やっぱりドキュメントをちゃんと読まないと損だなと思いました。

また、仕組みなどは違いますが、ファイルベースでフィールドを定義できるカスタムフィールドプラグインに、キタジマタカシさんによる、Smart Custom Fieldsもありますので、使わせていただきたいと思います!
くわしくは以下をごらんください。
Smart Custom Fields でカスタムフィールドの定義を Git で管理できるようになりました! | モンキーレンチ

↓ プラグインを作る方々への本、書きました。 ↓

OGP Generator: Facebookでシェアされた時の表示をコントロールするための WordPress プラグイン作った

Facebook のいいね!ボタンが押された時、シェアされた時、フィードには画像やタイトルや記事の抜粋などが表示されます。その表示のされ方を、シェアされるウェブサイト側(みなさんのブログ)でコントロールするのに使える仕組みが、OGP(Open Graph Protocol)です。

その OGP を「いい感じに」設定するためのプラグインを作りましたので、お知らせします。

ダウンロード: OGP Generator « WordPress Plugins

どの辺がいい感じなのか?

以下の3点がいい感じだと思います。

  1. ブログや会社サイトに最適と思われるパターンに特化したシンプルさ
  2. 気が利いている(特に画像とディスクリプション)
  3. 設定が簡単(項目は3つだけ)

1. シンプルさ

OGP はこだわろうと思えばとことんこだわれます。たとえばポッドキャストを配信しているブログであれば、音声ファイルの種類やURL、音源の長さなどを出すことができます。うまくすればその場で再生できたりするのでしょう、多分。

でも、このプラグインではそういうところは置いておき、記事がシェアされた時に、きちんとタイトルと画像と説明文がFacebookのフィードに出るようにする、ということに決めて作りました。

ただし、会社サイトとブログサイトの両方でうまく使えるようにする、という風になっています。

2. 気が利いている

たとえば画像(og:image)であれば、以下のようなルールで画像が表示されますので、OGP画像にこだわりたい人もそういうのが面倒くさい人も、ちゃんと使えます。

  1. 個別の記事ページで、アイキャッチ画像を指定している場合はその画像
  2. アイキャッチはないけど画像が添付されている(その記事の編集ページでアップした)場合はその画像
  3. アイキャッチも添付画像もないけど、なんらかの画像が含まれている場合にはその画像
  4. なにもない場合には、管理画面の「設定 > 表示設定」の一番下の欄で指定したデフォルト画像

次に、og:type というそのURLで表示されるページがどういう種類のページなのかを指定するタグがありますが、以下のルールになっています。

  • 管理画面の「設定 > 表示設定」で、「固定ページ > フロントページ」 に設定されているページの場合、会社サイトやサービスの紹介サイトのトップだろうから、 “website”
  • 管理画面の「設定 > 表示設定」で、「固定ページ > 投稿ページ」 に設定されているページの場合、ブログのトップページになっているはずなので、 “blog”
  • その他の場合、 “article”

その他にも、タイトルの下に出る説明文は、抜粋があればそれを、なければ投稿の本文を採用しつつ、画像タグとかショートコードとかは出ないようにするなど、いろいろとちゃんとしてました。

Facebook の Object Debugger を通してみた画像
Facebook の Object Debugger を通してみた

3. 簡単設定、3項目だけ

どうしてもやってもらわないと困ってしまう部分、管理画面で入力をしてもらってます。

  • デフォルト画像の URL
  • fb:app_id なのか fb:admins なのか
  • ID それ自体

の3つです。管理画面にページを増やさないよう、「設定 > 表示設定」の下の方にちょこっと足してあります。

今後について

多分、あまり変わらないと思いますが、バグフィックスや以下のことをやると思います。

  • ロケール(言語と地域を示す記号)が、WordPressが持っているものとFacebookが指定するものが微妙にずれているので(ja と ja_JP や、th と th_TH など)、そこをできるだけ多くの言語で調整する(需要があれば)
  • article の場合、 author や published_time などを指定できるみたいですが、これが何かの役に立ちそうならば入れる
  • og:see_also というのがあって、多分これってフィードで流れてきた記事をクリックすると、その下に3つくらいの別の記事が出てくると思うのですが、それ?なのかな?であれば、トラフィックにすごい影響がありそうなので実装したい。カテゴリとかタグを見たり、他の関連記事系プラグインと連携できるようにしたりとか

以上です。

ダウンロードは、OGP Generator « WordPress Plugins
ダウンロードは、OGP Generator « WordPress Plugins

↓ プラグインを作る方々への本、書きました。 ↓

テーマレビュー用の真新しい環境を1分で作成する。WP-CLI Advent Calendar 2014 19日目

wp-cli アドベントカレンダー、先週は僕ではなくて自称の私に書いてもらうという失態をしてしまってすみません。。。ひゃっほーーー!!!というキャラだったのかしらアラヤダ。

さて、昨日の自作プラグインに追加した wp-cli コマンドの出力結果を整形しよう ( WP-CLI Advent Calendar 2014 18日目 ) | dogmap.jpに引き続きまして、本日19日目は、wp-cli を利用してテーマレビュー用の環境を作ろうというテーマで、パワフルなwpのコマンドの紹介をしつつ、1個のファイルにまとめて置いておけば、便利でいいさね、といったところをご紹介したいと思います。

テーマレビュー用の環境?一度作ればそれでよくない??

そういう疑問も出てくるとは思うのですが、

  • 毎回まっさらな状態を用意しないといけない
  • けど、テーマユニットテストデータのインポートも必要
  • サイトの名前やタグラインを長くしたりいろいろしないといけない
  • プラグインもいろいろ入ってるとありがたい
  • もろもろ最新版にしておきたい

というまっさらだけど、いろいろ準備しないといけないというのが大変なわけです。そんな方々のために、宮内さんのVCCWなるVagrant環境もあります。こちらも超簡単で、

$ wp_theme=http://example.com/path/to/zipped/theme/file.zip vagrant up

というコマンドのみでいろいろしてくれます。

 今回のやること

今回自動的にパパっとやってしまいことは、上から順番に以下のようになります。

  1. データベースのテーブルを全部消しちゃう
  2. WordPressのインストールプロセスを実施(サイト名、ユーザ名/パスワード/メールを指定)
  3. WordPressのコアを最新版にする
  4. テーマチェック、debogger、非推奨をロギングしてくれるの、モンスターウィジェット、WordPressインポーターのプラグインをインストールして、有効化する
  5. デバッグバー、WordPressベータテスタープラグインをインストールだけする。
  6. プラグインを全部最新版に更新する(2回目以降は、ステップ4と5では古いバージョンはアップデートされないので)
  7. ブログディスクリプションをめっちゃ長くしておく
  8. posts_per_page を 5 にするなど細かいオプションの設定
  9. テーマユニットテストデータのダウンロード、インポート、削除
  10. 指定したテーマのインストール
  11. 画像の再生成(サイズを合わせる)

となります。
実際のコマンドは以下のようになりますので、WordPressのルートに、newreview というファイル名で保存します。

これで、このレビュー用のディレクトリに移動して、以下のコマンドを入力すると、
続きを読む テーマレビュー用の真新しい環境を1分で作成する。WP-CLI Advent Calendar 2014 19日目

↓ プラグインを作る方々への本、書きました。 ↓

wp-cliのglobalパラメータ/YAMLコンフィグのオプション ( WP-CLI Advent Calendar 2014 5日目 )

WP-CLI アドベントカレンダー 2014 の第5日目!昨日の @wokamoto さんによる Chef で wp-cli を管理するためのレシピ | dogmap.jp に続きまして、頑張らせていただきます!

グローバルなパラメータ?

wp-cli には、すべてのコマンドと一緒に使うことができるグローバルパラメータというものがあり、 Configuration | WP-CLI のページで解説されています。

たとえば、以下のコマンドは WordPress がインストールされているパスを指定する --path というパラメータをつけています。

$ wp option get home --path=/var/www/vhosts/example.com/

wp option get home は、 WordPress の home_url( '/' ); が返す値を得るためのコマンドです。通常、 wp-cli は WordPress がインストールされているディレクトリ以下でなければ使えませんが、 --path=/path/to/wp/ をつけることで、ターミナルでそこまで移動していってコマンドするのと同じことになります。移動の手間が省けるだけではなく、複数の処理にまとめるときだとか、cronで実行するときなどに便利です。

そこで今日は、

  1. グローバルパラメータの種類
  2. これらのパラメータは設定ファイルにも書いて置いておくことができるのだが、その優先順位

について書きたいと思います。

設定ファイルについてはどなたかがこのリレーブログの中で誰かが書いてくれるであろうことを期待しております。誰も書かなければ来週も私なので書こうと思います。

グローバルパラメータの種類

フラグ 説明
--path=<path> WordPressがインストールされているディレクトリへのパスデフォルト値: null
--url=<url> リクエストが行われたURLを仮想的に指定できます。マルチサイトでは、この引数を指定することでどの子サイト(または親サイト)でコマンドを実行するのかを特定することができます。たとえば、
wp plugin status --url=colog.jp
だと親サイト、
wp plugin status --url=colog.jp/colochan または、 wp plugin status --url=colochan.colog.jp
で特定の子サイトで、どのようなプラグインがインストールされていて有効化されているかなどの状態が分かります。デフォルト値: null
--user=<id|login|email> WordPressのユーザを指定する。(ことができるらしいのですが、使い道が思いつきません。 wp user コマンドではIDなどをそのまま指定できますし、wp post url などで --user=<id> を指定しても絞り込むことはできませんでした。)デフォルト値: null
--skip-plugins[=<plugin>] プラグインのロードをスキップすることができます。
例: wp user generate --skip-plugins=user-role-editor でユーザに関するプラグインの影響を受けないようにしながらユーザを作成する。デフォルト値: ""
--require=<path> コマンドが実行される前にロードされるべきphpファイルを指定する。複数回使用可能。デフォルト値: []
--no-color, --color 出力のカラーリングのオンオフ。デフォルト値: "auto"
--debug php エラーを表示するかどうかデフォルト値: false
--prompt 対話形式で値を渡したいときに使います。たとえば、wp-config.php を作成するための
wp core config
というコマンドでは、DBの名前やユーザ名他いろいろなパラメータを渡さないといけません。これをいちいち長いのを作るのが面倒な時、 wp core config --prompt とやりますと、以下のような形でひとつひとつ聞いてくれます。デフォルト値: false

$ wp core config --prompt
1/10 --dbname=: hello
2/10 --dbuser=: hey
3/10 [--dbpass=]: pass
4/10 [--dbhost=]: :)
5/10 [--dbprefix=]: (๑╹ڡ╹๑)
6/10 [--dbcharset=]: nyoro
7/10 [--dbcollate=]: asdf
8/10 [--locale=]: 123
9/10 [--extra-php] (Y/n): n
10/10 [--skip-salts] (Y/n): n
--quiet 情報系のメッセージを抑制することができます。デフォルト値: false

 

パラメータを指定する際の(指定方法の)優先順位

パラメータの指定は、コマンドと一緒に --example=example という形でつけるだけではなく、.ymlファイルに設定を書いておくことでも可能です。

たとえば、wp-cli.yml というファイルが置いてあるとして、その内容が、 skip-plugins: akismet backwpup third fourth の一行であったとすると、このファイルが設置されている場所以下でのコマンドに、この内容が反映され、指定されたプラグインは無いものとしてコマンドが実行されます。

ymlファイルの置き場所は複数ありますので、それらの優先順位をこれまた同じページからですが、日本語にしておきます。優先順位の高い順位、

  1. コマンドラインからフラグを付けて指定する
  2. wp-cli.local.yml ファイル内の指定。
  3. wp-cli.yml ファイル内の指定内容。
  4. ~/.wp-cli/config.yml ファイル内の指定内容。(パスは環境変数 WP_CLI_CONFIG_PATH で変更が可能)
  5. デフォルト値

この優先順位の利用方法としては、たとえばローカル環境にたくさんのWordPressがいるとして、

  • どのプロジェクトでも使いたい設定については ~/.wp-cli/config.yml に。
  • 特定のプロジェクトだけで利用したい設定については wp-cli.yml に。
  • 特定のプロジェクトで、ローカルだけで利用したい設定については wp-cli.local.yml に書いて .gitignore に記載。

といった形にしておくと、細かいことを気にしないで短いコマンドを使うことができるかと思います。忘れると面倒だけど。

というわけで、本日はグローバルなパラメータがあったんだ!ということで、何かの時に思い出していただければと思います。

明日は、yuji.takehiro さんです!(明日、リンクします!)

↓ プラグインを作る方々への本、書きました。 ↓

タイでWordPress Meetupを開催しながら考えてきたこと

WordPress Advent Calendar 2014の第1日目です。高橋さん、今年もありがとうございます。

家族でタイで暮らしています

妻と2人の子どもたちとで、タイの首都バンコクで暮らしています。
普段は WordPress を使って、お客さんのためにウェブサイトを作って暮らしています。

タイで WordPress Meetup をやっています

今日は、タイで WordPress のミートアップを続けてきて、考えたことについて書きたいと思います。

私自身、日本のWordPressコミュニティ、特にWordBench、WordCampにはとてもお世話になりました。
WordPressを始めて、買ってきた書籍を読んでひとりで勉強していたときには分からなかったことが分かるようになって、たくさんの人たちに出会うことができました。

そういう経験がバンコクでもできたらいいなと思い、また、私が受けてきた恩恵をバンコクの人たちにも経験してもらい、そこから更に開発者やビジネスが出てきたらいいなと思い、こちらでも毎月 WordPress Meetup を行っています。 続きを読む タイでWordPress Meetupを開催しながら考えてきたこと

↓ プラグインを作る方々への本、書きました。 ↓