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

WordPress Trac noreply at wordpress.org
Sun Jan 4 00:59:34 UTC 2015

#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:  Awaiting
Component:  Query                                |  Review
 Severity:  normal                               |     Version:  3.8.1
 Keywords:  has-patch needs-testing 2nd-opinion  |  Resolution:
                                                 |     Focuses:
Changes (by boonebgorges):

 * keywords:  has-patch needs-testing dev-feedback => has-patch needs-
     testing 2nd-opinion


 Thanks, ericlewis. Now I see what's going on.

 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. So perhaps the most
 straightforward way to resolve this is by doing a "real" `$wp_query` loop
 on edit.php. See [attachment:18408-wp-query-in-admin.php]. This is similar
 to your original suggestion to modify `get_default_post_to_edit()`, but
 far more targeted.

 The good thing about this solution is that `WP_Query` instances on
 edit.php now work exactly like `WP_Query` instances anywhere else. The bad
 thing is that it's kinda arbitrary. On the front end, the WP bootstrap
 process (see especially `WP::main()`) fires up the main WP query based on
 the query vars parsed out of the URL. If we fake it on post.php as I've
 suggested in the patch, we're reproducing only part of this process, which
 could lead to other bits of confusion down the line. (For example, if you
 see a `$wp_query` global, do you also expect to find a

 It's possible that there would be odd side effects of the suggested
 `$wp_query` override - in particular, I guess, if a metabox is
 manipulating the global in some funny way. That being said, I'm having a
 hard time thinking of any realistic examples of possible breakage.

 What do others think?

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

More information about the wp-trac mailing list