技術的な話題ではないのでスルーされがちですが、WordPressの本質に関わることなので、日本の開発者やユーザーの皆さんも「こういうことが起こっている」程度でもいいので、知っておき、頭の片隅にでも置いていた方がいいのでは？と思い記事にしてみました。

2つの大きな論争とは：

1. WordPressが採用しているGPLライセンスに関する論争
2. WordPress3.0に埋め込まれた”P”に関するコード

です。

なお、僕もこの2つの論争をはじめから全てフォローできているわけではありません。静まったと思ったらまた再熱したりしています。議論が交わされている場所も無数にあります。それから、僕自身はWordPressコアの開発には加わっていないので、裏事情までは知りません。幾つか英語の記事や、Trac上のチケット、そしてそれらに寄せられたコメント等を読んで、状況を大体把握できたしだいです。そこはご了承下さい。

修正（2010-10-29 00:31）：記事のタイトルの「片隅に」の「に」が抜けていたので修正しました。 thanks @naokomc

WordPressが採用しているGPLライセンスに関する論争

まず1つ目はGPL関連です。”また”GPL関連です。WordPressコミュニティーでは幾度と無く話題に上っているトピックですね。日本でもこのGPLというライセンス形態がなかなか正確に理解されず、特にWordPressの商用利用においてはハードルの1つになっているんじゃないでしょうか？日本のプレミアムテーマでも、はたしてライセンス形態をきちんと理解した上で売っているのだろうか？と思う物もあります。

GPL

改めて整理します。WordPressはGPLです。GPLのライセンス要項の1つに、そのソフトウェアがGPLの場合、そのソフトウェアのソースコードを利用したり改変したりするのは自由であるが、配布行為を行う際にはその元となったソフトウェアのライセンスを引き継がなければいけない、というのがあります。要するに、WordPressのソースを利用したり改変したりするのは利用者の自由であり、それをどのように―商用、非商用にかかわらず―利用するかはその人しだい。ただし、それを不特定多数の人に配布する場合はWordPressのライセンスであるGPLを引き継がなければいけない、ということです。

この問題、とくにテーマやプラグインにおいてこのライセンス内容をどのように解釈するかは、これまで幾度と話題に上っていますよね。英語圏では、忘れたころにこの議論が再熱、を繰り返してきたように思います。特に去年、プレミアム・テーマがポピュラーになってきたときは、（大ざっぱに言えば）「WordPressのコア開発陣及びAutomattic vs. テーマで収入を得ている人」の対決となり、これまで以上に熱い議論が交わされたと記憶しています。

プレミアム・テーマ

しかし、GPLを採用しながらも利益を上げているプレミアム・テーマが１つ、2つと増えていくと（例えばWoo Theme）、しだいにGPLを採用しているプレミアム・テーマが増えていきました。ただただテーマを売るだけでなく、手厚いサポート体制や、他の購入者との交流の場を設けたりし、付加価値を上げることにより、購入者を増やしているのです。

しかし、「これでは生活ができない」とし、かたくなにGPLを採用しないプレミアム・テーマはまだあるようで、今夏に（ちょっと言い方が悪いですが）槍玉に上がったのが非常にポピュラーなThesis。特にマット・マレンウェッグとの間で話がこじれてしまい、「法廷にもっていく」とまでマットが言い出す状況になってしまいました。Thesis側は「テーマをGPLにしてしまうと我々のビジネスがつぶれるかもしれない」と主張していました。しかし実際Woo Themeのように利益をあげつつGPLを採用しているプレミアム・テーマがあるので、その主張はあまり強いとは言えません。また、このテーマの中にはWordPressのコアのコードを流用している箇所があるらしく（と開発者の1人は語っています）、そうであればこのテーマもWP本体が採用しているGPLに則って、GPLを採用しなければいけないということになります。

更に、これまでGPLのライセンスが法廷にて争われたことがない米国の法廷にて争われたことがない（下記加筆注意）点がこの議論を大きくしていました。僕は法廷やライセンス、著作権の専門家ではないので軽々しく書けないのですが、「ならなければいけない」というのは、あくまでもフリードマンストールマンによって提唱されたGPLの中では、です。法廷で争われた実例が無いために、マット側が敗訴する可能性もある、ということです。となると、WordPressだけの問題ではなくなってくる・・・そこがこの論争の行き着く先の本質だったと思います。

修正＋加筆（2010-10-30 16:48）：はてブで指摘の有る通り、フリードマンではなくストールマンです。超ケアレスミスです、すみません…

修正＋加筆（2010-10-29 11:30）：おでさんがコメント欄にて指摘してくださった通り、2006年ドイツにてGPL違法利用の裁判（民事訴訟）があり、GPL利用違反と、GPLの法的有効性を認める判決がでていました。これはドイツ国内でのみ有効であり、米国や日本でどうなるかは分かりません。とはいえ、GPLの利用違反で訴訟される可能性はどの国でもあり、少なくともこういう事例があるという事です。参考リンク：GPLにドイツ裁判所からお墨付き – SourceForge.JP Magazine : オープンソースの話題満載

「敗訴すればGPLのみならずオープンソース関連の利用に大きな影響が出る」「勝訴しても深い傷を残すだろう」などなど、英語圏のコメントをいろいろと読んでいると、マットの主張には賛成するが、提訴は反対という意見を結構見かけました。今のこの状況が崩れるのを恐れている開発者が多いことがよくわかります。

終焉

結局どうなったか？

こりゃ法廷へ行くんじゃないかなー、と思っていた矢先、ThesisがGPLを採用することに方針転換し、危機を回避。どちらが正しいとかはさておき、事態が沈静化して、前に動き始めたのはいいことです。日本の個人・法人でプレミアム・テーマやプラグインを発売されている方々は、今一度ライセンスについて理解を深めておいて損はしないと思います。

WordPress3.0に埋め込まれたコード

二つ目の論争は、WordPressの「P」の話です。

WordPress3.0がリリースされましたが、このバージョンからcapital_P_dangit()という関数がコアの中に付け加えられました。このコードが何をするかと言うと、記事のタイトル（the_title）、記事の本文（the_content）、そしてコメントの本文（comment_text）に、間違ったスペルのWordPressが書かれていると、それを自動的に正しいスペルに修正する、というものです。（厳密にいうと、DBには間違ったまま保存され、記事として動的に出力される時に正しいスペルで表示するようfilterがかかります。）

WordPressの正しいスペルはWordPress（WとPのみ大文字）です。WordpressもwordpressもWORDPRESSもWoRdPrEssもWord Pres もWordPress（＝小さい大文字）も全て間違いです。「単なるスペルミス」と思われるかもしれませんが、WordPressは固有名詞であり、商標登録もされているので、正しいスペルで書くことは大切なことです。

実はこういうスペルミスは、ネイティブもよくやっています。単なるケアレスミスの場合もあるし、知らなかった、そんなの気にしない、等様々です。以前からよくあることで、きちんと書こうという声が過去にもあがっています。

しかし・・・

さて、このcapital_P_dangit()。スペルミスを修正してくれるこの関数は一見便利です。しかし今回はこれ関して２つの問題があり、それらが議論の対象となっています。

1つ目は技術的な問題です。

例えば記事本文内にリンクhttp://hoge.com/wordpress.jpgが貼ってあるとします。そのリンクのURLに”wordpress”と含まれてますよね。これも”WordPress”と置き換えられhttp://hoge.com/WordPress.jpgと出力されます。そうすると、そのリンクはリンク切れになってしまいます。そんなファイル名やURLを付ける人が多いか少ないかはともかく、プログラムのバグには変わりありません。

内部へのリンクであれば、この際全部書き換えて対応する手があります。しかしそれはそれで物凄く大変です。そんなことやってられない、が正直なとこでしょう。そして外部へのリンクであれば、どうにもこうにもすることはできませんよね。

2つ目はWordPressのブログソフト/CMSとしてのもっと本質的な問題です。

このcapital_P_dangit()論争に関してJustin Tadlockさんが書かれた記事に素晴らしくまとめられているのですが、要するに、我々が書いた文章をソフト側（この場合WordPress）がその出力を勝手に編集し出力してしまってよいのか？ということです。たとえそれがスペルミスであっても。これは、僕たちが書く文章をWordPressが一種の「検閲」を行っている、と解釈されてしまう恐れがあります。

さて、この論争はどうなるのか？

技術的問題に関しては、既にTrac上でチケットが切られており（#13971）、修正コードもアップされているようなので、おそらく3.1には含まれるんじゃないかと思います。

それよりも厄介なのが2つ目の問題。前述のTadlockさんも「これこそがこの議論の本質」と書いているように、今後コミュニティに深い溝を作る原因となりえるとても重要な問題です。

更に、これもまたその過程の幾つかの出来事によって、更に複雑化してるようです。色々なところで関連記事やチケット上の議論などを読むと、以下がその”出来事”：

1. WordPressは有志によってオープンソースとして開発されているにも関わらず、Trac上でチケットを切ることもなく、勝手に？トップダウンで？capital_P_dangit()が追加されていた。
2. capital_P_dangit()の技術的問題に気づいた人が3.0リリース以前に切ったチケットがスルー？保留？されたまま3.0がリリースされた。
3. このcapital_P_dangit()反対の声に対してのマットの反応が…うーん…どうもつっけんどんというか、一部の人たちは非常にエゴイスティックな発言ととったようです。

なお、上でも「一部の人たち」と書きました。いろんなとこで沢山の人たちが反対の意見を言っていますが、声を上げているユーザーはまだ全体のごく一部だと思います。認識しているけどあえて首をつっこんでいない人たちも大勢いるようです。また、意見を述べている人たちの中にも、この人は真剣に考えてレスしてるなー、と思うのもあれば、過剰に反応している人、とりあえず便乗している人、そう思われる人たちも多いと感じました。

また、一部の場においてはその議題からそれて発展していたり、ねじれたりしているようでもあります。とはいえ、ともかく、良いか悪いか「WordPressの開発はどうあるべきか」「コミュニティと開発側はどうつきあえば良いか」といったレベルにまで議論が膨らんでしまっています。

フィロソフィー

この問題、正しい悪い、ではなくコミュニティに関わる人各々のフィロソフィー（哲学）とか考え方の違いなので白黒つけるのは難しい問題じゃないでしょうか。ただWordPressの場合、そのオープン性とかコミュニティとか自由（Freedom）というフィロソフィーに共感し、使い続けてる人もいると思います。特に古くから.orgを使っている人たちには多いんじゃないでしょうか？そのため、「コミュニティーの声を無視している」と感じる人が多くなれば…もう分からないですね、その先は。

どうすればよいか

さて、日本のWordPressユーザーの方のほとんどは「いきなりフィロソフィーとか本質とか言われても・・・」だと思いますが、合ってますでしょうか？とりあえず今は次のように対応するのが良いのではと思います。

まず、こういう議論があったと頭の片隅におきつつ、3.1でリンク切れバグが解消するのを見守りましょう。そのリリースはまだ先ですが、直前になると今どうやら休戦中？の「いったんcapital_P_dangit()を削除してから最良の対応を再検討するべきだ」議論の再熱もありうるかと思いますので要注目かと。

次に、現在capital_P_dangit()が原因で何かしらの問題（リンク切れ等）を抱えている方は、capital_P_dangit()を無効にする2つの対策のうち1つを適用してください。

• プラグイン「Remove WordPress to WordPress filter」をインストールし、適用する。
• 以下のコードをfunctions.phpに記述する。

remove_filter( 'the_content', 'capital_P_dangit' );
remove_filter( 'the_title', 'capital_P_dangit' );
remove_filter( 'comment_text', 'capital_P_dangit' );

こういう非技術的な、フィロソフィーとかで議論が盛り上がるのはいかにも欧米だなぁと思います。また、そこまでWordPressが（特に米国では）浸透しているんだなぁ、とも感じさせられる議論です。テーマ作成やらスニペット、ティップスを追っかけるのも良いですが、それのみだとこういう本質的議論から生じた変更等の理解が深まらず、対応が後手後手になるかもしれません。意識しておきたいところです。

ダウンロード：ManabiTheme – IntermediateLeve ver.0.9

ManabiThemeを作成した経緯と、その特徴は、初級編の記事を参照してください。デザインの変更もありません。

中級編に追加したテンプレートファイルは以下の5つ。

• single.php
• archive.php
• page.php
• search.php
• functions.php

テーマの機能としては、サイドバーのウィジェットに対応しています。

初級編と同様に、解説をコメントで説明していますが、初級編で書かれていたコメントは一部を除いて全て削除しています。分からない箇所があれば、初級編のテンプレートファイルをもう一度参照して下さい。もちろん、中級編にて新たに追加したテンプレートタグや、逆に削除したテンプレートタグは、初級編のように解説をコメントで説明しています。

下図は前回の記事に載せたManabiTheme計画です。

[cacoo width="400" height="300" theme="cacoo" toolbar=true]https://cacoo.com/diagrams/HEFVSZjsaDKibFhJ[/cacoo]

この計画では、WordPress3.0の新機能を頭に入れていないというミスをしてしまいました。とは言うものの、ManabiThemeの中級編からWordPress3.0の新機能を取り入れるのはステップアップすぎます（笑）。その為、計画の変更は行っていません。新機能やテンプレートタグが加わっても、テーマの基礎的なところは変わっていないので、心配はありません。なお、WordPress3.0-beta2で動作確認を行っています。

ご意見及びご感想はこの記事のコメント欄にお願いします！

このManabiTheme（学びテーマ）は、「テーマを学ぶ為のテーマ」として作成しました。外部に公開するWordPressブログ用のテーマとしても使用可能ですが、それよりは、ローカル環境（XAMPP等）にてWordPressテーマを学ぶ為に使用されることを主たる目的として作成しています。

ManabiThemeを作成した経緯

去年の秋頃だったと思うんですが、@khoshinoさんが、とあるWordPressの勉強会にてこんな趣旨のつぶやきをされました。

「テーマを学ぶ為のオススメのテキストやサイトは？」

このつぶやきに反応して、僕を含めて何人かの方がオススメしたのを纏めると。

「一番良いテキストブックは良いテーマ。」

僕はWordPressのテーマを1.5系からいじっているのですが、ある程度基礎的な事が分かると、あとはダウンロードしてきたテーマのコードを読んで学びました。XHTMLとCSSも、「これは！」と思うサイトのソースを読んでましたね。

で、@khoshinoさんに「ではどのテーマが良いですか？」と聞かれて改めて気がついたのですが、最近は「勉強するならこれがいいですよっ」と１つ進められるテーマがないんですよねぇ。WordPressが多機能になるにつれ、テーマの中身が複雑化しました。例えばサイドバーのウィジット化やコメントのスレッド化です。そして、公式レポジトリにアップされるテーマの数が多くなるにつれ、テーマ作者は競うように高機能化を進めていく。例えば、管理画面から各種設定が行えたり、様々な種類のレイアウトからお好みのを選択できたり。悪くはもちろんないんですが、テーマを独学する為の教材としては敷居が高くなってしまった感は否めませんね。

ならば、それに適したテーマを作ってみよう、と思って作成したのがこのManabiThemeです。他人のソースコードを（良い意味で）盗み、学ぶのは、スキルアップに不可欠だと個人的には思います。このManabiThemeがその入り口となってもらったり、きっかけの１つになってもらったら幸いです。

ManabiThemeの特徴

幾つか特徴をご紹介いたします。

1.　解説をコメントで説明

テーマからテーマを学ぶというコンセプトなので、テーマのテンプレート・ファイルに、テンプレートタグやWordPressループの説明をコメント形式で記述してあります。ブラウザからソースを表示させても読めるよう、あえてXHTMLのコメントとして記述してあります。条件分岐に関しては、PHPのコメントとして記述してあります。

2.　ファイル数を最小限に

ファイル数はPHPのテンプレートファイルが5つ、CSSが１つ、そしてスクリーンショットのPNGが１つ。よく使うこれらファイル7つにしてあります。初級編（後述）はシンプルに、最小限で。

3.　デザインもシンプルに

このManabiThemeは、テンプレートのコードを学ぶのが主たる目的で有るため、ブログのデザインは典型的な2カラム（サイドバー左側）の、非常にシンプルなデザインとしました。コードを編集しても、その変化が分かりやすいと思います。

トップページ

タグ・アーカイブのタイトル

カテゴリ・アーカイブのタイトル

月別アーカイブのタイトル

4.　これは初級レベルです

現段階の個人的な計画としては、今後、中級レベル、上級レベルを作成して、リリースしたいと思っています。それぞれのファイルや、実装されている機能の違いについては以下の図を参照。

[cacoo width="400" height="300" theme="cacoo" toolbar=true]https://cacoo.com/diagrams/HEFVSZjsaDKibFhJ[/cacoo]

初級レベルでは、できるだけシンプルに、かつ、基本的なテーマの構造がわかるよう、幾つかの機能を実装していません。例えばウィジット。それからコメントのスレッド化。また、functions.phpを用いたテーマ独自の機能の実装や関数等も使用せず、全て標準の、そして現行（ver.2.9.2）の、WordPressのテンプレート・タグを使用しています。

なお、上図に示した、中級と上級レベルの詳細は決定ではありませんので、ご意見やご感想も踏まえつつ、作成しようと思っています。

まとめ&ダウンロード

まとめると：

ローカル環境にて、ソースコードからWordPressテーマを学ぶことを目的とした、テーマを学ぶ為のテーマ　ManabiTheme – Entry Levelです。

Versionはとりあえず、0.9にしてあります。ライセンスの方は特に何も考えて無いというか、今気がついたのですが（笑）、G.P.Lで。

ダウンロード：ManabiTheme – EntryLevel ver.0.9

ご意見及びご感想はこの記事のコメント欄にお願いします！

ファビコンを変更。

• 上部の2色のバーを秋っぽい色に変更。
• サイドバーのLatest Postsの日付をthe_date関数からthe_time関数へ修正。
• ファビコンは古いロゴを元にした画像のままだったので、新しいロゴに変更しただけです。最後にファビコンを作成したのは随分昔だったので、その時に書いた記事を元に作成（笑）。

ページ上部の2色の線は、主に十二単のかさねいろを参考にしてます。今回は秋のかさねいろから朽葉を使いました。

the_date関数からthe_time関数というのは、WPループを使ってこのように最新の記事やコメントリストを表示させた場合、the_date関数だと同じ日に投稿された記事の内ループの最初の記事しか日付が表示されないのです。修正前のスクリーンショットを見てください。

WordCamp Kyoto 2009 – Photo#3と#4の記事は、同じ10月25日に投稿されています。なので、the_date関数だと、ループで先にでてきた#3の方にしか日付が表示されません。これを解決するには、the_date関数をthe_time関数に置き換えます。そうすると、同じ日付でもきちんと投稿日が表示されます。

僕がテーマを作成したり編集・カスタマイズしたりし始めた頃に2～3度ハマったところです。皆さん、気をつけてください！（僕は今回すっかり忘れてしまってました…汗）

ちなみに、日本語版のCodexにもちゃんと書かれていますね。

テンプレートタグ/the date – WordPress Codex 日本語版

テンプレートタグ/the time – WordPress Codex 日本語版

その他には、コメントやコメント周りや…

コメント投稿周りを少し変更しました。

ちなみに今、「視覚マーケティング実践講座　～　ブログデザインで自分ブランドを魅せる」を読んでいるんですが、これはまだ実践できていないです。途中です。面白い本ですよ。ブログのデザインに悩んでいるのであれば是非。

視覚マーケティング実践講座 ブログデザインで自分ブランドを魅せる

ウジトモコ, ブログデザイン勉強会参加ブロガー / インプレスジャパン ( 2009-09-10 ) /

waviaeiのバインダーで詳細を見る

MediaMarker

これを、WP2.8から新たに加えられたテンプレート・タグbody_classに、add_filterを使って表示してやると、たとえばこんな風に：

[xhtml]<body class="home blog logged-in safari">[/xhtml]

表示されて、すごくすっきりします。と、言うティップスをHow to detect the visitor browser within WordPressにて発見。やり方は、元記事にあるコードをfunctions.phpに記述するだけ。簡単です。いまさらns4の判別が必要なのかはともかく、iphoneも判別対象になっていますね。ここらへんは日本仕様に合わせて変更できるかも。

ここでは具体的にWordPressテーマのファイルやディレクトリ構造を見ていきます。

最低限必要なテンプレート・ファイルはどれなのか？

モジュールは？

などなど、テーマの中身が分かると思います。

必要最低限のファイル

テーマとして機能する為に必要最低限なファイルが２つあります。

• style.css
• index.php

style.cssはCSSを記述するのに必要なのはもちろんの事、テーマの名称、ヴァージョン、作者名、概要、などの情報も記載されます。管理画面にて表示されるテーマ名は、このstyle.cssを参照して表示されています。言い換えれば、それらの情報がきちんと記述されたstyle.cssが無ければ、そのテーマをWordPressは認識することができません。

index.phpは 重要なテンプレート・ファイルです。全てのテンプレートをこれ１つで済ます事もできますし（まず無い！ですが）、モジュールと組み合わせる事もできます （こちらの方が普通）。ブログのトップページはもちろんの事、例えば個別記事やアーカイブの表示など、その他のページでも適用できます。状況に応じたテン プレート・ファイルがなければ、WordPressはこのindex.phpをテンプレートとして使用します。全ての基本とも言えるテンプレート・ファイルなのです。

モジュール化する

大抵の場合はモジュール化されています。これはどう言う事なのか？

「ブ ログのデザイン」でも少し書きましたが、ブログではトップページのみならず全てのブログのページで共通する部分があります。ヘッダー、サイドバー、そして フッターです、又、個別記事表示ではコメント部分もそれにあたります。以下にリストした５つのファイルはテンプレート・ファイルの中でもモジュラー・テン プレートとよばれるファイルです。

• header.php
• sidebar.php
• footer.php
• comments.php
• comments-popup.php

header.php

header.phpにはヘッダー部分を記述します。HTMLファイルでは１行目から、ヘッダーのdivの終わりまでが一般的に含まれます。ヘッダーのすぐ下に、横に並ぶメニューが有る場合は、それもheader.phpに記述しておくと便利です。

sidebar.php

sidebar.phpにはサイドバー部分を記述します。HTMLファイルでは一般的に<div id="sidebar"> </div>となっている箇所です。サイドバーは共通する部分とはいえ、ページによってはあったり無かったりする箇所もよくあります。例えば、個別記事の場合のみアフィリエイトのバナーを貼り付けたり、トップ・ページにのみ「注目記事」と言ったリストを貼り付けたり、です。これは全てsidebar.php内にて条件分岐（後で説明）を用いる事で可能です。なので、それぞれのページにあわせたサイドバーのモジュールを作る必要はありません。

footer.php

footer.phpにはフッター部分を記述します。HTMLファイルでは<div id="footer">とそれ以降の箇所です。

comments.php

comments.phpにはコメント部分を記述します。個別記事のページでは記事本文のすぐ下、投稿されたコメントのリストとコメントフォームの箇所です。

comments-popup.php

comments-popup.phpに もコメント部分を記述しますが、これはコメントとコメントフォームを別ウィンドウで（ポップアップして）開く設定にブログをしてある時に使われるモジュー ルです。ただ、この機能をオンに設定している人はほとんどいないようで、僕自身もまだ見たことがありません。その為か、テーマをダウンロードしてきても、 省略されている事が多いように思います。ちなみに、WordPressに付属してくるdefaultテーマには付いていて、もし別ウィンドウで開く設定に してあり、使用されているテーマにcomments-popup.phpが含まれていない場合は、defaultテーマのcomments-popup.phpが適用されます。

モジュールを呼び出す

さて。いくらモジュール化しても、それらを利用しなければ意味がありません。つまり、テンプレート・ファイルに読み込ませる必要があるのです。その為のテンプレート・タグが用意されています。

• <?php get_header(); ?>
• <?php get_sidebar(); ?>
• <?php get_footer(); ?>
• <?php comments_template(); ?>

これらを、例えばindex.phpなど、のテンプレート・ファイルに記述すれば良いわけです。

モジュール化の利点

本家のCodexにも記されており、一般的によく利用されているモジュー ルを５つ紹介しましたが、実は全て使う必要はありません。一切使わなくても良いし、この５つ以外にもさらにモジュールを作っても良いのです。例えば、 defaultテーマには検索フォームのみを切り出したsearchform.phpが有ります。

し かし、テンプレート・タグが用意されている４つのモジュールは使用することをオススメします。大きな利点としては、やはり管理がしやすくなる事です。 １０００行以上のコードが書かれてある１つファイルは、２００行×５ファイルの方が見やすい上に、カスタマイズもしやすいのは明らかです。そしてもう１つ は、WordPressテーマではindex.php以外にも幾つかテンプレートファイルがあります。モジュール化することで、これらの箇所を毎回コピー＆ペーストするのは面倒な作業も要りません。テンプレート・タグを記述するだけです。コピー＆ペーストミスの可能性もなくなります。

幾つかあるテンプレート・ファイル

index.phpと、モジュラー５つのテンプレート・ファイルの他に、以下の９つのテンプレート・ファイルがあります。

home.php

ブログのトップページ（つまりホーム）のテンプレートとして使用。

single.php

個別記事を表示するときのテンプレートとして使用。

page.php

WordPressのページ機能を利用して作成したページのページを表示するときのテンプレートとして使用。

category.php

特定カテゴリのアーカイブを表示するときのテンプレートとして使用。

author.php

特定の投稿者が書いた記事のアーカイブを表示するときのテンプレートとして使用。

date.php

特定の日・月・年のアーカイブを表示するときのテンプレートとして使用。

archive.php

アーカイブを表示するときのテンプレートとして使用。もしcategory.php、author.php、date.php、が有る場合そちらを優先的に使用。

search.php

検索結果を表示するときのテンプレートとして使用。

404.php

要求された記事やページが見つからない時にエラーメッセージを表示するときのテンプレートとして使用。

モ ジュールの時と同様に、これ以外にも独自のテンプレート・ファイルを作成し、使用することもできます。また、全てのテンプレート・ファイルを使用する決ま りもなく、必要なテンプレートだけを用意すればよいのです。例えば、どの状況のアーカイブでも表示の仕方が同じであれば、category.php、author.php、date.phpは必要なく、archive.phpのみ作成すればよいのです。さらに、もしもアーカイブの表示の仕方をトップページ（index.phpを使用しているとして）と同じにするとすれば、archive.phpも要りません。index.phpを使えば良いのですから。

ただ、ここに上げた９つのテンプレート・ファイルはWordPressにとって特別な意味を持つテンプレート・ファイルだと言う事は重要です。これらは、それぞれの要求がなされた時に、index.phpの代わりとして真っ先にWordPressが探すテンプレート・ファイルだからです。

WordPressの他にサーバ・インストール型のブログ・ツールを使用した事がある方は、テーマのフォルダ内を覗いただけでWordPressテーマの仕組みは大体分かるんじゃないかと思います。

ここでは、前章で述べたウェブ・スタンダードに準拠する形でコーディングされたXTHML+CSSのブログ・デザインが、どの様にテンプレート・ファイル、更にWordPressテーマと成っていくのかを追っていきます。

XHTMLからテンプレートへ（一般的な仕組み）

こ こに一般的なブログのトップページ（ホーム）が有るとします。ブログ・ツールはWordPressでも、Movable Typeでも、Serene Bachでも、何でもかまいません。ヘッダー、サイドバー、フッターがあり、コンテンツ部分には最近の記事が幾つか表示されています。このページは XHTMLでコーディングされ、外部CSSファイルによって見た目がコントロールされています。この何の変哲も無いウェブ・スタンダードな XHTML+CSSが目の前にあると思ってください。そしてCSSはいったん横に置き、XHTMLの方に注目します。

「目印」に置き換える

ブ ログでは、状況によって表示内容が変化する箇所が幾つかあります。記事のタイトル、日付、カテゴリ、タグ等はもちろんの事、トップページやアーカイブ表示 は時系列で記事が並んでいるので、新しい記事を投稿するたびに古い記事は下へ下へと移動していきます。さらに、例えばサイドバーにカテゴリの一覧をリスト 表示しているとすると、新たなカテゴリを作れば自動的にそのリスト付け加えて更新、表示してくれれば非常に便利です。

例えば、記事のタイトルと日付をXHTMLで記述すると（一般的に）下の図のようなコードになります。

これだと「test for writing a raw code」と「October 8th, 2006」のようにそのまま表示されます。そこで、これらを特別な「目印」に置き換えます。この「目印」はそれぞれ表示目的用の物があって、記事のタイト ルと、その日付ならば、それぞれ「（リクエストに）確答する記事のタイトルをこの場所に表示する為の目印」と（リクエストに）確答する記事の日付をこの場 所に表示する為の目印」になります。

「テンプレート・ファイル」と「テンプレート・タグ」

このように、残りの「状況によって表示 内容が変化する箇所」も全て「目印」に置き換えてしまいます。こうする事で「型板」と言うか、「枠組み」ができあがります。この「枠組み」こそが一般的に 言う「テンプレート・ファイル」（テンプレートと言うこともある）で、「目印」こそが「テンプレート・タグ」です。

注意！： 最近のWeb2.0ブームに乗って、記事やブックマーク等をタグで管理する手法をよく目にします。WordPressにもその機能を果たすプラグインが幾 つか有り、Ultimate Tag Warriorは非常にポピュラーです。この管理手法の「タグ」とテンプレート・タグの「タグ」は別物なので注意してください。直訳すると似たような意味 になるのは確かなのですが、使用目的は違うので別物と考えてください。

テンプレート＋データをアウトプット

ここでWordPressも含めた一般的なブログ・ツールのテンプレート・システムの流れをまとめてみます。

データとはブログのデータ、つまり、記事のタイトル、記事の日付、記事の本文、などです。

WordPressの場合

ではWordPressの場合、これらはどうなっているのでしょうか？

WordPress の場合でも、上図の流れは変わりません。ただし、ブログ・ツールによって細かな所に違いがあります。WordPressが特別と言うわけではありません。 ツールによって用いている記述方法が違っていたり、それぞれの開発者が最適だと考えているフォルダとファイル構造に違いがあったりする訳です。

テンプレート・タグの記述方法

WordPressのテンプレート・タグは、<?phpで始まり、>で終わります。例えばブログのタイトルであれば<?php wp_title(); >と記述します。

こ れを見て分かる方もいると思いますが、これはWordPressを作るのにも使われているプログラミング言語PHPの記述方法なのです。「ここから始ま り、ここで終わるよ！」と教えてあげる役割をはたしている区切り文字（スクリプティングデリミタ）はPHPのそれですし、タグの中身wp_title();もPHP関数の記述式とそっくりです。（ただしwp_title();等の中身自体はWordPress独自の物で、PHPにはありません。）

先ほどの、記事のタイトルや日付をそれぞれの「目印」に置き換える、をWordPressに当てはめるとこのようになります。

ちなみに、他のブログ・ツールではこのように記述しています。例えば、Movable Typeの区切り文字はMovableTyp独自の物です。

• WordPress: <?php ～ ?> （例：<?php wp_title(); ?>）
• Movable Type: < ～ >もしくは<$ ～ $> （例：<$MTBlogName$>）
• Nucleus: <% ～ %> （例：<%blogsetting(name)%>）
• Serene Bach: { ～ } （例：{blog_name}）

テンプレート・ファイルの拡張子

WordPressテンプレート・ファイルの拡張子は「*.php」です。（つまりPHPファイルとなるんですが・・・。）他のブログ・ツール、例えばMovable TypeはHTML、PHP、*.tplなど、色々と使えるようです。

テンプレート・ファイルの数

必要なテンプレート・ファイルの数と種類はブログ・ツールによっ てまちまちです。例えば、Serene Bachは１つのファイルをインポートするだけです。Movable Typeは状況に応じたテンプレート・ファイルが必要であり、全ての状況で共通する箇所も（基本的には）全て複製しなければなりません。

WordPressではこの重複する箇所は全てモジュールとして外部ファイルから呼び出す事ができます。また、製作者自身が独自のモジュールを作成していく事もできます。ファイル数が少ないのもあれば、多いのもあるのです。

WordPressテーマ

上図では、このページで書いたWordPressでの一連の流れをまとめてみました。そんなに複雑ではないと思います。

赤 枠で囲んだファイルたち　－　テンプレート・ファイル、CSS、画像、など　－　をまとめて１つのパッケージ（フォルダ）とした物をWordPressで はテーマ（Theme）と呼んでいます。このテーマの仕組みによって、ユーザ側はフォルダを１つアップロードする手軽さで新しいテーマを導入できますし、 製作者側としても非常に柔軟で奥の深い作り方ができるようになっています。

WordPressテーマの説明に入る前にブログで実践されるウェブ・デザインを知っておく必要があります。正直言って、WordPressテーマ をカスタマイズ、もしくは作成するにあたって重要なのはPHPよりも、XHTML+CSSでコーディングされたウェブ・スタンダードなサイトを作れるスキ ルです。（データベースからの結果を操作する、設定パネルを作る、等のよほど凝ったカスタマズでない限り。）

ここでは、WordPressテーマの構造を理解するのに必要な一般的なブログのレイアウトと、ウェブ・スタンダードとの関連性についてだけを簡単に解説します。XHTMLとCSSのスキルが足りないと感じている方は、ほかのサイトや書籍も参考にして下さい。

ブログ・デザインの定番

最 近は幾つか個性的なデザインも出てきましたが、まだまだ下の画面のようなデザインが一般的ではないでしょうか。ヘッダー（Header）とフッ ター（Footer）にサンドイッチされる形で、コンテンツ（Content）とサイドバー（Sidebar）があります。画面はWordPressの ディフォルト・テーマですが、ここではサイドバーが右に配置されています。テーマによっては、右側に表示されていたり、左右両方に表示されていたりしま す。

大抵の場合、これらの大きな「ブロック」は<div>...</div>で囲まれており、一目でそれと分かるID名（もしくはclass名）が振られています。例えば、上図にみられるようにdefaultテーマでは：

• <div id=”header”>…</div>
• <div id=”content”>…</div>
• <div id=”sidebar”>…</div>
• <div id=”footer”>…</div>

の４つです。更にこれらは<div id="page">...</div>として１つにまとめられています。普通よく目にするのはid="page"ではなくid="wrapper"、もしくはid="container"と言ったid名なのですが、役割は同じです。

構造と表現の分離

ほ とんどの（ほぼ全てと言っていいかも）ブログはXHTML+CSSでコーディングされており、WordPressも例外では有りません。構造部分は XHTMLで書かれ、「見た目」の部分はCSSによって制御されています。建物にたとえるならば、鉄筋コンクリートの骨組みはXHTML、壁紙や照明、家 具と言った装飾はCSS、と言った感じです。

先ほど「ブログ・デザインの定番」で出てきたWordPressのデフォルト・テー マもXHTML+CSSでコーディングされています。このテーマで使用されているCSSを一時的に無効にすると、下の図のように表示されます。上から順に ヘッダー、コンテンツ、サイドバー、フッターの順に書かれています。

ウェブ・スタンダード

この「構造と表現の分離」はウェブ・スタンダードの大きな柱の一つです。ウェ ブ・スタンダード（Web Standards）とは一種のガイドラインのようなもので、W3Cが策定と勧告を行っている規格に準拠した本来の正しい制作手法でウェブ・サイトを作ろ うと言う動きです。

もう１つウェブ・スタンダードの大きな概念として「構造を示すタグ付け」があります。これは表示方法を指定する為ではなく、文書中での役割を示す為にタグを使おう、と言う事です。例えば、<h1>～</h1>タグは文字のサイズを大きく見せる為ではなく、きちんと見出しとして使用する。強調する為に文字を太字にするのであれば、<b>～</b>ではなく、<strong>～</strong>を使用する。

このほかにも幾つか重要な要素（DOM、アクセシビリティ、セマンティック等など）がウェブ・スタンダードには有るのですが、ここでは省略します。

（メ モ：よくWeb Standardsは「Web標準」や「Webの標準規格」として訳される事が多いです。何か１つに決められまとめられた、つまり標準化された、規格だと 思われる方が多いようですが、そうではありません。「標準」は間違った訳ではないのですが、「Standards」は複数形であって、「１つ」ではないの です。「ガイドライン」又は「方向性を示す目印」とも言えるかもしれません。）

ウェブ・スタンダードとWordPressテーマ

ではなぜウェブ・スタンダードの事を書いたかと言うと、WordPressテーマの仕組みはウェブ・スタンダードに準拠したサイト製作が出来るように作られており、現にダウンロードできるテーマのほぼ全てはウェブ・スタンダードに（少なからず）準拠したものだからです。

もちろんテーマにはピンからキリまであり、ウェブ・スタンダードのお手本になれるような素晴らしいテーマもあれば、そうでないのもあります。しかし概ね、少なくとも僕自身が見てきた中では、最低限「構造と表現の分離」は実践されています。

状 況に応じた（動的な）表示や、WordPress本体との連携にはPHPを用いていますが、ブラウザ上で見える「見た目」に関する多くの部分はPHPでは なく、「XHTML+CSS」なのです。そして、海外では当たり前になってきている「ウェブ・スタンダード準拠」がどういう事か知っておいて損はしませ ん。「XHTML+CSS」と後述する「テンプレート・タグ」の２つが、テーマの見た目を自分好みにカスタマイズする上で最も重要な要素と言えると思いま す。

WordPressテーマのカスタマイズ方法や作成方法を求めてここにたどり着いた方には説明不要だとは思いますが、一応書いておきます。

WordPressとは？

WordPress はPHP+MySQLで構築されるコンテンツ・マネジメント・システム（CMS）で、主にサーバ・インストール型のブログ・ツールとして使用されていま す。日本での知名度と使用率はまだまだメジャーとは言えませんが、海外ではMovable Typeと人気を二分するほど有名で人気があり、一部ではMovable Typeを抜き去ったとも言われます。今年になって登場したレンタル版（登録無料）も好評で、WordPress人気にますます拍車がかかっています。

WordPressテーマとは？

WordPress テーマ（Theme）とは、WordPressで作成したブログの外観を簡単に変えられる機能です。テンプレート・ファイルやCSSファイル、画像ファイ ル等、必要なファイルが全て１つのフォルダに収められています。そのフォルダ一式をサーバにアップロードして、WordPressの管理画面から選択する だけです。

テーマによっては、管理画面から更なる細かいオプションを選択できる物もあれば、ディフォルトで様々なプラグインをサポートしている物もあります。

WordPressプラグインとは？

WordPressプラグインとは、WordPressに色々と便利な機能を付け足す事ができる機能で、ある特定の処理をするシンプルなプラグインもあれば、非常に複雑なプラグインもあります。

プラグインによっては、WordPressテーマのファイルを少し編集する必要がある物もあります。

WordPress は、ver.2からコアの機能以外はなるべくプラグインで対応する方向へ進んでいるそうです。例えば、スパム対策のAkismetや、バックアップの WordPress Database Backupはディフォルトで本体に付いてはきますが、プラグインとして機能を果たしています。なので、プラグイン探し（いじり？）はテーマ作成＆カスタ マイズと共に自分好みのWordPressブログ作りの２大要素と言えると思います。