I’m hooking into ‘edit_form_after_editor’
add_action('edit_form_after_editor', 'make_the_button_to_generate_a_report_number');
function make_the_button_to_generate_a_report_number($post) {
Check that I am dealing with a custom post type of ‘publications’
if ($post->post_type != 'publications') return;
Create a number of arguments that I then run in a WP_Query
$new_query = new WP_Query($report_number_args);
use that data to do stuff…
Then I want to reset $post back to how it was, so I run
wp_reset_postdata();
But $post stays on the last item I had received from my new WP_Query().
What am I doing wrong? Is there a special way to reset the postdata when dealing with a custom post type?
Update:
At the beginning and end of the function I have:
echo("<h4>the title = </h4>");
echo(the_title());
At the beginning the title is the title for the custom post type I clicked on to edit, or blank if I am creating a new post.
At the end the title is always the last post from my query.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
I believe the official stance is to not use WP_Query in the admin panel. There’a a trac ticket #18408 on this exact same issue. Here’s what Boone says:
The root issue is that
wp_reset_postdata()is designed to reset globals to match the main query. But in the case ofpost.php, there is no main query – the$postglobal is populated manually, usingget_post(), rather than through the normal$wp_queryloop.
Because the post is populated manually in the admin panel you will not be able to reset it in a traditional fashion. If you print out the global $wp_query at this point you’ll also find that it’s empty.
The preferred method is to instead use get_posts() which doesn’t override the global $post object.
You could manually preserve the global $post object in a custom variable and manually reset it once you’re done with your loop. That being said, I do not know the overarching consequences with this method. It’s safer to use get_posts() when possible.
global $post;
$tmp_post = $post;
$posts_query = new WP_Query( $args );
if( $posts_query->have_posts() ) {
while( $posts_query->have_posts() ) {
$posts_query->the_post();
the_title();
}
$post = $tmp_post;
}
Another solution may be, specifically in the admin panel, store the global $post in the global $wp_query object during loop_start. For example:
/**
* Store the global $post object so we may reset it
*
* @return void
*/
function wpse377565_admin_post_storage() {
global $wp_query,
$post;
if( ! is_admin() ) {
return;
}
$wp_query->post = $post;
}
add_action( 'loop_start', 'wpse377565_admin_post_storage' );
The wp_reset_postdata() function looks for $this->post in the global $wp_query object which is both empty and available in admin requests. We could use the above action hook to allow us to call wp_reset_postdata(). Again, I also do not know the overarching consequences of doing this, use with caution.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0