WordPress の投稿タイプ

世界の CMS のシェアは、WordPress、Joomla、Drupal で上位を占めており、これら 3 つを合わせて「世界 3 大 CMS」などと呼ばれています。中でも、WordPress は約 6 割と突出したシェアを持ち、ネット上に存在するすべての Web サイトの ほぼ 40% が WordPress を使用しているとも言われています。

https://w3techs.com/technologies/overview/content_management/all

WordPress は元々ブログソフトウェアですが、動的なコンテンツ生成やプラグインによる拡張性を生かし、現在では、より用途の広いコンテンツ管理システム（CMS）として利用されるようになっています。この CMS としての WordPress が、Drupal で言うところのコンテンツタイプやタクソノミーをどのように扱っているのかは興味深いところです。

カスタムフィールド

Drupal では、コンテンツタイプを定義し、その属性を格納する項目としてフィールドを追加できるようになっていることについて前回のポストでご説明しました。それに対し WordPress では、ユーザー定義の情報を投稿に付加できる、カスタムフィールドという仕組みを提供しています。Codex（WordPress の公式ドキュメント）の日本語版によれば、このカスタムフィールドで追加される情報は名前と値の組み合わせからなる「メタデータ」と呼ばれています。

一般にメタデータとは、データについてのデータ、つまりあるデータに付随する、そのデータ自身についての付加的な情報を指します。データとメタデータの関係は、HTML コンテンツと、meta タグで埋め込まれる情報（キーワード、文字コード、作者、…）の関係から類推するとわかりやすいでしょう。カスタムフィールドの情報がメタデータだということは、それがコンテンツそのものではなく、付随情報を意図したものであることがうかがえます。これは、投稿画面の表示オプションのカスタムフィールドが既定ではオフになっていることにも表れています。

既定でオフの WordPress のカスタムフィールドのオプション

このオプションを有効にすると、投稿画面にカスタムフィールドの入力フォームが表示され、名前と値のペアを自由に追加できます。一度追加したフィールド名は記録され、次回以降の別の投稿でも選択肢として指定できるようになります。また、カスタムフィールドは、投稿に追加しただけでは表示コンテンツに反映されず、表示させるにはテンプレートの編集が必要になります。こうした使い方を見ても、WordPress のカスタムフィールドは、個々のブログ投稿への付随情報として用意されたもので、Drupal のフィールドとは用途や目的が異なることがわかります。

また、標準のカスタムフィールドでは、保存できる情報は単純なテキストデータのみで、この点も Drupal がコアで提供しているフィールドとは大きく異なります。ただし、Advanced Custom Fieldというプラグインを利用することで、Drupal と同様に多様なデータをカスタムフィールドとして保持することが可能です。

多様な種類のフィールドデータに対応できる Advanced Custom Field ãƒ—ラグイン

カスタム投稿タイプ

Drupal と同様、WordPress も多数の異なるタイプのコンテンツを保存し、表示することができます。こうした投稿コンテンツの種類を WordPress では「投稿タイプ」と呼んでいます。デフォルトの投稿タイプとして、投稿、固定ページ、添付ファイル、リビジョン、ナビゲーションメニューがありますが、独自の投稿タイプを定義することもできます。

参考：https://wpdocs.osdn.jp/投稿タイプ

カスタム投稿タイプは、WordPress の API を使ってプログラムコードから登録することができますが、登録した投稿タイプをプラグイン化したり、Custom Post Type UI ã¨ã„うプラグインを使って管理画面から登録することもできます。先に紹介した Advanced Custom Fields プラグインと組み合わせることで、Drupal と同様、管理画面の操作で投稿タイプを定義したり、カスタムフィールドを追加したりすることが可能です。

カスタム投稿タイプにカスタムフィールドを追加しているところ

別のコンテンツを参照する「関連」というフィールドタイプも用意されているので、投稿タイプ間の関連を実装することも可能です。機能上は、Drupal と同様に、独自の投稿タイプと固有のフィールド設計が可能になっています。Drupal との大きな違いは、こうした機能が拡張プラグインで実現されていることと、カスタムフィールドが元々投稿の付随情報として用意されたものだということです。

カスタム分類

WordPress にはタクソノミーもあります。カテゴリー、タグ、リンクカテゴリー、投稿フォーマットという 4 つのデフォルト分類のほか、カスタム分類と呼ばれるユーザー定義の分類を作成することができます。分類も API で登録しますが、Custom Post Type UI を使用すれば管理画面からタクソノミーを作成することもできます。

参考：https://wpdocs.osdn.jp/カスタム分類

MovableType のカスタムフィールド

国内で WordPress と肩を並べるメジャーな CMS として MovableType（以下、MT） があります。MT はバージョン５までオープンソース版の MTOS が提供されていましたが、バージョン ６以降 MTOS の配布は終了となり、現状、最新版は商用 CMS という位置づけになります。さて、この MT の場合はどうでしょう。

MT には標準でカスタムフィールドを追加する機能が用意されています。WordPress のように追加プラグインを導入する必要はありません。スクリーンショットに示すように、テキストのほか、URL、日付、ビデオ、画像など、多様な種類のデータをカスタムフィールドとして追加できるようになっています。

MT6 ã®ã‚«ã‚¹ã‚¿ãƒ ãƒ•ã‚£ãƒ¼ãƒ«ãƒ‰è¿½åŠ ç”»é¢

ただし、MT も WordPress 同様、記事やページが常にコンテンツの基本であり、カスタムフィールドはその拡張データです。MT7 以前は Drupal のようなユーザー定義のコンテンツタイプという考え方はありませんでした。

しかし、2018 年 5 月にリリースされた MT7 では、新たにコンテンツタイプが導入され、従来のブログ記事やウェブページに代わる、自由に構造を定義できる仕組みが提供されました。

https://www.slideshare.net/swordbreaker/movable-type-7-80522292

Drupal の視点から

このように、今日では WordPress や MT でも独自のコンテンツタイプやフィールド構造を定義できることがわかります。ただ、ブログソフトウェアとしての成り立ちはまだ色濃く残っており、構造化コンテンツを管理するための汎用的な基盤システムとして見た場合、やはり Drupal に一日の長があることは否めないように思います。これは、過去紹介してきた Drupal の歴史を見てもそう感じるのではないでしょうか。以前も指摘したように、これは製品の優劣ではなく、それぞれの目指してきたものの違いによると言えるでしょう。

また、フィールドの扱いにも象徴的な違いがあります。Drupal のフィールドタイプは情報の種類（プログラム言語でいうデータ型）を表すものですが、他方 WordPress や MT におけるフィールドのタイプは、そのデータを入力するフォーム部品もイメージしたもののように見えます。たとえば、Drupal のフィールドタイプには「真偽値」や「リスト」はあっても、チェックボックスやセレクトボックス/ドロップダウンはありません。Drupal では、フィールドに格納するデータそのものとその入力部品とは別の情報として扱われます。Drupal でフィールドを追加するときには、フィールドタイプとは別に、入力フォームの部品（ウィジェット）や多重度を指定する手順をとります。

Drupalのフィールドを追加する時の選択肢

プログラミングやデータ設計をイメージすれば Drupal のアプローチは自然ですが、コンテンツの付随情報としてのフィールドには無用に複雑な仕組みと感じられるかもしれません。こういったところにも、常に Web コンテンツ前提で情報管理の仕組みを考えてきたシステムと、より一般化されたデータモデルへの適用を意識して変化を重ねてきたシステムとの違いが垣間見えるのではないかと思います。

Drupal ではバージョン 7 でエンティティの考え方が導入され、Web コンテンツに限定しない任意のビジネスデータを Drupal の API で統一的に扱うことが可能になりました。これは現在の Drupal 8 にも受け継がれ、新しいツールと相まって、より洗練された開発指向の環境へと進化しています。たとえば、Drupal Console ã¨ã„うツールを使うと、エンティティを定義するモジュールを自動生成し、1行もコーディングすることなく独自のエンティティを組み込むことができます。自動生成されるコードはエンティティのモデル定義、表示や編集のためのテンプレート、ルーティング、テストコードなど多岐にわたります。仕様を与えて対応するプログラムコードを自動生成させるところは、Ruby on Rails の scaffold などと似ているかもしれません。

Drupal Console を利用して Company エンティティのモジュールを生成する例

自動生成されたソースファイル群

こうして登録したエンティティは、プログラムコードから操作することも、コンテンツタイプと同様 Drupal の管理 UI から操作することもできます。CMS の機能として発達してきた仕組みが開発プロセスの中でも活用できるわけです。

生成したエンティティの構造を管理画面で編集

Drupal は CMS であると同時に、API、開発ツール、コア実装と管理 UI を組み合わせた独特の開発スタイルに基づく開発環境と見ることもできます。この環境は、認証、デザインテーマ、多言語対応など、CMS が得意とする機能を基本要件とする大規模な Web システムの構築で大きな力を発揮するはずです。

まとめ

今回は、国内で広く使用されている WordPress や MT の投稿タイプと分類の取り扱いを Drupal と比較してみました。コンテンツの構造や分類を柔軟に設計できる手段を古くから提供してきた Drupal と、ブログやホームページ制作といった個別用途のソフトウェアとして発展してきた CMS との違いを感じていただけたでしょうか。次回はブロックシステムを紹介したいと思います。