$wp_query と $post
投稿データ取得の仕組みを知る上で重要なのは、$wp_query 、 $post という2つの変数です。
どちらもWordPress内部で自動的に生成され、利用されているものですが、グローバル変数のため、テンプレート内のどこでも、
global $wp_query;
print_r($wp_query);
等と記述すれば、中身を確認することができます。
投稿情報取得とループの仕組み
WordPressの基本動作で触れた通り、WordPressは、URLにアクセスした瞬間に（テンプレートを読み込む前に）URLに基づいて、データベースを検索します。
$wp_query には、query_vars、posts という2つの配列が含まれており、query_vars にその検索条件、posts にその検索結果が格納されます。
もう少し厳密にいうと、
query_vars に検索条件をセット
→検索を実行
→結果をpostsにセット
という流れです。
このとき、検索結果の1件目（singleページなら、その投稿そのもの）が、変数 $post に格納されます。
普段はあまり目にすることのない変数ですが、
テンプレートタグでお馴染みの have_posts() は、この $wp_query の posts に中身があるかどうかを判定しています。
そして、ループの中に必ず記述する the_post() は、この posts の次の1件を、$post にコピーする処理を行っています。
つまり、$post には「現在ループ中の投稿情報」が格納されています。
the_title() や the_contents() などのテンプレートタグは、この $post の情報を取得しています。
投稿情報取得のカスタマイズ
現在では使われることが少なくなりましたが、query_posts() は、この $wp_query を直接変更してしまう関数です。
$wp_query はWordPress内部の様々な処理に関わるため、不具合を起こしやすく、現在では推奨されない方法となりました。
それに変わって普及した、
$my_query = new WP_Query($arg);
という手法。
これは、$wp_queryと同じように、検索条件query_varsと検索結果postsを持った変数（ここでは$my_query）を、新たに作成する方法です。
引数の$argが検索条件query_varsとなり、自動的に検索が行われ、検索結果がpostsに格納されます。
この場合、ループ処理では、the_post() の代わりに、
$my_query->the_post();
と記載しますね。
the_post() は $wp_query（のposts）の中身を $post にコピーしますが、
$my_query->the_post() は、自分で作った $my_query（のposts）の中身を $post にコピーします。
（もちろん、the_post() の代わりに $wp_query->the_post() とすることもできます。）
このとき、自動生成される$wp_queryと、新たに作成した$my_queryという2つの変数が存在しているわけですが、
注意しなければならないのは、$post はひとつしかないということです。
元々、$post には、$wp_query （のpostsの1件目）のデータが格納されていますが、$my_query->the_post() によって、これが上書きされます。
再度、$wp_query の情報を $post に戻すために用意されている関数が、new WP_Query() と必ずセットで使うことが推奨されている、wp_reset_postdata() です。
なお、同じく投稿情報を取得する get_posts() は、$wp_query にも $post にも影響しません。スポットで使うには、非常に安定性が高いと言えます。
（関数の内部では、$wp_queryと同じような変数が作成されています）
テンプレートによる投稿情報検索カスタマイズの限界
これら3つの方法で、ページのメインのループ処理を記述することは、いくつかの問題があります。
これら3つの方法は、いずれも、テンプレートに記述するものです。
WordPressの基本動作で触れた通り、テンプレートが読み込まれる前に、既にデフォルトの検索は実行されています。
そのため、これらの方法でメインループを変更する場合、第1に、データベースの検索を1回余分に行うことになります。
第2に、デフォルトの検索の結果によって実行された後続処理を、変更できないこと。最もわかりやすいのは、テンプレートの決定です。
例えば、20件の投稿があるとき、テンプレートに new WP_Query() を記述し、1ページあたりの表示件数を5件に変更したとしても、
デフォルトの検索実行時には1ページ（デフォルトの）10件なので、3ページ目のURLにアクセスすると、404テンプレートが選択されてしまいます。
pre_get_postsの使用
特にメインループにおいて、検索条件に変更を加える際は、pre_get_postsフィルターを利用することが推奨されています。
冒頭で、WordPressによって自動的に $wp_query が生成される際には、
query_vars に検索条件をセット
→検索を実行
→結果をpostsにセット
という処理がなされるとお話ししました。
これは、query_posts() を実行した際や、new WP_Query() を使用した場合でも、同じです。
pre_get_postsフィルターは、この「検索を実行」が行われる直前に、検索条件 query_vars の中身をチェックし、変更することができます。
デフォルトの検索自体を変更できるので、無駄な検索が発生せず、テンプレートの選択もその検索結果によって決定されるため、前述のような問題もありません。
