DockerでWordPressを立ち上げる。GUIで。

Docker で WordPressを立ち上げる。GUIを使って。

WordPress の プラグインのテストや、テーマのテストを行いたい時、Docker を利用することでもっと便利になるでしょう。

今まで Wockerを利用していましたが、エンジニア以外でも簡単に立ち上がれる方法を探りました。

Kitematic を利用する

結構前からあったと思うのですが、今は dockertools として cli と一緒にダウンロードできるみたいです。

Kitematic

ダウンロード後インストールし、Kitematic を開くと綺麗なウィンドウが開きます。

さて、WordPressを早速立ち上げて見ましょう。

コンテナの作成、設定

MySQL コンテナの作成

Docker が配布している WordPress のイメージには MySQL 環境が含まれていません。
よって、別にMySQLのコンテナを立ち上げる必要があります。

右上の検索窓から mysql と入力後検索し、これまた Docker のオフシャルリポジトリの MySQL イメージをクリックして立ち上げます。
また、初期状態では root ユーザーのパスワードが空のままなので、

MYSQL_ROOT_PASSWORD

に任意のパスワードを指定してください。

WordPress の立ち上げ

WordPress の立ち上げも、右上の検索窓から行います。
wordpress と検索すると、オフシャルのリポジトリが表示されるのでクリックしてダウンロードしましょう。

注意点として、いくつかのパラメータを設定する必要があります。
先ほどの MySQLコンテナと繋ぐために、MySQLのホストを設定します。

  • WORDPRESS_DB_PASSWORD に MySQLのroot ユーザに設定したパスワードを指定
  • WORDPRESS_DB_HOST に mysql指定

すると、綺麗に WordPress が表示されます。

番外編 :  立ち上げたVMにログインする

やはり php.ini をいじりたい時がが出てきました。

$ docker ps -a

 

上記のコマンドで、立ち上げた コンテナのIDが表示されるので、
そのIDをもとに、

$ docker exec -i -t {id} bash

 

でログインすることができます。

地味に便利なショートカット WordPress プラグインを作りました。

687474703a2f2f7a697070792e6766796361742e636f6d2f4f6e6c795365636f6e644172616269616e686f7273652e676966

はい。地味に便利な WordPress プラグイン「Powearch」を作成しました。

今、WordPressの公式リポジトリにも申請を出している途中なのですが、、

通ったらおいおい追記します。

審査通りました。
https://wordpress.org/plugins/powearch/

どんなプラグインよ?

一言でいうと、WordPress 版 Alfred ( 下位互換 ) プラグインです。
シフトキー2回で立ち上がり、打ち込んだキーワードを Ajax でサーバーに送り、
結果を JSON で返し、選択肢として表示します。

選択後、エンターキーを押すことでそのページに飛びます。
これだけです。

内部的には、Twitter の Typeahead.js を利用しています。
日本語入力も対応されており、非常に楽でした。

正直、一般的なクライアントにとっては使いにくいですが、
制作者やブロガーさんには便利なんじゃないかと思います。

一応、フロント側でも管理画面側でも立ち上がるようになっています。
どうしても、「フロント」→ 「管理画面」→「目的のページ」となるWordPressの動線を、
めちゃくちゃにするものです。

 

インストール方法

まだ WordPress.org には審査申請中なので、

管理画面→プラグイン → 新規追加 から 「powearch」で検索するとヒットします。

それか、github のリポジトリから zip をダウンロードして、手動でアップロードしてください。

https://github.com/1shiharat/powearch/archive/master.zip

どんな検索結果がかえってくるのか

・管理画面のメニューに表示されているすべて

・WP_Query で 検索した記事

以上が検索結果として表示されます。

記事に関しては パラメータ s にキーワードを渡しただけです。
取得した記事は、フロント側を表示するもの
なお、投稿タイプはパブリックなものを取得してきます。

今後やりたいこと

まだ設定画面も何もつくっていないので、トリガーとなるキーを設定したり、
独自のショートカットを登録出来たり、
取得した投稿への操作を選べたりしたら楽しそうですね。

 

 

WooCommerce 決済代行会社について

久々にWooCommerce を使ってみたら、いい感じだったのでメモ。
管理画面の日本語化は問題なし。
コードもオブジェクト指向で、読みやすい。

問題は、決済代行会社がどこまで対応しているのかですな。

ってことで、ゆるゆるな調査スタート!

WooCommerce用ペイジェント決済(WordPress対応ECプラグイン) – 株式会社ペイジェント

GMP イプシロン (イプシロン的には非公式っぽい)

Webpay (こちらも非公式)

・Paypal

…. 上記の4つっぽいですね。
まぁ、ペイジェントがあるだけまだいいかな。ペイジェント使いづらいけど。

Automattic 社に買収されて久しいですが、今後も楽しみです。

WordPress の高速化施策 #wpacja2014

WordPress Advent Calendar 2014 ということで12日目を担当します@1shiharaTです。
取り敢えず、今まで Advent Calendar に参加した事がなかったので、今年こそは参加しようと思い立ちました。

とはいえ、ネタもそこまで豊富ではないので…

今回は絞り出して WordPress の高速化施策について語ろうと思います。

目次

0. 原因の調査

まずは、サイトの問題を調べること。それが適切な対処に繋がります。
WordPress は CMSですので、フロントエンド側のボトルネックと”バックエンド側のボトルネック”を調べることが重要となります。

フロントエンド側の調査

主に、開発者ツールを使用して調査することになります。
( 私自身 Chrome を使用しているので Chrome Developer Tool を軸に書きますが、他のブラウザでも出来るかと思います。)

( Chrome Extension )

Google 製のウェブパフォーマンス測定ツールです。
基本的に、Chrome Extension 版を使用することが多いです。

Chrome 開発者ツールの「Network」タブも役に立ちます。

ブラウザがそれぞれのリソースを読み込むのにどれぐらいかかったかというのが一目瞭然です。

簡単に言うと、一番上のリクエストページ自体のレスポンスが遅い場合と、画像などの静的ファイルの読み込みに時間がかかっている場合が一目瞭然です。

バックエンド側の調査

フロントエンド側の調査の結果、リクエストしたページ自体のレスポンスが遅い場合にはコチラの調査を深くほっていかねばなりません。

上記プラグインを有効化すると、ログイン時のアドミンバーにQuery Monitor バーが出現します。

それぞれの項目をクリックすると、データベースクエリーや応答時間、PHPのエラーなど 結構詳細な事項が出てきます。
これに応じて、プラグインを無効にしたり、時間のかかっている箇所を修正したりすることになります。

開発者のためのプラグインも結構たくさんあるのですが、僕が普段使用する中ではこれが一番お手軽かなという気がします。

1.プラグインリソースの最適化

1.1 プラグインのデメリット

WordPress の一つの利点として、拡張性の高いプラグイン機能が思いつきますね。
こんな機能つけたいな…っていう見切り発車的な発想でも、wordpress.org の公式プラグインディレクトリや
Google 先生に聞くと割と解決策が返ってきます。

しかし、その結果プラグインごとに用意された css , jsファイルを個別にロードすることになります。
WordPressのコア機能では、静的ファイルをプラグインを超えてまとめてくれたりはしません。
よって、大量のリソースにリクエストする状態に陥ってしまいます。
どれだけテーマを作成する時に Grunt, Gulp といったタスクランナー を使ってminify かけようと、これではあまり意味がない気がします。

一方、HTTP1.1 では同時接続数が決まっているので、比較的新しいブラウザでも最大で6つのリソースずつしか読み込むことができません。
ココらへんの知識には下記の記事が非常に参考になると思います。

身につけておきたいWebサイト高速化テクニック #2|検証ツールとそもそもHTTPって何だ編

1.2. 解決方法

これは プラグインの仕組み上仕方ないことなので、サーバーサイドで解決することになります。
プラグインから静的リソースを読み込ませる時には、wp_enquene_scripts()といった関数を使って、
wp_head(), wp_footer() に埋め込みます。ですので、比較的簡単に対処することができます。

WordPressにおける静的ファイルの管理

WordPressではどのように静的ファイルを管理しているのかについて、軽く触れます。
基本的に以下のファイルにその記述がなされています。

おおまかに説明すると、WP_Dependencies というclassを拡張して、WP_Scripts, WP_Stylesという classを作成。
functions.wp-scripts.php と functions.wp-styles.php というファイルで、
それぞれの classのインスタンスを関数内で global で取得し、いろんな操作をしています。

ってことは、テーマ内からでも global $wp_scripts, $wp_styles という記述をしてあげれば、出力の調整が可能です。( ちゃんと関数も用意されています )
まぁ、でも面倒ですね

AssetsMinify を使う。

$wp_scriptsや$wp_styles といったインスタンスを使って、自分で圧縮したり、キャッシュを取ることも可能です。
が、ここはWordPress。既にプラグインもあります。
プラグインで起こっている問題もプラグインで解決するという..なんかおかしな状態ですが。

AssetsMinify


このプラグインでは、Assetic という symphony などでも使用されている静的ファイル管理用ライブラリと、
cssMin や jsMin といった Minify するためのライブラリを使っています。

このプラグインを有効化して設定をすると、$wp_scripts, $wp_styles に登録しているcss,jsファイルをひとまとめにしてくれます。
ちゃんとminifyせずに出力したいファイルも登録できるので、何気に便利です。

2. キャッシュを使用する

キャッシュを使用する…といっても、W3 Total Cache といったキャッシュ系プラグインを利用する方法が一番簡単かなと思います。

では、WordPress のプラグインを開発したり、テーマ開発を行う際に私達が行えるキャッシュについて考えてみます。
WordPress でオブジェクトキャッシュを取るには、WP_Cache クラスを利用します。( 正確には wp_cache_add(), wp_cache_get といった関数 )
また、options テーブルに 有効期限を定めたデータを保存する 「Transients API」も用意されています。
Transients は「一時的なデータ」といった意味合いかと思います。(間違っていたらすみません)

これらを利用することで、データベースへの問い合わせも減り、高速化につながります。
例として、twentyfourteen テーマのコードを挙げます。

/**
 * ブログで複数のカテゴリーが登録されているか調べる関数
 *
 * @since Twenty Fourteen 1.0
 *
 * @return 真偽値 : 複数のカテゴリーが登録されている場合は true を返す
 */
function twentyfourteen_categorized_blog() {

     // ‘twentyfourteen_category_count' というキーのデータが見つからない場合
     if ( false === ( $all_the_cool_cats = get_transient( 'twentyfourteen_category_count' ) ) ) {
          // 投稿があるカテゴリーリストを取得
          $all_the_cool_cats = get_categories( array(
               'hide_empty' => 1,
          ) );

          //
          // 取得したカテゴリの数を数える
          $all_the_cool_cats = count( $all_the_cool_cats );

          // ‘twentyfourteen_category_count' というキーでカテゴリ数を保存
          set_transient( 'twentyfourteen_category_count', $all_the_cool_cats );
     }

     // 取得したカテゴリ数が1じゃない場合
     if ( 1 !== (int) $all_the_cool_cats ) {
         // true を返す
          return true;
     } else {
         // false を返す
          return false;
     }
}

/**
 * twentyfourteen_categorized_blog 関数で使用している一時的なデータを削除するアクションフック
 *
 * @since Twenty Fourteen 1.0
 */
function twentyfourteen_category_transient_flusher() {
     // ‘twentyfourteen_category_count’ というキーを持つデータを削除
     delete_transient( 'twentyfourteen_category_count' );
}

// カテゴリー編集時と投稿保存時に上記関数を動作させる
add_action( 'edit_category', 'twentyfourteen_category_transient_flusher' );
add_action( 'save_post',     'twentyfourteen_category_transient_flusher' );

Transients API を使わない場合ですと、twentyfourteen_categorized_blog() と実行した時に
get_category()関数を呼び出して データベースクエリを構築し、結果を取得しています。

しかし、Transients APIを利用することで以下の場合にのみ get_categories() を実行し、取得したカテゴリーを数える処理を行います。

  • テーマをインストールしてから最初の実行時
  • カテゴリー編集時
  • 投稿保存時
  • データをセットしてから24時間後

上記以外の場合は、twentyfourteen_category_count というキーに保存してあるカテゴリー総数を取得します。

3. 画像の最適化

WordPressの場合、画像の最適化をするポイントは2つあります。

  • テーマ内で使用する画像
  • 運用上 uploads ディレクトリへ追加される画像

テーマ内で使用する画像については、制作完了時に JPEGmini や pngmini, ImageOptim といった画像圧縮系ソフトを利用して最適化したり、
Grunt や Gulp といったタスクランナーによって最適化を自動化したり等、いろいろあると思います。

しかし、運用上 uploads ディレクトリへ追加される画像については、中々厳しい側面があります。
定期的に ディレクトリ毎ダウンロードしてソフトを通して再アップロードも面倒なので…

画像の最適化としては、EWWW Image Optimizerを使えば、そこそこ画像を最適化出来ると思います。
プラグイン内に画像最適化用のライブラリを内包しており、php から実行するようになっています。

対応OS

Windows, Mac, Darwin, SunOS, FreeBSD, Linux

内包ライブラリ

jpegtran, jpegmini, optipng, pngout, pngquant, gifsicle

メジャーどころのものしかないので、違うライブラリを使いたい場合には別の方法を考えた方がいいでしょう。

4. データベースの最適化

WordPress の投稿・固定ページ投稿タイプでは、初期状態でリビジョン機能が有効になっています。
リビジョンは差分管理ではなく、そのままの状態をデータベースに保存しています。
例えば、リビジョン数が20あったとすると、20記事分データベースには記事として保存してある状態です。

無効化する方法もあるので、必要ない時は下記の記事を参考にしてください。

WordPressのオートセーブとリビジョン機能をプラグインを使わずに無効化する。 | webOpixel

また、そういったデータベースを最適化するためのプラグインもあります。

5. CloudFlareを使う

もう大分おなじみのCDNサービスです。10月ぐらいに Universal SSL というサービスが始まり、SSL を無料でも利用することが出来るようになりました。
( ただし、WordPress やEC-CUBEなどで利用する場合、管理画面等でリダイレクトループが発生するので、こういったプラグインを使用して下さい。 )
導入もDNSレコードを書き換えるだけで簡単にできます。
優良プランだと、画像の最適化もすることができます。


駆け足になりましたが、僕が普段対処している方法はこんな感じです。
内容の中に間違っている箇所もあるかもしれませんので、その時は指摘していただけると助かります。
次回は、Masaさんです。

WordPress の最新動向 について話しました。

jMDDv0IGyo2TOiaFmylUU07QjJcHrS-1200

お疲れ様です。

先日行われた WordFes Nagoya 2014 にて、WordPress の最新動向についてお話しました。
相変わらず緊張しまくりの発表で、途中声が震えそうになりましたが、
なんとか無事に終わり良かったです。

WordPress の最新動向について

WordPress の最新動向について、僕自身コアに貢献した経験がなく、
話す資格あるのか…という感じでした(汗)

とりあえず本番までに何かしらできればと思い、ソースコードを読みまくりましたが間に合わず….
というか、英語力がないので時間がかかりすぎました。
当分の課題は英語を学ぶことになりそうです。

WordPress のコア開発について

今回、コア開発に参加するために、開発ブログやTracなどのドキュメントにひと通り目を通しました。

地道に翻訳しながらだったので不正確な点もあったかもしれませんが、
「こんなに慎重なんだ」ということを感じました。

一つのアクションフックや、関数などを追加することに対しても
何十といったコメントがされたていたり、いろんな視点から突っ込みが入ったりしていました。

WordPress がこれだけシェアを拡大している中、それは当然のことかも知れません。
後方互換性や歴史的な事情を考慮し、コアのコードに改変を加えるのは相当大変なことだと感じました。

コア開発へ参加するために必要なこと
  • 英語
  • HTML, CSS, JavaScript, php …etc などのスキル
  • 後方互換性への知識
  • 既存のコードに至った歴史的背景

もちろん、わからない所は相談すれば誰かが答えてくれると思います。
それがオープンソースのいいところであるのは間違いありません。
しかし、それが逆にノイズとなってコア開発の足かせとなっているのかも知れないなとも思いました。

やはり、簡単ではないなと感じました。
これから修行しようと思います。

これからの WordPress について

こちらの記事が非常に参考になりました。

The Future of WordPress

というか、僕のスライドなんかより上記の記事を読むことを強くおすすめします。

WordPress を使うということ

今回このスライドを作るに当たり、WordPress に対してもっと深く学習することができました。
と同時に感じたことがあります。

俺、WordPress に依存しすぎじゃないか…

ということです。(自分が)

基本的に実案件では9割 WordPress を使用してサイトを構築しています。

コードの多くは WordPress に依存しています。

内包されている API を利用し機能を実装することはとても便利です。
でも、もし自分が WordPress を使用せずに1からその機能を実装できるかと言われたら
相当な時間がかかると思います。
そもそも学習から始まることがたくさんあるかと。

そこら辺を意識して今後も開発なり学習を進めていかないと、
気づいた時には手遅れになりそうで怖いです。
頑張ろう。

スライド内の参考URL

スライド内で紹介している参考サイトのURLを以下に書き出します。

セクション2 – 3.9, 4.0 の復習

セクション3 – 今後の開発動向

セクション4 – コア以外の開発トレンド

WP Pointer API を使って「使い方ツアー」を管理画面にさくっと導入!

-2014-05-23-0-10-37-1

以前、管理画面カスタマイズってことでアクションフックについて書きましたが、
中々まとめる時間が取れず今に至る 1shiharaT です。

一気にまとめるとすごい量になると思うので、何回かに分けて書きたいと思います。

今回は、 WP Pointer API の実装方法についてです。

初心者の方に使い方を教える一番の方法… ってなんだろう?

WordPress って、思ったより多機能です….よね。
僕のクライアントさんは企業のWeb担当者の方のような、普段は余り Web に関わらないような方が結構な数を占めます。

そんな中、デフォルトの機能に加えカスタム投稿タイプだったり、カスタムフィールドだったり、
いろいろなカスタマイズをして納品とするわけですが、
やっぱり最初は使い方を教える所から始めないといけません。

GrowGroup では、管理画面に使い方マニュアルのようなものを貼り付けていたり,
Skype でレクチャーしたり、しておりまして、最近は操作説明動画を撮影して管理画面に貼り付けていました。

でも、やはり説明出来ない所は多いですし、分からない所はやっぱり出てきます。
そんな中なんかもっといい方法ないかなーと思って色々考えていました。

よくある「ツアー形式」の使い方レクチャー

最近だと ( とは言っても結構昔かも知れませんが ) 会員登録後、自動的に始まる「使い方ツアー」なるものを見たりします。
これを WordPress で実装できたらなぁと思いまして、今回の WP Pointer にたどり着きました。

※ ちなみに、「使い方ツアー」なるイメージは下のリンク先のようなイメージです。
http://bootstraptour.com/

WP Pointer は バージョン 3.3 から搭載されている API です。
日本語での解説は高橋文樹さんの記事しか見つかりませんでした。

よくプラグインをインストールした時に見かけるかもしれません。

こういうやつ

書こうかな… と思ったら既に Gist で使えそうなコードがあったので紹介します。(手抜き)

https://gist.github.com/DevinWalker/7595475

これを元に、ちょっとだけ変更を加えました。

最初のは、1ページに1つのポインターのみ設置になっていたので、無理矢理複数設置可能にしました。
67行目から記述が始まる $adminpages という変数に配列として値を渡すことで実装できます。

// 例 
$adminpages = array(
    // 表示させたいページのスクリーンIDを指定
    'customize' => array(
        // 1ページに何個も表示させたいため、更に囲みます
        array(
            'content' => 'ポインターの内容をここに。h3 タグがタイトルとして装飾されます。',
            // ポインターを表示したい要素のセレクター
            'id' => '#menu-appearance', 
            'position' => array(
                // ポインター矢印の位置 : top left right bottom 
                'edge' => 'left',       
                // ポインターの位置     : top left right bottom 
                'align' => 'left'      
            ) ,
            // ボタンのテキスト
            'button2' => '次へ' , 
            // ボタンをクリックした時に実行する挙動
            'function' => 'window.location="' . admin_url('widgets.php?welcome_tour=2') . '";'
        ) ,
    ) ,
);


雑なコードで申し訳ないです….

まだまだ改善の余地ありまくりなので、
管理画面から内容を操作できるようにプラグイン化しますー!

WordPress の制作効率UP! 「TGM-Plugin-Activation」

今日は、ちょっとした制作効率を上げる Tips です。

普段 WordPress でサイトを制作する際に、独自に制作している内部的なテーマを使う会社も多いんじゃないかなと思います。

そこで、実際にサイトを制作する際に繰り返す作業が「プラグインのインストール」作業です。

大体、サイト制作する時に必須なプラグインって決まってきますよね? (僕だけ?)

そんな非効率な作業を今回短縮できるソフトウェアを紹介します。

TGM-Plugin-Activation

Github で公開されている TGM-Plugin-Activationというリポジトリがあります。

結構前から公開されていまして、なにができるかと言いますと….

プラグイン一括インストール & 有効化 です。

予めPHPファイルに、インストールさせたいプラグインを記述しておき、管理画面から一括インストールすることができます。

設置方法

Github で公開されていますので、zip で落としてくるなり、
フォークして自分のリポジトリ作っておいたり、なんなりと。

今回はとりあえず、zip で落としてくるパターンの設置方法を説明します。

1. テーマ内にディレクトリを作成

テーマ構成をとりあえず仮定しときます。
hogehoge というテーマの場合です。

/hogehoge/
    /assets
    /includes
    style.css
    functions.php
    index.php
    page.php
    single.php
    .....

とりあえず、テーマ内の第一階層に 「plugins」 というディレクトリを作成します。

/hogehoge/
    /assets
    /includes
    /plugins
    style.css
    functions.php
    index.php
    page.php
    single.php
    .....

2. ダウンロードしたzipファイルを解答し、先程作った「plugins」ディレクトリ内に展開

/hogehoge/
    /assets/
    /includes/
    /plugins
        /plugins/..
        /composer.json
        /README.md
        /class-tgm-plugin-activation.php
        /example.php
    style.css
    functions.php
    index.php
    page.php
    single.php
    .....

zip でダウンロードしたものを、先程作成した plugins フォルダ内に展開すると、上記のようなファイル構成になります。

3. example.php をリネームし、functions.php で読み込む

plugins フォルダ内に入っている example.php をそのままではかっこ悪いので、plugins-install.php 等にリネームします。

リネーム後、functions.php で読み込みましょう。

require get_template_directory . '/plugins/plugins-install.php';

4. plugins-install.php を編集

やっと、一括インストールしたいプラグインの情報を追加していきます。

既に、plugins-install.php には、サンプルコードが書いてありますので、それを編集していきましょう。

※ 上記ファイルは確認していないサンプルコードです。

wordpress.org にホスティングされているプラグインであれば、

http://downloads.wordpress.org//plugins/zip/[プラグインのスラッグ名].zip

がダウンロードする zipファイルまでの絶対パスとなります。

スラッグ名は、プラグインのページURLを見ればわかります。

http://wordpress.org/plugins/[ここの部分]/

5. 管理画面からインストール

管理画面の「外観」メニューに「Install Plugins」というメニューができていますので、
そこからプラグインを一括インストールします。

これで、サーバーの設定などに問題がなければ、通常のプラグインと同じようにプラグインがインストールされていきます。

長々書きましたが、出来る人だと 5分ぐらいでできるはずです。

フォークして自分用に作っておくと便利ですね。

あとがき

一応、正規のリポジトリからインストールするので、ライセンスなどは問題ないかとは思います。
どうなんでしょうか。ご意見いただけたら幸いです。

有料でテーマを配布するなんて時には使ったらまずいと思いますが、
社内で使うテーマなどのにおいての効率化には使えるんじゃないでしょうか。

WP CLI を使って自動化すれば良い話かもしれませんが、世の中そんなに黒い画面が出来る人ばかりではないので….

現場からは以上です。

力技!Json から WP Theme Customizer の設定

今回は WordPress に関する小規模なハックです。

テーマに組み込んで、ユーザーさんにテーマのカスタマイズを簡単に提供する「テーマカスタマイザー」機能ですが、設定がややこしく、コードも肥大化しがちになります。

なんで、json などから手っ取り早く設定項目かけたらなと思って、
ちょっとコードを書いてみました。

めちゃくちゃなコードと英語かも知れませんが、Gist にあげているので良かったら参考にして下さい。

上記ファイルと同じ階層に以下の形式の json ファイルを作成して渡してあげると、
無事テーマカスタマイザーに反映されます( はずです )

    "gg_general_settings": { // セクション ID
        "title" : "基本的な設定", // セクションのタイトル
        "priority" : 29, // セクションの順番
        "setting" : {
            "general_keywords" : { // 設定 ID
                "transport" : "postMessage", // js でリアルタイムに反映させる場合は "postMesage", リロードさせる場合は "refresh"
                "default" : "", // デフォルトの値
                "label" : "キーワードをカンマ区切りで入力してください。", // 項目のラベル
                "type" : "option" // 設定項目のタイプ "select","radio","option","image","color"
            }
        }
    }

でも、結局あんまり意味がなかったような……あはは
こんなこともできるんだよレベルで覚えてもらえたら嬉しいです。

次は管理画面から簡単に設定できるようなプラグイン作ります。

( 最近プラグイン作ろう作ろう詐欺になりつつある )

2014年06月11日 追記 :

WordCamp kansai 2014 2日目のコントリビューターデイにて、プラグイン化しました。

https://github.com/1shiharaT/extend-theme-customizer