古今東西舎

ＥＲ図

WordPressの投稿タイプやタクソノミーを理解しようとするとき、ＥＲ図を書いてみると、視覚的に理解しやすくなります。

データの集合をエンティティと呼びます。下図は、３つのエンティティ（ブログ投稿、市区町村、ジャンル）をデータの実例付きで図示したものです。
　ＥＲ図では、主キーと外部キーを記述します。主キーは、図056の最左端のデータ項目で、エンティティのレコードを識別します。表の右端にある「市区町村ＩＤ」「ジャンルＩＤ」は、それ自身が別のエンティティの主キーとなり得るデータ項目で、外部キーと呼ばれます。　一つのエンティティに主キーは必ず一つですが、外部キーは複数持つことができます。図では、ブログ投稿は二つの外部キーを持つことによって、「ジャンル」と「市区町村」２つのエンティティを関連を持っています。
　また、「市区町村」の事例は、外部キーが自身の主キーと結びつく「親子関係」のエンティティの事例です。

ブログ投稿と市区町村の関係は、１：Ｎ

・１つのブログ投稿に対し１つの市区町村が関連。
・その市区町村は別のブログ投稿とも関連。

ブログ投稿とジャンルの関係は、Ｎ：Ｎ

・ジャンルは、１つのブログ投稿に対し複数設定可能。
（例）
西仲通り商店街は、「商店街」と「路地」に関連

市区町村は親子ループ（１：Ｎ）を持つ

・１つの親は１つまたは複数の子を持つ。
・子に対し、親は１つ。
・同一エンティティの中で主キーと外部キーが結びつく（親子関係）。

主キーと外部キー

上記のＥＲ図の主キーと外部キーのみを表記すると下図のようになります。主キーと外部キーに注目すると、下記４パターンに集約されます。
ⓐDestinationパターン
ⓑSourceパターン（MetaQuery、TaxQuery）
ⓒAncestorsパターン（現世代→先祖）
ⓓDescendantsパターン（現世代→子孫）

ＷＥＢサイトの要件をＥＲ図に書き表す

Ｗｅｂサイトを開発する前に全体のデザイン（設計）をすることが必要です。まず、エンティティを抽出し、それらの関連づけを行うための主キー、外部キーはを決めることが重要です。

下図は当サイトの場合のＥＲ図の事例です。WordPressは投稿タイプとタクソノミーの２種類がありますので、どちらにするかも最初にするかを決めておく必要があります。

WordPressの外部キー

エンティティ同士の関連には、
　❶投稿タイプとタクソノミーの関連づけ
　❷投稿タイプのカスタムフィールドによる関連づけ
　❸parentフィールドによる親子関係の関連づけ
の３種類があります。

WordPressはイベント駆動型モデルであると言われています。これは、ＵＲＬを指定するだけで自動的にデータを取得（メインクエリー）し、自動的にテンプレートファイルを選択して画面表示（メインループ）するものです。

しかし、カスタム投稿タイプやカスタムタクソノミーを使ったＷｅｂアプリケーション開発に重きを置く場合は、サブクエリーを多用する場面が増えてきます。

WordPressには、サブクエリーを効率よく開発するためのモデルがありません。

今回は、サブクエリーを効率よく開発するために、ＭＶＣモデルを適用することについて解説します。

ＭＶＣモデルは、Ｍｏｄｅｌクラス、Ｖｉｅｗクラスにコードを集約し、オブジェックト指向の継承やオーバーライドを使って、類似のコードを抽象化することによって、コーディングの作業を軽減することができます。

次にオブジェクト指向でないコード（従来の書き方）とＭＶＣモデルを使ったオブジェクト指向のコードを比較してみることにします。

オブジェクト指向でないコード

//サブクエリー
	　$args = array(		
　//条件の記述
	　);
　//WP_Query
	　$the_query = new WP_Query($args) ;

//サブループ
	　if($the_query->have_posts()){
	　　　While($the_query->have_posts()){
		　　　$the_query->the_post();
		　　　　　//表示の記述
		　　　　　the_title() ;
	　　　　　　　echo "<br>\n" ;	
	　　　}
	　}//endif

オブジェクト指向のコード（ＭＶＣモデル）

class Controller
{
　public function __construct($var){
	　　　$par =(object)$var;
	　　　$user = new Model($args);
　　　または
　　　$user = new ViewPost() ;
　　　$user->format();
　}
}

class Model
{
	public function __construct($var)
	{
	
//サブクエリー
		$args = array(		
　　//条件の記述
		);
　　//WP_Query
		$the_query = new WP_Query($args) ;

//サブループ
		if($the_query->have_posts()){
			While($the_query->have_posts()){
				$the_query->the_post();
					//Viewクラスの呼び出し
					$user = new ViewPost() ;
                                 $user->format();
			}
		}//endif
	}//endfunction
}//endclass

class View
{
public function __format()	

	}//endfunction
}//endclass

class ViewPost extends View
{
public function __format()
			//表示
			the_title() ;
			echo "<br>\n" ;		
	}//endfunction
}//endclass

//呼び出す側　
$args = arry(
//条件の記述
);
$user  = new Controller($args);

サブクエリー（WP_Query）とサブループは、書き方のパータンがたくさんあり、すべてのパターンを覚えるのは大変なことです。そのため、書くたびにコードディングミスが起こり、完成するまでに時間がかかります。当然のことながら、これをメンテする作業も大変です。

これに対し、オブジェクト指向で書かれたコードは、呼び出す側は、フィルタリング条件を記述してクラスを呼び出すだけで、サブクエリー～サブループ～表示までの処理が完了します。
　もちろん、呼び出される側のクラスとして、Controllerクラス、Modelクラス、Viewクラスがあり、これらのコードを合わせると、オブジェクト指向を使った場合の方がコードの量は格段に増えます。しかし、これらのクラスは、再利用することを前提に作成していますので、次回からは、呼び出す側の記述のみで済みます。
　また、クラスには、スーパークラス（親クラス）の機能を継承して、差分の部分のみをサブクラス（子クラス）に記述することができ、メンテの効率が向上します。

WordPressの基本の理解で最も重要なことは、構造の理解です。理解するためには、図で示すことが最も近道です。
WordPressは、クエリーとループから成り立っています。

クエリー：データの検索
ループ：データの表示

WordPressの入門時に一番初めに理解すべきことは、メインクエリーとメインループですが、メインクエリーは「WordPressコア」と呼ばれる基本部分に包含されていて、通常はカスタマイズできないということです。（メインクエリーをカスタマイズするには、「フック」という特別なカスタマイズ方法を用います。）

WordPressのカスタマイズを理解の第一歩は、テーマの中にあるメインループを見つけ出し、ループの中の記述を自分の好みに合うようにカスタマイズし、実感をつかむことです。

<?php 
if ( have_posts() ) {
	while ( have_posts() ) {
		the_post(); 
		//
		// この部分が記述（カスタマイズ）部分
		//
	} // end while
} // end if
?>

上記のコードのif ( have_posts() )から} // end ifまでがメインループの記述で、その内側の部分がカスタマイズ部分で、ここに、たとえば、the_title();と書けば、投稿のタイトルが表示され、the_content();と書けば、投稿の本文が表示されるわけです。

<?php 
if ( have_posts() ) {
	while ( have_posts() ) {
		the_post(); 
		//記述（カスタマイズ）部分
　　　　　　　　　　the_title();
　　　　　　　　　　the_content();
		//
	} // end while
} // end if
?>

もう一つ重要なポイントは、このメインループが実行される手前の段階で、「WordPressコア」の中のメインクエリーが、既に実行を完了しており、その結果がオブジェクトと呼ばれるデータの塊に保持されているということです。この塊から具体的なデータを抜き出す命令が、the_title();やthe_content();です。このとき、データは複数件あるので、これをメインループで回して表示しています。

WordPressのカスタマイズで頻繁に出てくるサブループについては、上記の概念図に併記すると理解が深まります。
メインクエリーが「WordPressコア」の中にあって、自動的に実行されるものであるのに対し、サブクエリーは、自分でコードを書く（カスタマイズする）ことが必要ですが、行っている処理は、メインクエリーと同じです。（両方ともWP_Queryが実行されている同じ処理。）

サブクエリーの結果は、オブジェクトに出力され、それを表示するのがサブループです。メインループとサブループの書き方は、ほぼ同じです。

上記の概念図では、左から右へ「クエリー」「ループ」「表示」と情報が転送され、全体としては、上から下へ「メイン」「サブ」と処理が進んでいくことを図示しています。

これまで、WP_Queryのカスタマイズ事例※1※2※3を示してきましたが、今回は、このうちのDestinationパターン※1とSourceパターン※2の事例を統合した万能型サブクエリーについて解説します。

カスタム投稿タイプの先祖の表示。

前回※1 「投稿のカスタムフィールドに関連付けられた投稿の表示」で、ブログ記事に文献の情報を関連付ける事例を紹介しました。（実際の画面サンプルはこちらです。）

この例では、「第八章 月島の商業」が関連付けられていますが、この上の階層である「第三編 明治以降の月島」と最上位階層である書籍名の「月島発展史」を併せて表示しています。

カスタム投稿タイプ「参考文献」は、親子関係を持った木（ツリー）構造になっていて、最初に関連付けされた「第八章 月島の商業」をキーに、祖先（父母→祖父母）の階層を表示しています。

リスト37639は、カスタム投稿タイプの祖先を表示するコードです。

カスタム投稿タイプの子孫の表示。

カスタム投稿タイプ「参考文献」の全体を一覧表示する場合は、階層のトップのIDを指定し、それをキーに子孫の階層を上から順番に検索して表示します。（実際の画面サンプルはこちらです。）

リスト37639は、投稿の子孫を表示するコードです。WordPressのテンプレートタグ「get posts」を使って子孫を検索しています。 

タクソノミーの祖先と子孫の表示

木（ツリー）構造を持つタクソノミーの全体を表示する事例を紹介します。（実際の画面サンプルはこちらです。）

たとえば「中央区」を選択した場合、祖先に東京都、子孫に月島３丁目があります。これらの表示をクリックするとどちらにでも移動できるようにすると便利です。また、自分が現在どの階層にいるかも解りやすくなります。

リスト36732は、タクソノミーの祖先と子孫の両方を表示する事例です。現世代の「中央区」を指定すると、まずその先祖を表示し、次に子孫を表示します。

リスト37167は、meta_queryの事例。
リスト37179は、tax_queryの事例です。

今回は、投稿データに関連付けられたタクソノミーや別の投稿を表示する方法について紹介します。

WP_Queryは、あるデータの集合（これをエンティティと呼びます）の外部キーから別のエンティティの主キーを検索しデータ群（オブジェクト）取得する仕組み（クラス）です。
　WordPressの場合のエンティティは、「投稿タイプ」「カスタム投稿」「カテゴリー」「ターム」「カスタムタクソノミー」などのデータの集合です。これらのエンティティ同士は、主キーと外部キーで関連付けられます。

下図は、ブログ投稿の外部キーにカスタムタクソノミー「ジャンル」が関連づけられている場合を図示したものです。

リスト37209は、投稿のカスタムフィールドに関連付けられた投稿の表示の事例です。
ブログ記事のような投稿データに、別の投稿データを関連づけて表示したい場合があります。

リスト37211は、投稿に関連付けられたタクソノミーの表示の事例です。
ブログ記事のような投稿データには、タクソノミー（カテゴリー、タグ）を関連づけて記事の分類分けをしますが、このとき、ブログ記事のタイトルの上部や本文の末尾などにタクソノミーを表示したい場合があります。

サブクラスにおいてWP_Queryを使うことのメリットは、拡張（継承）してカスタムクラスを作れることです。Rakhitha Nimesh Ratnayake（ラーキサ・ニーメシュ・ラーネヤク）は、その著書「WordPressによるWebアプリケーション開発」の中で、WP_Queryクラスの継承の用例を示しています。＊1

リスト37188は、ラーネヤク氏が示した用例を本書のテーマに即してアレンジしたものです。
通常、WP_Queryを使うときは、次のように配列にすべてのフィルタリング条件を記述しなければなりませんが、リスト37188では、Modelクラスの中にこの記述を書いているので、呼び出す側は、１行のコードのみで済みます。

たしかに、同じフィルタリング条件を何度も繰り返し使う場合はこの方法が有効であり、クラスを継承すれば、少し異なる条件の場合も含めて抽象化できるかもしれません。

しかし、あらゆるパターンのサブクエリー（投稿の場合、タームの場合、親子の場合）と表示をすべて網羅的に抽象化するためには、もう一工夫必要です。

リスト36618は、リスト37188をアレンジし、この課題を解決するための方法です。

呼び出す側に、フィルタリング条件を羅列しますが、そこには値を直接記述します。これを受け取ったModelクラスは、その値をWP_Queryのフィルタリング条件にあてはめます。
この方法のメリットは、面倒なWP_Queryの記述から解放されるということです。
さらに、表示するViewクラスの名称なども呼び出す側の条件に加えることにより、サブクエリーから表示までを一貫して抽象化することができそうです。