Learning WP_Query

January 22, 2008

# 書きかけ

WordPress のいわゆる「ループ」の実体である WP_Query クラスの扱いについてよく知ろう、という趣旨です。

クエリ変数のリストを書き込むと、WP_Query により生成される SQL リクエストとその結果、さらに各種 $is_* 変数の状態を見ることができる学習用プラグイン Learning WP_Query を作りました。

ダウンロード: こちら

使い方:

  1. zip を展開してlearning-wp-query フォルダごと wp-content/plugins ディレクトリへコピー、Learning WP_Query プラグインを有効化
  2. [Options] - [Learning WP_Query] に管理ページが追加されているのでそこに移動
  3. いろいろいじってボタンを押したりしていると要領がつかめると思います

Sandbox 1.2

January 3, 2008

昨年の12月25日に Sandbox テーマのバージョン 1.2 がリリースされています。2006年8月にこのブログで紹介したときには 0.6.1 でしたがあれから大きく変わってきています。

Sandbox 1.0 での大きな変更として、それまで“スキン”と呼ばれていたスタイルシート部分の扱われ方が変わりました。1.0 以前は Sandbox のディレクトリの中にスタイルシートが置かれ、Sandbox の専用管理画面でどのスタイルシートを使用するか選択するようになっていましたが、1.0 以降ではスタイルシートを Sandbox ディレクトリの外に置くようになっています。

例えば Sandbox とそれをベースにした Sandbox Kubrick をインストールする場合、構成は

wp-content/
  |
  +- themes/
    |
    +- sandbox/
    +- sandbox-kubrick/

のように、Sandbox と Sandbox Kubrick が並列になります。

配置した後、管理画面のテーマ選択ページで Sandbox Kubrick を選択します(Sandbox を選択するのではないことに注意)。このように Sandbox は「置いておくだけ」ですが、Sandbox ベースのテーマを使う場合には必ず Sandbox も配置しておく必要があります。

Sandbox ベースのテーマ (Sandbox Kubrick) の中身はどのようになっているかというと、意味のあるファイルは style.css だけです。PHP のテンプレートなどは含まれていません。これだけでどうして Sandbox とつながるのか不思議になりますが、カギは style.css のコメント部にある TEMPLATE の行にあります。

/*
THEME NAME: Sandbox Kubrick
THEME URI: http://wordpress.org/
DESCRIPTION: Modification of the default WordPress theme, Kubrick, originally designed by Michael Heilemann.
AUTHOR: Andy Skelton
AUTHOR URI: http://andy.wordpress.com/
TEMPLATE: sandbox
*/

TEMPLATE 行が指定されていると、WordPress はテンプレート (index.php や single.php など) を指定されたテーマから継承して使うようになります。

このテンプレート継承の機能はこれまでほとんど使われることがありませんでしたが、実は現在のテーマシステムが導入された WordPress 1.5 の時点ですでに用意されていました。
Read the rest of this entry »

WordPress にはテキスト整形のための API が用意されていて、プラグインを作るときなどにはあらかじめ知っておくと重宝します。とはいえ関数が多くて把握しきれないので、自分用のメモとしてまとめてみようと思いました。

以下、WordPress 2.1.3 の wp-includes/formatting.php で定義される関数の一覧です。気が向いたときに注釈を書き足すつもりです。
Read the rest of this entry »

WordPress 2.1 ではアタッチメント(編集画面からアップロードされた画像などのファイル) 管理のための API が拡張され、それ以前と比べて格段に充実しています。アタッチメント関連のプラグイン作者向けに、WordPress 2.1 の変更ポイントや今後の方向性についてまとめました。

参考: Hitting WordPress Attachment Handling by mdawaffe
Read the rest of this entry »

WordPress 2.0 から 2.1 の間でファイルの大幅な再編成が行なわれています。通常の利用には影響はありませんが、プラグインやテーマを作るような時には関係がある場合もあるので一応把握しておいた方がよいでしょう。

特に変更の大きい wp-includes ディレクトリのファイルの移動について以下にまとめています。それぞれ WordPress Trac の Changeset にリンクしていますので経緯について知りたい場合はそちらを参照してください。
Read the rest of this entry »

Sandbox テーマ

August 17, 2006

Sandbox テーマとは

Sandbox という画期的なコンセプトのテーマが最近注目されていて、WordPress の次期デフォルト・テーマの有力候補とも目されています。

Update: 2007年12月25日に公開された Sandbox 1.2 についてこちらに書きました

従来 WordPress のテーマというのは PHP テンプレートと CSS のスタイルシートがパッケージ化されたものでしたが、Sandbox ではこれらを明確に分離して、スタイルシート部分を “スキン” という新導入のレイヤーに置き換えました。テンプレートは単一のまま、スキンは複数から選ぶことができます。ちょうど現在テーマを複数から選んでいるように、Sandbox テーマの中でスキンを選ぶことができるようになるというわけです。

従来のテーマでは PHP と CSS の両方を理解していないとテーマの中身をいじることが難しかったので、デザイン担当とコーディング担当に分業するような場合に少々都合が悪かったですが、Sandbox ではその辺がやりやすくなると思います。

単にスキンが選べるようになるだけではありません。Sandbox ではテンプレートの主要な要素の class 属性に豊富なセマンティック情報を盛り込んでいて、そのおかげで CSS のセレクタ指定の自由度が格段に高くなっています。実際に見た方が早いですが、

<body class="wordpress y2006 m08 d16 h03 single s-y2006 s-m08 s-d06 s-h10
    s-category-uncategorized s-author-admin loggedin">

例えばこの body 要素に見られるように、今表示しているページにどのような情報が含まれているかを示すかなり細かい情報がクラスとして盛り込まれます。

クラス指定の全種類とそれぞれの意味について最後に一覧でまとめています。

Sandbox は hAtom マイクロフォーマットをサポートしています。hAtom についてはまだ良くわかっていませんが、ブログやニュース記事などが持つセマンティック情報を class 属性などの形で XHTML そのものの中に埋め込む仕様のようです。この辺はもう少しわかったら詳しく書きたいと思います。
Read the rest of this entry »

翻訳ファイル作成の 3 ステップ

先日、プラグインとテーマのローカライズについて主にプラグインやテーマの開発者の視点に立って書きましたが、今度は翻訳をする人の立場で見てみたいと思います。

gettext の翻訳ファイル作成をサポートするツールはいくつかあるようですが、Windows では poEdit が使えます。poEdit の現時点での最新バージョンは 1.3.4 です。

poEdit を使った翻訳ファイル作成作業の流れは次の各段階に分かれます。

  1. ソースコードから翻訳対象のテキストを自動抜粋、.po ファイルを生成する。

    翻訳対象となるテキストは __()_e() のところなので、poEdit はソースファイルをサーチして自動で収集してくれます。生成される .po ファイルはテキストフォーマットのファイルで、次の翻訳作業で編集に使われます。

  2. .po ファイルを編集、翻訳作業を行なう。

    この段階が実際の翻訳作業です。作業は poEdit のインタフェイスから行ないますが、.po ファイルは普通のテキストファイルなので他のエディタで編集することも可能です。

  3. .po ファイルを保存、同時に .mo ファイルが生成される。

    編集した .po ファイルを保存すると同時に .mo ファイルが自動生成されます。.po は人間が読み書きするのに適したテキストファイルであるのに対して、.mo はマシンが高速に読み込むことに適したバイナリファイルです。

既に誰かが .po ファイルを公開していてそれを一部手直しして使いたいだけなら、1 を飛ばして 2 の手順から始めることになります。1 は少々ややこしいので先に 2 の説明から始めます。
Read the rest of this entry »

WordPress のローカライズの基本

WordPress には gettext を利用したローカライゼーション(多言語化、現地語化)の仕組みが組み込まれているので、必要な翻訳ファイルさえ手に入ればわずかな設定で日本語化することが可能です。

簡単に手順をまとめると、

  1. 翻訳ファイル(.mo) を入手する。日本語リソースの情報がこちらにまとめられています
  2. 翻訳ファイルを <WP_INSTALL>/wp-includes/languages/ 以下に配置する。languages というディレクトリは最初はないので自分で作る必要があります。
  3. <WP_INSTALL>/wp-config.php の
    define ('WPLANG', '');
    の行を翻訳ファイルの名前に合わせて書き換える。日本語なら翻訳ファイルが ja.mo なので
    define ('WPLANG', 'ja');
    とします。WPLANG を変更できない場合はファイル名の方を WPLANG に合わせて変更しても問題ないはずです(ja.mo ⇒ ja_UTF.mo とか)。

ところがこの手順で日本語化できるのは基本的には管理パネルの内容だけで、一般の読者が目にするオモテの部分は対象になりません。なぜかというとオモテの部分はテーマでコントロールされているので、テーマのテンプレートに含まれるテキストの日本語化がされない限りオモテは変わらないのです。プラグインについても同様で、プラグインで制御されるテキストのローカライズは個々のプラグインごとに考慮される必要があります。

それではテーマやプラグインの作者がローカライズのために考慮すべきポイントとは何でしょうか。テーマやプラグインにおいても gettext を使用してローカライズすることには変わりありません。テーマやプラグインではその内部で明示的に翻訳ファイル(.mo) をロードする必要があるわけですが、プラグインが翻訳ファイルをロードするために使うのが load_plugin_textdomain() という関数です。
Read the rest of this entry »

テーマのディレクトリ(<WP_INSTALL>/wp-content/themes/theme-name/)に置くことができるのはビジュアル・テンプレートだけではありません。ディレクトリ内に functions.php という名前のファイルを作っておくと、それが自動的にインクルードされて実行されます。

functions.php はそれを含むテーマが有効化されている場合に限定してインクルードされます。プラグインで実装されるような機能が functions.php で実現されることも良くあります。

実際の使用例を挙げると、Default テーマ (Kubrick) ではヘッダイメージの色を変更できる追加のサブメニューを導入していますが、このメニューの追加などの処理は functions.php の中で書かれています。このようにテーマ固有の機能性を盛り込むことができます。

kubrick-additional-panel.png

これほど大掛かりでなくてもテンプレート内部で複雑なロジックを記述する必要があるような場合は、それらのロジックを functions.php に移動させてテンプレートから関数として呼び出ししたほうが、テンプレートの構造がシンプルでわかりやすくなるでしょう。