関連記事の追加後に記事タイトル・本文が別の記事へ変わる原因
｜wp_reset_postdata()を確認

どこから別の記事へ変わるかを先に確認する

この記事でいうサブループは、ブラウザで開いている個別記事とは別に、関連記事や新着記事などを取得して表示する追加のループです。本文の下だけでなく、上部、サイドバー、テンプレートパーツ内に置く場合もあります。大切なのは画面上の上下ではなく、PHPが実行される順番です。

サブループの作り方や、1ページで複数の一覧を安全に扱う基本は、次の記事で詳しく説明しています。

あわせて読みたいWordPressの一覧を変える？追加する？｜メインクエリとサブクエリの違い記事を読む

この記事では、ブラウザで開いている記事を「WordPress高速化ガイド」（ID 28）、追加する関連記事を「関連記事：キャッシュの使い方」（ID 26）と「関連記事：画像を軽くする方法」（ID 27）として再現します。関連記事は正しく表示されますが、その処理の後に実行されるthe_title()やthe_content()が、最後の関連記事のタイトルや本文を表示してしまう状態です。

追加した一覧の最後の記事と同じタイトル、本文、アイキャッチ、リンク先URLが、その処理の後にも表示されているなら、取得条件を変える前に投稿データの参照先を調べます。

次の画面は、検証用WordPressで動かした記事ページです。上部のタイトルと「あわせて読みたい」は正しいままですが、赤枠の「この記事のまとめ」だけが最後の関連記事へ変わっています。まとめには投稿のタイトルと抜粋を表示しています。

サブループの最後の記事を参照したままになる理由

独自クエリの$related_query->the_post()は、取得した一覧の次の記事へ進む処理です。それに加えて、「いまどの記事を表示しているか」を表すglobal $postも、その関連記事へ切り替えます。ここで使う->は、左側の$related_queryに対して右側のthe_post()を呼び出すPHPの書き方です。$related_queryは引数ではなく、操作する取得結果を持つWP_Queryオブジェクトを示しています。

the_title()、the_content()、get_the_ID()などは、投稿IDを明示しない場合、global $postに入っている記事を使います。今回の例では、ループの最後に「関連記事：画像を軽くする方法」が入ったままになるため、その後のテンプレートタグもこの関連記事を表示します。

一方、get_queried_object_id()は、WordPressが今開いているURLから判断した個別記事のIDを返します。そのため、URLが示すIDは「WordPress高速化ガイド」のままでも、global $postとget_the_ID()だけが最後の関連記事へずれることがあります。

whileの処理が終わっただけでは、global $postはブラウザで開いている個別記事へ戻りません。サブループを終えた位置で、投稿データを元へ戻す処理が必要です。

resetなしのコードではループ後も関連記事を参照する

次は、個別記事のテンプレートで関連記事を表示し、その処理の後に、開いている記事のタイトルと本文を表示する失敗例です。検証用のクラシックテーマのsingle.phpで、メインループのthe_post()を実行した後に置く部分を示します。実際のサイトで試すときは、既存のタイトル・本文の出力と二重にならない位置にしてください。

今回は画像と同じ2件だけを、ID 26、27の順に取得します。これらのIDは検証用の値なので、ご自身の検証環境にある2件の投稿IDへ置き換えます。関連記事の自動選定ではなく、同じ投稿を使って、リセットの有無だけを比べるための条件です。

$related_query = new WP_Query(   [      'post_type'           => 'post',      'post_status'         => 'publish',      'posts_per_page'      => 2,      'post__in'            => [ 26, 27 ],      'orderby'            => 'post__in',      'ignore_sticky_posts' => true,   ]); if ( $related_query->have_posts() ) {   echo '<ul>';    while ( $related_query->have_posts() ) {      $related_query->the_post();       printf(         '<li><a href="%1$s">%2$s</a></li>',         esc_url( get_permalink() ),         esc_html( get_the_title() )      );   }    echo '</ul>';} // ここでは global $post が最後の関連記事を指したままです。the_title( '<h2>', '</h2>' );the_content();

この状態では、最後の2行が、いま開いている「WordPress高速化ガイド」ではなく、サブループで最後に表示した「関連記事：画像を軽くする方法」のタイトルと本文を出します。post__not_inや並び順を変えても、ループ後の表示対象は元へ戻りません。

wp_reset_postdata()をサブループ直後へ置く

修正では、追加したループが終わった直後、次のタイトルや本文を出す前にwp_reset_postdata()を置きます。次の例では、関連記事を囲むifが閉じた後に1回だけ追加しています。

$related_query = new WP_Query(   [      'post_type'           => 'post',      'post_status'         => 'publish',      'posts_per_page'      => 2,      'post__in'            => [ 26, 27 ],      'orderby'            => 'post__in',      'ignore_sticky_posts' => true,   ]); if ( $related_query->have_posts() ) {   echo '<ul>';    while ( $related_query->have_posts() ) {      $related_query->the_post();       printf(         '<li><a href="%1$s">%2$s</a></li>',         esc_url( get_permalink() ),         esc_html( get_the_title() )      );   }    echo '</ul>';} wp_reset_postdata(); // ここからは、いま開いている個別記事を参照します。the_title( '<h2>', '</h2>' );the_content();

このコードのポイントは、関連記事のループが終わった直後にwp_reset_postdata()を1回呼ぶことです。メインクエリで表示対象になっている投稿を使って、global $postなどの投稿データを設定し直します。個別記事のメインループ内なら、通常はブラウザで開いている記事へ戻ります。

ただし、wp_reset_postdata()は任意の直前の状態へ戻す関数ではありません。独自ループの中に別の独自ループを入れた場合は、外側のWP_Queryオブジェクトのreset_postdata()で戻す必要があります。まずは今回のように、個別記事へ関連記事を1つ追加した構成で動きを確かめます。

リセットを加えたコードは、本番とは分けたWordPress環境で、関連記事の後のタイトルと本文が元へ戻るか試します。検証や公開に使うサーバーをこれから用意する場合は、Xserverの料金・バックアップ条件も確認できます。契約によってリセット忘れが直るわけではありません。

サブループの直後に投稿データを戻す

リセットはページ末尾やfooter.phpへまとめず、サブループを書いたテンプレートやテンプレートパーツ内に置きます。サブループと元へ戻す処理を離すと、その間に追加されたテンプレートタグが別の記事を参照してしまうためです。

取得結果が0件なら、そのループではthe_post()が呼ばれず、投稿データも切り替わりません。ただし、ifの外にリセットを1回置く基本の書き方にしておくと、取得件数の変更や条件分岐の追加後も後片付けを忘れにくくなります。

正常なループ内の順番も見直したい場合は、the_post()の役割と基本構文を次の記事で確認できます。

あわせて読みたいthe_post()はいつ必要？役割・書く場所・使わないケース記事を読む

あわせて読みたいWP_Queryの基本構文と$argsの書き方記事を読む

4つの値を同じ場所で記録して原因を確かめる

表示だけで判断しにくい場合は、ローカル環境でサブループの直後とwp_reset_postdata()の直後に同じログを置きます。URLが示す個別記事のIDと、テンプレートタグが表示対象にしている記事のIDを分けて記録するのがポイントです。

global $post; error_log(   wp_json_encode(      [         'queried_object_id' => get_queried_object_id(),         'global_post_id'    => $post instanceof WP_Post ? $post->ID : null,         'get_the_ID'        => get_the_ID(),         'title'             => get_the_title(),      ],      JSON_UNESCAPED_UNICODE   ));

wp-config.phpでWP_DEBUGとWP_DEBUG_LOGを有効にしている場合、通常はWordPressのwp-content/debug.logで出力を確認できます。画面にログを出さないため、WP_DEBUG_DISPLAYはfalseにします。これらはローカルやステージング環境だけで一時的に使い、本番では有効にしないでください。

queried_object_idだけがブラウザで開いている個別記事で、残り3つが最後の関連記事なら、クエリ条件より先にwp_reset_postdata()の有無と位置を確認します。4つがすべて開いている記事へ戻れば、その後のthe_title()やthe_content()も同じ記事を参照できます。確認用ログは原因を特定したら削除してください。

リセットで直らないときは表示が変わる場所を見直す

別タイトルが出る問題でも、発生位置によって確認先は変わります。

IDや投稿オブジェクトを明示してget_the_title( $post_id )やget_permalink( $post_id )を使い、the_post()もsetup_postdata()も呼んでいない処理は、global $postを切り替えません。その処理だけを理由にwp_reset_postdata()を追加する必要はありません。

query_posts()でメインクエリそのものを置き換えた場合は、wp_reset_query()まで含めて別に考えます。新しい独自一覧にはnew WP_Query()を使い、今回の症状へ不要な修正を混ぜないようにします。

投稿データを戻す仕組みやWP_Queryの基礎から確認したい場合は、次の記事もあわせてご覧ください。

あわせて読みたいwp_reset_postdata()が必要な理由｜WP_Queryのサブループ後に戻すもの記事を読む

あわせて読みたいWP_Queryとは？初心者向けに役割と使い方を解説記事を読む

リセットの位置を直しても、関連記事として取得される投稿が違う場合は、投稿タイプや絞り込み条件を見直します。WP Query Builderで必要な条件を整理できます。

リセット前後で、タイトルと投稿IDがどう変わるか

最後に、記事の表示対象が切り替わる順番を追ってみましょう。「WordPress高速化ガイド」（ID 28）を開き、関連記事2件を表示する例では、次のように変わります。上の画面と同じローカルWordPressで取得した値です。

URLの対象は途中で変わりません。表示対象だけが関連記事へ進み、最後のリセットで「WordPress高速化ガイド」へ戻ります。自分のページで調べるときも、同じ場所でIDを比べると、どこからずれたかを追いやすくなります。

投稿データを戻す仕様を公式資料で確認する

wp_reset_postdata()の戻り先と、WP_Queryのthe_post()が投稿データを設定する範囲は、WordPress公式ドキュメントで確認できます。

元の記事へ戻ったことを確かめてから反映する

タイトルだけでなく、本文やリンク先も元の記事へ戻っているかを確認してください。調査のために追加したログは取り除き、変更前のファイルへ戻せる状態で本番へ反映しましょう。