当サイト、Codex 日本語版は今後積極的な更新は行わない予定です。後継となる新ユーザーマニュアルは、https://ja.wordpress.org/support/ にあります。
万が一、当サイトで重大な問題を発見した際などは、フォーラムWordSlack #docs チャンネルでお知らせください。</p>

「Designing Themes for Public Release」の版間の差分

提供: WordPress Codex 日本語版
移動先: 案内検索
(Reconsider Plugins の翻訳)
(Style ALL the Template Files 全てのテンプレートファイルのスタイルを作成する)
101行目: 101行目:
 
</pre>
 
</pre>
  
==Style ALL the Template Files==
+
==全てのテンプレートファイルのスタイルを作成する==
  
Before WordPress v1.5, it was all about the <tt>index.php</tt> file, forcing it to do all the work for every element of your page. Today's WordPress uses [[Templates|modular elements]] to make up an entire page.
+
WordPress 1.5 より前のバージョンでは、ページに関する作業はすべて <tt>index.php</tt> ファイルで行っていました。現在のバージョンでは、[[テンプレート|テンプレートモジュール]] を用いてページを構築しています。
  
The Default Theme for WordPress relies upon the <tt>index.php</tt>, <tt>sidebar.php</tt>, <tt>single.php</tt> (for a single post which looks different from the categories and archives), <tt>comments.php</tt>, <tt>header.php</tt>, and <tt>footer.php</tt>, among others. If you create a theme or style based on only the <tt>index.php</tt>, leaving out the comments, header, footer, or others, you may run into design problems.
+
WordPress のデフォルトテーマは、<tt>index.php</tt>, <tt>sidebar.php</tt>, <tt>single.php</tt>(カテゴリやアーカイブとは異なる個別記事), <tt>comments.php</tt>, <tt>header.php</tt>, <tt>footer.php</tt> 等を使用します。<tt>index.php</tt> のみを用いて、コメント、ヘッダー、フッター等を省いたテーマやスタイルを作成すると、デザイン上の問題が発生するかもしれません。
  
If WordPress can't "find" the modular part, such as the comment template, it will look for it in the default folder. Therefore, if the designer hasn't taken this modular template into consideration, the layout and design might be a little messed up. It will work, but it could look weird. You don't have to use all the various bits and pieces, keeping the header and sidebar inside of the <tt>index.php</tt> or <tt>single.php</tt>, but do look at the parts as well as the whole.
+
If WordPress がモジュール部、例えばコメントテンプレート、を見つけられなかった場合、default フォルダ内の(同名の)テンプレートを探します。もし、デザイナーがこれあのモジュールテンプレートを考慮しなかった場合、レイアウトおよびデザインがおかしくなるかもしれません。動作はするかもしれませんが、奇妙な表示になるかもしれません。これらのモジュールをすべて使用する必要はありません。<tt>index.php</tt> <tt>single.php</tt> にヘッダーやサイドバーを含めることもできます。ただし千体だけでなく、各パーツにも注意を払ってください。
  
* [[Template_Hierarchy|WordPress Template Hierarchy]]
+
* [[テンプレート階層]]
 
* [[Conditional_Tags|WordPress Conditional Tags]]
 
* [[Conditional_Tags|WordPress Conditional Tags]]
 
* [[The_Loop|The WordPress Loop]]
 
* [[The_Loop|The WordPress Loop]]
* [[Templates|WordPress Templates]]
+
* [[テンプレート]]
* [[Theme Development]]
+
* [[テーマの作成]]
  
===Style Sheet Structure===
+
===スタイルシートの構造===
  
There is a lot of debate about how to layout the structure of a CSS style sheet.  The key to the layout is how to make it easier for users (and designers) to find the information they want and need, for information and to make modifications.  Some say that an alphabetical order of the Selectors (names of the style identifiers) makes it easy so that if you are looking for <tt>#post</tt> you just scroll towards the bottom of the page.
+
CSS スタイルシートの構造のレイアウトについては、いろいろと議論されています。重要なのは、ユーザー(とデザイナー)が、スタイルシートを知って変更するために欲する/必要とする情報を見つけやすくすることです。セレクタ(スタイル識別子名)がアルファベット順であると見つけやすく、例えば <tt>#post</tt> を探すのに、順にスクロールしていけば良い、という意見があります。
  
Yet, if you are designing a Theme, different elements, like links, may have a different look between sections.  So would you naturally look for the <tt>#post a:link</tt> in <tt>post</tt> or under <tt>a:link</tt>?  If you didn't know it was in the <tt>post</tt> section, you would look in the latter area.
+
しかし、テーマをデザインする場合、リンクのように異なるエレメントは、セクション間で異なる見た目になるかもしれません。そのようなとき、<tt>#post a:link</tt> を、<tt>post</tt> の中を探しますか、それとも<tt>a:link</tt> の下を探しますか?<tt>post</tt> セクション内に書かれていると知らなければ、後者を探すかもしれません。
  
Some people prefer to group their related selector elements together such as structure, links, lists, headings, and so on.  This makes a lot of sense and is helpful to the user.  If they are tweaking the structure, for example, any change to the <tt>header</tt> height will impact the <tt>content</tt> and <tt>sidebar</tt>.  Instead of bouncing up and down the page from middle to top to bottom, all of the elements would be close to each other, preferably identified as <tt>/* Structure */</tt> in the style sheet.  If the user wanted to change the look of all of the links to make them more vibrant, then all the links would be together in one place.
+
構造、リンク、リスト、見出し等の関連するエレメントをグループ化するのを好む人もいます。これは十分理に適った方法で、ユーザーにとって便利でしょう。構造を微調整する場合、例えば <tt>header</tt> の高さを変更すると、<tt>content</tt> <tt>sidebar</tt> に影響するでしょう。スタイルシートを、真ん中から先頭や末尾へと行ったり戻ったりする代わりに、 <tt>/* Structure */</tt> と明記されており全てのエレメントが近接しています。もし、ユーザーが、全てのリンクをもっと鮮明に変更したい場合、リンクに関する記述が一ヶ所にあるほうが望ましいでしょう。
  
There are no hard and fast rules about this.  Consider what works best for you and then what may work best for the end user.  Keep your presentation consistent.  Make a plan on how you want to do this early on in your designing so you won't spend so much time rearranging things later.
+
厳密な規則があるわけではありません。自分にとってもっとも良いものをまず考えてください。それからエンドユーザーのことを考えてください。一貫した表記になるようにしてください。デザインする初期段階で方針を決め、後から再編集する手間を省くようにしてください。
  
 
==Consider the Details==
 
==Consider the Details==

2009年2月12日 (木) 16:01時点における版

このページ「Designing Themes for Public Release」は未翻訳です。和訳や日本語情報を加筆してくださる協力者を求めています

WordPress はオープンソースなので、ユーザーが WordPress で行うことについて、比較的自由にまかせてきました。しかし、スタイルやテーマをコンテストに応募したり公開したりするときは、考慮すべき点がいくつかあります。テーマを公開する前に行うことについて、厳格な規則ではなく、ガイドラインがあります。

サイトの見た目を瞬時に変更できることは、とても興奮します。また自分のテーマやスタイルが皆に選ばれるなら一層興奮するでしょう。こういう素敵な経験をしたいなら、立派な作品、優れたデザインを公開する前に、知っておくべき一貫性のある事があります。

Get Familiar With the Process

WordPress を使用するための主要なドキュメントである WordPress Codex には、テーマ、テーマの作成、CSS スタイリング、テンプレートタグ等についての疑問に答える情報が掲載されています。作業に取りかかる前に、WordPress の機能について良く知っておくことをお勧めします。これらについての記事の包括的リストは、テンプレート に掲載されています。

計画を立てる

デザインの可能性を考えるなら、発想の種として CSS Zen Garden をチェックしてみてください。ボランティアのデザイナーが HTML 1ページと、何百ものデザインを提供しています。HTML は変更しないで、スタイルシートのみが変更されます。デザインは非常に多岐に渡り、独創的です。CSS デザインの威力だけでなく、非常に単純な情報をアートとして創り出す創造力を目の当たりにすることでしょう。まずは計画を立てることです。

NuclearMoose によると、有名な WordPress 支持者の1人が、コンピュータを用いない基礎ツールで計画をたてました。

I have some tips...paper, pencil, sticky notes, and pencil crayons. "Whazzat for?" you ask? I'll tell you.

I use the sticky notes to represent a piece, chunk, module, or section of the page. (Use your own appropriate term.) I write "Links" and "Navigation" etc. on them and set them on a blank piece of paper. That way, I can easily move around the elements as I like, finding something that looks balanced. I even cut some of them to size to more closely represent their actual proportion on a page.

After I get something I like, I will sketch it out with more detail. Often I will colour things to try out various colour combos. Actually, I just like colouring, but I don't want my kids to think I'm colouring for fun...this is serious stuff!

I write down all of the things I want to include in the site on a piece of paper. Then I plan out each part of it, making notes about fonts, alignments, plugins that may be needed, background images, or other artwork/graphics that I may want.

At the end of all this process, I have a pretty good handle of how I want things to look, as well as how it should be structured. I can start gathering all of the assets for the site (images, plugins, etc.) and begin to think about coding.

In other words, there's a fair bit of non-computer-related work up front. I've found that this helps me a lot when starting the actual "construction" of the site since I'm not sitting in front of my 'puter with a blank screen in front of me, being taunted by that damn cursor blinking, blinking, blinking...

Oh yeah, it doesn't hurt to have a CSS pocket reference or some other favourite CSS resource material handy so that you don't do silly things like *cough* use deprecated attributes *cough* on some of your elements.

Once you get tired of all the work, you can invite your kids to come and help Dad colour the web site and spend some quality time together.

Couldn't have explained it any better. Your plan should include:

  • Structural layout - Where do all the parts go?
  • Specific Elements - Will you have a calendar, comments, what parts will you include?
  • Template Modular Elements - Which templates will you use or add? Site map? Pages? A distinctly different single post page?
  • Graphics - What graphics should go where?
  • Colors - How many, how are they used, do they have a purpose or are just for show?
  • Fonts - How many and what sizes go where?
  • Space - Space is an important part of layout so how will you use space?
  • Itinerary - How and when are you going to do all this?

Know Your Sources

As you design your Theme or style, you will be using HTML and CSS references. Decide to get into the code and add some PHP, you need to have the right resources to dig into and get the information right to make your WordPress website sing. We've put together a few of the resources you will need to become very familiar with over time to help you get started.

Part of designing a solid WordPress Theme is to know what you are doing. This means, you have to know where to get the answers. Keep that list handy, bookmarked or saved to your hard drive. You'll refer to it often.

まずは Default または Classic テーマから

他人が作成したテーマやスタイルシートを元にするのも良いかもしれませんが、そうしたいならば、WordPress に付属する2つのデフォルトテーマから始めるのが良いでしょう。この2つのテーマは、"Classic" と "Default" です。

なぜこの2つなのですかって?この2つは、デザイナー、テスター、テーマに関心の強い多くのユーザーによって、手を加えられてきたからです。大半が信頼できるコードであり、出発点として優れています。ここからあなたの創造を行ってください。

コアリファレンスを維持する

"default" WordPress CSS リファレンスを削除してはいけません。

ちょっと大げさ過ぎる表現でした。デザイナーが何をしようと、適切なコードであれば構いません。ここの記述はガイドラインであり、規則ではありません。

WordPress テーマをデザインするときは、ユーザーフレンドリーであることが重要です。そのためには、テンプレートCSSファイル内のコードのデフォルト要素を維持すること、それらを改変しても構いませんが、コードリファレンスは削除しないことです。コードリファレンスは見えなくしても構いませんが、削除しないでください。

例えば、WordPress default テーマでは、投稿記事の著者タグ(あなたのブログで著者名をわざわざ表記する必要はないでしょう)やカレンダーを削除しました。カレンダーのコードを見ると、コメントアウトされています。このためユーザーがカレンダー機能を使いたい場合、使うことができます。カレンダーのスタイルもスタイルシートに残っているので、カレンダーを有効にしても見苦しくありません。

細かい部分については、ユーザーの多様な好みに対応できるようにコードを残しておいてください。

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.phpsingle.php にヘッダーやサイドバーを含めることもできます。ただし千体だけでなく、各パーツにも注意を払ってください。

スタイルシートの構造

CSS スタイルシートの構造のレイアウトについては、いろいろと議論されています。重要なのは、ユーザー(とデザイナー)が、スタイルシートを知って変更するために欲する/必要とする情報を見つけやすくすることです。セレクタ(スタイル識別子名)がアルファベット順であると見つけやすく、例えば #post を探すのに、順にスクロールしていけば良い、という意見があります。

しかし、テーマをデザインする場合、リンクのように異なるエレメントは、セクション間で異なる見た目になるかもしれません。そのようなとき、#post a:link を、post の中を探しますか、それともa:link の下を探しますか?post セクション内に書かれていると知らなければ、後者を探すかもしれません。

構造、リンク、リスト、見出し等の関連するエレメントをグループ化するのを好む人もいます。これは十分理に適った方法で、ユーザーにとって便利でしょう。構造を微調整する場合、例えば header の高さを変更すると、contentsidebar に影響するでしょう。スタイルシートを、真ん中から先頭や末尾へと行ったり戻ったりする代わりに、 /* Structure */ と明記されており全てのエレメントが近接しています。もし、ユーザーが、全てのリンクをもっと鮮明に変更したい場合、リンクに関する記述が一ヶ所にあるほうが望ましいでしょう。

厳密な規則があるわけではありません。自分にとってもっとも良いものをまず考えてください。それからエンドユーザーのことを考えてください。一貫した表記になるようにしてください。デザインする初期段階で方針を決め、後から再編集する手間を省くようにしてください。

Consider the Details

There are a lot of details that have to be taken into consideration when designing your WordPress Theme for public release. Here are a few to consider.

Consistent and Standard Fonts

As you work your Theme, fonts play a critical part in the design. Many inexperienced web page designers present themes and styles with only one font. Not just an overall font style for the whole page but ONE font. In the body style tag it may say:

body {margin: 0; font-family: "Trebuchet MS", 
sans-serif; font-size: 1em;...}

What happens if the user doesn't have Trebuchet on their computer? It happens every day. If that font isn't on the user's computer, the system default shows up which is often Arial or some similar sans-serif font. If you like the look, great, because just about everyone has it, but if you want Trebuchet and you really want your fonts to have a specific look, then you have a problem.

To increase the chances of a font similar to the one you really want showing up on the page when it displays, add more choices to the font-family like this:

font-family: "Trebuchet MS", Verdana, Futura, Arial, Helvetica, sans-serif;

If the browser can't find Trebuchet, it looks for Verdana, and if can't find that, it looks for Futura (Mac systems), and so on. That should cover all your bases.

Also remember that while there are some fonts which are common on Windows systems, there are other computer systems out there like Linux and Mac. Consider using fonts that will also work on their machines, too.

As you choose your fonts and design your Theme, make sure you choose fonts that are readable and easy -to-read, keeping font-sizes large to avoid eye-strain yet sized to fit within your design.

Comment Comment Comment

Have you looked under the hood of a racing car lately? The bells and whistles inside are a nightmare to figure out. Remember the first time you looked at PHP, CSS, or HTML code? Bet that gave you a few moments of hysteria. When you are releasing your Themes and styles to the public, remember the user may take a peek under the hood and run screaming from the room, too.

Comments are part of code that helps the designer and the user figure out what is what. Comments help users identify DIVs that cross templates, when a template begins and ends, and any changes that indicate you, the designer, has modified something that makes it different from the original code.

Help your users by commenting as much as possible to helps them find the different sections and use your Theme with ease.

Lean and Mean CSS Style Sheet

WordPress stresses that code and style files should validate and be laid out with a lot of tabs so they are easy to read. The World Wide Web Consortium and the Web Standards Organization stresses that all web page code be compliant with their standards. If you are going to get into this, you should familiarize yourself with the most basic of these standards.

One of those standards is to present a clean and optimized style sheet and HTML code. While WordPress contests tend to be lenient on this subject, other web page design contests don't. Their motto tends to be "a clean and tight code is a work of art, too".

Basically, it means doing some housekeeping on your code before you release it. Yes, you will need to validate it and test it across browsers, but let's start with some simple cleaning.

Every space, character, and bit in your code and style sheets add up to bytes. That sentence came to about 64 bytes. Each byte of information adds up and the larger they are, the longer they take to load. You do yourself and your users a favor by keeping your file sizes down to byte sized sizes. So where do all these bandwidth wasters hide?

If you have set your code to look pretty with lots of indents, have you checked to see if there are any TAB codes at the end of the line before the line break? I find a lot of these. You don't need a TAB before a line break, only after, but somehow, these sneak into the code.

Using spaces to line up code adds to the size. A TAB is considered one character in most editors, but the five spaces that copy the TAB indent takes up five characters. Using double spaces instead of single spaces in your code and styles adds up, too.

Using a good search and replace capable text editor, you can quickly clean these up, making your styles and code optimized for fast loading.

Condense and Use Shorthand

It's a good idea to use shorthand for your CSS. While it isn't a required standard, it is part of code optimization. Use this technique with caution as some browsers can't handle it, typically "older" browsers. If you are unfamiliar with CSS shorthand, we've put together a short tutorial for you.

Validate! Validate! Validate!

Make sure your codes and styles validate across the board. That means they have to meet the "strict" standards set by the W3C Organization and pass a variety of validations for CSS and HTML. Not all validators check for the same things. Some only check CSS, others HTML, and others for accessibility. If you are sincere in presenting solid code to the public, test your code with several validators.

Validation doesn't just mean putting your pages through some web driven testers. It also means test-driving it with friends, relatives, co-workers, and strangers you meet on the street. Everyone has a little different system, so ask for others to test-drive your styles or themes before you make them public. The Your WordPress section in the WordPress Forums is dedicated to checking out your site by WordPress volunteers while you are working on it, when you have trouble, or just to say ooooh and ahhhhhhh.

If you are unfamiliar with how to validate your web pages and style sheets, we've put together a list of resources and information to help you.

CSS and HTML Bugs

WordPress Themes and styles are diverse examples of the brilliant and imaginative WordPress users out there. What all of them have in common as they hold the design concept in their head and work long hours to convert it into code that matches their imagination is.....browser bugs.

You work for three days to make it beautiful in Microsoft Internet Explorer, take a look at the same site in Firefox and it looks different. In fact, things don't line up right. Or you designed it to work in Opera, but when you view it in Internet Explorer, the sidebar is now half off the screen.

Before you pull out your hair, remember that others have suffered before you and you are not alone. Check out these resources for help on solving the many CSS, HTML, and browser bugs that are out there.

What Else...?

These are a few of the most common things to take into consideration when presenting your themes or styles to the public, but it is only the tip of the iceberg. Remember, if there is a problem with your theme, users should begin their search for help on your website, but they often turn to the WordPress Forums. The more consistent with the default codes and style references, the faster users can get the help they need if there is a problem. We know that you read through this article and followed all of these recommendations to the letter, users will come to the WordPress Forums to brag and show off instead.

The better designed your Theme is, the more web standard and cross-browser compliant, the more successful your Theme may be. As we said, there are no hard and fast rules for design, only guidelines for the code under the hood. The sky is the limit.

Promoting Your Theme

Once your WordPress Theme has been validated and tested thoroughly, then it is ready for release.

Put all your Theme files, including a readme text file with information and description, in a zip file for easy downloading. If possible, provide two or more file compression types like RAR, ZIP, GZIP, etc. to maximize user choices. Be sure and include information on any custom tweaks, tips, plugins, or things the user must know in a readme file.

Post a link to a page on your site with the following:

  • Demo or Screenshot of various page views
  • Description
  • Downloadable zip file

Go to the Using Themes/Theme List and find the appropriate category for your Theme. Post a link to the Theme information and downloadable file, and add the name and keyword description of the Theme, per other examples. The more keyword descriptions you use, the easier it is for people to search through the list to find your Theme.

Post a note about your new Theme on the WordPress Forum under Themes and Templates describing the Theme. The more descriptive keywords you use, the more likely people's search for Themes will turn up your request. Include links to your Theme and the downloadable zip file.

Check the other lists for Theme Resources on the Using Themes article and check there for instructions on adding your Theme to their resource list.

It is preferable that you provide support for your Theme on your site with a link in the Theme and readme file for the support page, to help users. Also check the Forum frequently to see if people are having problems with your Theme and address their issues as much as possible and update your Theme if necessary. If you update, please add a note of the update with the version number in the Forum and on the Theme List in the Codex.

最新英語版: WordPress Codex » Designing_Themes_for_Public_Release最新版との差分