[wp-trac] [WordPress Trac] #18408: Can't wp_reset_postdata after custom WP_Query in an admin edit page

[WordPress Trac]

#18408: Can't wp_reset_postdata after custom WP_Query in an admin edit page
--------------------------------------------------+------------------------
 Reporter:  ericlewis                             |       Owner:  ericlewis
     Type:  defect (bug)                          |      Status:  reopened
 Priority:  normal                                |   Milestone:
Component:  Options, Meta APIs                    |     Version:  3.8.1
 Severity:  normal                                |  Resolution:
 Keywords:  has-patch needs-testing dev-feedback  |     Focuses:
--------------------------------------------------+------------------------
Changes (by misternifty):

 * status:  closed => reopened
 * resolution:  invalid =>
 * version:  3.2.1 => 3.8.1
 * component:  Editor => Options, Meta APIs


Comment:

 This is not invalid. I was able to replicate this in 3.8.1. 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.

 @ericlewis assertion that WP_Query and template tags should not be used in
 wp-admin is not documented anywhere in the Codex that I can find nor in
 any posts by core contributors. Multiple loops using the an explicit
 creation of a WP_Query object in wp-admin post screens should work just
 like any other query method or function.

 This is causing issues for other plugins that register meta boxes and
 generating support tickets like the following:
 http://wordpress.org/support/topic/plugin-wordpress-seo-by-yoast-after-
 update-it-wont-save-seo?replies=32
 I identified the noted support example here after trying to save post meta
 for WP SEO but the meta that surfaced after update was based off the post
 ID of the last post in my custom query in the previous meta box. After a
 look under the hood, the meta was actually saved properly to the origin
 post ID as it was a form option in the DOM already.

 Using get_posts instead of new WP_Query works, but that's just applying a
 bandaid fix when this should work out-of-the-box. It's my opinion that
 this needs to be fixed rather than say, 'use another query method'. Plugin
 authors will continue to use WP_Query in meta boxes and it will continue
 to break the main query for the subsequent page load.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/18408#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform