制作して終わり、ではなく、その先のサイト運用まで考慮した高度なテーマ設計について。
まずはじめに、CMSを導入するメリットは、制作側の効率化だけではなく、運用側の効率化にこそあります。
HTMLやCSSなどの専門的なスキルを持たない人でも安心してサイト運営に参加できること、それを実現するのがCMSです。
制作者と運用者が異なるレイヤーである場合、運用レベルまで落とし込んだテーマ設計を心がけることが大切だと思います。
テーマ内包スタイルシートだけ、の弊害
サイトのスタイル定義は、テーマ内包スタイルシート（テーマディレクトリ > style.css）に記述しますが、これだけでは運用者に不都合が生じることがあります。
例えば、以下のようなサイトを作りたいとします。（超適当
これをテンプレート化するとこうなります。
> テンプレート
<?php if (have_posts()) : while (have_posts()) : the_post(); ?> <h2><?php the_title(); ?></h2> <div><?php the_content(); ?></div> <?php endwhile; endif; ?>
> テーマディレクトリ/style.css
body {
font: 13px/26px Arial,Helvetica,sans-serif;
margin: 0px;
padding: 0px;
}
h2 {
font-size: 18px;
line-height: 30px;
border-left: 5px solid #CCC;
padding-left: 20px;
}
h3 {
font-size: 16px;
line-height: 20px;
color: blue;
}
この場合、h2タグはテンプレート内包なので、運用時に入稿することはありません。
一方、h3タグは、運用者が自由に入稿可能な設計になります。
不都合が生じるのは、運用者がビジュアルエディタで入稿した場合です。
h3タグのスタイルが適用されていないのは一目瞭然ですが、フォントタイプもまるで一致していません。
これではwysiwygエディタとは言えませんね。
テキストモードでh3タグを直接書いて入稿してくだい、などというのは制作者の勝手で、最初に言ったように、運用に特別なスキルを要求していはいけません。運用者はビジュアルエディタで入稿する、と想定しておくべきです。
（補足）入稿フォームのフォーマット化と自由度のバランス
カスタム投稿タイプとカスタムフィールドを組み合わせて、完全に入稿フォームをフォーマット化できればそれがベストかもしれません。
運用者はタグを一切記述する必要はなくなります。
ただ、イレギュラーな想定がある場合は、汎用性を持たせなければならず、上記のように、エディタとして自由入稿フォームを設置することになります。
この辺のバランスは非常に重要であり、事前のヒアリングや設計を十分行っておく必要があります。
サイト上の見た目と入稿エディタの見た目が同じでなければならない
それを解決するのは、add_editor_style()関数です。WordPress ver3.0から導入されています。
1. テーマ内包のfunctions.phpにadd_editor_style()を記述する。
> functions.php
<?php add_editor_style(); ?>
2. editor-style.cssをテーマディレクトリに設置する
editor-style.cssのスタイルシートが入稿エディタに適用されます。
> editor-style.css
body {
font: 13px/26px Arial,Helvetica,sans-serif;
margin: 0px;
padding: 0px;
}
h3 {
font-size: 16px;
line-height: 20px;
color: blue;
}
これで、サイト側の見た目と入稿エディタの見た目が一致し、運用を考慮したwysiwygエディタを提供できます。
（補足）OOCSSで設計するCSSでは
実は、さきほどのCSSの書き方はあまりよくありません。
CSSの設計思想としては、構造（structure）とスキン（skin）を分離したオブジェクト指向CSS（OOCSS）を勧めています。
OOCSSの考え方に基づいて設計するなら以下のように書き換えるべきでしょう。
> テンプレート
<?php if (have_posts()) : while (have_posts()) : the_post(); ?> <h2 class="post_title"><?php the_title(); ?></h2> <div class="post_content"><?php the_content(); ?></div> <?php endwhile; endif; ?>
> テーマディレクトリ/style.css
/* structure */
h2 {
font-size: 18px;
line-height: 30px;
}
h3 {
font-size: 16px;
line-height: 20px;
}
/* skin */
h2.post_title {
border-left: 5px solid #CCC;
padding-left: 20px;
}
div.post_content {
margin-top: 20px;
}
div.post_content h3 {
color: blue;
}
サイト側のスタイルシートの設計としては望ましい書き方ですが、エディタ側のスタイルシート（editor-style.css）に入稿領域のCSSをそのまま切り出すことはできません。
エディタにはテンプレートの構造は引き継がれないので、エディタ側のスタイルシートにはセレクタの指定を変更したCSSを記述することになります。構造のクラス設計ができないエディタ側についてはこの方法しかないので気にすることはないと思います。
運用者が後から追加できるカスタムスタイルシート
運用者がCSSを多少書けるスキルを持っていた場合、管理画面上からカスタムCSSを入稿できる仕組みを提供するのもいいと思います。
テーマ内包スタイルシートを直接変更することも可能ですが、それはするべきではありません。
WordPressがプラグインAPIを提供して、コアファイルの改変をせずに機能拡張ができる仕組みを持っているように、ユーザライクなスタイルシートは、テーマ内包スタイルシートとは別に用意されるべきです。
※レイヤーの違いをモジュールとして明確に定義した図
プラグインAPIと違って、スタイルシートの場合は、優先度による上書き特性を利用すれば、問題は簡単です。
ここは、JetPackプラグインを使って簡単に実装してみます。
JetPackプラグインを有効化したら、カスタムCSSの機能を有効化します。
管理画面にユーザライクなCSSを入稿できるメニューが設置されます。
外観 > CSS編集
運用者のレベルによっては、このような仕組みを用意することで、より自由なサイト運用を提供できるのではないかと思います。
まとめ
・運用レイヤーでカスタム可能なCSS領域を用意する
ただ制作して終わりではなく、その先のサイト運用まで考慮した高度なテーマ設計を行えば、CMS導入を成功に導けるのではないでしょうか。