WordPress 4.2の共有term分割後は保存済みterm_idを新しいIDへ更新する

pluginやthemeがterm_idをoption、post meta、user metaへ保存しているなら、WordPress 4.2への対応を確認してください。複数taxonomyで共有されているtermを更新すると、新しいterm_idへ分割される場合があります。split_shared_term actionで保存済みIDを移し替えます。

通常のtaxonomy queryだけを使い、term_idを別の場所へ固定保存していない処理は、影響を受けにくい構造です。すべてのsiteで一括変換を走らせる前に、自作pluginとthemeがIDをどこへ保存しているかを調べます。

変わるのはterm_taxonomy_idではなくterm_idである

WordPress Coreのterm splitting解説によると、異なるtaxonomyで同じslugを共有していたtermは、一つのwp_terms行を使う場合がありました。WordPress 4.2では、その共有termを更新すると、新しいwp_terms行が作られます。

分割時にはterm_taxonomy_idが維持され、term_idが変わります。categoryやtagを表示する通常処理ではなく、古いterm_idをoptionなどから直接読み、特定のtermを参照する処理が確認対象です。

たとえば「注目記事に使うtag ID」をoptionへ保存しているpluginでは、tagの説明を管理画面で変更した後、保存済みIDが分割前の値を指し続ける可能性があります。投稿の所属を数え直す問題ではなく、保存した参照先を更新する問題です。

split_shared_termで対象taxonomyと古いIDを確認する

split_shared_termには、古いterm ID、新しいterm ID、term taxonomy ID、taxonomyが渡されます。保存済みIDとtaxonomyの両方が一致した場合だけ、新しいIDへ更新します。

function satolab_update_saved_tag_id( $old_id, $new_id, $tt_id, $taxonomy ) {
    if ( 'post_tag' !== $taxonomy ) {
        return;
    }

    $saved_id = (int) get_option( 'satolab_featured_tag_id', 0 );

    if ( $saved_id === (int) $old_id ) {
        update_option( 'satolab_featured_tag_id', (int) $new_id );
    }
}
add_action( 'split_shared_term', 'satolab_update_saved_tag_id', 10, 4 );

これは説明用の仮例です。option名、taxonomy、値の型は、実際のplugin設計に合わせます。古いIDだけを見て更新すると、別taxonomyの参照まで置き換えるおそれがあります。$taxonomyを条件へ入れてください。

callback内で更新する対象は、そのpluginやthemeが所有する保存値に限定します。WordPress Coreのtaxonomy tableを直接書き換える処理は加えません。

分割後のIDはwp_get_split_term()でも確認できる

WordPress 4.2は、分割したtermの情報を保存します。actionを受け取れなかった処理や、後から移行を確認する処理では、wp_get_split_term( $old_term_id, $taxonomy )から新しいIDを調べられます。対応する分割情報がなければfalseです。

この関数を使う場合も、取得した新IDを無条件で全データへ書き戻さないでください。保存値が本当に同じtaxonomyを指すかを確認し、更新件数と変更前後の値を記録します。

actionで即時更新する方法と、後から照合する方法は役割が違います。新しい分割を確実に追うならaction、既存データの点検や移行ならwp_get_split_term()を使います。

更新前にterm_idの保存場所を棚卸しする

最初にcodeから、term_idをoption、post meta、user metaへ保存する箇所を探します。次に、そのIDがcategory、post tag、custom taxonomyのどれを指すか、値と一緒にtaxonomyも保存しているかを確認します。

表は棚卸し用の仮例です。実際のdatabaseを確認せず、該当件数を推測してはいけません。

制作会社やplugin開発者へ対応を委託する場合は、変更するcodeだけでなく、保存場所、対象taxonomy、移行方法、戻し方を受け取ります。実装を委託しても、どのpluginがどの分類IDを所有するかを把握する責任はsite所有者に残ります。

最初の一手は、自作codeをterm_id、update_option、update_post_meta、update_user_metaで検索することです。固定保存が見つからなければ、不要な移行処理を追加せず、通常のtaxonomy操作が動くかを検証します。