WordPress 4.6のWP_Term_Queryはcategoryとtagを取る条件を先に分ける

categoryやtagの一覧をthemeへ出すとき、先に決めるのはqueryの書き方ではありません。どのtaxonomyから、どのtermを、どの順で、どのpageへ出すかです。WordPress 4.6のWP_Term_Queryはtermを取得する仕組みを整理しますが、siteの分類方針まで決めるものではありません。

4.6ではWP_Term_Queryが加わり、get_terms()はこのclassを呼ぶwrapperになります。これまでのget_terms()の使い方は後方互換を目指し、term_taxonomy_idでのqueryにも対応します。したがって、既存themeを新しいclass名へ一括で書き換える前に、何を表示するためのqueryかを確認します。

一覧に出したtermは、利用者にとってsiteの案内になります。categoryを並べれば、どんな内容があるsiteかを伝えます。tagを大量に並べれば、細かい言葉を探せる場合もありますが、似た名前や使われていない分類まで見せることになります。queryが全termを返せることと、全termを公開画面に置くことは別です。

分類を作ることと、一覧へ出すことを分ける

termを取得できても、すべてをnavigationやsidebarへ出す理由にはなりません。

説明用の仮例として、サービス一覧を独自taxonomyで管理し、footerには主要な三分類だけを出すsiteを考えます。get_terms()で全termを取れても、受付を終えたserviceや準備中の分類までfooterへ出すと、利用者は現在選べる内容を判断できません。取得条件と公開する範囲を別に決めます。

たとえば「制作」「運用」「広告」の三分類だけをfooterに出すなら、各分類にどの投稿を入れるかも確認します。分類名だけがあり、archiveに記事がない状態では、linkを開いた人が次に読めません。反対に、社内の整理用に作った細かなtermまでfooterへ出すと、利用者は選択肢の多さに迷います。分類を作る目的と、navigationへ出す目的を一つにしません。

categoryとtagも同じ役割ではありません。categoryはsiteの大きな主題を分けるために使い、tagは記事の中で繰り返す具体的な論点をたどるために使う場合があります。どちらもtermとして取得できますが、表示する場所まで同じにする理由はありません。sidebarにcategoryだけを出し、記事下に関連するtagを出すなら、それぞれの取得条件と見せる理由を別に記録します。

親termと子termがあるtaxonomyでは、親だけを入口にするのか、子termまで並べるのかも決めます。親termの下に数十の子termをすべて出すと、navigationが長くなります。子termを隠すなら、archive内でどう案内するかを考えます。取得するtermの階層と、利用者が迷わず進める階層は同じとは限りません。

get_terms()を替える前に既存の表示を確認する

4.6でWP_Term_Queryが加わっても、一般的なget_terms()の出力が変わることを前提にしません。themeやpluginを変更するなら、次の順で確認します。最初に探すのは、source上の関数名だけではありません。header、footer、sidebar、記事下、custom page template、管理用の一覧のどこでtermを使っているかを確認します。同じget_terms()でも、用途が違えば確認する画面が違います。

1. get_terms()を使うtemplateとpluginを探す。
2. それぞれが取得するtaxonomy、条件、並び順を記録する。
3. 空のterm、非公開のterm、親termの扱いを確認する。
4. 4.6のtest siteで一覧、個別archive、管理画面を確認する。
5. classを直接使う必要がある箇所だけを変更し、結果を記録する。

説明用の仮例として、footerではhide_emptyの条件で使用中のtermだけを出し、管理画面の補助一覧では空のtermも出す構成を考えます。両方に同じqueryを使っているように見えても、必要な条件は違います。footer用の条件を管理画面へそのまま使うと、整理中のtermが見えなくなるかもしれません。逆に管理用の条件を公開画面へ使うと、記事のない分類が並びます。表示する場所ごとに、空のtermをどう扱うかを決めます。

term_taxonomy_idを使うqueryは、名前やslugを基にした分類より、dataの対応を意識する必要があります。管理画面でtermを作り直したときに同じものを指すとは限らないため、IDだけを手掛かりに画面の意味を決めません。IDへ依存する理由があるなら、どのtaxonomyのどのtermを指すかを記録します。分類名を変更した場合、archiveの見出し、link文言、説明文も同じ意味を保っているかを確認します。

並び順も公開画面の意味を変えます。名前順なら利用者は名称から探しやすくなります。任意順なら、事業側が優先して見せたい分類を上にできます。投稿数順にすると、内容の多い分類が目立ちますが、受付を始めたばかりの重要な分類は下へ回ることがあります。orderbyを指定する前に、その順で利用者へ何を伝えたいかを決めます。

test siteでは、一覧が出ることだけでなく、termを一つ増やしたときと、投稿を外して空になったときも確認します。新しいtermが意図しない場所へ出ないか、空になったtermが消える条件は正しいか、親子の順が変わらないかを見ます。公開pageのlinkを開き、archiveの見出しと説明文が分類名と合うかも確認します。queryの返り値だけでは、navigationとしての問題は分かりません。

queryの実装と分類方針を分ける

制作側はtermを取得するqueryを実装できます。しかし、どの分類を公開するか、古い分類を残すか、tagをnavigationへ出すかは、コンテンツの運用判断です。queryを替えることと、分類が利用者に伝わることは別です。制作側へ「tagを出してほしい」と頼む前に、どのtagを何のために見せるかを決めます。

頼むときは、taxonomy名、出すtermの条件、順番、表示場所、空のtermの扱い、link先archiveの扱いを渡します。制作側はqueryとtemplate、公開画面のlinkを確認します。事業側は、分類名、説明文、古い分類を残すかどうかを確認します。分類を増やす権限と、queryを実装する権限を同じ人が持たない場合も、変更を伝える経路を残します。

最初の一手は、現在出しているterm一覧を一つ選び、「taxonomy」「取得条件」「並び順」「出力page」「消す条件」を五行に分けて書くことです。次に、表示しているtermを一つ増やし、一つ空にして、公開画面でどう変わるかを確認します。五つが決まってからqueryを見直します。WP_Term_Queryは取得を整理する仕組みであり、分類の見せ方まで自動で整えるものではありません。