wp_reset_postdata not working? See if you’re being affected by this known WordPress bug

Are you having trouble with wp_reset_postdata not working like it should?

If you’re trying to reset post data on an admin page, you may not be experiencing a simple case of programmer error. There’s a known bug in WordPress (that’s been around for SEVEN years, believe it or not) related to wp_reset_postdata on admin edit pages.

Read on to find out if this bug is affecting you, and if so, how to get around it.

Known wp_reset_postdata bug on admin pages

To put it simply, there’s a known bug in WordPress core that means wp_reset_postdata doesn’t work as it should on admin edit pages.

A tiny note exists on the WP_Query class reference, but if you happen to miss that—I did when I stumbled on the bug myself—you could potentially spend hours wondering what the heck you’re doing wrong.

Don’t hold your breath for a quick fix, either: the bug was first reported in 2011 and the last progress you can see on the ticket was from over a year ago, so it may not be getting fixed any time soon. It’s not a huge bug, so the WordPress team have bigger fish to fry.

There’s a lot more detail on the specifics of the problem on Trac ticket #18408. Some of the most informative comments are:

While using an explicit WP_Query object in a meta box, you cannot reset the postdata after the loop, no matter what you try. Any subsequent meta boxes identify global $post as the last post of the custom query.
— @misternify, https://core.trac.wordpress.org/ticket/18408#comment:9

The root issue is that wp_reset_postdata() is designed to reset globals to match the main query. But in the case of post.php, there is no main query – the $post global is populated manually, using get_post(), rather than through the normal $wp_query loop.
— @boonebgorges, https://core.trac.wordpress.org/ticket/18408#comment:14

How to get around the wp_reset_postdata admin bug

There are a handful of different solutions suggested in the Trac ticket’s discussion. The one you ultimately choose is down to programmer preference, but here’s how I decided to proceed:

The solution I used in EBB was suggested by @jpSimkins in https://core.trac.wordpress.org/ticket/18408#comment:25:

To bypass this issue, do not use the_post as this is the issue.

So, after you issue your query and start to loop through the results, do not use $query->the_post() to set up post data. As @jpSimkins notes in his comment, you won’t be able to use template tags like get_the_title() without arguments, but you can still access that information in other ways.

Here’s the relevant code snippet from EBB for your reference:

$args = array(
	'post_type' => EBB_Optin_CPT::POST_TYPE_SLUG,
	'post_status' => 'publish',
	'posts_per_page' => -1,
	'order_by' => 'title',
	'order' => 'ASC'
);

$optin_query = new WP_Query( $args );

if ( $optin_query->have_posts() ) {

	$results = array();

	// Non-standard loop due to ongoing bug in core: https://core.trac.wordpress.org/ticket/18408
	// Can't wp_reset_postdata on post.php edit screen
	foreach ( $optin_query->get_posts() as $p ) :

		$results[] = array(
			'id' => $p->ID,
			'title' => get_the_title( $p )
		);

	endforeach;

}

According to the discussion on the Trac ticket, you can also use get_posts without encountering the bug (as long as you don’t setup_postdata in your results processing).

Have you been affected by the dreaded wp_reset_postdata bug? Feel free to moan about how much time you wasted looking for the problem in the comments below. ?