サブループの場合

これや、

$query = new WP_Query( $args );
while ( $query->have_posts() ) :
  $query->the_post();
  // 記事を表示
endwhile;
wp_reset_postdata();

これを、

$my_posts = get_posts( $args );
foreach ( $my_posts as $post ) :
  setup_postdata( $post );
  // 記事を表示
endforeach;
wp_reset_postdata();

こう。

do_action( 'mytheme/subloop', $args, '記事出力テンプレート名' );

ちょっとイケてる気がしてきましたか？もちろん、これもこれだけだとシーーー……ンなので functions.php に下のような処理を書いておきます。

/**
 * Loop post objects.
 *
 * @param array|string query parameters or query string.
 * @param string $slug The slug name for the generic template.
 * @param string $name The name of the specialised template.
 */
add_action( 'mytheme/subloop', function ( $args, $slug, $name = '' ) {
  $query = new WP_Query( $args );

  while ( $query->have_posts() ) :
    $query->the_post();
    get_template_part( $slug, $name );
  endwhile;
  
　// do_action( 'mytheme/pagination', $query );

  wp_reset_postdata();
}, 10, 3 );

または…

add_action( 'mytheme/subloop', function ( $args, $slug, $name = '' ) {
  global $post;
    
  $posts = get_posts( $args );
  
  foreach ( $posts as $post ) :
    setup_postdata( $post ) ;
    get_template_part( $slug, $name );
  endforeach;
  
  wp_reset_postdata();
}, 10, 3 );

これを一回コピペしておけば、実際にループしたい場所に do_action() を書けば済みます。ちなみに wp_reset_query() は query_posts() の後処理用なので必要ありません。

まとめ

オレオレ親テーマ・フレームワークなどにこういった action の処理を忍ばせておくと、テンプレートファイルはスッキリ見通しが良くなりますね。何だったらよくあるこういうのも、

if ( function_exists( 'wp_pagenavi' ) ) wp_pagenavi();

こうすれば、

do_action( 'pagination' );

いいと思いますよ。

以上、アクションベーステーマコーディング部からの提言でした。

タームの親子関係を保持して表示する

WordPress には、階層（ツリー, 木）構造を持つデータ（オブジェクト）の親子関係を保持しつつ HTML を作成するためのクラスが用意されています。タクソノミー関連では以下のクラスがあります。

• Walker_Category
• Walker_CategoryDropdown

これらはすべて抽象クラス Walker の派生クラスです。これらのクラスを直接利用する必要は無く、各々以下の関数で利用できます。

• walk_category_tree()
• walk_category_dropdown_tree()

walk_category_* 関数に先ほどの関数で取得したタームオブジェクトの配列を渡すと、親子関係が保持された HTML（文字列）を取得できます。第3引数のオプションは省略すると Notice になるので必ず指定します。

$terms = get_the_terms( $post, 'my_taxonomy' );
if ( $terms && ! is_wp_error( $terms ) ) {
  echo walk_category_tree( $terms, 0, array(
    'use_desc_for_title' => false,
    'style' => 'list',
) );
}

<select>
<?php
$terms = wp_get_object_terms( $post->ID, 'my_taxonomy' );
if ( $terms && ! is_wp_error( $terms ) ) {
  echo walk_category_dropdown_tree( $terms, 0, array(
    'show_count' => false,
    'selected'   => 0,      // selected term id
  ) );
}
?>
</select>

ターム取得に失敗した場合（タクソノミーが存在しない等）各関数は false, array(), WP_Errorオブジェクトのいずれかを返します。取得成功を前提にしていると予期せぬ不具合に見舞われることがあるため、成否判定と必要なら例外処理を入れるようにしましょう。

全タームの親子関係を保持して表示する

リスト, ドロップダウン

get_terms() で全タームを取得して、タームの親子関係を保持して表示する と同様に … とややこしいことをしなくても、以下のビルトイン関数でできます。

• wp_list_categories( ‘title_li=&taxonomy=my_category&get=all’ )
• wp_dropdown_categories( ‘taxonomy=my_category&get=all&hierarchical=1′ )

全タームの取得には 'hide_empty' => false が慣習的に指定されがちですが 'get' => 'all' の方が意味的に良いように思います。

チェックボックス

チェックボックスの HTML も取得可能です。下記の Walker 派生クラスと専用の関数が用意されています。

• Walker_Category_Checklist
• wp_terms_checklist( int $post_id = 0, array $args = array() )

これらは wp-admin/includes/template.php 内で定義されているため、公開画面側で利用するには予めインクルードしておく必要があります。

include_once( ABSPATH . 'wp-admin/includes/template.php' );
echo '<ul>', wp_terms_checklist( get_the_ID(), 'taxonomy=my_taxonomy&checked_ontop=0'), '</ul>';

タームの並び順を好きな順番に変更する

「記事毎にタームの並び順を指定する」 term_order という情報が wp_term_relationships テーブルにあります。register_taxonomy() のオプションに 'sort' => true を指定しておいて wp_set_object_terms() に順序付けしたターム（の ID またはスラッグ）配列を渡すと term_order が設定され、wp_get_object_terms() のオプションに 'orderby' => 'term_order' を指定すると指定した順序でタームを取得できます。

register_taxonomy( 'my_taxonomy', 'my_post_type', array(
  'sort' => true,
    :
);

$terms_to_set = array( 'orange', 'melon', 'apple' );
wp_set_object_terms( $post->ID, $terms_to_set, 'my_taxonomy' );
  :

$terms = wp_get_object_terms( $post->ID, 'my_taxonomy', array(
  'orderby' => 'term_order',
  'fields' => 'names',
) );

でもこれは記事毎の並び順なので使いづらいですね。

並び順の指定にプラグインを使う

よく利用されるプラグインは以下の2つでしょうか。

• Ps Taxonomy Expander
• Category Order and Taxonomy Terms Order

Category Order and Taxonomy Terms Order は階層ありのタクソノミーのみが対象ですね、何故… いずれのプラグインも下記の私的な要望には合わないため、自作することにしました。

• wp_terms テーブルに order 用のカラムを追加したくない。
• 並び順の指定は専用ページではなく、ビルトインの一覧画面でドラッグ＆ドロップしたい。

並び順を変更するプラグインを作った

Anything Order というプラグインを作成して、Plugin Directory に登録してみました。詳しくは Anything Order の公式プラグインディレクトリ をご覧ください。Anything なのでタクソノミーだけでなく、各種投稿タイプの並び順変更にも使えます。

特長

• 以下の関数で並び順が指定した通りになります。
  • get_the_terms()
  • wp_get_post_terms()
  • wp_get_object_terms()
  • get_terms()
  • wp_list_categories()
  • wp_dropdown_categories()
  • wp_terms_checklist()
• 前項の関数で orderby の指定は不要です。指定がある場合は、並び順 → orderby指定 の順になります。
• 複数の項目をドラッグ＆ドロップして並び替えできます。
• 並び順をリセット（クリア）できます。
• 特定のタクソノミーで並び替えしたくない場合は「表示オプション」でカラムを非表示にします。
• 並び替えをするには以下の権限が必要です。
  • 投稿タイプ：’edit_others_posts’
  • タクソノミー：’manage_terms’
• プラグイン専用の設定ページはありません。
• ビルトインのテーブル構造を変更しません。

今後の予定

• ドラッグ＆ドロップで親子関係を変更したい。
• Anything なのでユーザー等（等？）の並び順も変更したいかもしれない。

ご要望・バグレポートをお待ちしてます！

• WordPress.org プラグインサポートフォーラム
• Github

まとめ

プラグインの告知がしたいだけの記事でしたが、大体のことは WordPress のビルトイン関数で何とかなるようですね。

参考

• [WordPress]サイドバーに設置したカスタム分類のターム一覧をセレクトメニューにする | tipsBear
• [WordPress]カスタムタクソノミーに親子関係（階層）を持たせ、複数選択したタームの並び順を親＞子の順番に表示する | tipsBear
• 【WordPress】記事に設定したカスタムタクソノミーのタームの並び順を好きな並び順にする方法 | ht79.info

EXEC-PHP最高 EXEC-PHP Awesome

テンプレートファイル（以下テンプレート）に PHP を書くことに慣れてくると記事本文にも PHP を書きたくなってくるという必然の欲求をズバリ解決するプラグインをネット上で礼賛する。

解説

誰もが通る道なのでいたしかたないのですが、ネット上での礼賛は炎上必至です。当該のプラグインは長らく更新されておらず、炎上をきっかけに「入力フォームにコードを書ける ＝ セキュリティリスク」ということが周知されたと思われるので、このアンチパターンを目にすることは無くなるでしょう。

ベストプラクティス

• ショートコード を使う。

参考

• 使用している WordPress Plugin | dogmap.jp
• Exec-PHP使いは要注意！メリット＜デメリット | アンドウェブ

関数キライ Function Hater

WordPress に用意されている便利な関数の数々を一切使わない。

解説

ビルトイン関数を使うのは負けだと思っているのか、単に関数の存在を知らないのか詳しい原因は不明ですが、中途半端に「PHP できますよ」というエンジニアによく見られます。以下はコーディングの例です。グローバル変数を多用するのも特徴です。

// トップページ判定
// is_home(), is_front_page() を使おう
if ( $_SERVER['REQUEST_URI'] == '/' )

// カスタム投稿タイプアーカイブ判定
// is_post_type_archive( 'info' ) を使おう
if ( $wp_query->is_archive && $wp_query->query_var['post_type'] == 'info' )

// フォームのチェック状態を設定
// checked() を使おう
<input type="checkbox" name="cb1" value="val1">

ベストプラクティス

• 車輪を使う。

オプション多過ぎ Options Hell

テーマやプラグインで可能な限りの「設定」を用意する。

解説

GUI で簡単設定できて嬉しい反面、コードでの設定や設定のインポート／エクスポートが簡単にできない場合、毎度 GUI 操作による設定に時間を取られることになります。ユーザーのためにと何でもできるようにし過ぎるのが原因ですが、まずは本当にそれをユーザーが必要としているかを考えると良いでしょう。

ベストプラクティス

• 減らす。

参考

• Getting Real: Avoid Preferences (by 37signals)
• YAGNI – Wikipedia
• KISSの原則 – Wikipedia

固定テンプレート Rage Template

デザイン・レイアウトが異なる固定ページに対して各々カスタムページテンプレートを作成し、編集画面からいちいちそのテンプレートを指定してめんどくさい固定ページ爆発しろとなる。

解説

固定ページの表示にはデフォルトで page.php などのテンプレートが使用されますが、個別にカスタムページテンプレートを指定することもできます。カスタムページテンプレートを作成するには、テンプレートの初めに下記のように PHP のコメントでテンプレート名を指定 します。

このカスタムページテンプレートは、テンプレート内に書くべき HTML や PHP が他と異なり、かつ、ひな形として複数の固定ページに適用する場合に使います。それを「デザインが違う固定ページ毎に必要」と誤解しているのがこのバッドプラクティスの原因です。
特定の1ページ専用のテンプレートを作るなら page-{ページスラッグ}.php, page-{ページID}.php といったファイル名にするだけで、編集画面から指定しなくても自動で適用されます。

ベストプラクティス

• 特定の1ページのみに適用するテンプレートは 特定ページテンプレート （適切な日本語訳求む）にする。
• スタイルの変更だけで済むなら body_class() が出力する page-id-{ID} クラスを利用する。
  ID が扱いづらいなら body_class フィルタで page-{slug} クラスを追加すれば良い。

参考

• コーポレートサイトのCMSにWordPressを使うとか言うヤツは眉唾モノ！　WP向きなサイトとそうでないサイト。CMS使い分けのコツ！ | しかたこうきブログ
• WordPressをカスタマイズするなら絶対覚えておきたいテンプレートファイルの使い方 | Webデザインレシピ

プラグイン入れ過ぎ Tons of Plugins

20個以上のプラグインをインストール・有効化してサイトを構築する。

解説

クライアントへの提案はプラグインでできることに限られ、プラグイン選定の時間が開発の大部分を占めます。過ぎたるは猶及ばざるが如し、レスポンスが著しく悪いサイトで有効化されていた各種キャッシュ系プラグインをすべてアンストールしたところ常識的なレスポンスに改善された、というネタのような実話もあります。なお、プラグイン依存度は下記のように分類されます。

ベストプラクティス

• 入れ過ぎない。

まとめ

固定テンプレートと言いたいだけのエントリですが、いかがでしたでしょうか。問題は多くの場合システムではなく使う側にあるのだと理解することが大事ですね。

ツールチップの注意点

2.2.2 のリリースで、ツールチップ・ポップオーバーの挿入方法を<body> への追加から、対象要素へ insertAfter するように変更しました。これにより z-index 問題が解決し、フォークした場合のツールチップのスタイリングやコントロールが劇的に簡単になりました。

しかしながら adjacent（子、子孫、隣接、間接）CSS セレクタ によって input グループが崩れるバグが発生したため、container オプションを追加することにしました。insertAfter で正しく機能しない場合は、このオプションで適切な要素を指定すれば解決します。

Bootstrap 3 について

バージョン2.3 は バージョン2系としては最後のリリースになります。今後の最新情報は Bootstrap 3 pull request をフォローしてください（訳注：日本語情報は、当サイトの Bootstrap 3 で何が変わるのかをまとめてみた をご覧ください）。簡単に紹介すると:

• Bootstrap 3 はモバイルファースト。
• レスポンシブファイルの分割廃止 – ひとつになるのさベイビー
• IE7 と Firefox 3.x のサポート廃止。
• グリッドはリキッド（フルード）レイアウト一本でいく。
• モーダルのレスポンシブ対応。
• サブメニュー廃止。
• カルーセルのリデザイン
• 変数名をキャメルケースからダッシュ（ハイフン）つなぎのチェインケースに変更。
• Glyphicon は画像からアイコンフォントへ変更。
• JavaScript のイベントに名前空間（ネームスペース）を指定。
• ドキュメントの再編。Scaffolding と Base CSS は CSS ページで統合。
• ギャラリーページ（Bootstrap 利用サイトのショーケース）の追加。

大事なことなので2回言いますが、我々が日々この悪ガキと格闘している様子は Bootstrap 3 pull request で確認できます。プルリクエストへのコメントや Twitter などでのフィードバックをお待ちしています。

<3,

@mdo and @fat

まとめ

両端揃えナビゲーションは、自前で実装していたので おぉ！ と思ったのですが、ドキュメントに見当たりませんでした。発見された方がいらっしゃいましたらお知らせください。

参考

• Bootstrap 2.3 released
• 2.3.0 milestone
• 2.3.0 pull request

ドキュメント

主に organization 周りのページとコードの変更。

全般

• Scaffolding と Base CSS ページを新規の CSS ページに統合。
• Mustache テンプレート から i18n タグを除く。{{_i}} {{/i}} は使わない。
• ギャラリーページを追加。
• Extend ページを削除。
• ページタイトル用の変数を追加。

ホームページ

• Retina 用にスクリーンショットを更新。
• 新しいサイト用にスクリーンショットを差替。
• 新しいギャラリーページへリンク。
• ギャラリーページにネタを追加。
• Redo の例（？）

CSS ページ

• アイコンを大きくする。

Example テンプレート

• マークアップとモバイルファーストの変更を反映。

CSS

IE7, Firefox 3.6 のサポート廃止、CSS ファイルの統合、など。

• IE7 のサポート廃止。* ハック、*zoom: 1; など IE7 用スタイルをすべて削除。
• Firefox 3.6 のサポート廃止。-moz-box-shadow やボタンのインナーパディングハックを削除。
• キャメルケースの変数名をダッシュ連結に変更。例 @bodyBackground を @body-background に変更。
• モバイルファースト。レスポンシブ関連スタイルもすべて bootstrap.css 1つにまとめる。
• @blue @orange などのセマンティックでない色変数を廃止し、@state-warning-text のような意味のある変数にする。また @black @white も廃止する。#000 #fff の方が 20% も短く、そもそも変数で変更する値ではないため。
• .border-radius() .border-*-*-radius mixin の廃止。ベンダープレフィックスが必要 なのは Android 2.1, iOS 3.2 と古いブラウザのみなので削除。各コーナー（左上、右下など）はベンダープレフィックス不要のため mixin を削除。.border-left-radius のような 1辺（2コーナー）の mixin は引き続き使用可能。
• layout.less の廃止。スタイルが2つしかなく、fluid（リキッド）コンテナは廃止（次セクション 参照）のため不要。.container のスタイルは grid.less へ移動。
• clearfix mixin の名称変更。mixin は .clear_float()、クラスは .clearfix になる。現在 LESS は mixin と同名のクラスをサポートしていないため “mixins.less にクラスは含めない” 方針によりこのような変更となった。
• .hide .show に !important を付加。どの要素でもこれらのクラスを機能させるため、より少ないコードで実現できる !important フラグを選択した。
• reset.less を廃止し、最新の Normalize にアップグレードする。normalize.less を追加することになる。印刷用スタイルやレスポンシブ画像用スタイル（reset されたスタイルを変更するだけのもの）は scaffolding.less に移動。
• .*-important を廃止して .*-danger に変更。ボタンやラベルなどの赤色のバリエーションのクラス名は .*-danger に統一する。
• 未練たらしい “TODO” が無いことを確認する。

レイアウトとグリッドシステム

グリッドシステムは1つになり、fluid をあえて指定する必要はなくなる。

• グリッドシステムのオーバーホール：デフォルトで fliud（リキッドレイアウト）
  • 今までのデフォルトの固定幅グリッドとは別に定義していた fuild グリッドシステム、コンテナ、レイアウトを廃止。
  • .row によるグリッドシステムは、ピクセル指定の幅やマージンの代わりに パーセンテージ指定や box-sizing: border-box を使う。
  • グリッドのネストをサポート。カラムは親要素のサイズに比例する。
  • オフセットもサポート。
• テーブル用グリッドクラスの廃止
  • グリッド指定する必要はない。
  • .table 要素内の .span* から float 指定を削除。
• input 用グリッドクラスの廃止
  • input 用のグリッド mixin および span クラスを廃止。
  • 新しいグリッドシステムでは input 要素はデフォルトで width: 100%;。
  • input 要素に直接クラスを指定するより、グリッドカラムに 100% 幅の input 要素を置く方が良い。
• すべての .container に width の代わりに max-width を指定することで、navbar のようなコンポーネントで起こる問題を防止できる。

文字

• @altFontFamily 変数の廃止。
• レスポンシブ時の jumbotron 用 font-size を調整。
• px の代わりに rem の使用を検討。IE8 用フォールバックで px は必要。

テーブル

• table.info クラスの廃止。
• ネスティングのためにより狭いスコープのテーブル用クラスを検討。

画像

• サムネイルスタイルの整理。
  .thumbnail と同じなので .img-polaroid を廃止。通常のインライン（または inline-block）画像には .img-thumbnail を使う。複数の要素からなるコンポーネントには .thumbnail を使う。

ボタン

不明瞭でセマンティックでないものは廃止。

• .btn-inverse の廃止。だってこれ マジで 意味わからんし。
• デフォルトのデザインを改良（外側の box-shadow 廃止）。
• disable ボタンのホバー時に background-color が変わるのを防止するためスタイルをリファイン。

フォーム

フォーム関連コントロールはデフォルトで 100% 幅。input グループをオーバーホールする。フォームステートをシンプルにする。

• input 要素のボックスモデルを変更。すべての input 要素をデフォルトで box-sizing: border-box; width: 100%; に変更。これは各自で input 要素のサイズを指定する必要があることを意味する。3.0 以前では input 要素には約220px を指定していた。
• デフォルトのデザインを改良（外側の box-shadow 廃止）。
• .input-group 用の input-prepend input-append を廃止。これらのクラスは各要素に指定する。また、ボタンを使うにはマークアップの追加が必要。
  • input やアドオンをラップする親要素に .input-group クラスを指定する。
  • テキストを prepend/append するには、.addon の代わりに　.input-group-addon を使う。
  • ボタンを prepend/append するには、その要素のクラスとして .btn の代わりに　.input-group-btn を使う。
• .form-search の廃止。
• fieldset[disabled] をサポート。disabled な fieldset 内のフォームコントロールを適切なスタイルにする。
• グリッド input の .controls-row を廃止。3.0 では input 要素が width: 100%; であり、別途 input 用グリッドを実装したくないので廃止した。代わりに標準のグリッドシステムで input 要素群を .row でラップし、個別の input を .span* のカラムにすればよい。
• .input-block-level mixin とクラスを廃止。input 要素が width: 100%; なので冗長になるため。input 要素は display: inline-block なので、block にしたい場合は個別に指定する必要がある。
• Horizontal フォーム（ラベルと input 要素が横に並ぶフォーム）はモバイルファーストになる。768px 幅未満ではラベルと input 要素が1行ずつスタックし、それ以上の幅ならフロートして横に並ぶ。
• チェックボックスとラジオボタンは div でラップする。label.checkbox の代わりに　label 内に div.checkbox が必要。これでラベルもクリッカブルになる。
• インラインのチェックボックスとラジオボタン用クラスの追加。radio.inline の代わりに label に .radio-inline クラスを指定する。インラインのチェックボックスとラジオボタンは div でラップする必要はない。
• 分割ドロップダウンと通常のドロップダウンのクラス名を分ける。
• フィールドのステート（disabled）を個々の input 要素に適用する。
• 新しいインプットグループ内でボタングループが機能するようにする（border-radius で問題あり）。
• .help-inline .help-block をリファクタリング。
• フォームコントロールのマージンを改善。現在上書きしまくっているため、フォームコントロールはデフォルトではマージン無しがいいかも。

アイコン

• フォントアイコン！PNG を廃止して Glyphicon を v1.7 @font-face にする。
• すべてのアイコンのクラスに プリフックスを追加：.glyphicon-

レスポンシブユーティリティ

• 新しいモバイルファーストのアプローチに合わせて responsive-utilities.less をリファクタリングする。
• メディアクエリーの変更をドキュメントに反映する。

ボタングループ

• ボタングループ内でドロップダウンを使えるようにリファクタリングする。
• 通常のドロップダウンを分割ドロップダウンのクラスを分ける。

ラベル、バッジ、カウンター

色々検討が必要。

• .label コンポーネントの角丸を小さくする。
• .label のサイズを親要素の font-size に合わせて自動で調整する。
• クソなので .badge を廃止。
• 色オプション無しの .counter として .badge を再実装する。OS X の Mail.app ぽくできるだけニュートラルにする。

ヒーローユニット（ジャンボトロン）

（訳注：ジャンボトロンは商標です…）。

一般的な変更

• .hero-unit から .jumbotron へクラスを変更。関連する変数も合わせて変更する。
• 見出しの font-weight を軽くする。ボールドの代わりにセミボールドを使う。

モバイルファーストスタイルの改善

• 初期状態では full-width にするか（角丸なし、など）？
• ブレークポイントごとに文字のスタイルを改善するか？

ナビゲーション

ナビゲーションバー

• .navbar-search の廃止。フォームレイアウトから .navbar-search を廃止したため。.navbar-form は生かす予定。
• navbar とサブコンポーネントのデフォルトスタイルをオーバーホール：
  • ドロップダウンメニューのキャレット（インジケーターでなくメニューとして追加されている）を廃止。ドロップダウンメニューは navbar の端に位置する。
  • 縦の分割線は navbar の高さいっぱいには拡張しない。
  • navbar の box-shadow、グラデーションを廃止。
  • 44px だった navbar の高さを モバイルでは 62px へ、デスクトップでは 50px へ変更。
• .navbar-inner の廃止。インナーの div は不要。
• 標準・インバース navbar で .btn-navbar が :hover :focus のステートを含むように変更。
• モバイルでのナビゲーションリンクのアクティブステートを変更。
• nabvar 内の非ナビゲーションリンクサポートの改善。.navbar-link が必要なのがクソ。
• nabvar 内でのフォーム・ボタンサポートの改善。スタイル上書きしまくりでクソすぎる。改善しよう。
• ドロップダウンや他のコンポーネントを扱いやすくするため、collapsed navbar の振る舞いを改善。

Navs

• BS2のサイドナビゲーションのように .nav-list のオプションをリデザインする。
• 左・右・下のタブを廃止。左・右のタブは便利だが Bootstrap のコアからは削除する。必要なら JavaScript プラグインや CSS を各自で利用されたし。
• ページネーションの親 div および中央・右のアライメントオプションを廃止。経緯は #6562 を参照。
• ナビゲーションオプションを再実装。
  • Tabs
  • Pills
  • Justify バリエーション

モーダル

• .hide が不要になりました。クラッシュを避けるためにユーティリティクラスで !important を使うようにしたため、モーダルで .hide を指定しなくて済む。現在は modals.less で直接 display: none; を指定している。3 にアップグレードする際は、既存のモーダルから .hide クラスを削除しておくこと。
• モバイルファーストのためにモーダルをリビルドする
  • fixed の代わりに相対位置を使う。
  • 内容に合わせて高さが可変となるので overflow-y: scroll; は不要。
• .modal-small .modal-large のサイズオプションを加えるか検討中。
• 縦横位置の改善。

ドロップダウン

• サブメニュー廃止。これが使われているのを見たことがないし、JavaScript でインタラクションやキーボードナビゲーションのコードを書くのはマジクソ。なので廃止。

Support for submenus—only CSS, no JS enhancements—are back in 3.0.0-wip for the time being. Still unsure if they’ll remain at launch though.

— Twitter Bootstrapさん (@twbootstrap) 2013年2月17日

サムネイル

• .thumbnails メタコンポーネントの廃止。代わりにグリッドシステムを使うこと。.thumbnail のスタイルは利用可能だが、グリッドカラムのような width を指定した親要素が必要。

カルーセル

• リデザイン！キャプション同様に前後ナビゲーションのスタイルを軽くする。
• カルーセルコントロールのマークアップを変更。 .carousel-control 内に <span class="control"> が必要です。

まとめ

クソクソ書いてますがこれは @mdo がそう書いてるためいたしかたなくです。ご了承ください。

モバイルファーストということで fluid（リキッド）レイアウトが標準というかこれのみになったことが一番大きい変更でしょうか。変数名のキャメルケースや .navbar-inner の廃止が個人的にはあいたたたですが、よりシンプルに改善されるのは良いことですね。リリースされるのを wktk しつつ、色々準備しておかなければと思いました。本家の情報が更新されたら、このページにも随時反映する予定です。

間違いや抜けなどありましたらお知らせください。ではまた。

参考

• Bootstrap 3 plans
• 
  Upcoming 3.0 changes
• Bootstrap 3 pull request

その壱 フィルターで書き換えるべし

スタイルの方は style_loader_tag というフィルターフックで link タグを書き換えることができます。

preg_replace( array( "| type='.+?'\s*|", '| />|' ), array( ' ', '>' ), $tag );

こんな感じで良さそうです。type 属性を削除するついでに />（これは何と呼ぶんでしょうか…）を > に置換しています。HTML5 的には /> でも良いのですが、無くてもいいものは無い方がいいルールに従ってシンプルに徹します。

一方、スクリプトの方は style_loader_tag に相当するフィルターが無く、タグがいきなり echo されています。困りましたね… WordPress カスタマイズ虎の巻 を読み進めましょう。

その弐 クラスを継承すべし

スクリプト関連の処理は WP_Scripts クラスが担っていて、必要になったときにこれを new したインスタンスがグローバル変数の $wp_scripts に代入されます。ということは、WP_Scripts クラスを継承して処理を書き換えてグローバル変数の $wp_scripts に突っ込めば、こちらの思うがままということになります。というわけで継承してみました。

継承ついでに header.php に html5.js の条件付きコメントを直書きしなくて済むようにしておきました。

スクリプトで条件付きコメントを使う

wp_enqueue_style() したスタイルは条件付きコメントで囲って link タグを出力することができます。wp_enqueue_styles アクションをフックして、

wp_enqueue_style( 'ie7', get_stylesheet_directory_uri() . '/css/ie7.css' );
$GLOBALS['wp_styles']->add_data( 'ie7', 'conditional', 'lte IE 7' );

とすれば、HTML ソースに、

<!--&#91;if lte IE 7&#93;>
<link rel='stylesheet' href='http://example.com/wp-content/themes/mytheme/css/ie7.css?ver=3.5' media='all'>
<!&#91;endif&#93;-->

のように出力されます。どちらかというとスクリプトの方が需要がある気がしますが、WordPress はスタイルしかサポートしていないため、上記の PM_Scripts クラスで実装しました。wp_enqueue_scripts アクションをフックして、

wp_enqueue_script( 'html5', get_stylesheet_directory_uri() . '/js/html5.js' );
$GLOBALS['wp_scripts']->add_data( 'html5', 'conditional', 'lt IE 9' );

とすれば、HTML ソースに、

<!--&#91;if lt IE 9&#93;>
<script src='http://example.com/wp-content/themes/mythemes/js/html5.js?ver=3.5'></script>
<!&#91;endif&#93;-->

のように出力されます。

IE のためだけの対応をしなくてよい未来は、もうすぐやってきますよ…きっと…

add_data() 豆知識

使う機会はあまりありませんが WP_Styles, WP_Scripts クラスの add_data() メソッドでいろいろなことができます。

$GLOBALS['wp_styles']->add_data( 'スタイルのID', 'alt', true );
        -----> link タグの rel 属性を rel='alternate stylesheet' にします

$GLOBALS['wp_styles']->add_data( 'スタイルのID', 'title', 'タイトルですよ' );
        -----> link タグに title='タイトルですよ' を追加します

$GLOBALS['wp_scripts']->add_data( 'スクリプトのID', 'data', 'JavaScript のコード' );
        -----> script タグの前にインラインでスクリプトを出力します。

wp_localize_script() 豆知識

話題がどんどんそれてますが、Ajax でポストするデータを PHP から JavaScript に渡すときに良く使う関数を紹介します。本来は wp_localize_script() の名のとおり、スクリプト内で使うテキストをローカライズするためのものだと思われます。なお、この関数は対象とするスクリプトを enqueue した後で呼ぶ必要があります。以下のように書くと、

wp_enqueue_script( 'my_script', get_stylesheet_directory_uri() . '/js/my_script.js' );

$params = array(
    'action'      => 'my_action'
  , '_ajax_nonce' => wp_create_nonce( 'my_action' )
  , 'post_id'     => $post->ID
);

wp_localize_script( 'my_script', 'my_var', array(
    'ajaxurl' => admin_url( 'admin-ajax.php' )
  , 'params'  => $params
) );

HTML ソースには以下のように出力されます。

<!--
var my_var = { json_encode() された変数の値 };
//-->

インラインの方は HTML5 ぽく CDATA を無くしてあります。これで my_script.js 内の JavaScript から my_var.ajaxurl my_var.params.action などの値を使うことができますね。

まとめ

style_loader_tag フィルターと PM_Scripts クラスの使い方は以下のとおり。ここでは link タグに付く ID も消しています。

WP_Styles, WP_Scripts, enqueue 関連は concat（enqueue された内容を連結して出力）の仕組みもあったりと、結構奥の深いつくりになっていますよ。ぜひコードを読んでみてください。
また、今回のクラスを継承してカスタマイズする方法は、適切なフックがない場合に有効なケースが多いです。覚えておいて損はないですよ。

ではまた。

get_included_files() / PHP

PHP では get_included_files() で、それまでにロードされたすべてのファイルのパスを取得することができます。これを全部表示するととんでもないことになるので、テーマディレクトリ以下のファイルのみに限定するとほぼ、欲しい結果を得られます。テーマディレクトリのパスは get_theme_root() で取得できるので、

1. get_theme_root() で始まるパスのみ抽出し、
2. パスから get_theme_root() に一致する部分を削除します。

これでロードされたテーマ関連ファイルのみを見やすく表示することができます。

全部見せスニペット

wp_footer アクションにフックしているので、footer.php で wp_footer() してください。

また、このコードでは Debug-Bar-Extender の Variable Lookup ページで確認できるようにしているため、このまま使う場合は Debug Bar とあわせてプラグインをインストール・有効化してください。

まとめ

ファイルのパスは $includeds に配列で入っているので、Debug Bar を使わずに var_dump() などでお手軽に確認することもできます。せっかくなのでこのサイトの single ページの結果を晒しておきますね。

Included Files = array (
          0 => '/pimpmysite.net/functions.php',
          1 => '/rootstrap/functions.php',
          2 => '/rootstrap/library/class-pm-rootstrap.php',
          3 => '/rootstrap/library/class-pm.php',
          4 => '/rootstrap/library/class-pm-admin.php',
          5 => '/rootstrap/library/class-pm-page.php',
          6 => '/rootstrap/library/class-pm-ogp.php',
          7 => '/rootstrap/library/class-pm-options.php',
          8 => '/rootstrap/library/class-pm-order.php',
          9 => '/rootstrap/library/class-pm-ajax.php',
          10 => '/rootstrap/library/class-pm-scripts.php',
          11 => '/rootstrap/library/class-pm-nav-menus.php',
          12 => '/rootstrap/library/class-pm-less.php',
          13 => '/rootstrap/index.php',
          14 => '/rootstrap/header.php',
          15 => '/rootstrap/parts/html.php',
          16 => '/rootstrap/parts/head.php',
          17 => '/rootstrap/parts/og.php',
          18 => '/rootstrap/parts/og-article.php',
          19 => '/rootstrap/parts/favicon.php',
          20 => '/rootstrap/parts/analytics.php',
          21 => '/rootstrap/parts/afterbody.php',
          22 => '/pimpmysite.net/parts/masthead.php',
          23 => '/pimpmysite.net/parts/navigation.php',
          24 => '/pimpmysite.net/parts/billboard.php',
          25 => '/pimpmysite.net/parts/social.php',
          26 => '/rootstrap/parts/primary.php',
          27 => '/pimpmysite.net/content.php',
          28 => '/pimpmysite.net/sidebar.php',
          29 => '/rootstrap/footer.php',
          30 => '/rootstrap/parts/colophon.php',
        )

テンプレートは「13：親テーマの index.php」です。これは Debug Bar の WP Query のページでも確認できます。

テンプレートの確認方法は色々紹介されているので参考にしてみてください。

（クエリー）テンプレートを確認する方法

• gatespace / view_template_files.php
• Reveal Template | わーどぷれすっ！
• [WordPress] 使用しているテンプレート名を取得する | memo.dogmap.jp

WordPress の便利関数

WordPress には気の利いた便利でマイナーな関数がたくさんあります。ここではさりげなく使うとカッコイイ関数をいくつか紹介します。

フィルターにお決まりの値を返す

__return_true()
__return_false()
__return_zero()
__return_empty_array()
__return_null()

add_filter( 'filter_name', '__return_true' );

current_time( $type, $gmt = 0 )

human_time_diff( $from, $to = '' )

checked( $checked, $current = true, $echo = true )
selected( $selected, $current = true, $echo = true )
disabled( $disabled, $current = true, $echo = true )

absint( $maybeint )

trailingslashit( $string )

path_join( $base, $path )

zeroise( $number, $threshold )

wp_filter_object_list( $list, $args = array(), $operator = 'and', $field = false )

セマンティックな定数

define( 'MINUTE_IN_SECONDS', 60 );
define( 'HOUR_IN_SECONDS',   60 * MINUTE_IN_SECONDS );
define( 'DAY_IN_SECONDS' ,   24 * HOUR_IN_SECONDS   );
define( 'WEEK_IN_SECONDS',    7 * DAY_IN_SECONDS    );
define( 'YEAR_IN_SECONDS',  365 * DAY_IN_SECONDS    );

in wp-includes/default-constants.php

1日を秒数で指定するときは 60 * 60 * 24 より DAY_IN_SECONDS の方がわかりやすくてカッコイイですね。

デバッグに使えるコード

WordPress コアファイルではありませんが、Debug Bar, Debug-Bar-Extender などのデバッグ用プラグインを使いこなしているとカッコイイですね。

Debug_Bar_Extender::instance()->trace_var( $value, $var_name = false )

変数の値を <pre /> 付き var_dump() で確認できます。var_dump() の代替以上の使い勝手ですよ。実際に使う場合は、プラグインが停止されていてもエラーにならないように if ( class_exists( 'Debug_Bar_Extender' ) ) で判定をしましょう。

Debug Bar 関連情報

• WordPress 開発に便利なプラグイン Debug Bar | dogmap.jp
• Debug Barプラグインをもっと有効活用してみよう！ | カクニンプラスのweb日誌

番外編

使いどころがわからない関数や不要かもしれない関数も結構あります。カッコよくないかもしれないので注意してください。

is_new_day()

is_new_day() in wp-includes/functions.php

一覧表示時（ループ中）に記事の公開日付が変わったかどうかを判定するようですが、どこからも使われていません。ちなみに the_date() 内部で関連するグローバル変数を操作していて、そこで new day 判定も直接しています。何故 is_new_day() を使わない…

まとめ

これらの他にも antispambot() size_format() ファイル操作関数など、個人的には使う機会がないですが、いざ必要となったときにあると便利な関数やコードのヒントが WordPress にはたくさんあります。ソースや Codex を眺めていると新たな発見があるかもしれませんよ。以上、全然まとめきれていませんがこの辺りで失礼します。

ではまた。

クラスの引数

PM_Schedule_Post() の引数は以下の通りです。

pubstart

string required 公開開始日時用カスタムフィールドの名前（キー）英数字推奨

pubend

string required 公開終了日時用カスタムフィールドの名前（キー） 英数字推奨

label

string optional 公開終了ステータスの表示用ラベル

まとめ

このクラスは expired という投稿ステータスを追加します。画像の例では表示用ラベルを”公開終了”にしています。

日時の指定の仕方による動作の違い：

公開開始日時のみ指定

未来日時なら予約投稿になります。過去日時なら公開済になります。

公開終了日時のみ指定

即時公開され、指定日時に公開終了になります。

公開開始日時と公開終了日時の両方指定

指定された日時の期間だけ公開になります。

イレギュラーな指定で困ったことになった場合はお知らせください！

気にしなければいいんですが

制作者が気にしなくてもお客様は気になり出したら止まりません。プラグインでメニューを消したり並び替えたりもできますが、年末なので頭の体操的にスニペットを書いてみました。これで投稿タイプを上へまとめてしまいます。

custom_menu_order フィルターで true を返すと、メニューの順序を変えるための menu_order フィルターが呼ばれるので、お好みで順序を変更します。もっとスマートに書けるよ！とかあったら教えてください。