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

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

情報系(参照系)と業務系(更新系)という分類

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

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

  • 更新系システムの特徴
    1. 取引データが複数機能に渡って継続的に利用される。
    2. マスタとそれに伴う管理画面が多い。
    3. 必然的にデータ更新のSQL文が複雑になる。
  • 参照系システムの特徴
    1. 取引データは基本は参照に利用される。
    2. マスタの数が少なくマスタ同士の連携も少ない。
    3. データ更新のSQL文がシンプル。

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

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

MVCモデルではないWordPess

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

  1. フロントエンドHTML+CSS+Javascript(jQuery)で対応可能な範囲のWordPressテーマのテンプレートファイル開発。
  2. バックエンドHTMLフォーム(フロントエンド)からの入力情報に基づいて機能するformタグのaction属性で指定されるPHPプログラムの開発やWordPressプラグイン開発(functions.php)など。

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)

(テンプレートファイル)

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)

(テンプレートファイル)

Hookによるイベントドリブン(Controller)

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

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

  1. フィルターフック一覧(入出力データの加工)
  2. アクションフック一覧(イベントにあわせて実行)

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

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

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

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

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

ここに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種類です。

  1. 投稿(Post)
  2. ページ(Page)
  3. メディア(attachment)
  4. リビジョン(revision)
  5. ナビゲーション(nav_menu)

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

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

wp_posts

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

  1. ID 投稿ID(保存順に自動採番)
  2. post_author 投稿者のユーザID
  3. post_date 投稿日時
  4. post_date_gmt 投稿日時(GMT)
  5. post_content 本文
  6. post_title タイトル
  7. post_excerpt 抜粋オプション
  8. post_status 投稿ステータス ‘publish’: 公開済み ‘pending’: ペンディング ‘draft’: 草稿 ‘private’: プライベート(非公開) ‘static’:(2.0.x 以前はページ) ‘object’: ‘attachment’: ‘inherit’: 継承(添付ファイル、改訂履歴・自動保存のとき) ‘future’: 予約投稿
  9. comment_status コメントステータス ‘open’: 許可 ‘closed’: 不許可 ‘registered_only’: 登録ユーザのみ
  10. ping_status ピン・ステータス ‘open’: トラックバック・ピンバックを受け付ける ‘closed’: 受け付けない
  11. post_password 閲覧パスワード
  12. post_name 投稿スラッグ ‘{親ID}-revision(-#)’ (改訂履歴のとき) ‘{親ID}-autosave’ (自動保存のとき)
  13. to_ping text
  14. pinged ピン通知済み URL
  15. post_modified 更新日時
  16. post_modified_gmt 更新日時(GMT)
  17. post_content_filtered
  18. post_parent 親ID 親ページの投稿ID 添付ファイルが属する投稿ID 改訂履歴・自動保存のベース投稿ID
  19. guid varchar(255)
  20. menu_order ページの表示順
  21. post_type 投稿種別 ‘post’: 投稿 ‘page’: ページ ‘attachment’: 添付ファイル ‘revision’: 改訂履歴・自動保存
  22. post_mime_type 添付ファイルのとき MIMEタイプ(image/png など)
  23. comment_count コメント数

wp_postmeta

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

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

  1. meta_id メタID(一意)(登録順に自動採番)
  2. post_id 投稿ID
  3. meta_key カスタムフィールドのキー名
  4. meta_value カスタムフィールドの値

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

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

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

root/wp-settings.php抜粋

こんな投稿も読まれています