WordPressによるサイト構築において最も重要な設計について。
私が普段実際に行っているプロセス、考え方を紹介します。
CMS設計の基本的な考え方
2. 将来的な機能拡張に耐えられる設計
クライアント、制作者、運用者、エンドユーザ、すべてにおいてメリットとなり、CMS導入を成功に導くためには、以上の2点を最大限に考慮した設計が最も重要であるといえます。
CMS設計からテンプレート作成までのプロセス
1. CMS設計
サイト設計、デザインも含み、これから紹介するCMS設計手法のプロセス
2. CMS構築
設計に基づいてCMSを構築していくプロセス。あとで紹介するプラグインを使うことでUI上から簡単に行うことができる。
3. テンプレート作成
構築されたCMSと設計に基づくコーディングのプロセス。
以上、設計からテンプレート作成までのプロセスは以上の3ステップに分類されます。
すべてのコンテンツをオブジェクトとして設計する
まずは”記事”をひとつのオブジェクトであると考えます。
それぞれの記事オブジェクトは独立していて関連性を持っている、というイメージをすることが大事です。
また、動的サイトの場合、記事=コンテンツはデータなので、データベースのテーブル構造をイメージして記事オブジェクトを捉えます。
投稿オブジェクト
投稿オブジェクトの基本は以下のようなテーブル構造をイメージすれば良いでしょう。
IDとタイトルと本文、この組み合わせがひとつの投稿オブジェクトのまとまりとなります。
投稿オブジェクトの拡張 – カスタム投稿
CMSとしてサイトを構築する場合、投稿オブジェクトの拡張が必須となります。“カスタム投稿”と呼ばれているものです。
「投稿」は post_type=post、「固定ページ」は post_type=page であり、一方”カスタム投稿”は post_type を任意に定義できる投稿オブジェクトということです。
投稿オブジェクトは”投稿型”と”固定型”に区分される
「投稿」や”カスタム投稿”は投稿型、「固定ページ」は固定型に区分されます。
これらの違いはパーマリンク構造にあります。
投稿型
アーカイブベージが存在する
固定型
アーカイブページが存在しない
投稿オブジェクトを定義する、しいては記事を投稿するということは、動的サイトにおいてパーマリンクURLを定義する＝URLを存在させることと同義なので、投稿型と固定型のどちらにすべきかは、パーマリンク構造とアーカイブページが存在するかどうかで判断するのがいいでしょう。
よって、固定型の投稿オブジェクトは固定ページ（post_type=page）のみで問題ありません。
フィールドオブジェクト
フィールドオブジェクトとは、上記のテーブル構造において「ID」「title（タイトル）」「content（コンテンツ）」のことを指し、ひとまとまりの投稿オブジェクトを構成するデータフィールドです。
フィールドオブジェクトの拡張 – カスタムフィールド
「タイトル」「本文」以外のフィールドを定義することで、投稿オブジェクトのデータフィールドが拡張され、より使いやすいものとなります。
カスタム投稿と同様に、CMSとしてサイトを構築する場合に必須となります。
例えば、先ほど定義した「写真」という投稿オブジェクトでは、「タイトル」「本文」以外に画像を格納しておくデータフィールドが必要になるでしょう。
このような場合にフィールドを拡張します。“カスタムフィールド”と呼ばれているものです。
カテゴリオブジェクト
カテゴリオブジェクトとは、記事オブジェクトをグルーピングするメタオブジェクトです。
ディフォルトでは「投稿」という記事オブジェクトに「カテゴリー」「タグ」の2つのカテゴリオブジェクトが定義されています。
これらももちろんオブジェクトとして考えます。
カテゴリオブジェクトの拡張 – カスタムタクソノミー
ディフォルトでは、「投稿（post_type=post）」という投稿オブジェクトに「カテゴリ」と「タグ」というカテゴリオブジェクトが適用されています。
任意に定義されたカテゴリオブジェクトが“カスタムタクソノミー”と呼ばれるものです。
カテゴリオブジェクトは”カテゴリ型”と”タグ型”に分類される
カテゴリ型
タグ型
カテゴリ型のみ、階層型を定義することができます。
どちらにすべきかはサイト構成と運用方法を考慮して決定する必要があります。
メニューオブジェクト
管理画面の「外観 > メニュー」で設定するオブジェクトを「メニューオブジェクト」と呼ぶことにします。
これもサイト全体を横断するグローバルオブジェクトに括られますが、システム上便利なUIとAPIが用意されているので区別します。
オブジェクトのまとめ
・フィールドオブジェクト
・カテゴリオブジェクト（カテゴリ型/タグ型）
・メニューオブジェクト
サイトを構成するすべてのコンテンツを、この4つのオブジェクトに分類して定義することが設計ということになります。
この設計に従ってCMSを構築していきます。
CMS構築に便利なプラグイン
オブジェクトは整理されました。
設計プロセスが終わったら、設計書に基づいてCMSを構築していくわけですが、このプロセスを便利に簡単にしてくれるプラグインを紹介します。
Custom Post Type Generator
投稿オブジェクト、カテゴリオブジェクトを定義
Advanced Custom Fields
フィールドオブジェクトを定義
いずれもUI上から簡単にこれらのオブジェクトを定義できるプラグインなので、WordPressをCMSとしてサイト構築する際には必須といえるでしょう。
CMS構築はUI上から行えるので、特別な技術やスキルは必要としません。
設計フォーマット
設計プロセルを設計書におこすならば、フォーマットは以下のようになります。
メニューオブジェクト
| ID | Slug |
|---|---|
| 1 | header-menu |
| 2 | footer-menu |
投稿オブジェクト（投稿型）
| ID | Label | Slug | Archive | Single |
|---|---|---|---|---|
| 1 | 写真 | photo | あり | あり |
投稿オブジェクト（固定型）
| ID | Label | Slug | Parent |
|---|---|---|---|
| 1 | 会社概要 | about | |
| 2 | 代表者挨拶 | message | about |
カテゴリーオブジェクト
| ID | Label | Slug | Type | Objects |
|---|---|---|---|---|
| 1 | ジャンル | genre | Category | photo |
フィールドオブジェクト
| Field Group Name | Objects |
|---|---|
| custom post : phot | post_type=photo |
| ID | Label | Slug | Type | Other |
|---|---|---|---|---|
| 1 | タイトル | title | テキスト | No Formatting |
| 2 | 画像 | image | 画像 | |
| 3 | リンクURL | url | テキスト | No Formatting |
| 4 | リンクターゲット | target | ラジオボタン | _self : _self _blank : _blank |
おまけ : グローバルオブジェクト
投稿オブジェクト、カテゴリオブジェクト、フィールドオブジェクトは基本的に記事単位であるのに対して、サイト全体を横断して利用するオブジェクトも必要になってきます。
例えば、サイト名やメタタグで出力するdescription、全ページを横断的に表示するサイトのメインイメージなどもこれに該当するでしょう。
これらのオブジェクトを「グルーバルオブジェクト」と呼ぶことにします。
ディフォルトで用意されているカスタムヘッダー、カスタム背景という機能で拡張可能なオブジェクトも、グローバルオブジェクトとして一元化することにします。
このアドオンを使わない場合は「管理画面 > 設定」のフィールドを拡張することで代用可能です。ただしそれなりのカスタムスキルは必要になります。
※Options Pageアドオンを使う場合の拡張方法
/*
* Custom ACF options page
*/
add_filter( 'acf/options_page/settings', 'my_options_page_settings' );
function my_options_page_settings( $options ) {
$options['title'] = __( 'サイト設定' );
$options['pages'] = array(
__( 'Options' ),
);
return $options;
}
まとめ
設計、CMS構築、テンプレート作成までの一連のプロセスにおいて、最初の設計が最も重要で難しいところです。
設計が完璧にできてしまえば、あとは作業プロセスとなるので、工数次第となります。
参考になれば