WordPress 4.4の非公開taxonomyは表示しないだけでなく公開queryを確認する

WordPressで管理用のtaxonomyを作るなら、読者がURLから絞り込める分類と同じものとして扱ってはいけません。WordPress 4.4では、publicをfalseにして登録したtaxonomyを公開queryできなくなります。更新前に見るべきなのは、管理画面へ分類欄が出るかだけではなく、そのtaxonomyを使って公開ページの投稿を絞り込んでいないかです。

管理画面で記事を整理するための分類と、読者がarchiveやリンクからたどる分類は役割が違います。非公開にしたい分類を、テーマの特集一覧や関連投稿の条件に使っていたなら、更新後にその一覧が期待どおり出ない可能性があります。分類を見せるかどうかと、分類で公開ページを作るかどうかを、登録時に一緒に決めます。

管理用の分類と公開用の分類を分ける

WordPressのtaxonomy変更の案内は、WordPress 4.4でpublic => falseとして登録したtaxonomyが公開queryされないことを案内しています。この変更は、分類名をメニューから隠すだけの指定ではありません。公開画面でそのtaxonomyを条件に投稿を探す処理まで関わります。

たとえば、編集担当者が「確認待ち」「写真未着」のように投稿の制作状況を分けるなら、その分類は読者に見せるためのものではありません。一方、「講座」「事例」「お知らせ」のように読者が読みたい記事を探すための分類なら、一覧ページ、リンク、表示する投稿の基準まで設計します。同じ投稿に付ける分類でも、目的が違えば一つのtaxonomyへ混ぜない方が安全です。

公開用のtaxonomyでは、読者が分類名を理解できることも必要です。社内だけで使う略語や作業順をそのまま表示すると、一覧に何があるか分かりません。逆に、読者向けの分類を社内の進行管理にも使うと、制作途中の事情が分類に混ざります。管理の都合と読む人の探し方は分けます。

更新前に公開queryを使う場所を探す

独自taxonomyがあるサイトでは、register_taxonomy()だけでなく、そのtaxonomyを読んでいる処理を確認します。投稿一覧、taxonomy archiveへのリンク、テーマ内のWP_Query、検索フォーム、関連投稿、外部連携のどこで使うかによって、更新後に確認するページが変わります。

1. 独自taxonomyの名前とpublic設定を一覧にする。
2. 各taxonomyが管理用か、公開導線用かを一文で決める。
3. 公開導線用なら、archive、リンク先、絞り込みページを一件ずつ開く。
4. 管理用なら、投稿編集画面で選択と保存ができるかを確認する。
5. themeまたはpluginが投稿を絞り込む条件に使っている場合は、その一覧も確認する。

確認は、管理者でログインした画面だけでは足りません。公開ページで分類リンクを押し、想定した投稿が並ぶか、URLを直接開いたときに意図しない内容が出ないかを見ます。非公開のtaxonomyなら、読者へ出す一覧が別の公開用taxonomyや別の条件で組み立てられているかを確認します。

関連投稿にも注意します。テーマが投稿に付いたtermを読んで似た記事を選ぶ作りなら、公開用ではないtaxonomyを条件に含めるべきかを考えます。編集者だけが付ける作業用のtermで関連記事が決まると、投稿を整理し直しただけで読者に見せる組み合わせまで変わります。関連記事を読者の探し方として出すなら、公開用の分類、投稿日時、固定した表示条件のどれを使うかを明示します。

外部のpluginについても、更新直後に一覧が空になったからといって、taxonomyをすぐpublic => trueへ戻す判断は急ぎすぎです。その分類を公開してよいのか、表示したい投稿をどの条件で選ぶのか、URLを持たせる必要があるのかを分けて確認します。問題が独自themeのqueryにあるなら、設定を公開へ戻しても、分類設計の混同は残ります。

公開しないtaxonomyを後から公開用へ変える場合も、設定だけを変えて終えられません。URLの形、archive template、投稿に付いているterm、空の一覧をどう扱うかまで決めます。反対に、公開用だったtaxonomyを管理用へ変える場合は、既存のリンクや検索結果から来た読者の入口が失われないかを先に調べます。

分類を非公開にしても権限の問題は残る

taxonomyを公開queryできなくしても、誰が編集できるかは別の問題です。管理用の分類ほど、変更できる担当者と、誤って付けたときに直す手順を決めておく必要があります。公開されないからといって、値の意味が曖昧でよいわけではありません。担当者ごとに同じ作業を別の言葉で分類すれば、一覧を集計しても判断に使えなくなります。

最初の一手は、独自taxonomyを一つ選び、その分類を読者へ見せるのか、社内整理だけに使うのかを一文で決めることです。両方の答えが必要なら、分類か表示設計を分けます。公開範囲を後から推測しなくてよい状態にしておけば、WordPressを更新するときも確認する画面を絞れます。

分類の名前、用途、公開範囲を一覧にしておけば、新しい担当者がテーマのqueryを見たときも、なぜその条件を使っているかを判断できます。分類が増えるたびに、管理用か公開用かを決めずに追加すると、後からURLや一覧の役割を直す作業が大きくなります。分類を作る時点で、読者が使う入口か、編集のための印かを残します。