[wp-trac] [WordPress Trac] #15063: Add a "context" property to WP_Query as a 2nd param to its constructor

[WordPress Trac]

#15063: Add a "context" property to  WP_Query as a 2nd param to its constructor
--------------------------+-------------------------------------------------
 Reporter:  mikeschinkel  |        Owner:         
     Type:  enhancement   |       Status:  closed 
 Priority:  normal        |    Milestone:         
Component:  Post Types    |      Version:         
 Severity:  normal        |   Resolution:  wontfix
 Keywords:                |  
--------------------------+-------------------------------------------------

Comment(by mikeschinkel):

 Replying to [comment:16 prettyboymp]:
 > I have a couple of reservations about adding a 'context' as a 2nd
 parameter.

 Thanks for sharing your specific concerns.

 > First, it can be added as a query_var passed into WP_Query that is just
 as easy to access as if it were a direct property of WP_Query.

 True, but I equally have reservations about storing it in `query_vars`:

   1.) Less important but still a concern is that storing `context` in
 `query_vars` turns it into a '''reserved word''' and thus can no longer be
 used for actual queries. I think it's reasonable to expect that people
 might want to create "Context" custom post types and/or have use-cases
 where the term `"Context"` was in their problem domain vs. the technical
 domain. And this use of context ''feels'' to me to be more on peer with
 `query_vars` than being one of many query vars.

  2.) More important is what I wrote in
 [http://core.trac.wordpress.org/ticket/15063#comment:11 comment 11] which
 is I think we need multiple contexts much like you can put multiple CSS
 classes on a single HTML element and be able to inspect each separately.
 If it's stored in a `query_var` this really doesn't work; it probably
 needs it's only mini `"context"` API for adding and inspecting.

 > The second is that 'context' describes the theme context, but not really
 the data that needs to be returned.  A query_var that related more to the
 filter would be better here.

 I both disagree and concur at the same time. I don't agree that my example
 was specific to the theme context but I do agree that we need to know the
 context of the query (you call it "filter" but I think you really meant
 "query", right?)

 Basically we need to be able to pinpoint a logic path and be able to say
 ''"I want my filter to apply to *that*, and that only!"''

 > This not only better describes the filter, but allows you to potentially
 pass in several query modifiers instead of just one that context would
 represent.

 And here I think we are in sync regarding the need to have multiple
 contexts as CSS has multiple classes.  Maybe what we need is a
 `WP_Context`and a global `$wp_context` instead?

 ----

 So I should have done this up front so let me give some examples:

 {{{
 http://example.com/wp-admin/edit.php?post_type=page
 }}}

 `WP_Query` is called on line 912 in `wp_edit_posts_query()` and has the
 following values in `$wp_query->query_vars`:

  - post_type="page"
  - order="asc"
  - orderby="menu_order title"
  - posts_per_page=-1
  - posts_per_archive_page=-1

 So there's no real context for me to draw on except to inspect
 `$pagenow='edit.php'` and `$_GET['post_type']='page'`. It would be much
 nicer if context were set on line 912 and I could just inspect
 `$wp_query->context` to see if it were equal to `'admin-page-list'`

 Moving on to the page editor:
 {{{
 http://example.com/wp-admin/edit.php?post_type=page
 }}}

 On line 4452 in `wp_get_post_autosave()` `WP_Query` gets called and
 assigns the following values:

  - name="2-autosave"
  - post_parent="2"
  - post_type="revision"

 Now I can guess that if name is `preg_match('#^([0-9]+)-autosave$',…)` and
 `post_status=='inherit'` and `$pagenow=='post.php'` and
 `isset($_GET['post'])` and '`isset($_GET['action']) &&
 `$_GET['action']=='edit'` that I'm getting the post autosave from the
 admin page but is would be immensely easier if I were simply able to
 inspect `$wp_query->context=='get-post-autosave'`.

 On the dashboard:
 {{{
 http://example.com/wp-admin/
 }}}

 On line 485 of `/wp-admin/includes/dashboard.php` the function
 `wp_dashboard_recent_drafts()` calls `WP_Query` with `query_vars` of

  - post_type="post"
  - post_status="draft"
  - author="1"
  - posts_per_page="5"
  - orderby="modified"
  - order="DESC"


  Again, nothing besides artifacts that tell me this was being called for
 the dashboard's recent posts. `$wp_query->context=='dashboard-recent-
 posts'` would be better.

 Of course in the prior example, `'dashboard-recent-posts'` is being called
 in the context of a metabox but how would I know that? The function
 `do_meta_boxes()` on line 2830 of `/wp-admin/includes/template.php`
 exports no context information. Having this use a global `$wp_context`
 could really help.

 -----

 Anyway, I don't feel like I know what the fully correct solution is yet
 but I do now that there is a problem; I'm hoping others will see that
 problem and help come up with a workable solution.

 -Mike

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/15063#comment:19>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software