WordPress 4.7のWP_Taxonomyは分類を扱うcodeの戻り値とhook引数を確認する

WordPress 4.7へ更新するとき、独自の分類を使うthemeやpluginは、分類を扱うcodeの戻り値とhook引数を確認します。WordPress 4.7ではWP_Taxonomy classが加わり、get_taxonomy()はWP_Taxonomy objectを返します。一部のhookへ渡される分類の値も同じobjectになります。分類を画面へ表示しているだけのsiteで、すぐ書き換える必要はありません。しかし、値のclassを判定していたり、global変数を直接処理していたりするcodeは、更新前に見直す必要があります。

分類は、投稿を種類ごとに分けるための仕組みです。標準のcategoryやtagのほか、商品、地域、施工例のような独自の分類を登録できます。分類を追加することと、その内部の値を直接操作することは別です。register_taxonomy()やget_taxonomy()のようにWordPressが用意したfunctionを通して扱っている箇所と、$wp_taxonomiesを直接読んだり書き換えたりしている箇所を分けて確認します。

更新前に確認するcodeを絞る

WordPress 4.7の変更で最初に確認するのは、分類の名前ではありません。分類を受け取ったあと、その値を何として扱っているかです。get_taxonomy()を呼び出してlabelやrewrite設定を読むだけなら、まず実際の表示を確認します。一方、返ってきた値が特定のclassかどうかを調べるcode、arrayへ変換して別のfunctionへ渡すcode、globalの$wp_taxonomiesを直接変更するcodeは、処理の前提を読み直します。

たとえば、商品用のproduct_typeというcustom taxonomyを登録し、管理画面の操作を補うpluginがあるとします。そのpluginがget_taxonomy( 'product_type' )の結果について、昔のclass名と一致するかを調べてから処理しているなら、更新後に条件が通らないおそれがあります。逆に、name、label、rewriteのようなpropertyを読むためだけにfunctionを使っているなら、先にclass名を書き換えるのではなく、管理画面と公開pageで必要な表示を確認します。確認する理由が違うためです。

「objectになった」と聞くと、分類を使うcodeを全部作り直したくなります。しかし、正常に動いているpublic APIまで一斉に置き換える必要はありません。更新の目的は新しい書き方へそろえることではなく、siteの分類、URL、絞り込み、管理画面の操作を壊さないことです。変更の影響がある条件を先に絞れば、必要のない修正を増やさずに済みます。

global変数を便利な設定置き場にしない

$wp_taxonomiesはWordPressが管理するglobal変数です。分類の一覧を見たいだけなら、これを直接使うより、目的に合うfunctionで取得する方が、codeが何をしたいのか分かりやすくなります。globalの内部構造へ依存すると、WordPress本体が内部を整理したときに、表示のためのcodeまで更新対象になります。

ここでいう「直接変更」は、分類の公開範囲やlabelを決めるためにregister_taxonomy()を使うことではありません。登録済みの分類を取得して、global配列の中身を書き換えることです。分類を追加したいなら、登録する場所、対象のpost type、公開URL、管理画面で使うかどうかをregister_taxonomy()の引数で決めます。すでに登録された分類へ後から値を押し込むと、登録順やほかのpluginとの関係が読み取りにくくなります。

説明用の仮例として、制作会社が商品分類のlabelをサイトごとに変えられるよう、theme内で$wp_taxonomies['product_type']へ直接値を入れている場合を考えます。この方法では、何が登録時の設定で、何が表示直前の上書きなのかを後から区別しにくくなります。WordPress 4.7への更新で表示が変わらなかったとしても、分類の設定をどこで決めるかは整理しておく方がよいでしょう。設定を依頼する側も、分類名だけでなく、対象の投稿、URL、管理画面の表示、既存記事へ与える影響を渡します。

分類は閲覧者にも見えることがあります。product typeのarchive URLや記事下のlinkが変われば、管理画面だけの問題では済みません。制作する人が内部のcodeを直す仕事と、運用する人が分類名や公開範囲を決める仕事を分けます。依頼時に「taxonomyを4.7対応にする」とだけ伝えても、公開URLを守るのか、管理画面の表示をそろえるのか、既存記事の分類を変えるのかは決まりません。

stagingで分類の入口と出口を一組で確かめる

確認は、更新後にerrorが出たかどうかだけで終えません。分類を使うsiteでは、管理画面の入力と公開pageの出力を一組で確認します。まずstaging環境かbackupから戻せる複製環境へWordPress 4.7を入れます。次に、独自の分類を使うpost typeを一つ開き、分類を選ぶ、保存する、公開pageを開く、分類archiveを開く、の順で確かめます。

確認対象は、すべての記事を読むことではありません。分類を使う条件が異なる投稿を選びます。分類を一つだけ付けた投稿、複数付けた投稿、分類を付けない投稿、古い投稿の四つがあれば、一覧表示と個別表示の違いを見つけやすくなります。商品分類なら、商品一覧の絞り込み、個別商品へのlink、分類archiveのtitleも確認します。どの画面を開いたかを残せば、更新後に問題が出たとき、どこまで確認済みかが分かります。

公開siteだけで先に試すと、表示が崩れたときに、WordPress本体の変更なのか、themeのcodeなのか、pluginの条件分岐なのかを分けにくくなります。更新前のversion、確認した分類、開いたURL、変更したfileを残します。外部へ修正を頼む場合も、この記録があれば、相手は「分類が動かない」という曖昧な依頼ではなく、再現する画面と条件から調べられます。

全ての分類機能を更新対象にしない

WordPress 4.7のWP_Taxonomyは、分類を扱う内部の基礎を整える変更です。categoryやtagを普通に選び、archiveを表示しているだけなら、その機能だけを理由にthemeを作り直す必要はありません。必要なのは、変わった戻り値やhook引数を前提にしているcodeがあるかを探し、影響する範囲を試すことです。

また、分類名やURLを変更する作業は、今回のversion更新とは別に扱います。表示を確認する途中でlabelが気になっても、更新の確認と名称変更を同じ作業へ混ぜると、問題の原因が追えなくなります。先に既存の分類が保存、表示、archiveで保たれることを確認します。名称や構成を変えるなら、そのあとで対象記事、URL、link、検索からの入口を別に確認します。

最初の一手は、themeとpluginからget_taxonomy、$wp_taxonomies、分類に関係するhook名を検索し、該当fileを一覧にすることです。見つかったcodeは、classを前提にしている処理、hookの引数を受ける処理、globalを直接扱う処理へ分けます。その一覧と分類を使う代表投稿を用意してから更新すれば、必要な確認を短く、しかし抜けなく進められます。