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

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

独自のWP_Queryが0件なのか、アーカイブURLが404なのか、ループ後の表示だけがおかしいのかを分けます。 症状ごとに確認する場所が違うためです。

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

よくある原因一覧

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

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

あわせて読みたいコードをどこへ置くか確認する記事を読む

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

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

post_type、post_status、posts_per_page だけにして確認します。この例は works という登録キーを使い、そこに入っている公開済みの開催情報を最大3件表示します。自分のサイトでは実際の登録キーへ置き換え、カテゴリー、カスタムフィールド、日付などの追加条件をいったん外してください。

現在のWP Query Builderで、投稿タイプを「custom」、カスタム投稿タイプを「works」、公開状態を「publish」、件数を「3」にし、自動高速化をオフにして生成した未編集の$argsを使います。Builderが作るのは取得条件までで、表示ループ、0件時の文言、投稿IDの表示、wp_reset_postdata()は手動で追加しています。

PHPテンプレートを使う子テーマの template-parts/works-check.php に保存し、表示したいテンプレートのメインループで the_post() の後に get_template_part( ‘template-parts/works-check’ ); と呼びます。投稿本文や追加CSSには貼りません。確認が終わったら、不要になった呼び出しとファイルを外してください。

<?php$args = array(    'post_type' => 'works',    'post_status' => 'publish',    'posts_per_page' => 3); $works_query = new WP_Query( $args ); if ( $works_query->have_posts() ) {   echo '<ul>';   while ( $works_query->have_posts() ) {      $works_query->the_post();      echo '<li><a href="' . esc_url( get_permalink() ) . '">' . esc_html( get_the_title() ) . '</a>';      echo '<br>投稿ID：' . esc_html( (string) get_the_ID() ) . '</li>';   }   echo '</ul>';} else {   echo '<p>条件に合う公開済みの情報はありません。</p>';} wp_reset_postdata();

最小構成で表示されるなら、原因は外した条件のどれかです。 tax_query、meta_query、orderby、pagedを1つずつ戻します。0件のままなら、スラッグ、公開状態、投稿タイプの登録状態を調べてください。

workとworksの1文字の違いで結果を比べる

同じ3件の投稿に対し、上の post_type だけを変えています。このサンプルでは works に公開済み3件があり、work の投稿はありません。ループ・件数・公開状態は同じです。

投稿タイプの設定や表示コードを調べる作業は、本番と分けた環境で行います。サーバー上へ試す場所を用意する場合は、XserverのPHP対応やバックアップ条件も確認できます。

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

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

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

管理画面の「イベント」のような表示名、投稿タイプの登録キー、公開URLの rewrite[‘slug’] は別々に設定できます。WP_Queryへ渡すのは登録キーです。

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 が返ります。

次を template-parts/debug-post-type.php に保存し、先ほどと同じテンプレートから get_template_part( ‘template-parts/debug-post-type’ ); と一時的に呼びます。通常は init で登録されるため、その後に実行されるテンプレートで確認します。読み込み途中の functions.php の先頭で判定しないでください。

<?php$checked_post_type = 'works';$post_type_object = get_post_type_object( $checked_post_type ); if ( $post_type_object ) {   echo '<p>' . esc_html( $checked_post_type . ' は登録されています。' ) . '</p>';} else {   echo '<p>' . esc_html( $checked_post_type . ' は登録されていません。' ) . '</p>';}

「登録されていません」と出たら、投稿タイプ名、登録処理の読み込み順、CPTを登録するプラグインの有効化状態を確認します。確認後はこのパーツの呼び出しとファイルも外します。

なお、データベースに投稿が残っていれば、未登録の投稿タイプでも明示した独自クエリで取得できる場合があります。「一覧に出た」ことだけでは、投稿タイプの登録や個別URLまで正常とは判断できません。

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

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

公開ページでは post_status => ‘publish’ を明示して確認します。下書きや非公開の有無は権限のある管理画面で調べ、表示を出すために any へ広げたり、公開予定でない投稿を公開したりしないでください。

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

登録キーと公開状態で取得できたら、WP Query Builderで次の絞り込みを組み立てられます。生成した$argsを最初の表示ループへ渡し、条件を1つ加えるごとに対象の投稿IDを見比べます。

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

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

public を true にすると、個別指定がない場合の publicly_queryable・show_ui・show_in_nav_menus は true、exclude_from_search は逆の false になります。ただし各設定は個別に上書きでき、has_archive が自動的に true になるわけではありません。

この記事の works は has_archive => false ですが、最初の独自クエリでは3件取得できます。アーカイブを持つかどうかと、テンプレート内の独自クエリで取得できるかは別の確認です。 公開設定を変える場合も、下書きや内部用途の投稿を読者へ見せない要件を先に確認します。

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

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

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

メインクエリだけを変えるなら、管理画面を除外し、フックで受け取った $query->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は独自クエリと分けて、登録設定とリライトルールを確認してください。