[wp-trac] [WordPress Trac] #23833: Add a unique ID or NAME to target queries .

[WordPress Trac]

#23833: Add a unique ID or NAME to target queries .
-------------------------+------------------------------
 Reporter:  krembo99     |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Query        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+------------------------------

Comment (by MikeSchinkel):

 @prettyboymp - Thanks for the follow up.

 I think I understand your concern, but only on an abstract basis, i.e. to
 make sure that 3rd party hooks are not affected by context. What I can't
 envision is an example of the thing you are trying to guard against. Your
 examples show how to do it right, but without a corresponding how-to-do-
 it-wrong example it's unclear where the problem would be.

 BTW, the OP suggested a context and then @SergeyBiryukov references my
 related ticket #15063 so my interest may be different than the OPs; he'll
 have to explain himself better for me to understand what his use-cases
 really are.

 My use-case need for contexts was about queries that WordPress itself
 generates, typically from within the admin but also within widgets, and by
 definition the contexts supplied would need to be cumulative, i.e. code
 calling a high level function might set context to `'admin_page_list'` and
 then `WP->query_posts()` adds `wp_query_posts` to context, and so on down
 the chain.  A perfect example need for context is the code in
 `WP_Posts_List_Table` that displays a category dropdown for the Quick
 Edit:

 {{{
 if ( 'top' == $which && !is_singular() ) {

   $this->months_dropdown( $this->screen->post_type );

   if ( is_object_in_taxonomy( $this->screen->post_type, 'category' ) ) {
     $dropdown_options = array(
       'show_option_all' => __( 'View all categories' ),
       'hide_empty' => 0,
       'hierarchical' => 1,
       'show_count' => 0,
       'orderby' => 'name',
       'selected' => $cat
     );
     wp_dropdown_categories( $dropdown_options );
   }
   do_action( 'restrict_manage_posts' );
   submit_button( __( 'Filter' ), 'button', false, false, array( 'id' =>
 'post-query-submit' ) );
 }
 }}}
 If I need to modify the `WP_Query` that `wp_dropdown_categories()`
 ultimately calls, let's say I want to limit categories to only list the
 parent categories for some reason, it can be error prone and hard to know
 for certain that I'm only modifying what I want to modify and not
 accidentally modifying some other use of `wp_dropdown_categories()`. I can
 inspect `$pagenow` and verify that it is `edit.php` but what happen if
 some other plugin also uses `wp_dropdown_categories()` on the same page
 but for a different purpose? My code will break theirs.

 However, if WordPress were to establish a "standard" for an optional
 `'context'` array then WordPress itself could change the code above to
 include a context argument such as `'context' => array(
 'admin_post_list_quick_edit' )`:
 {{{
 if ( 'top' == $which && !is_singular() ) {

   $this->months_dropdown( $this->screen->post_type );

   if ( is_object_in_taxonomy( $this->screen->post_type, 'category' ) ) {
     $dropdown_options = array(
       'show_option_all' => __( 'View all categories' ),
       'hide_empty' => 0,
       'hierarchical' => 1,
       'show_count' => 0,
       'orderby' => 'name',
       'selected' => $cat,
       'context' => array( 'admin_post_list_quick_edit' )
     );
     wp_dropdown_categories( $dropdown_options );
   }
   do_action( 'restrict_manage_posts' );
   submit_button( __( 'Filter' ), 'button', false, false, array( 'id' =>
 'post-query-submit' ) );
 }
 }}}
 With this a plugin developer could be sure to target changes to only work
 when `'admin_post_list_quick_edit'` is in `$query->context` and thus not
 break other plugin's use of `wp_dropdown_categories()`. And other plugins
 could also add a context so that still others that target their contexts
 could do so explicitly.

 BTW, as far as I can envision the benefits are not really needed when you
 are the developer writing the `WP_Query()` call because you can already do
 it yourself. The benefits are instead two-fold and if/when WordPress core
 decorates its code with contexts:

 1. To enable plugin developers to target queries that they did not write
 and for which there are no hooks that allow them to modify the query args
 before it is called _(even if there were/are hooks using hooks for this
 means multiple collaborating hooks to effect just one change.)_
 2. To establish a best practice for plugin developers to follow so their
 specific queries can be targeted by other plugin developers too.

 Given my use-case can you envision it causing the kind of problems you are
 concerned about and if so can you give specifics to help me better
 understand? Thanks in advance.

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