パーマリンクURLを生成するという考え方に基づいたWordPress設計

生成できるURLの種類

パーマリンク設定は「投稿名(/%postname%/)」になっている前提で説明。

投稿(post_type=post)

投稿はアーカイブページとシングルページを生成する。
アーカイブページは設定によるが一般的には /root/ となる。

アーカイブページURL: /root/
シングルページURL: /root/{$postname}/

固定ページ(post_type=page)

固定ページはシングルページのみ生成する。

シングルページURL: /root/{$postname}/

カスタム投稿タイプ

カスタム投稿タイプはアーカイブページとシングルページを生成する。

アーカイブページURL: /root/{$post_type}/
シングルページURL: /root/{$post_type}/{$postname}/

カスタムタクソノミー(カテゴリー、タグ)

カスタムタクソノミーはアーカイブページのみ生成する

/root/{$post_type}/{$taxonomy}/{$term}/

以上がWordPressの基本的なURL体系であり、まとめると下記表のようになっている。

オブジェクト アーカイブページ シングルページ
投稿 /root/ /root/{$postname}/
固定ページ /root/{$postname}/
カスタム投稿タイプ /root/{$post_type}/ /root/{$post_type}/{$postname}/
カスタムタクソノミー /root/{$post_type}/{$taxonomy}/{$term}/

すなわち、記事を投稿するということはURLを生成すること、と言い換えることもできる。

固定ページとカスタム投稿タイプアーカイブのURLの違い

“photo” という投稿名の固定ページを作成すると /root/photo/ というURL(シングルページURL)が生成される。
“photo” という名前のカスタム投稿タイプを定義すると /root/photo/ というURL(アーカイブページURL)が生成される。

どちらも同じURLが生成されるが、用途によってどちらを使うべきかは明確に判断できる。

投稿コンテンツが存在して編集可能にしたい場合は固定ページを使い、URLだけが欲しい場合はカスタム投稿タイプを使う。

例を示す。

例)動的なサイトマップを作成したい。

サイトマップは自動的に生成されるものとし、欲しいURLは /root/sitemap/ とする。

固定ページでURLを生成する場合

  1. “sitemap”という投稿名の固定ページを作成する。
     /root/sitemap/ というURL(シングルページURL)が生成される。
  2. page-sitemap テンプレートを作成する。

カスタム投稿タイプでURLを生成する場合

  1. “sitemap”という名前のカスタム投稿タイプを定義する(has_archive=true, show_ui=false)。
     /root/sitemap/ というURL(アーカイブURL)が生成される。
  2. archive-sitemap.php テンプレートを作成する。

どちらも同じURLが生成されてフロントの表示は実装できるが、この場合はカスタム投稿タイプを使うべきである。

固定ページを使った場合、管理画面のユーザが触れるところにURLの実体=記事が存在することになり、誤って固定ページを削除してしまうとURLは消滅して404になりかねない。
また、デフォルトだと固定ページの編集画面にはコンテンツ入稿フィールド(content)が存在するが、ここに入稿してもフロントにはなにも反映されないため、無駄な入稿UIと言える。

一方、カスタム投稿タイプとして定義し、show_ui=falseを設定しておくことで、管理画面のユーザが触れるところにURLの実体は存在しないので、誤ってパーマリンクが消滅するのを防ぐことができる。

さらに、カスタム投稿タイプの定義をテーマに内包してしまうことで archive-sitemap.php テンプレートとセットで完全なテーマとすることができる。
テーマを有効化しただけでサイトマップのページが生成される。
固定ページの場合だと、まず固定ページを作成しなければならない。

カスタムタクソノミーについて

カスタムタクソノミーを定義するとタームでソートされたアーカイブページのURLを生成する。
ここでも重要なのは、URLを生成することに意味があるかどうかという点である。
もしURLは不要でソート機能だけ実装したいということであれば、必ずしもカスタムタクソノミーを定義する必要はなく、他の方法でも実装可能ということになる。

比較となるのはカスタムフィールド=メタデータである。
あらかじめ定義された選択肢のなかからメタデータを登録させ、URLパラメーターなどでソートさせる方法もある。

また、カスタムタクソノミーを定義すると、管理画面のユーザが触れるところにURLの実体を配置することになり、URLの生成もユーザに許可することを意味する。

よって、カスタムタクソノミーを使うべきかカスタムフィールド等を使うべきかも、やはりURLを生成する必要性を考えれば明確になってくる。

コメントを残す