- 赤色のリンクは、まだ日本語Codexに存在しないページ・画像です。英語版と併せてご覧ください。（詳細）
Designing Themes for Public Release
このページ「Designing Themes for Public Release」は 情報が古くなっている可能性があります。最新版（英語）も合わせてご覧ください。最新に更新してくださる協力者を求めています。
目次
WordPress はオープンソースなので、ユーザーが WordPress で行うことについて、比較的自由にまかせてきました。しかし、スタイルやテーマをコンテストに応募したり公開したりするときは、考慮すべき点がいくつかあります。テーマを公開する前に行うことについて、厳格な規則ではなく、ガイドラインがあります。
サイトの見た目を瞬時に変更できることは、とても興奮します。また自分のテーマやスタイルが皆に選ばれるなら一層興奮するでしょう。こういう素敵な経験をしたいなら、立派な作品、優れたデザインを公開する前に、知っておくべき一貫性のある事があります。
作業を知る
WordPress を使用するための主要なドキュメントである WordPress Codex には、テーマ、テーマの作成、CSS スタイリング、テンプレートタグ等についての疑問に答える情報が掲載されています。作業に取りかかる前に、WordPress の機能について良く知っておくことをお勧めします。これらについての記事の包括的リストは、テンプレートに掲載されています。
計画を立てる
デザインの可能性を考えるなら、発想の種として CSS Zen Garden をチェックしてみてください。ボランティアのデザイナーが HTML 1ページと、何百ものデザインを提供しています。HTML は変更しないで、スタイルシートのみが変更されます。デザインは非常に多岐に渡り、独創的です。CSS デザインの威力だけでなく、非常に単純な情報をアートとして創り出す創造力を目の当たりにすることでしょう。まずは計画を立てることです。
- 構造レイアウト - どんなパーツをどこへ？
- 特定の要素 - カレンダー、コメント等、どんなパーツを含めるか？
- テンプレートモジュール要素 - どのテンプレートを使用する、あるいは追加するのか？サイトマップか？ページか？特別な個別記事ページか？
- グラフィックス - どのグラフィックをどこへ？
- 配色 - 何色を使うか、どう使うか、目的があるのか単に表示のためか？
- フォント - 何種類のフォント、どんな大きさ？
- 空白 - 空白はレイアウトで重要だがどのように使用するか？
- 道程 - これらをいつどうやって行うか？
ソースを知る
テーマやスタイルをデザインするとき、HTML や CSS リファレンスを使用するでしょう。コードを追加し、PHP スクリプトを追加する場合、WordPress が正しく動作するようにするには適切なリソースが必要です。few of the resources you will need/en に、デザインを始めるのに役立つリソースをまとめています。
きちんとした WordPress テーマをデザインするには、自分が何をしているか知ることが大事です。答えがどこで手に入るかを知る必要があります。一覧をブックマーク等で保存しておいてください。後でしばしば参照するでしょうから。
まずは Default または Classic テーマから
他人が作成したテーマやスタイルシートを元にするのも良いかもしれませんが、そうしたいならば、WordPress に付属する2つのデフォルトテーマから始めるのが良いでしょう。この2つのテーマは、"Classic" と "Default" です。
なぜこの2つなのですかって？この2つは、デザイナー、テスター、テーマに関心の強い多くのユーザーによって、手を加えられてきたからです。大半が信頼できるコードであり、出発点として優れています。ここからあなたの創造を行ってください。
コアリファレンスを維持する
"default" WordPress の CSS リファレンスを削除してはいけません。
ちょっと大げさ過ぎる表現でした。デザイナーが何をしようと、適切なコードであれば構いません。ここの記述はガイドラインであり、規則ではありません。
WordPress テーマをデザインするときは、ユーザーフレンドリーであることが重要です。そのためには、テンプレートと CSS ファイル内のコードのデフォルト要素を維持すること、それらを改変しても構いませんが、コードリファレンスは削除しないことです。コードリファレンスは見えなくしても構いませんが、削除しないでください。
例えば、WordPress default テーマでは、投稿記事の著者タグ(あなたのブログで著者名をわざわざ表記する必要はないでしょう)やカレンダーを削除しました。カレンダーのコードを見ると、コメントアウト/enされています。このためユーザーがカレンダー機能を使いたい場合、使うことができます。カレンダーのスタイルもスタイルシートに残っているので、カレンダーを有効にしても見苦しくありません。
細かい部分については、ユーザーの多様な好みに対応できるようにコードを残しておいてください。
WordPress の翻訳をスムーズに行うため、_e() 関数を用いてテンプレートファイル内にタイトルやヘッダを表示するようにしてください。こうすることで、翻訳ファイルをフックしてサイトの言語に合わせてタイトルを翻訳することが容易になります。
スタイルシートを編集し、テンプレートファイルを編集する場合、<div id="header"> が残るようにしてください。単に名前が気に入らないという理由で <div id="fred"> に変えたりしないでください。4列目を追加する場合、あるいは新しい区分やクラス識別子を追加する場合は、好きな名前をつけることができます。その場合はスタイルシートとテンプレートファイルに注釈を書いてください。
スタイルシートで新しい要素へのリファレンスを追加するとき、デフォルトリファレンスから独立させ、ハイライトしたり、関連要素とグループ化される場合は注釈を加えると、利用者が理解しやすくなるでしょう。あなたの作成したスタイルコードを目立たせ、デザインの独自性を示すことにもなります。
繰り返しますが、これらはコンテストに応募する等公開を目指すデザイナーが気にかけるべきガイドラインです。自分のサイトで使うためなら自分の好きなように行っても構いません。
プラグイン再考
プラグインは、WordPress に様々な拡張機能を追加することができます。プラグインの中には、ユーザーがテーマを編集して、プラグインを呼び出すコードを追加するものがあります。プラグインがテーマに含まれる場合、ユーザーがそれらを使うかどうか決めたいこともあるでしょう。テーマはプラグインから独立しているべきであり、プラグインに依存すべきではありません。残念なことに、WordPress フォーラムで、テーマと関連するプラグインについて、多くの質問が飛び交います。プラグインを有効化あるいは無効化する方法や、テーマ中のコードについて知ろうとします。
テーマ中でプラグインをサポートしたい場合は、以下が参考になるでしょう。
- プラグインのテストをきちんと行い、様々な条件下で動作することを確実にすること。
- プラグインもしくはプラグインへのリンクを含むこと。
- テーマにプラグインをインストール／アンインストールする説明を含むこと。
- プラグインが無効化された状態でもテーマが動作するように、テンプレートタグをコーディングすること(下記参照)。
- テーマだけでなく、プラグインに関する質問もサポートする準備をしておくこと。
- テーマおよびプラグインのサイトのリンクや情報が更新された場合、最新にすること。
テンプレートファイルにプラグインタグが埋め込まれていることがあります。プラグインが有効化されていない場合、テーマを破壊したり、エラーが発生したり、読み込みできなかったりします。このため、プラグインが無効にされている場合にプラグインを検出しないようにする必要があります。
プラグインがインストールされているか調べるには、function_exists() を用いることができます。プラグインが存在するかを if (function_exists()) が調べ、存在する場合のみ使用します。もし FALSE すなわち「見つからない」場合は、プラグインタグを無視して読み込みを続けます。
<?php
if (function_exists('FUNCTION NAME')) {
FUNCTION_NAME();
}
?>
下の例では、コンテンツを印刷する関数 jal_get_shoutbox() を使用しています。
<?php
if (function_exists('jal_get_shoutbox')) {
jal_get_shoutbox();
}
?>
全てのテンプレートファイルのスタイルを作成する
WordPress 1.5 より前のバージョンでは、ページに関する作業はすべて index.php ファイルで行っていました。現在のバージョンでは、テンプレートモジュール を用いてページを構築しています。
WordPress のデフォルトテーマは、index.php, sidebar.php, single.php(カテゴリやアーカイブとは異なる個別記事), comments.php, header.php, footer.php 等を使用します。index.php のみを用いて、コメント、ヘッダー、フッター等を省いたテーマやスタイルを作成すると、デザイン上の問題が発生するかもしれません。
If WordPress がモジュール部、例えばコメントテンプレート、を見つけられなかった場合、default フォルダ内の(同名の)テンプレートを探します。もし、デザイナーがこれあのモジュールテンプレートを考慮しなかった場合、レイアウトおよびデザインがおかしくなるかもしれません。動作はするかもしれませんが、奇妙な表示になるかもしれません。これらのモジュールをすべて使用する必要はありません。index.php や single.php にヘッダーやサイドバーを含めることもできます。ただし千体だけでなく、各パーツにも注意を払ってください。
スタイルシートの構造
スタイルシートの構造のレイアウトについては、いろいろと議論されています。重要なのは、ユーザー(とデザイナー)が、スタイルシートを知って変更するために欲する／必要とする情報を見つけやすくすることです。セレクタ(スタイル識別子名)がアルファベット順であると見つけやすく、例えば #post を探すのに、順にスクロールしていけば良い、という意見があります。
しかし、テーマをデザインする場合、リンクのように異なるエレメントは、セクション間で異なる見た目になるかもしれません。そのようなとき、#post a:link を、post の中を探しますか、それともa:link の下を探しますか？post セクション内に書かれていると知らなければ、後者を探すかもしれません。
構造、リンク、リスト、見出し等の関連するエレメントをグループ化するのを好む人もいます。これは十分理に適った方法で、ユーザーにとって便利でしょう。構造を微調整する場合、例えば header の高さを変更すると、content や sidebar に影響するでしょう。スタイルシートを、真ん中から先頭や末尾へと行ったり戻ったりする代わりに、 /* Structure */ と明記されており全てのエレメントが近接しています。もし、ユーザーが、全てのリンクをもっと鮮明に変更したい場合、リンクに関する記述が一ヶ所にあるほうが望ましいでしょう。
厳密な規則があるわけではありません。自分にとってもっとも良いものをまず考えてください。それからエンドユーザーのことを考えてください。一貫した表記になるようにしてください。デザインする初期段階で方針を決め、後から再編集する手間を省くようにしてください。
詳細を考慮する
WordPress テーマを公開する場合、考慮すべき詳細がたくさんあります。いくつかを取り上げます。
一貫性のある標準的なフォント
テーマを作るとき、フォントが重要です/en。未熟なウェブデザイナーの多くは、一種類のフォントだけでテーマとスタイルを作ります。 全体のフォントスタイルが一パターンなだけでなく、本当に一種類のフォントです。ボディのスタイルタグに、以下のように書かれていることがあります。
body {margin: 0; font-family: "Trebuchet MS",
sans-serif; font-size: 1em;...}
ユーザーのコンピュータに Trebuchet が無かったらどうなるでしょうか。フォントが無いなんてのは、良く起きることです。ユーザーのコンピュータにそのフォントが泣ければ、システムのデフォルト、Arial かあるいはこれに類似した sans-serif フォントが表示されます。もしあなたがデフォルトフォントを気に入っている場合はメデタシメデタシです。誰もが持っているのですから。しかし、Trebuchet を表示したい、特定の表記のフォントを表示したい場合は、困るでしょう。
ページが表示されるときに、あなたが表示させたいフォントになるべく近いものが表示される可能性を増やすためには、以下のように、font-family を追加してください。
font-family: "Trebuchet MS", Verdana, Futura, Arial, Helvetica, sans-serif;
ブラウザは Trebuchet が見つからない場合、Verdana を探します。それもダメなら Futura (Mac systems) を、と順に探すので、すべてをカバーするはずです。
Windows システムでは良く用いられるフォントでも、Linux や Mac 等の他のコンピュータシステムで用いられないものもあることも覚えておいてください。これらの端末でも表示されるフォントを用いることも考慮してください。
テーマのフォントやデザインを決めるとき、読みやすく、目が疲れない大きさでデザインに合う フォントを選択する/enようにしてください。
コメント、コメント、コメント！
レーシングカーのフードの下から見たことがありますか？ベルとホイッスルは悪夢です。初めて、PHP、CSS あるいは HTML コードを見たときのことを覚えていますか？きっと、一瞬ヒステリーを起こしたことでしょう。テーマやスタイルを公開するとき、利用者がフードの下から見て、叫びながら部屋からでていくかもしれません。
コードへのコメント/enを付けることで、内容を理解しやすくなります。テンプレートの最初と最後にコメントすると、複数のテンプレートに跨がる DIV が理解しやすくなります。元のコードに変更を加えたとき、その箇所を示すことができます。
可能な限りコメントを付けることで、異なるセクションを見つけやすくなり、利用者が安心してテーマを利用することができます。
野心的な CSS スタイルシート
WordPress は、コードおよびスタイルファイルが妥当性があり、読みやすいように多くのタブを用いるべきであることを強調しています。World Wide Web Consortium と Web Standards Organization は、全てのウェブページが標準を満たすことを強調しています。これに取りかかるには、これらの標準について良く知っておくべきでしょう。
標準の一つは、綺麗で最適なスタイルシートと HTML コードを作ることです。WordPress コンテストはこの点に関して寛大ですが、他のウェブデザインコンテストはそうではありません。「綺麗で簡潔なコードこそが芸術である」というようなモットーの傾向があります。
基本は、公開する前にコードを綺麗にする/enことです。もちろん、妥当性の検証やいろいろなブラウザでの動作チェックが必要ですが、簡単なところから始めましょう。
コードおよびスタイルシートの空白、文字、およびビットはバイトになります。この文は約 64 バイトです。各バイトが大きくなるほど、読み込み時間も長くなります。あなたとユーザーはファイルサイズを削ることを好むでしょう。それでは、どこに帯域を無駄使いするコードが隠れているのでしょう？
たくさんインデントすることで見やすくしている場合、TAB コードが行の最後、改行の前にないかチェックしましたか？たくさん見つかるでしょう。改行の前に TAB は不要です。改行の後にあればいいのですから。しかし、どういう訳か、コードには混入しています。
コードの整頓に空白を使用するとサイズ肥大になります。TAB はほとんどのエディタで一文字とみなされますが、TAB を複製する 5 つの空白は五文字とみなされます。シングルスペースではなくダブるスペースを使用することも、コードサイズを大きくする原因です。
優れた検索／置換機能を持つエディタを使用すると、これらを素早く綺麗にし、スタイルとコードを速く読み込みできるよう最適化することができます。
凝縮し、ショートハンドを使用する
CSS ショートハンド/en を使用するのも良いでしょう。ショートハンドは必須の標準ではありませんが、コード最適化の一部といえます。一部のブラウザ、典型的には古いブラウザがショートハンドを認識できないことに注意してください。CSS ショートハンドについて知りたい方は、チュートリアル/enを参照してください。
コードの検証を忘れずに !
コードおよびスタイルは、必ず妥当性があるようにしてください。妥当とは、W3C Organization が定める "strict" 標準に合致し、各種の CSS および HTML 検査に合格することをいいます。全てのバリデータが同じチェックをするわけではありません。CSS のみをチェックするもの、HTML をチェックするもの、アクセシビリティをチェックするもの等があります。きちんとしたコードを公開するつもりなら、いくつかのバリデータでテストしてください。
妥当性の検査は、あなたのウェブページをウェブ上のテスターで調べるだけではありません。友人、親戚、同僚、通行人等にもテストしてもらいます。皆が同じということはないので、スタイルやテーマを公開する前に、他人にもテストしてもらいます。 WordPress フォーラムの自作品の告知フォーラムが用意されており、WordPress ボランティアが制作中のテーマや、問題についてチェックしたり、単にあーだこーだ言ったりします。
ウェブページやスタイルシートを検証する方法を知りたい方は、list of resources and information/enを参照してください。
CSS および HTML バグ
WordPress テーマおよびスタイルは、優れた、創造性のあるユーザーによるものです。デザインを創るときに皆が共通して頭を悩まし、適合するように時間を費やすのは、ブラウザのバグです。
Microsoft Internet Explorer で美しく表示されるように3日間を費やし、同じサイトを Firefox で見ると異なって表示されます。正しく配置されないでしょう。Opera で綺麗に表示されるようにデザインすると、Internet Explorer では、サイドバーが半分表示されないでしょう。
頭をかきむしる前に、あなただけでなく、皆がこの問題で悩んできたことを忘れないでください。以下のリソースをチェックすると、CSS、HTML およびブラウザのバグを解決する手がかりとなるでしょう。
その他
テーマやスタイルを公開するときに考慮すべきことをいくつか提示しましたが、これらは氷山の一角にすぎません。テーマに問題があった場合、ユーザーはあなたのウェブサイトで解決法を見つけるかもしれませんが、しばしば [jaforum: WordPress フォーラム] に駆け込みます。デフォルトのコードおよびスタイルリファレンスに整合していれば、ユーザーは速く解決法を得ることができます。この記事をしっかり読んで推奨する方法にしたがえば、ユーザーはフォーラムに自慢しにやってくるでしょう。
テーマをより良くデザインし、ウェブ標準に合致させ、多くのブラウザ対応にすればするほど、あなたのテーマは素晴らしいものになるでしょう。繰り返しになりますが、デザインにガイドラインはありますが、規則はありません、
テーマの宣伝
WordPress テーマの検証およびテストを行ったら、公開しても良いでしょう。
ダウンロードしやすいように、readme テキストファイル(テーマの情報や解説)を含む全てのテーマファイルを 1 つの zip ファイルにします。可能ならば、RAR, ZIP, GZIP 等の圧縮ファイルを用意し、ユーザーが選べるようにしましょう。調整のための情報、小技、プラグイン情報、その他ユーザーが知っておくべきことを readme ファイルに記載するようにしてください。
あなたのサイトに、以下のようなページを用意してリンクしてください。
- デモ、あるいはいくつかのページのスクリーンショット
- 説明
- ダウンロード用 zip ファイル
テーマについてのノートを WordPress フォーラムの テーマに投稿してください。詳細なキーワードを使うと、あなたの望むように皆が検索してくれるでしょう。あなたのテーマへのリンクとダウンロード用 zip ファイルへのリンクを記載するようにしてください。
テーマの使い方のテーマリソース(日本語ページには無い)リストをチェックして、あなたのテーマをこれらのリソースリストに追加する方法をチェックしてください。
あなたのテーマのサポートページを、あなたのサイト内に作成するのが望ましいでしょう。またテーマおよび readme ファイルにサポートページへのリンクを掲載するとユーザーにとって便利でしょう。時々フォーラムをチェックして、ユーザーが困っていないか、問題点は何かを確認し、必要ならテーマをアップデートするようにしてください。アップデートする場合は、フォーラムと Codex のテーマリストに、バージョン番号を追加してください。
最新英語版： WordPress Codex » Designing Themes for Public Release （最新版との差分）
