中小企業のどんな悩みにも寄り添って一緒に解決する愛知県の経営コンサルタント

メニュー

カスタムタクソノミーを追加できるWordPressの関数「register_taxonomy」の使い方まとめ

最終更新日:

公開日:2014年05月02日

WordPress

どうも、くーへいです。

かなり前に”カスタム投稿タイプを作成できるWordPressの関数「register_post_type」の使い方まとめ”を書きましたが、今回は切っても切れない関係と言っても過言ではない「カスタムタクソノミー」を追加する「register_taxonomy」について、その使い方をまとめてみます。

「カスタムタクソノミー」とは

「カスタムタクソノミー」とは、「WordPress」の初期機能である「投稿」でいうところの「カテゴリ」や「タグ」にあたります。
階層化できる「カスタムタクソノミー」が「カテゴリ」、階層化できない「カスタムタクソノミー」が「タグ」に近いイメージです。

「カスタムタクソノミー」は「カスタム投稿タイプ」とともに使用することができ、「カスタム投稿タイプ」で投稿された記事を「カテゴリ」に分けることが可能です。
(「カスタムタクソノミー」は既存の「投稿」等でも使用できます。)

「register_taxonomy」とは

「register_taxonomy」は「カスタムタクソノミー」を追加するための関数で、主に「functions.php」で使用します。

「register_taxonomy」の書き方

記述例

「カスタムタクソノミー」のみを作成する場合は以下のように記述します。

add_action('init', 'register_blog_cat_custom_post');
function register_blog_cat_custom_post() {
	register_taxonomy(
		'blog_cat',
		'blog',
		array(
			'hierarchical' => true,
			'label' => 'ブログのカテゴリ',
			'show_ui' => true,
			'query_var' => true,
			'rewrite' => true,
			'singular_label' => 'ブログのカテゴリ'
		)
	);
}

しかし、「カスタムタクソノミー」は「カスタム投稿タイプ」と一緒に使う場合もありますので、その際は以下のように記述することが多いと思われます。

add_action('init', 'register_blog_custom_post');
function register_blog_custom_post() {
	register_post_type(
		'blog', array(
			'label' => 'ブログ',
			'description' => '',
			'public' => true,
			'show_ui' => true,
			'show_in_menu' => true,
			'menu_position' => 5,
			'capability_type' => 'post',
			'hierarchical' => false,
			'rewrite' => true,
			'query_var' => true,
			'has_archive' => true,
			'exclude_from_search' => true,
			'supports' => array('title','comments','author'),
			'taxonomies' => array('blog_cat'),
			'labels' => array(
				'name' => 'ブログ',
				'singular_name' => 'ブログ',
				'menu_name' => 'ブログ',
				'add_new' => '新規追加',
				'add_new_item' => 'ブログの新規追加',
				'edit' => '編集',
				'edit_item' => 'ブログの編集',
				'new_item' => '新しいブログ',
				'view' => '表示',
				'view_item' => 'ブログのブログ',
				'search_items' => 'ブログの検索',
				'not_found' => '見つかりません',
				'not_found_in_trash' => 'ゴミ箱にはありません。',
				'parent' => '親',
			)
		)
	);
	register_taxonomy(
		'blog_cat',
		'blog',
		array(
			'hierarchical' => true,
			'label' => 'ブログのカテゴリ',
			'show_ui' => true,
			'query_var' => true,
			'rewrite' => true,
			'singular_label' => 'ブログのカテゴリ'
		)
	);
}

「register_taxonomy」のパラメータ

Codexを参考に、「register_taxonomy」のパラメータをまとめてみました。

基本形

<?php register_taxonomy($taxonomy, $object_type, $args); ?>

$taxonomy

文字列で指定します。必須項目です。

「カスタムタクソノミー」の名称を指定できます。(categoryなどの予約語は使用不可)
英数字で指定し、大文字やスペースを含めることはできません。32文字を超えてもいけません。(データベースの構造による制限らしいです)
ここで指定した文字列がURLに反映される場合があります。

初期値:null

$object_type

文字列で指定します。必須項目です。配列を用いて複数使用することもできます。

「カスタムタクソノミー」を使用するオブジェクトタイプ(postやpage、カスタム投稿タイプなど)を指定します。

初期値:null

初めから組み込んであるオブジェクトタイプ

  • post(投稿)
  • page(固定ページ)
  • attachment(メディア)
  • revision(リビジョン)
  • nav_menu_item(メニュー)

カスタム投稿タイプ

「カスタム投稿タイプ」を指定する際は、大文字やスペースを含んではいけません。

null

nullを明示的に指定しても、「カスタムタクソノミー」が登録されます。しかし、どのオブジェクトにも関連付けられないため、管理画面からは使用できません。その場合は、「register_post_type()」の「taxonomy」で手動で登録するか、「register_taxonomy_for_object_type()」を使用する必要があります。

$args

文字列で指定します。配列を用いることもできます。必須項目ではありません。

初期値:null

$argsの設定値

label

文字列で指定します。

「カスタムタクソノミー」の名前を指定します。日本語等も使用できます。
labelsのnameに上書きされます。

labels

配列で指定します。どのパラメーターも日本語が使用できます。

「カスタムタクソノミー」の各ラベルを指定します。
hierarchicalがfalseの場合は「タグ」、trueの場合は「カテゴリ」のラベルが初期設定として使用されます。

labelsを指定しないと、nameにはlabelの値が、singular_nameにはnameの値が指定されます。

  • name・・・一般的な名称。複数形の名称を登録しますが、日本語の場合はあまり関係ないでしょう。
  • singular_name・・・単数形の名称を登録しますが、日本語の場合はあまり関係ないでしょう。
  • menu_name・・・メニューの名前。たぶん管理画面のサイドバーでいうと、アイコンのある部分だと思いますが、試したことがありません・・・。
  • all_items・・・カテゴリーでいうと、記事投稿画面の「カテゴリー一覧」
  • edit_item・・・カテゴリーでいうと、「編集」
  • view_item・・・カテゴリーでいうと、「表示」
  • update_item・・・カテゴリーでいうと、「更新」
  • add_new_item・・・カテゴリーでいうと、「新規カテゴリーを追加」
  • new_item_name・・・カテゴリーでいうと、新規追加画面の「名前」
  • parent_item・・・カテゴリーでいうと、新規追加・編集画面の「親」
  • parent_item_colon・・・カテゴリーでいうと、新規追加・編集画面の「親」
  • search_items・・・カテゴリーでいうと、「カテゴリーの検索」
  • popular_items・・・カテゴリーでいうと、記事投稿画面の「よく使うもの」
  • separate_items_with_commas・・・カテゴリーでいうと、記事投稿画面の「タグが複数ある場合はコンマで区切ってください」
  • add_or_remove_items・・・JavaScriptが無効の時の記事投稿画面の追加もしくは削除に使用されるテキスト。hierarchicalがtrueの際には使われません。初期値は「追加もしくは削除」もしくはnull
  • choose_from_most_used・・・カテゴリーでいうと、記事投稿画面の「よく使われているタグから選択」。hierarchicalがtrueの際には使われません。
  • not_found (3.6+)・・・「よく使われているタグから選択」をクリックしたときに、タグがない場合に表示される文字。初期値は「タグが見つかりませんでした。」

public

trueかfalseで指定します。

このタクソノミーを管理画面に表示するかどうかを指定します。

初期値:true

show_ui

trueかfalseで指定します。

このタクソノミーをデフォルトの管理画面で管理するかどうかを選択します。
デフォルトの管理画面で管理しない、となると、独自に管理画面を実装するか、関数等で管理する必要があります。

初期値:値が設定されていない場合はpublicの設定値が初期値になります。バージョン3.5ではattachmentでfalseにすると、管理画面に表示されなくなるようです。(メディアのメニューの話でしょうか?)

show_in_nav_menus

trueかfalseで指定します。

trueだと、このタクソノミーがナビゲーションメニューで選択できるようになります。ナビゲーションメニューとは、管理画面のサイドバーを指します。

初期値:値が設定されていない場合はpublicの設定値が初期値になります。

show_tagcloud

trueかfalseで指定します。

trueにすると、このタクソノミーでタグクラウドウィジェットが使用できるようになります。

初期値:値が設定されていない場合はshow_uiの設定値が初期値になります。

meta_box_cb

コールバック関数を指定します。

バージョン3.8以降で使用可能で、メタボックスの表示に使用されるコールバック関数名を指定できます。
メタボックスとは、記事投稿画面の右サイドバーにある、「カテゴリー」や「タグ」などのボックスを示します。
hierarchicalがtrueのタクソノミーの場合は、カテゴリーでも使用されている「post_categories_meta_box()」(meta-boxes.php内に記述有)が使用されます。hierarchicalがfalseのタクソノミーの場合は、タグでも使用されている、「post_tags_meta_box()」が使用されます。
「meta_box_cb」にfalseを設定すると、メタボックスは何も表示されません。

初期値:null

show_admin_column

trueかfalseで指定します。

バージョン3.5以上で使用可能で、「カスタム投稿タイプ」の一覧画面で、記事の持つ「カスタムタクソノミー」が表示されるようになります。初期の「投稿」の一覧画面で「カテゴリー」や「タグ」が表示されているのと同じイメージです。

初期値:false

hierarchical

trueかfalseで指定します。

階層構造を持つかどうかを指定します。trueだと「カテゴリー」のように、falseだと「タグ」のように振る舞います。
つまり、trueのタクソノミーは、投稿画面でチェックボックスにてタクソノミーを指定します。falseのタクソノミーは、投稿画面で空のテキストボックスがあり、そこにターム(タクソノミーの中の値1つ1つをタームと呼びます)を指定します。

初期値:false

update_count_callback

文字列で指定します。

※説明文が把握しきれなかったので、僕が勝手に解釈した日本語と英語の両方を掲載しておきます。

「投稿」のような、オブジェクトタイプのカウントが更新された際に呼び出される関数名を指定します。いわゆる「フック」のように動きます。

初期値は空です。「wp_update_term_count_now()」によってカウントの更新が実行されるとき、もしそのタクソノミーが1つの投稿タイプに関連付けられている(ユーザーのように他のワードプレスのオブジェクト違う形で)場合、「_update_post_term_count()」関数はタームに関連付けられた公開中の投稿のみをカウントに使うが、そうでなければ「_update_generic_term_count()」が代わりに使用され、そのような(カウントを更新する)処理は行われない。
この点が重要になるのはメディアの場合で、なぜならメディアは「投稿」のタイプなので、デフォルトでは「_update_post_term_count()」を使用している。しかし、ほかの投稿に関連付けられているメディアも数えてしまうので、望ましくありません。これが意味するのは、メディアは単純にワードプレスがメディアライブラリーに使用しているが、ほかの投稿に関連されたものはカウントしていないということです。もし、文章を管理するツールとしてメディアライブラリを活用するためにタクソノミーを利用する意図があった場合、投稿に関連付けられたメディアよりも、関連付けられていないカウントに興味を持っているでしょう。そのような場合、「update_count_callback」に「_update_generic_term_count」を指定して「_update_generic_term_count()」関数を使用するように指定する必要があります。

初期値:None – but see Note, below.

Note: While the default is ”, when actually performing the count update in wp_update_term_count_now(), if the taxonomy is only attached to post types (as opposed to other WordPress objects, like user), the built-in _update_post_term_count() function will be used to count only published posts associated with that term, otherwise _update_generic_term_count() will be used instead, that does no such checking.

This is significant in the case of attachments. Because an attachment is a type of post, the default _update_post_term_count() will be used. However, this may be undesirable, because this will only count attachments that are actually attached to another post (like when you insert an image into a post). This means that attachments that you simply upload to WordPress using the Media Library, but do not actually attach to another post will not be counted. If your intention behind associating a taxonomy with attachments was to leverage the Media Library as a sort of Document Management solution, you are probably more interested in the counts of unattached Media items, than in those attached to posts. In this case, you should force the use of _update_generic_term_count() by setting ‘_update_generic_term_count’ as the value for update_count_callback.

query_var

trueかfalseもしくは文字列で指定します。

falseの時はquery_varが無効になるので、デフォルトの$taxonomyやタクソノミーの「name」の代わりに独自の文字列を設定します。

初期値:$taxonomy

rewrite

trueかfalseもしくは配列で指定します。

falseに設定すると、自動的にパーマリンクが書き換えられるのを防ぎます。下記を配列で設定することで、デフォルトのURLを上書きすることができます。

  • slug・・・例えば「/tag/」のようなきれいなパーマリンクになります。初期値はタクソノミーの「name」
  • with_front・・・フロントベースがパーマリンクの前に付記されます。初期値はtrue
  • hierarchical・・・trueにすると、URLの階層化を許可します。(バージョン3.1で実装されました)初期値はfalse
  • ep_mask・・・このタクソノミーにエンドポイントマスクを割り当てます。初期値はEP_NONE。(より詳しい情報は割愛してます)

この設定を変更した場合は、リライトルールを更新しないといけません。リライトルールを更新するには、管理画面の「設定」、「パーマリンク設定」で「変更を保存」ボタンを押す(値を変更する必要ありません)。もしくは、「$wp_rewrite->flush_rules()」を実行します。タクソノミーを作成した後にだけ更新する必要がありますが、プラグインやテーマをロードするたびに更新する必要はありません。

初期値:true

capabilities

配列で指定します。

このタクソノミー独自の権限を生成します。

初期値:None

ちなみに、何も設定しないと、以下のような権限が割り当てられています。

  • manage_terms・・・manage_categories
  • edit_terms・・・manage_categories
  • delete_terms・・・manage_categories
  • assign_terms・・・edit_posts

sort

trueかfalseで指定します。

タームが追加された際に順序を記憶するかどうかを指定します。

初期値:None

_builtin

trueかfalseで指定します。通常は使用しない設定です。

このタクソノミーがビルドインかどうかを設定します。
ワードプレス自体の開発者のみが使うもので、ワードプレスの使用者が設定するのは推奨されません。

初期値:false

まとめ

「register_taxonomy」は設定値が少ないですが、重要な項目が多く存在します。
一つ一つの項目をきっちり確認して設定しないと、404エラーが頻発してはまってしまうかもしれません!

カスタム投稿タイプを作成する「register_post_type」については、以下の記事を参考にしてください。

カスタム投稿タイプを作成できるWordPressの関数「register_post_type」の使い方まとめ

関連記事

ご相談受付中です IT・DX・SEO・経営・・・幅広く中小企業のお悩みに寄り添います

スポンサードリンク