Cntlog

WordPressのテーマを作る時に気をつけている事

CMS

投稿日

WorsPressのテーマを作れるようになって数年経ってリニューアルとか運用をする中でテーマをこうやって作っておけばよかったなと反省して最近は私が気をつけているテーマ制作のポイントを紹介します。

前提の環境

私はコーディングは得意ですがPHPをガリガリ書けるというわけではありませんがWordPressで用意された関数をちょいちょい使えるくらいのスキルしかありません。
ですので常に誰もが使いやすいようにするために一個ずつカスタマイズするというわけではありません。
私の環境ではHTML・CSSはわかるけどWordPressはわからないという人が多く、何か修正が必要になると私しかテーマを触れないという所での話でそんな環境でテーマを作った後のトラブルを減らへるために気をつけていることです。
また、HTML・CSSのわからないクライアントのためにも気をつけているポイントもあります。

プラグインとテーマの領域

WordPressでは公式テーマを配布している場所があり、そこで公開されているテーマは誰でも登録できます。
ただテーマ作成にはガイドラインがあり、その中にプラグインの領域(プラグインテリトリー)というものがあります。

テーマレビューガイドライン(英語)

プラグインテリトリー(英語)

プラグインテリトリー例

プラグインテリトリーと言うのは、テーマに依存せずそのサイトの設定になるような項目になります。

Analytics scripts
Google Analytics等のアクセス解析用のコードなど
SEO options (meta tags, page title, post titles, robots.txt, etc.)
metaとかのSEOのために行なっているようなもの。
これテーマの中に書いているとプラグインを追加したときに重複したりします。
そして案外気がつかない罠
Content Sharing buttons/links
Twitter,facebookなどのソーシャルボタン。
Custom post-content shortcodes
ショートコード。テーマ変えた時にショートコードないと…
Custom Post Types・Custom Taxonomies
カスタム投稿やカスタムタクソノミー。これテーマに依存してるとリニューアルのときに殺意沸く。

テーマに依存するということは、テーマが差し替わった時点でこれらの設定がすべてなくなるということです。
見た目の設定と内部の設定を切り分ける事でそのような自体を未然に防ぐことが出来ます。

なので下記のように切り分けるとわかりやすいと思います。

サイトの設定=プラグインで行う
見た目の設定=テーマで行う

または、同じテーマを2つ以上のサイトで流用して問題ないかと考えるとプラグインですべき領域が見えやすくなります。
アナリティクスのコードが全然別のサイトに入っていたらマズイですよね…

プラグインテリトリーを侵した時のトラブル例
  • テーマを差し替えたらアクセス解析のコードがなくなって激おこされる
  • テーマを差し替えたらカスタム投稿がなくなって激おこされる

管理画面でみんなが更新できるようにする

昔は「自分で作ってるんだから、自分がWordPress触れたらいいや」って考えを持っていましたが、クライアントや同僚の細かい修正に対応するのがめんどry自分だけが触れるというのはかなりのリスクだと気がついたのでなるべくWordPressのテーマを触れない人でも修正・変更できるように気をつけています。
※とはいっても当然、管理画面で全部を触れるわけではないので、よく触る簡単な所に限らせてもらってます。

Webのわかる人とそうでない人といるので更新できる人に合わせてどこまで修正できるようにするか決めるのも大事なポイントです。

Webのわからない人の更新箇所例
営業日などのテキスト情報を変更したい、ナビゲーションを追加したいなど。
Webのわかる人の更新箇所例
特定の固定ページにJSやCSSを追加するなど。

だいたい管理画面でできるようにするのはプラグインを使って先程のプラグインテリトリーを部分になります。
特に需要が高いのはウィジェットやカスタムナビゲーションあたりになります。

クライアントと打ち合わせるときはワイヤーの段階でページ以外のどこを更新したいか最初に確認しておく(コンセンサスとっておく)のがとても大事ですね。
時々あとで「あれもこれも更新したい」と 言ってくる人もいるので。

また良く全部更新できるようにとも言われますが「もちろん費用・工数が莫大に変わりますよ?」と言えば多分理解してもらえるので、本当に必要なところを更新者から引き出すのも重要ですね。(予算を引き出すのも大事です)

「CMSは作って終わりじゃないんですよ、開発してる時点で運用も設計して作るものなのですよ」
(とても大事なことです)

プラグインテリトリのためによく使うプラグイン

色々書きましたが、要はテーマにプラグインテリトリを含まずに作って、誰がどこを更新できるようにするか明確化してWordPressのサイトを作ると良いですよって私の感想です。
当たり前の事と思えた人は素晴らしいテーマ製作者です。

最後にプラグインテリトリを侵さないようにするために私が使っているプラグインを紹介しておきますね。

Smart Custom Fields
カスタムフィールドを作るためのプラグイン。
日本語であること(日本人がプラグインを作成)とシンプルな設定で(カスタムフィルードの事を知っていれば)見ただけでわかるくらい簡単。
私イチオシ (ステマ)
Custom Post Type Generator
カスタム投稿タイプとカスタムタクソノミーを作るためのプラグイン。
「Smart Custom Fields」同様、日本語であること(日本人がプラグインを作成)とシンプルな設定で(カスタム投稿タイプとカスタムタクソノミーを知っていれば)見ただけでわかるくらい簡単。
私イチオシ(ステマ)
Per page add to head
head内にタグを追加出来ます。
個別投稿にも対応しているいて、metaだけじゃなく、CSSやJSの追加も可能です。
もちろん共通のタグも入れれます。
DuracellTomi’s Google Tag Manager for WordPress
googleタグマネージャーを管理するためのプラグイン。
私アナリティクスはタグマネージャーで配信してるのでいつもこれで設定しています。
Code Snippets
function.phpに書くようなコードを一つづつ管理できます。
管理画面のカスタマイズやWordPressの設定の上書きなどテーマに依存しないコードを投稿するみたいに機能ごとに追加・編集・停止・削除できます。
Widget Logic
ウィジェットの表示にトップページだけなどの条件分岐の機能を入れられます。
Custom Post Widget
投稿する時みたいにウィジェットを作れますので、HTMLタグがわからない人でもちょっとしたウィジェットが簡単に作れます。
Remove Widget Titles
ウィジェットのタイトルを削除して表示することができるようになります。
Nav Menu Images
カスタムメニューに画像を追加出来ます。
ホバー時やアクティブの時の画像も設定できるので便利です。
※個々最近プラグインが更新されていないのでいつか使えなくなるかもって不安があります。