タグアーカイブ get_queried_object

WooCommerce 11.0でget_queried_object()がショップページでもWP_Postを返す改善

WooCommerce 11.0より、ショップページで get_queried_object() を呼び出した際の戻り値の型が WP_Post_Type から WP_Post に統一される。これまでショップページだけが例外的に商品の投稿タイプオブジェクトを返していたが、今回の変更でWordPress標準の挙動と一貫性が保たれることになる。

この修正は、WooCommerceが内部的に管理するクエリの取り扱いをWordPressコアに合わせるもので、テーマやプラグインの開発者が「ショップページかどうか」を意識せずに get_queried_object() を扱えるようにする狙いがある。フロントページにショップページを設定している場合も同様の挙動となる。

WooCommerce 11.0のショップページ改善

WooCommerce 11.0のショップページ改善

get_queried_object() は現在のWordPressクエリに対応するオブジェクトを取得する標準関数だ。通常の固定ページや投稿ページでは WP_Post オブジェクトを返すが、これまでのWooCommerceではショップページに限り WP_Post_Type オブジェクト、つまり商品(product)の投稿タイプ情報を返していた。この不一致が開発者にとって混乱の元となっていた。

WooCommerce Developer Blogの説明によれば、ショップページで get_queried_object() を呼び出して「商品アーカイブであること」を判定するコードを書いていた場合、この変更の影響を受ける可能性がある。逆に言えば、今回の修正で is_shop() のような条件分岐タグと get_queried_object() の戻り値の関係が整理され、より直感的なコードが書けるようになる。

WooCommerce 10.x までの挙動(Before)
Shopページ WP_Post_Type (商品の投稿タイプ情報)
その他固定ページ WP_Post (ページの投稿オブジェクト)
Shopページだけが例外で、他のページと異なるオブジェクト型を返していた
WooCommerce 11.0 以降の統一された挙動(After)
Shopページ WP_Post (ショップ固定ページの投稿オブジェクト)
その他固定ページ WP_Post (ページの投稿オブジェクト)
すべてのページで一貫して WP_Post を返すように統一された

この変更の背景には、WordPressの「投稿ページ」設定と同様にショップページでも WP_Post を返すべき、という設計上の判断がある。WooCommerce 11.0ではこの長年の不一致が解消され、より予測しやすいAPIへと改善された。

影響を受けるコードの判断方法

影響を受けるコードの判断方法

自作のテーマやプラグインでショップページのクエリオブジェクトを参照している場合、以下のいずれかの関数やプロパティを使用していないか確認する必要がある。

  • get_queried_object() を呼び出している
  • get_queried_object_id() を呼び出している
  • $query->queried_object に直接アクセスしている
  • $query->queried_object_id に直接アクセスしている

これらのコードがショップページ上で実行され、戻り値として WP_Post_Type オブジェクトを期待しているなら、WooCommerce 11.0へのアップデート後に動作が変わる可能性が高い。とくに、queried_object->labels->name などのプロパティに依存している場合は要注意だ。

Before / After コードの比較

具体的なコードの違いを見てみよう。以下はショップページでの get_queried_object() の戻り値の変化を示している。

// WooCommerce 10.x まで Shopページのみ例外
get_queried_object();          // → WP_Post_Type
get_post_type_object( 'product' ); // → WP_Post_Type

// その他の固定ページ
get_queried_object();          // → WP_Post
get_post_type_object( 'product' ); // → WP_Post_Type
// WooCommerce 11.0 以降 Shopページも含めて統一
get_queried_object();          // → WP_Post
get_post_type_object( 'product' ); // → WP_Post_Type

この変更の影響を受けないケース

次のような状況では、WooCommerce 11.0の変更による影響はなく、既存のコードはそのまま動作する。

  • 単一の商品ページ(single-product)では引き続き商品の WP_Post オブジェクトが返る
  • 商品カテゴリやタグ、ブランド、属性などのタクソノミーページでは WP_Term オブジェクトが返る
  • その他の投稿タイプアーカイブや個別ページはもともと変更の対象外
  • is_shop()is_archive()is_post_type_archive( 'product' ) といった条件分岐関数の挙動は従来どおり変わらない

開発者が取るべき具体的な対応

開発者が取るべき具体的な対応

もし既存のコードがショップページで get_queried_object() の戻り値を WP_Post_Type として扱っている場合、WooCommerce 11.0へのアップデートに備えて改修が必要だ。修正の基本方針は「オブジェクトの型をチェックしてからプロパティにアクセスする」ことにある。

商品の投稿タイプ情報を取得する推奨方法

商品の WP_Post_Type オブジェクトが必要な場合は、get_post_type_object() を使うのが安全で推奨される方法だ。この関数はWooCommerceのバージョンに関係なく常に正しいオブジェクトを返す。

$product_post_type = get_post_type_object( 'product' );

if ( $product_post_type instanceof WP_Post_Type ) {
    // 商品のWP_Post_Typeオブジェクトは
    // get_post_type_object() から引き続き取得できる
    $singular_name = $product_post_type->labels->singular_name;
}

ショップページのWP_Post情報を扱うコード例

ショップページ自体の情報(ページタイトルやスラッグなど)を取得したい場合は、WooCommerce 11.0以降は get_queried_object() から直接 WP_Post としてアクセスできるようになる。以下はその典型的な使用例だ。

$shop_page = get_queried_object();

if ( $shop_page instanceof WP_Post ) {
    // WooCommerce 11.0以降、ショップページでも
    // WP_Postとして扱える
    $shop_title = $shop_page->post_title;
    $shop_slug  = $shop_page->post_name;
}
修正の流れと対応手順
STEP 1 ショップページで get_queried_object() / $query->queried_object を使っている箇所を特定する
STEP 2 戻り値を WP_Post_Type として使っているか確認する( instanceof や型チェックをしていない場合)
STEP 3 get_post_type_object( 'product' ) で商品の投稿タイプ情報を個別に取得し、既存コードを書き換える
STEP 4 テスト環境でWooCommerce 11.0にアップデートし、ショップページが正しく表示されるか検証する

重要なのは、get_queried_object() の戻り値に依存した条件分岐を書く前に、必ず instanceof でオブジェクトの型をチェックする習慣をつけることだ。これにより、WooCommerceの将来のアップデートや他のプラグインとの競合にも強いコードになる。

この記事のポイント

  • WooCommerce 11.0ではショップページの get_queried_object()WP_Post を返すように統一される
  • 商品の投稿タイプ情報が欲しい場合は get_post_type_object( 'product' ) を使用する
  • is_shop() などの条件分岐関数の挙動は変わらないため、ページ判定ロジックの修正は不要
  • 影響を受けるコードは、おもにショップページでクエリオブジェクトのプロパティに直接アクセスしている箇所
  • アップデート前に instanceof による型チェックを追加し、テスト環境で検証するのが安全な移行手順