WP_Queryでカスタム投稿が出ない原因
｜post_type・公開状態を確認

0件・404・表示ずれを分ける

独自のWP_Queryが0件なのか、アーカイブURLや個別URLが404なのか、ループ後の表示だけがおかしいのかで、疑う場所は変わります。まず症状を分けます。

post_typeを書いていても、表示名を指定していたり、スラッグのハイフンとアンダースコアを取り違えたりすると取得できません。

よくある原因一覧

取得対象の指定に迷う場合は、先にpost_typeの指定方法を確認してください。カスタム投稿に限らず結果が0件になる場合は、条件を外す順番をまとめた投稿が表示されない時のチェックリストから切り分ける方が早いです。

あわせて読みたいWP_Queryの基本から確認する記事を読む

複雑な条件を読む前に、投稿タイプ、公開状態、絞り込み条件、登録設定の順に確認します。

最小構成でカスタム投稿が取れるか確認する

post_type、post_status、posts_per_pageだけにして、公開済みのevent投稿が取れるか確認します。eventは実際の投稿タイプスラッグへ置き換えてください。カテゴリー、カスタムタクソノミー、カスタムフィールド、日付、並び順はいったん外します。

$args = [   'post_type'      => 'event',   'post_status'    => 'publish',   'posts_per_page' => 3,]; $event_query = new WP_Query( $args ); if ( $event_query->have_posts() ) {   while ( $event_query->have_posts() ) {      $event_query->the_post();       echo esc_html( get_the_ID() . ' : ' . get_the_title() );      echo '<br>';   }} else {   echo esc_html( 'event posts not found.' );} wp_reset_postdata();

ここで表示されるなら、後から足したtax_query、meta_query、orderby、pagedなどを1つずつ戻します。0件のままなら、スラッグ、公開状態、投稿タイプの登録状態へ戻ってください。

カスタム投稿が出ない原因を順に確認する

最小構成で結果を確認したら、投稿タイプ名、公開状態、登録設定、外部処理の順に実際の条件へ戻します。

post_typeのスラッグ違いを確認する

WordPress公式リファレンスでは、WP_Queryのpost_typeは投稿タイプを指定する引数で、通常の既定値はpostです。ただし、tax_queryを指定したクエリの既定値はanyになります。anyでも、exclude_from_searchがtrueの投稿タイプなどは対象外です。カスタム投稿を確実に対象にしたい時は、post_typeを省略せずに指定します。

スラッグが分からない場合は、登録コードやCPT系プラグインの設定画面を確認します。テーマやプラグイン内でregister_post_type( ‘event’, … )のように登録されているなら、WP_Queryに指定するのはeventです。

一時的にコードで確認したい場合は、get_post_type_object() を使う方法もあります。これは指定した投稿タイプ名の登録情報を取得する関数で、存在しない投稿タイプ名なら null が返ります。

$post_type_object = get_post_type_object( 'event' ); if ( $post_type_object ) {   echo esc_html( 'event is registered.' );} else {   echo esc_html( 'event is not registered.' );}

event is not registered.と出たら、WP_Queryではなく、投稿タイプ名、登録処理の読み込み順、CPTを登録するプラグインの有効化状態を確認します。

公開状態と絞り込み条件を確認する

post_type が正しくても、対象の投稿が下書き、予約投稿、非公開などになっていると、通常の公開ページでは期待通りに出ないことがあります。WP_Queryの post_status は、特に指定しない場合は基本的に公開済み投稿を対象にするものとして考えると分かりやすいです。

確認中だけであれば、post_status を明示して動きを見ます。ただし、本番表示で下書きや非公開まで出すのは意図しない公開につながる可能性があるため、目的がはっきりしている時だけにしてください。

条件を足した直後に0件になったなら、その条件を調べます。たとえばtax_queryなら、タクソノミー名、タームスラッグ、relation、operatorが意図どおりか確認します。

アーカイブURLが出ない場合は登録設定を見る

テンプレート内の new WP_Query() ではなく、カスタム投稿アーカイブのURLが表示されない、404になる、タクソノミーアーカイブで投稿が出ない、という場合は、WP_Queryの書き方だけではなく、カスタム投稿タイプの登録設定も確認します。

register_post_type()のpublicは、投稿タイプが管理画面や読者側にどう見えるかに関係する複数の設定へ影響します。公式リファレンスでは、publicをtrueにすると、個別指定がない場合のexclude_from_search、publicly_queryable、show_in_nav_menus、show_uiも公開側の初期値になります。publicがfalseなら、これらは非公開側の初期値になります。

たとえば「/event/ の一覧が404になる」という相談と、「固定ページテンプレートに書いたWP_Queryで event が0件になる」という相談は、似ていても別の問題です。前者はアーカイブやリライトルールの設定、後者はWP_Queryの条件を先に疑います。

pre_get_postsやループの後処理も確認する

サイト全体で pre_get_posts を使っている場合、意図せず別のクエリにも条件が効いていることがあります。たとえば、メインクエリ用に書いたつもりの条件が、管理画面や別の一覧にも影響してしまうと、カスタム投稿が出ないように見えることがあります。

メインクエリだけを変えるなら、管理画面を除外し、is_main_query()などで対象を限定します。また、独自のWP_Queryでthe_post()を使った後はwp_reset_postdata()で投稿データを戻します。これを忘れると、後続のテンプレートタグが別の投稿を参照します。

公式資料で確認したいポイント

post_typeとpost_statusはWP_Query、公開範囲はregister_post_type()、登録の有無はget_post_type_object()、メインクエリの変更はpre_get_postsの公式資料で確認します。

最後に確認したいこと

最小構成で表示されるなら追加条件、0件ならスラッグ、公開状態、登録状態を調べます。アーカイブや個別URLの404は独自クエリと分けて、登録設定とリライトルールを確認してください。