テーマレビュー用の真新しい環境を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 というファイル名で保存します。

これで、このレビュー用のディレクトリに移動して、以下のコマンドを入力すると、
Continue reading テーマレビュー用の真新しい環境を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 を行っています。 Continue reading タイでWordPress Meetupを開催しながら考えてきたこと

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

WordPressの管理画面に独自のオプション保存をするためのSettings APIの使い方

WordPressの管理画面に独自のオプションを保存するための方法です。

書籍『WordPressプラグイン開発のバイブル』の中では、紹介しきれなかった部分です。

Settings APIとは

Settings APIは、テーマやプラグインから管理画面に独自の設定保存領域を作るためのAPIで、バリデーションや保存などの大部分をWordPressに任せることができる便利なものです。

Settings API利用の基本的な流れ

もっともシンプルに項目を追加する流れは、以下のようになります。

  1. admin_init フックにて、以下の3つを登録
    1. セクション:管理画面のどこに表示するか ( add_settings_section )
    2. フィールド:input, selectなど (add_settings_field )
    3. 設定:name 要素 ( register_setting )
  2. セクションやフィールドのコールバック関数を定義する。
    ここで、管理画面に表示させるべきフォームや説明文などを決める。
  3. 保存される値のサニタイズ用の関数を定義する

自分自身でテーブルなどを書く手間がすべて省けますので、楽ちんです。

関数は3つ(全部admin_initにフックします)

1. add_setteings_section

add_settings_section(
    'ogp_settings', // id
    __( 'OGP Settings', 'nskw-ogp-generator' ), // 表示する文字
    'nskw_add_settings_section', // コールバック関数
    'media' // どのページに追加するか。
    );

上記のように使います。ここで指定したIDは、次のフィールドを登録するときの印になります。

3つめはコールバック関数の名前で、セクション内で実行される関数です。出力する場合には、echoします。

2.add_settings_field

add_settings_field(
    'ogp_img_field', // ID
    __( 'Default Image', 'nskw-ogp-generator' ), // 表示する文字
    'nskw_ogp_img_field', // コールバック関数
    'media', // どのページに追加するか
    'ogp_settings' // そのセクションに表示するか
    );

ここで指定したIDは次の設定を登録する際に使います。

3つめはコールバック関数の名前で、inputなどの要素を出力します。

3. register_setting

register_setting( 'media', 'ogp_img_field', 'esc_url' );

どのページ(media)に、なんという名前のsetting(ogp_img_field)を追加するかを登録します。最後のesc_urlはサニタイズするための関数名を指定します。自分で定義するか、年齢などの数値であればintvalなどでもよいです。

全体像

これらをまとめると以下のようになります。

// セッティングAPIを使ってみよう
add_action( 'admin_init', 'nskw_ogp_settings' );
function nskw_ogp_settings() {

	// セクションを登録
	add_settings_section(
		'ogp_settings',
		__( 'OGP Settings', 'nskw-ogp-generator' ),
		'nskw_add_settings_section',
		'media'
		);

	// フィールドを登録
	add_settings_field(
		'ogp_img_field',
		__( 'Default Image', 'nskw-ogp-generator' ),
		'nskw_ogp_img_field',
		'media',
		'ogp_settings'
		);

	// nameを登録して保存されるようにする
	register_setting( 'media', 'ogp_img_field', 'esc_url' );

}

// セクション用の関数
function nskw_add_settings_section() {
	_e( 'This image will be used in home page, archive pages and posts/pages which don\'t have post thumbnails', 'nskw-ogp-generator' );
}

// ogp-img-field用の関数
function nskw_ogp_img_field() {
	?>
	<input id="ogp_img_field" name="ogp_img_field" type="text" value="<?php form_option('ogp_img_field'); ?>" />
	<?php
	printf(
		__( 'Url of the default image. At least 600x315 pixels, but it\'s better to have a bigger one.<br />You can upload your image <a href="%s" target="_blank">here</a>', 'nskw-ogp-generator' ),
		admin_url( 'media-new.php' )
	);

}

これまでに説明していないのは2つのコールバック関数です。一つ目がセクションに登録した文章を出力するだけのもの、2つ目はinputを出力している部分です。inputのname要素は、register_settingフィールドで登録した名前にします。

また、textフィールドのvalueにあるform_option()というのは、オプションのキーを指定するとフォーム用にサニタイズしてechoしてくれる関数です。

Settings APIを使って、設定>メディアの画面に、プラグインから保存用の画面を作ったところ。
Settings APIを使って、設定>メディアの画面に、プラグインから保存用の画面を作ったところ。

以上です。

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