register_taxonomy()は分類名、対象post type、公開範囲、URLを分けて登録する

WordPressで独自の分類を追加するときは、register_taxonomy()の引数を並べる前に、何を分類し、誰がどこで使うかを決めます。分類のkeyと画面に出す名前、対象となるpost type、階層の有無、管理画面への表示、公開URLを分けてください。

publicだけで全部を決めようとすると、編集画面へ必要な分類が出なかったり、公開しない分類のURLが作られたりします。管理用の分類と、訪問者がたどる公開分類では、必要な値が違います。

第一引数は分類のkeyでlabelsは画面の名前を決める

register_taxonomy()の第一引数は、WordPressが分類を識別するkeyです。管理画面へ表示する名称ではありません。WordPress 4.0では、keyは32文字以内にします。表示名は第三引数のlabelsへ書きます。

たとえば、資料を主題別に分類する場合、keyをguide_topic、複数形と単数形の表示名を「資料分類」として登録できます。表示文言を変えてもkeyは変えず、保存済みのtermやtemplateが参照する識別子を保ちます。

add_action( 'init', 'example_register_guide_topic' );

function example_register_guide_topic() {
    register_taxonomy(
        'guide_topic',
        'post',
        array(
            'labels' => array(
                'name'          => '資料分類',
                'singular_name' => '資料分類',
            ),
            'hierarchical'      => true,
            'public'            => true,
            'show_ui'           => true,
            'show_admin_column' => true,
            'rewrite'           => array(
                'slug'       => 'guide-topics',
                'with_front' => false,
            ),
        )
    );
}

これは説明用の仮例です。実在するサイトの分類名やコードではありません。

第二引数は分類を使えるpost typeを限定する

第二引数のobject_typeには、分類を結び付けるpost typeを指定します。上の例ではpostだけが対象です。複数のpost typeで共用するなら、配列で指定します。

array( 'post', 'case' )

分類を登録しただけでは、あらゆる内容へ自動で使えるようにはなりません。記事と事例で同じtermを共有する必要があるのか、それぞれ別の分類にするのかを先に決めます。共有すると、一つのterm archiveへ異なるpost typeの内容が集まります。更新担当者が同じ言葉を同じ意味で使える場合だけ共用します。

hierarchicalは分類の入力方法と親子関係を変える

hierarchicalがtrueなら、categoryのように親子関係を持つ分類になります。falseなら、tagのように階層を持たない分類になります。見た目の好みではなく、分類語に上下関係があるかで選びます。

「広告」の下へ「検索広告」と「display広告」を置くように、上位概念と下位概念を運用するなら階層が役立ちます。一方、「JavaScript」「WordPress」のように、複数の観点から横断して付ける語なら、階層を持たせない方が自然です。

階層を深くできることと、深くする必要があることは別です。担当者がtermを選ぶたびに親子関係を迷うなら、分類表を先に作るか、階層を減らします。

publicと管理画面とnavigationを別々に考える

WordPress 4.0のregister_taxonomy()では、publicの初期値はtrueです。show_uiを省略するとpublicを引き継ぎ、show_in_menuはshow_uiを引き継ぎます。show_in_nav_menusはpublic、show_tagcloudはshow_uiを引き継ぎます。

これらは役割が同じではありません。

管理画面では使うが、訪問者向けの分類URLを作らない場合は、意図を個別に書きます。

register_taxonomy(
    'editor_note',
    'post',
    array(
        'labels'            => array( 'name' => '編集区分' ),
        'public'            => false,
        'show_ui'           => true,
        'show_in_menu'      => true,
        'show_in_nav_menus' => false,
        'show_tagcloud'     => false,
        'rewrite'           => false,
        'query_var'         => false,
    )
);

この仮例は、分類を秘密にする仕組みではありません。公開template、query、権限、backupへの出力は別に確認します。

rewriteは分類archiveのURLを決める

rewriteは、term archiveのURLを作る規則です。trueではtaxonomy keyがslugの基準になり、配列を渡すとslug、with_front、階層付きURLなどを指定できます。公開URLが不要ならfalseにします。

分類keyと公開slugを分ける場合は、両方を運用記録へ残します。keyはcodeと保存データが参照し、slugは内部link、外部link、XMLサイトマップが参照するためです。公開後にslugを変えるなら、旧term URLから新URLへの転送も必要になります。

query_varも、URLから分類を問い合わせる入口です。公開しない分類では、rewriteだけでなくquery_varも止めるかを確認します。管理画面へ出すかどうかと、front endのURLで取得できるかどうかを混同しないでください。

登録後は入力画面と公開URLの両方を確認する

実装後は、次の順で一つのtermを試します。

1. 対象post typeの編集画面でtermを選べるか
2. 投稿一覧の分類列が必要どおりに出るか
3. term archiveが意図したslugで開くか
4. archiveへ対象外のpost typeが混ざらないか
5. navigation menuへ出すか出さないかが設計どおりか

分類の登録を外部へ任せても、taxonomy key、対象post type、親子関係、公開slug、termを追加できる担当者はサイト運営側で記録します。codeの納品だけでは、分類語を増やす基準や、既存termを統合する責任までは残りません。

最初の一手は、分類名を考えることではありません。分類したい内容を一つ選び、その分類を使うpost type、親子関係、管理画面、公開URLの四項目を一行ずつ決めてください。