【wordpress】メインクエリーとサブクエリー、query_posts、wp_query、get_postとpre_get_postとページ送り

ざっくりいうと多分こんな感じ↓

メインクエリーとサブクエリーの関係


query_postsとwp_query、get_posts


pre_get_posts

まとめると、

メインクエリー系:(1).query_posts (2).pre_get_posts
サブクエリー系:(3).wp_query (4).get_posts

以下、解説。

1.  query_posts()

一旦セットされたメインクエリーを書換えるのでパフォーマンスが悪い。
wp公式では非推奨。
ページャーの使用は問題ない。

2. pre_get_post

ページを読み込む前の段階で、メインクエリー自体を希望のものに作成する。
他の方法に比べてパフォーマンスが良い。
ページャーの使用も問題ない。
現時点では多くのサイトがこの方法を推奨している。

3. wp_query

メインクエリーと同じ型のクエリーを、もう一つ別に作る感じ。
中身は投稿に関するものだけでなく、ページに関する情報など広範囲。
ページャーの使用には難あり。ただし解決方法は簡単。(後述)

4. get_posts

wp_queryと比較すると、wp_query >>>> get_posts
基本的に投稿の情報のみを取得する。
wp_queryとの比較で複雑なことは出来ないが、例えばサイドバーに「最新イベント情報」などとして特定の投稿タイプ10件のみを表示といった場合には、むしろwp_queryより動作が速くなるであろう点ではアドバンテージがあると思われる。

ページャーの使用は検索すれば出てくるけど、ややこしそうなのでパス。

各クエリーとヘージャーの関係

ページャーが参照するのは常にメインクエリー。

たとえサブクエリー内にページャーを設置しても、ページャーはメインクエリーを参照してページリストを作成する。そのため総ページ数や表示投稿数の相違などの不都合が生じる。

解決するためには、下記のようにオリジナルのクエリーをページャーに渡してやればOK(wp_pagenaviプラグイン使用時の記述)

wp_pagenavi(array('query' => $custom_query));

記述箇所はループの終った所。独自wp_queryのpost_dataをリセットする直前。

ここで再度整理。

  • query_posts(メインクエリーを作成)
  • pre_get_posts(メインクエリーを作成)
  • wp_query(サブクエリーを作成、ページ情報も取得)
  • get_posts(サブクエリーを作成、ページ情報は取得しない)

つまり、実質的にこの対応が必要となるのは、wp_queryでサブクエリーを作成した時のみとなる(はず)。

 

また、テンプレートページ内でクエリーを作成する場合は、下記の記載を加えるないと表示する投稿が送られない。

$paged = (int) get_query_var('paged');
$args = array(
  'paged' => $paged,
  …クエリー続き
);

つまり、query_postsとwp_queryでサブクエリーを作成し、ページャーを使用する場合はこの対応も必要となる。

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください