WordPressによるWEBサイト開発1 - MVCモデル的な設計

投稿される情報をユーザー単位に時系列に保存し、「会計システム」「インドネシアの税法」というようなカテゴリ、または「PPN」「WordPress」というようなタグ単位にフィルタして表示できるのがWordpressの最大の強みであり、これらカテゴリやタグなどの投稿記事の切り口（分類）をタクソノミーと呼んでいます。

情報系（参照系）と業務系（更新系）という分類

個人のブログから企業サイトまで「簡単に早く見栄え良く」WEBサイトを立ち上げるためにWordPressは有効であり、「で、一体どこまで出来るの？」という話になった場合、一般的にはWEB開発プラットフォームは「情報系（参照系）向き、業務系（更新系）不向き」とよく言われます。

確かにフォームへの入力値に基づいて頻繁にSQLでマスタを参照したり、計算ロジックが実行され出力結果を保管し、分析帳票を作成する業務システムのプラットフォームとしてWordPressは向きません。

WordPressは上記の更新系システムの特徴はWordPressには不向きであり、参照系システムの特徴に向いていると言えますが、Salesforceなどのクラウドベースの開発プラットフォーム全般は「CRM向き、ERP不向き」と言えます。

CMSとしてのWordPressに向いていないものを無理やり適用するのではなく「出来ること、適していること」に特化させて、不得意な分野はそれに適したツール（言語）で分業開発するが、WEBサイト全体としての「一体感」はキープしたい、というのが現実的な方針だと思います。

MVCモデルではないWordPess

フロントエンド開発を「ユーザーに見える部分の開発」、バックエンド開発を「ユーザーに見えない裏方処理の開発」と定義すれば、WEBサイト全体はフロントエンド（View）で入力されたデータが、バックエンドで処理（Controller）されて、データベースに格納（Model）されるという動きをします。

WordPressはテーマ（View）とコアシステム＆拡張機能プラグイン（Controller）とMySQLが独立して機能するという意味で、MVCモデルのような動きをすると言えますが、MVCフレームワークではないのでWordPressをインストールしたディレクトリやテーマフォルダの中に、viewとかcontrollerとかmodelというフォルダは存在しません。

MVC開発環境に慣れた開発者にとっては、ここがWordPressの気持ち悪いところなのかもしれませんが、WordPressユーザーの大多数はブログユーザーなので、コアシステム（WordPress本体）をテーマで着せ替えるというWordPressの概念が重要なのであって、ディレクトリ構造は問題になりません。

フロントエンドからバックエンドの呼び出し方（View）

このフロントエンドからバックエンドの呼び出し方にはいくつか方法があります。

PHPコードを直接埋め込む

投稿やページからロジックを動かす仕組みが必要になりますが、WordPressにはタグ付きでPHPコードを埋め込めるプラグインExec-PHPがあります。

ショートコードでfunctions.phpのユーザー関数を呼び出す

PHPコードはfunctions.phpに書いて、WordPressの標準機能であるショートコードで呼び出す方法であり、ショートコードを定義するWordPress関数add_shortcode()の第一引数にショートコードを、第二引数に呼び出す関数をセットします。

（functions.php）

function shortcodeFunc() {
  echo '<table width="580"><tr><td align="left" valign="middle" width="180" class="setsu"><input type="hidden" id="mydate1" name="mydate1" value="" />';

  echo '<table><tr><td><div id="mydatediv1" class="anchor"></div></td><td>';
	echo '<img src="cal.gif" style="cursor:pointer;" alt="Select date" onclick="javascript:show_datedialog(\'datedialog1\',\'mydate1\',\'mydatediv1\');" /><div id="datedialog1" class="datedialog">';

  echo '</div></td></tr></table>';
}
add_shortcode('shortcode1', 'shortcodeFunc');

（テンプレートファイル）

[shortcode1]

JavaScriptやスタイルシートを特定の投稿画面にのみ追加したい場合、Custom JS WidgetとCustom CSS Widgetをfunctions.phpに追加すると、投稿画面からJavaScriptを追加できます。

外部PHPプログラムをfunctions.phpからincludeする。

コードが長い場合は、functions.phpの関数内でPHPプログラムをinclude（またはrequire）し、出力されたHTMLフォームからJavaScriptを呼び出します。

これならフロントエンドはWordPressに任せて、ロジックは従来型のPHPとJavaScriptで開発可能であり、理屈ではWordPressをベースに業務系システムの開発が出来ることになります。

（functions.php）

function shortcodeFunc() {
  include("bc/datedialog-files/datedialog.php");
}
add_shortcode('shortcode2', 'shortcodeFunc');

（テンプレートファイル）

[shortcode2]

Hookによるイベントドリブン（Controller）

functions.phpまたはincludeした外部PHPファイルの関数を呼び出す場合と、PHPファイルをプラグイン化する場合とがあります。

AsprovaのCOMインターフェイス同様、WordPressもプラグインAPIがあり、WordPressの動作をコアシステムに触れずに外から操作できますが、これはコアシステム内のロジックの前後に、do_action(’フック名’,'引数')とapply_filters('フック名','引数')というアクセスポイント（プラグインキー）を設置しているからです。

つまりコアシステムのプラグインキーのタイミングでプラグイン関数を実行させたり、コアシステムの関数内で戻り値にフックを引っ掛けてあれば、関数add_action('フック名','プラグイン関数名')や関数add_filter(’フック名','プラグイン関数名')により引数を修正できます。

このプラグインAPIの使い方は主にアクションフックとフィルターフックの2通りあります。

<?php
/*
Plugin Name:おはようSelamat pagi!
Description:おはようをSelamat pagi!に変換
Author:yamazou
*/

function selamat_pagi($content){
 return str_replace('おはよう','Selamat pagi!',$content);
}

add_filter('the_content','selamat_pagi');
?>

add_filter関数でHookとしてthe_contentを指定していますので、「コアシステムがデータベースから取得した投稿コンテンツを画面に出力する前」にselamat_pagi()という関数を実行させます。

何でこんなことが可能かというと、コンテンツを出力する関数the_content()の$content出力部分にapply_filters()がかましてあるからです。

この関数はwp-includes/post-template.phpにあります。

function the_content($more_link_text=null,$stripteaser=false){
   $content=get_the_content($more_link_text=null,$stripteaser=false);
   $content=apply_filters('the_content',$content)
}

ここにapply_filters()がかましてあるのは「the_contentというフィルターで$contentを修正してもOK」という意味であり、もしapply_filtersがなかったら出力前に$contentの修正は出来ません。

apply_filters関数はフィルターフックthe_contentに追加された関数add_filters('the_content','selamat_pagi')を呼び出し実行した上で、戻り値$contentをthe_content関数（テンプレートタグ）に返します。

カスタムフィールド追加によるメタデータ指向（Model）

WordPressのデータベース構造（Codex日本語版）

テーブル関連があまりにシンプルで、ER図見た瞬間に業務機能単位のモジュールが処理するトランザクションが伝票番号で連携され、多くのマスタを必要とする業務系（更新系）に不向きであることが明白なのですが、そもそもwp_postsでコンテンツを分類している投稿タイプ（post_type）は以下の5種類です。

すべてのコンテンツを「post_typeカラムで差別化している」いわゆる単一テーブル継承方式です。

クラウド時代に入りマルチテナント、いわゆる単一データベース共通スキーマ方式指向にある現在、テーブル統一化はトレンドなのかもしれませんが、なんでもかんでもwp_postsに保存されてしまうことによる、テーブルの肥大化が心配されます。

wp_posts

新規にカスタム投稿タイプを追加した場合、デフォルトの投稿記事や固定ページ同様に、タイトルと本部まではwp_postsテーブルに格納されます。

wp_postmeta

デフォルトの投稿タイプ（post, page）からはタイトルとコンテンツの2つしか入力できないので、カスタムフィールドで追加情報（メタデータ）として情報を追加できますが、データはメタデータとしてwp_postmetaに格納されます。

wp_postmetaではカスタムフィールドの値がmeta_id（ユニークキー）とpost_id（投稿ID）とmeta_key（名前）をキーに管理されます。

カスタム投稿タイプの定義方法

デフォルトの投稿タイプにカスタムフィールドを追加するのではなく、全く新規の投稿タイプを作成するにはfunctions.phpにregister_post_type()でフォームを定義し、WordPressコアシステム（root/wp-settings.php）のdo_action('init')のタイミングで以下のプラグイン関数を実行させます。

//カスタム投稿タイプ追加
function new_post_type(){
	//カスタム投稿タイプを作る
	register_post_type(
		'additional-post',
		array(
			'label'=> 'カスタム投稿タイプ',
			'public' => true,
			'hierarchical'=> false,
			'has_archive' => true,
			'supports' => array(
				 'title',
				 'editor',
				 'thumbnail',
				 'excerpt'
			),
			'menu_position' => 5
		)
	);
}
add_action('init', 'new_post_type');

アクションフックinitのタイミング、つまりdo_action('init')がプラグイン関数new_post_typeを呼び出し、「カスタム投稿タイプ」という投稿画面にsupportsにセットした配列の値、タイトル・本文・アイキャッチ画像・抜粋という入力項目が表示されるようにします。

root/wp-settings.php抜粋

do_action( 'init' );
// Check site status
if ( is_multisite() ) {
	if ( true !== ( $file = ms_site_check() ) ) {
		require( $file );
		die();
	}
	unset($file);
}