テーマレビュー(2)

reviewテーマレビューがまた 「not-accepted」だった。3.0になってからの必須関数や非推奨関数があるため、Theme Review « WordPress Codex をよく見るように、とのこと。

必須関数で足りないのは、
・wp_nav_menu()
　グローバルナビゲーションを表示する。ハードコーディングはNG。
・comment_form()
　コメントフォームを表示する。パラメータでカスタマイズ可能。

メジャーアップデートの直後ということもあり、初心者にはつらいタイミングだったのか。くわえて英語の壁もある。スタッフの方にはお手数かけて申し訳ないけど、コツコツやろう。

jQueryクックブック

feedWordPressとは切っても切れないjQueryである。これといった参考書が見つからないままWebの情報で済ませてたところ、オライリーから真打ち登場だ。
新宿のブックファースト(コクーンタワー)で買ったところ、オライリー謹製ブックカバーが付いてきた。ちょっと嬉しいけど、表紙のイタチっぽいやつがかわいすぎちゃうからカバーはしない。(虫とか爬虫類のときに使うことにする)

jQueryでJSONPを扱う

jQueryでJSONPを扱うのに、ちょっとはまったのでメモ。

jQueryでJSONP形式のWeb APIを利用する場合は、$.ajaxか $.getJSONメソッドで処理を行う。URLパラメータに渡すcallback=? という記述がミソで、このときWeb API側がどのようなコールバックの名前を設定しようとも 自動的に function(data){ のところに返ってくる。

[sourcecode language=’php’]
$.getJSON( “http://example.com/service/?callback=?”,
null,
function(data){
// 処理
});
[/sourcecode]

さて、はまったのはWeb上に用意されているJSONP形式のファイルを扱う場合だ。データの更新頻度が少ない場合は、たまに更新される静的なJSONPファイルを扱うほうがだんぜん早い。
…ということでやってみると、ファイルの中にあらかじめコールバック(“mycallback”とする)の名前が埋め込まれているためか、上記のスクリプトではレスポンスがない。正しくは 「ない」のではなくて 別関数として function mycallback() を用意しておけば、そこに返ってくる。function(data){ へは返ってこない。当然といえば当然なのか。しかし、せっかくjQueryなんだからあくまでもスマートに記述したいのだ。いろいろやってみて以下のようなスクリプトに到達した。

[sourcecode language=’php’]
$.getJSON( “http://example.com/service/example.json?callback=?”,
null,
mycallback = function(data){
// 処理
});
[/sourcecode]

Webや書籍でこのような例が見つからない。あまりやらない方法なのかな？

テーマ再提出

WordPress.orgよりテーマ審査のレスポンスがあった。
結果は”Cannot review theme” で、つまり通過しなかった。指摘として以下の2点。

・automatic_feed_links()が非推奨API
・mb_strimwidth（）が未定義

wp-config.phpで、
[sourcecode language=’php’]
define(‘WP_DEBUG’, true);
[/sourcecode]
にして警告やエラーをチェックせよとのこと。レビュー以前の問題だ。wp-config.phpをよく見ると、「テーマおよびプラグインの開発者には、その開発環境においてこの WP_DEBUG を使用することを強く推奨します。」と記述されている。デバッグモードにすると、いろいろ警告がでてきた。
非推奨APIのautomatic_feed_links()については、自分でも 「ブラウザにフィードアイコンを表示するには」 でメモしたばかりだった。実践できてない。mb_strimwidth()は致命的なエラーだ。PHPの関数なのでどうして？と思ったら、環境設定に依存する関数らしい。自分のサーバーでは動いても、他のユーザに使ってもらおうとしたらこのようなことにも気を使う必要があるのか。テーマやプラグインを作るうえでは、基本中の基本なんだろうな。
こういうこと見直す機会にもなった。

WordPress.orgにテーマを申請

themeWordPress.orgにテーマを投稿し、ただいま審査中となっている。
業務や趣味でいくつかのテーマを作ってきたとはいえ、WordPress.orgに登録するには自分だけで使うのとは違った対応が必要になる。これまで作ったなかでも気に入っているフォトログのテーマについて、「WordPress.orgにテーマを登録する方法」を参照しながら、ちょこちょこと対応してみた。

まずは、GPLライセンス含め、テーマの概要、タグ、自己紹介をstyle.cssに明記する。それからウィジェット、ログイン有無での表示の違い、さまざまなアーカイブ表示など、ふだん自分に必要ない機能にもきっちり対応する。最後に言語対応。すべてのメッセージを英語で記述して、PoEditで作成した日本語ファイルを添付する。

ZIPに固めていざ投稿すると、すぐに警告がでた。単純なチェックはその場で行われるようだ。以下は警告された順。
(1)まず指定外のタグが記述されている。タグは決まったものからえらばなければならない。
(2)次に、<?php と<? の表記が混在している。<?php に統一せよとのこと。
(3)次に、wp_link_pages()がない。シングルページでの複数ページに対応していなかったので、修正した。
(4)さらに、visual editorが使用するCSSが定義されていない。そんなの知らなかったと思いつつ、示されたサンプルをstyle.cssに追加した。

警告はひとつづつでるので、直してはアップロードする。計5回のアップロードを繰り返したとことでようやく受理された。ほんとの審査はこれからだ。
どうなるのかなぁ…

カテゴリ別に年別アーカイブを表示するには

カテゴリ別に年別アーカイブを表示したいとの依頼があり、いろいろやってみた。
例えばプレスリリースの2010年の一覧を表示したい場合、
http://XXXXXX.jp/2010/category/release/
http://XXXXXX.jp/category/release/2010/
のようなURLで表示できると予測したものの、どちらもダメだった。前者はすべてのプレスリリースが表示されてしまい、後者は404となる。

そうこうしているうちに、
http://XXXXXX.jp/2010/?category_name=release
のURLでプレスリリースの2010年の一覧を表示することができた。

2ページ目移行は次のようなURLになる。
http://XXXXXX.jp/2009/page/2/?category_name=release

archiveせっかくパーマリンクを設定しているのにパラメータがついてしまって、ちょっとカッコ悪い。この場合テンプレートは、category-release.phpになる。年別表示をしているかどうかはis_year()で判断できる。

プラグインを使うとよいのだろうか？

シングルサイトをマルチサイトに引っ越す

いままでシングルサイトとして運営していたデータをWordPress3.0のマルチサイトとして移行するには、phpMyAdminでインポート作業を行う。
MySQLのテーブル接頭辞が以下のようになっているとして、

・移行元：wp_
・移行先(2つめのブログ)：wp_2_

移行元のwp_というテーブルが、移行先の2つめのブログとなるwp_2_というテーブルに上書きされるようにする。インポートするのはwp_options、wp_users以外のテーブル全部、と思っておけばよい(この２つは絶対に移してはいけない)。そうすれば投稿やカテゴリ、コメントなどのほかContact Form 7といったプラグインのテーブルも移行される。

さらに投稿者の再設定を行う。投稿者はwp-postsにユーザIDが入っているため、新しい環境のユーザIDに書き換える必要がある。phpMyAdminでクエリを発行して書き換える。

子テーマを作る

7/17(土)に行われたWordBench埼玉の勉強会に参加した。
アジェンタは、
・WordPress3.0のデフォルトテーマ「Twenty Ten」
・データベース負荷分散

ここで初めて知ったのは、子テーマという概念だ。あるテーマをフレームワークとして利用できるもので、3.0の新機能というわけではないものの「Twenty Ten」ベースにすることによって、3.0を最大限に生かしたテーマが作成できるとのことだ。

子テーマを作成するには、style.css冒頭のコメント部分に以下を加える。
[sourcecode language=’php’]
Template: twentyten
[/sourcecode]

twentytenというディレクトリのテーマを継承する、という意味になる。最低限このstyle.cssだけを用意すれば、子テーマとして利用可能となる。あとは、必要に応じてテンプレートやfunction.phpをオーバーライドしていけばよい。注意したいのは、function.phpの中に親テーマと同じ関数名がある場合は、子テーマの関数のみが有効になるということだ。
Twenty Tenを複製してからテーマを作る場合に比べて、将来WordPressのバージョンアップによってTwenty Tenが更新された場合に、子テーマも自動的にバージョンアップされるというメリットがある。

ひとりでは気づかないこともあるので、たまには勉強会よいな。子テーマをさっそく作ってみたい！

参考：子テーマ – WordPress Codex 日本語版

ブラウザにフィードアイコンを表示するには

feedブラウザ(FireFoxであればアドレスバーの右端)にフィードアイコンを表示するにはHTMLの<head>内に<link rel=”alternate”…>でフィードのURLを指定する。
WordPressの場合もちろん同様でもよいが、function.phpでautomatic_feed_links();を呼ぶと、自動的に<head>内に<link rel=”alternate”…>が挿入される。

WordPress3.0のデフォルトデーマを見ると、この部分は”after_setup_theme”という新しいフックを利用している。

[sourcecode language=’php’]
function my_theme_setup() {
add_theme_support( ‘automatic-feed-links’ );
}
add_action( ‘after_setup_theme’, ‘my_theme_setup’ );
[/sourcecode]

テーマでウィジェット対応

widgetいつかはWordPress.org にテーマを登録してみたい。それにはウィジェット対応が必須なため、ちょっとやってみた。
テーマでウィジェットに対応するには、widgets_init フックを利用してウィジェットを表示するエリアを登録する。functions.phpでウィジェット領域のidや、ウィジェットの前後のタグを指定する。こうしておくことで管理画面の[外観]-[ウィジェット]の設定でウィジェットを選択することができるようになる。

[sourcecode language=’php’]
function my_widgets_init() {

　　if ( function_exists(‘register_sidebar’) ){
　　　　register_sidebar( array (
　　　　　　’name’ => ‘widget-area’,
　　　　　　’id’ => ‘widget-area’,
　　　　　　’description’ => ‘Widget Area for sidebar’,
　　　　　　’before_widget’ => ‘

‘,
　　　　　　’after_widget’ => ‘

‘,
　　　　　　’before_title’ => ‘

‘,
　　　　　　’after_title’ => ‘

‘,
　　　) );
　}
}

add_action( ‘widgets_init’, ‘my_widgets_init’ );

[/sourcecode]

ウィジェットの表示はsidebar.phpで行う。以下の例では、上記で登録した’widget-area’を表示する。ウィジェットがひとつも登録されていない場合には、代替としてカテゴリーの一覧を表示する。

[sourcecode language=’php’]

if(!dynamic_sidebar(‘widget-area’)): ?>
　　

[/sourcecode]

ウィジェットはアーカイブ、タグクラウド、カレンダーなどデフォルトで用意されているほかにプラグインでも提供されている。WordPress 2.8以降ではウィジェットを簡単に作成できるクラスも提供されている。