WP_Query パラメーターfields

どういう時に使うか

後続処理に投稿IDだけ渡したい時や、対象IDを集めて別処理へ渡す時は ’fields’ => ‘ids’ が候補になります。

親子関係だけ必要なら ’id=>parent’ を使えます。返るのは ID と post_parent を持つオブジェクトで、完全な WP_Post ではありません。

タイトル、抜粋、アイキャッチなどをその場で表示する一覧なら、既定の ’all’ の方がコードは素直です。

近い引数との違い

posts_per_page は何件返すか、post__in はどの投稿を返すかを決めます。fields が変えるのは取得後のデータの形です。

’ids’ を高速化の合言葉にせず、返り値を受け取るコードがID配列に対応しているかを先に見ます。

Builderでの扱い

WP Query Builder では戻り値の形式として指定できます。選択肢には、後続コードで何が変わるかも表示するのが親切です。

IDだけを選んだ場合は、通常ループの見本ではなくID配列を処理する見本へ切り替えます。

使いどころ・避けどころと実践確認

投稿オブジェクト全体が不要で、IDまたはIDと親IDだけを受け取る処理に絞れる時に使います。

取得直後にタイトル、本文、メタ、タームを通常のテンプレートタグで読む一覧では選びません。

fields => ‘ids’ の戻り値は WP_Post ではないため、既存ループがオブジェクト前提なら型の違いで壊れます。

fields => ‘ids’ は取得量を減らせますが、その後にタイトルやメタを読むなら、かえって処理が増えることがあります。

戻り値の型と要素を出力し、後続処理が実際に読むプロパティ・関数を列挙してから通常取得と比較します。

実践記事で確認WP_Queryの基本構文と$argsの書き方

WP_Query の生成、戻り値の扱い、ループまでを基本構文で確認してから最小化できます。

記事を読む →

WordPressの仕様で確認するポイント

公式リファレンスの Return Fields Parameter で、all、ids、id=>parent の3種類を確認できます。

未対応の文字列を渡した場合の挙動も含め、推測した値を増やさないようにします。

最後は、値を変える目的と、変えた時に失う情報を一緒に確認します。