コーディングとCMSのテーマ設計の話です。かなりCMS構築に慣れていないと理解しづらい内容になるので、順を追って説明します。

モジュール型のサイト設計

CMSで運用されるサイトは、トップページや下層ページのサイドバーで、投稿の新着やナビゲーションなどの「モジュール」を埋め込む前提で構築やコーディングをします。
ここでは「モジュール」としていますが、CMSによって名称は異なります。よく知られているのはWordPressの「ウィジェット」です。

コーディングにについては、以前書いた記事「CMSの構築を考慮したコーディングとかクラスの命名規則の話」で詳しく書いていますが、つまりはこの場合、それぞれのモジュール（＝ウィジェット）はクラス名が付与されたdivで包括される前提となります。

例えば、WordPressの人気テーマ「Lightning」のトップページで、新着記事を表示している箇所は以下のようにマークアップされています。

<div class="widget widget_vkexunit_post_list" id="vkexunit_post_list-13">
（新着記事リスト）
</div>

自由モジュールであることを示す「widget」、テーマ専用パーツであることを示す「widget_vkexunit_post_list」のクラスに加え、一意のIDが付与されています。
これによって似たようなモジュールをページに複数配置しても、クラスかIDで区別してCSSスタイルを調整できます。

モジュールのクラス名を自由に決められるようにしてみる

DrupalのBlockやViewsでは、先述した包括divに付与するクラス名を変更できる機能があります。コーダー側のコーディングルールを活かせるので、とても魅力的な機能です。

ヘッダ、フッタのボタン、包括divの属性を変更できるようにした例

このクラス名変更機能を、a-blog cmsのモジュール設定に組み込んだのが、二年ほど前に公開したテーマ「echo_zero」でした。

モジュールの外観のカスタマイズ | はじめての方へ | 解説資料 | echo_zeroデモサイト

このテーマは当時はかなり満足していて、安定したウェブサイトをサクサク構築できるので、いくつかの案件にそのまま採用していました。
…が、二年が経って、一部の案件でこの機能が足を引っ張るようになってしまいました。

クラス名を見つけられない

完全納品ではなく、納品後も改修をお手伝いする案件だと、半年ほど経ってコンテンツが増えてきてから、二段階目の改修を依頼されることがあります。
モジュールの追加やデザイン変更などが発生しますから、コーディングも変わってきます。以前はイベント新着関係のモジュールが一個しかなかったのに、似たようなモジュール（関連イベント・現在位置から近い順）が増えたりします。

半年も経つと、自分の作ったテーマでも細かい構造は忘れています。このクラスは、どのモジュールで使用していたろうかと、テーマをクラス名の一部、例えば「module-event」などで検索してみても…見つかりません。
クラス名はCMS側で管理しているので、ローカル環境のエディタの全文検索ではヒットしないのです。
こうなると、a-blog cmsの管理画面に入って「モジュールID」の一覧から該当のモジュールを探すことになります。かなりの手間です。

CMSで何もかも管理すればいいわけでもない

一般に配布するテーマであれば、クラス名を変更できる機能は非常に便利です。
利用する人の大半は、モジュールごとに細かくCSSを調整したり、コーディングルールにこだわったりすることがないので、メリットの方が大きいでしょう。

ですが、自分がいちからテーマを作成していて、改修も多い場合は、修正すべき箇所をローカル検索できないというのは、毎回の時間のロスは大したことがないものの、けっこうストレスが貯まります。

そんなこんなで最近は、多くの人がやっているように、記事リストを呼び出す箇所を共通のインクルードファイルにして、クラス名や繰り返すコンポーネント名を変数で渡す構築になっています。
以下はa-blog cmsの場合です。a-blog cmsはJSON形式で変数を渡せます。これなら検索にもヒットします。

@include("/include/module/summary.html", {"class": "c-module-event-top", "mid": "summary_event_top", "loop": "event"})

ここまで書いて、どのくらいの人にこの文章が伝わっているのだろうか…と思いはじめていますが…

よく考えたら、モジュールの包括divを、制作者以外が変更できるようにする必要は基本的にないわけです。配布テーマでは便利でも、制作者が不便になるような機能は制作段階で外しておかなければと、改めて反省しています。

先日、CSSフレームワークについて記事を書いてから、今後のコーディング設計について具体的に考えています。

【Webdesign】Atomic Designの思想で、文系でもわかるCSSフレームワークを作りたい | ウェビンブログ

というより、再利用性のある業務用テーマの制作をいくつか依頼されており、いずれにしても着手しなければならないのです。

私の主業務が、CMS（それも特定のブランドによらない）を組み込んだサイトの制作であることを前提に、自分はどう設計していったらよいか、考えていることを書いておきます。

Drupal8がすっかり標準になりましたが、私はなかなか実践レベルになりません。ちゃんとサイトを作らなければ身につかないと、Drupalで趣味の素材配布サイトを立ち上げてみることにしました。

私のCMSの構築は、2005年頃にブームだった素材サイトからはじまりました。素材は、AI・PNG・壁紙などの属性が異なるファイルを、複数のタクソノミーで検索させる必要があり、自動化しようとすると奥が深いコンテンツです。

echo_zeroのフレームワークは今回も役に立ちました

投稿タイプ・フィールド・タクソノミー・Views・サブテーマまで勉強して、見た目はともかくきちんと機能する素材サイトがだいぶできてきました。

ここまでの段階で、MTやWordPressなどのブログベースのCMSで制作をしている人が、Drupal8を学習する前に知っておかないと苦労すること・損をすることがいくつかあると感じたのでメモしておきます。

これまでのコーポレートサイトのCMS構築において、ナビゲーション機能は重要度が高くありませんでした。公開後に変更されることが少ないので、HTML直書きでも充分だったのです。

しかし、コンテンツマーケティングの考え方が普及し、サイト公開後もナビゲーションの導線変更を検討するケースが増えてきました。
現時点の、日本国内の主要CMS6ブランド・7種類の「ナビゲーション機能」について改めて見直してみました。

2016-12-30追記

ユーザーの皆さんから情報をいただき、下記を修正しました。
不備が多く申し訳ありません…m(__)m

• Movable Type: Object Treeプラグインの情報を追加
• a-blog cms: ナビゲーションのカスタマイズについて追記
• concrete5: フラットビュー、ページ検索機能について追記
• baserCMS 4: ブログ・フォームを複数追加について追記
• Drupal: 「リンクの一覧」画面について追記

2016年2月27日に札幌市で開催されたCMSの合同イベント「CMSMix Sapporo」で、基調講演をさせていただきました。

CMSMix Sapporo 〜Web制作の幅が広がる！プロジェクトの傾向から考える、2つ目・3つ目のCMS選び〜 | Peatix

ジャクスタポジション西山さん

昨年秋の、名古屋のセミナーイベント「WCAN」での私のセッションに、札幌のMovable Typeのパワーユーザー、西山さんが興味を持ってくださいました。

WCAN2015 Autumnで、CMSディレクション全般について話しました | CMS | ウェビンブログ

これがきっかけで、a-blog cms・concrete5・Drupal・Movable Type・WordPressのパワーユーザーが集まる、貴重なイベントが実現しました。ありがとうございます。