[wp-trac] [WordPress Trac] #39632: Adding Query identifier attribute

WordPress Trac noreply at wordpress.org
Fri Jan 20 05:38:37 UTC 2017


#39632: Adding Query identifier attribute
-----------------------------+------------------------------
 Reporter:  prosti           |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Query            |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  ui
-----------------------------+------------------------------
Description changed by SergeyBiryukov:

Old description:

> You create any query by passing the arguments to `WP_Query`.
> What will happen if we add the custom query identifier `_id` like this?
>
> {{{#!php
> <?php
> $args = array(
>   '_id' => 'custom_name',
>    ...
> );
> $q = new WP_Query( $args );
> }}}
>
> Nothing bad, and one good thing.
>
> Using this `_id` I can work with filters like `posts_where` super easy.
> This would work for many other filters from ''wp-includes/class-wp-
> query.php''
>
> {{{#!php
> <?php
> function _20170118_posts_where( $where,  \WP_Query $q ){
>   // $q->query will hold the query arguments ...
>   if ( 'custom_name' == $q->query['_id'] ){
>     // do our improvement on $where
>     return $where.
>   }
>  return $where;
> }
>
> add_filter( 'posts_where', '_20170118_posts_where', 10 , 2 );
> }}}
>
> If you need more details here is the original
> [http://wordpress.stackexchange.com/questions/252246/how-to-detect-
> custom-query-inside-posts-where-hook/252406#comment375812_252406
> example].
>

> This already works, but we can benefit more if we add the `_id` for all
> WordPress core generated queries?
>
> This should happen just after `WP_Rewrite` returns the query arguments,
> based on the query flags.
>
> Let's test the future in case of main search query ( `$is_search` flag is
> true ).
>
> You may write like this to address the search query:
>
> {{{#!php
> <?php
> add_filter( 'posts_where', function ( $where, \WP_Query $q ) {
>   if( ! is_admin() && $q->is_main_query() && $q->is_search() ){
>   ... // do something with $where
>   }
> return $where;
> }}}
>
> but with the `_id` '''main-search''' argument, you could write:
>
> {{{#!php
> <?php
> add_filter( 'posts_where', function ( $where, \WP_Query $q ) {
>   if ( 'main-search' == $q->get( '_id' ) ){
>   ... // do something with $where
>   }
> return $where;
> }}}
>
> This is somehow similar to the threads
> https://core.trac.wordpress.org/ticket/15063
> https://core.trac.wordpress.org/ticket/23833
>
> but not exactly.
>
> What would be the gain?
>
> WordPress query programming may become simpler, and queries may be
> managed using '''human-readable''' names.

New description:

 You create any query by passing the arguments to `WP_Query`.
 What will happen if we add the custom query identifier `_id` like this?

 {{{#!php
 <?php
 $args = array(
   '_id' => 'custom_name',
    ...
 );
 $q = new WP_Query( $args );
 }}}

 Nothing bad, and one good thing.

 Using this `_id` I can work with filters like `posts_where` super easy.
 This would work for many other filters from ''wp-includes/class-wp-
 query.php''

 {{{#!php
 <?php
 function _20170118_posts_where( $where,  \WP_Query $q ){
   // $q->query will hold the query arguments ...
   if ( 'custom_name' == $q->query['_id'] ){
     // do our improvement on $where
     return $where.
   }
  return $where;
 }

 add_filter( 'posts_where', '_20170118_posts_where', 10 , 2 );
 }}}

 If you need more details here is the original
 [http://wordpress.stackexchange.com/questions/252246/how-to-detect-custom-
 query-inside-posts-where-hook/252406#comment375812_252406 example].


 This already works, but we can benefit more if we add the `_id` for all
 WordPress core generated queries?

 This should happen just after `WP_Rewrite` returns the query arguments,
 based on the query flags.

 Let's test the future in case of main search query ( `$is_search` flag is
 true ).

 You may write like this to address the search query:

 {{{#!php
 <?php
 add_filter( 'posts_where', function ( $where, \WP_Query $q ) {
   if( ! is_admin() && $q->is_main_query() && $q->is_search() ){
   ... // do something with $where
   }
 return $where;
 }}}

 but with the `_id` '''main-search''' argument, you could write:

 {{{#!php
 <?php
 add_filter( 'posts_where', function ( $where, \WP_Query $q ) {
   if ( 'main-search' == $q->get( '_id' ) ){
   ... // do something with $where
   }
 return $where;
 }}}

 This is somehow similar to the threads #15063 and #23833, but not exactly.

 What would be the gain?

 WordPress query programming may become simpler, and queries may be managed
 using '''human-readable''' names.

--

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


More information about the wp-trac mailing list