WordPress 4.7のマルチサイトはget_blog_detailsをget_siteへ置き換えて確認する

WordPress 4.7のマルチサイトでは、本体のcodeでget_blog_details()がget_site()へ置き換わります。次の4.8ではget_blog_details()のdeprecatedも予定されています。マルチサイトを使っているだけなら、すべてのsiteを急いで直す作業ではありません。独自theme、plugin、mu-pluginで古いfunctionを使っているなら、その処理が一siteを取るのか、条件からsiteを探すのかを分けて見直します。

site IDが分かっている場合、get_site()はget_blog_details()の直接の置換候補です。IDが分からず、domainやpathなどの条件からsiteを探すなら、get_sites()を使います。古いfunction名を新しい名前へ機械的に置き換える前に、codeが何を探しているかを確認します。

この区別を曖昧にすると、修正後に一見動いていても、別のsiteを扱う危険があります。site IDを決め打ちしている処理は、特定のsiteの情報を取り出す仕事です。domainやpathで条件を付ける処理は、networkの中から対象を選ぶ仕事です。後者を一件取得のように書き替えれば、新しいsiteを追加したときやURL構成を変えたとき、意図したsiteが見つからなくなることがあります。

取得したsite情報をどこで使うかも確認します。管理画面の一覧に表示するだけなのか、公開pageのlinkを作るのか、別のsiteへ設定を反映するのかで、失敗したときの影響が違います。公開pageのlinkに使う処理なら、取得したdomainとpathが正しいかを実際のURLで確かめます。管理画面だけで使う処理なら、権限の違う利用者で見え方が変わらないかも確認します。

一siteの取得とsite一覧の検索を混同しない

説明用の仮例として、network内の各siteへ共通の案内を出すpluginを考えます。一site IDだけを扱う処理と、条件に合うsiteを一覧から探す処理を同じfunctionで済ませると、更新後にどこを直すか分かりにくくなります。最初に「一件を取得する」「一覧から探す」と用途を書き分ければ、get_site()とget_sites()の選択を誤りにくくなります。

たとえば、特定siteの設定を表示するだけなら、一件を取得する処理です。network内で公開中のsiteを探して案内を出すなら、検索する処理です。両方を同じ取得方法で済ませると、条件を変えたときに意図しないsiteまで対象になることがあります。function名より、取得したdataを何に使うかを先に確認します。

説明用の仮例で、network内のsite一覧へ共通のお知らせを出す場合を考えます。公開中のsiteだけを対象にするつもりなら、停止中や準備中のsiteまで一覧へ混ざらない条件を確認します。一方で、管理者が特定のsiteを選んで設定を見る画面なら、一覧を検索して最初に見つかったsiteを使うのではなく、選択したsite IDを確認します。どちらもsite情報を取得しますが、確認する条件と失敗したときの扱いは同じではありません。

古いfunctionを置き替えるときは、戻り値を使っている後続のcodeも読みます。取得したsiteが見つからない場合、空の値をどう扱うか、画面に何を出すか、処理を止めるかを決めます。以前のcodeがたまたま動いていたからといって、見つからないsiteへの対応まで正しいとは限りません。置換する一行だけを直して終わらせず、取得後に何を表示し、どこへlinkするかまで確認します。

function以外の古い名前も検索する

blog_details filterはdeprecatedとなり、site_details filterを使います。wp_get_network()もget_network()へ移ります。functionを直接使っていないと思っても、古いpluginやmu-pluginがfilterを使っている場合があります。本体の更新だけを確認して終わらせず、独自code全体を検索対象にします。

検索するときは、次の語を別々に探します。

1. get_blog_details
2. blog_details
3. wp_get_network
4. site ID、domain、pathを使ってsiteを探している独自関数

見つかった箇所には、取得するsiteの数、使う条件、修正するfunction、確認する画面を残します。修正後は、代表する一networkと一siteを選び、site一覧、管理画面、独自pluginが表示する内容を確認します。PHPの文法だけでは、別のsiteを取得していないかまでは分かりません。

代表siteは、もっとも単純な一siteだけにしません。可能なら、通常のdomainとpathを使うsite、独自の設定を持つsite、停止中または公開していないsiteを分けて確認します。すべてのsiteを手で開く必要はありませんが、検索条件に違いが出るものを選ばなければ、条件の書き間違いは見つかりません。公開siteの一覧を出す処理なら、表示してはいけないsiteが混ざらないことも確認します。

更新作業を外部へ頼む場合は、function名の置換だけを依頼内容にしません。どのnetworkを対象にするか、siteの追加や停止があるか、公開画面と管理画面のどちらを確認するかを伝えます。制作会社がcodeを直せても、どのsiteを出してよいかを決めるのは運用側です。修正作業と、networkの対象範囲を決める責任を分けます。

4.8で予定されるdeprecatedに備えるためにも、今のうちに検索結果を残します。すぐに動かない原因がなくても、古いfunctionを使っている場所と目的が分かれば、次の更新前に確認する範囲を決められます。更新日になってからすべてを一度に直すより、使い方の違う箇所を分けておく方が、検査と復旧を行いやすくなります。

WordPress 4.7の変更は、4.8で予定されるdeprecatedを見越した移行です。更新日を待ってから慌てて直すより、独自codeの場所を先に分けておきます。最初の一手は、get_blog_detailsを検索し、一site取得か検索かを判定することです。