[wp-trac] [WordPress Trac] #14777: Adding "fields" to arguments array for get_posts()/query_posts()/WP_Query()

[WordPress Trac]

#14777: Adding "fields" to arguments array for get_posts()/query_posts()/WP_Query()
--------------------------+-------------------------------------------------
 Reporter:  mikeschinkel  |       Owner:                 
     Type:  enhancement   |      Status:  new            
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Query         |     Version:                 
 Severity:  normal        |    Keywords:                 
--------------------------+-------------------------------------------------
 Hi all,

 I find myself more and more often needing to get a list of post IDs so I
 can call another WordPress database API function to include or exclude
 those posts. Calling `get_posts()` on a potentially large number of
 records and passing all the fields (especially `post_content`) between
 MySQL and WordPress is hugely inefficient when I only need the one ID.

 My two (2) options are:

  1.) '''Code is directly in SQL.'''  This is easy but I know it's
 definitely not a best practice and I would like to use the WordPress API
 wherever possible.

  2.) '''To use a `post_fields` hook'''. Problem is that those are global
 and I have to start wrapping logic around my code to ensure I don't
 accidentally break some plugin or some other part of WordPress (this
 approach is much like trying to secure a server by starting with all the
 attack vectors open and then trying to close them all.)

 So I'd like to propose we simply add `"fields"` as a recognized argument
 for `get_posts()`, i.e.

 {{{
 $posts = get_posts(array(
    'fields' => 'ID,post_title',
    'post_type' => 'movie',
    'post_status' => 'publish',
    'order' => 'ASC',
    'posts_per_page' => -1
 ));
 }}}

 I know I could make the same argument for `joins`, `where`, `orderbys` et.
 al. but I'd argue this is enough of a special case it could really use
 some early attention. For a query on the home page of a high traffic site
 that changes often enough to not be able to be cached this tiny change
 could make a major difference in performance.

 If you'd like to see a use case here is one:

 - [http://wordpress.stackexchange.com/questions/1140/removing-duplicate-
 custom-taxonomy-terms-from-within-a-dropdown-select Removing Duplicate
 Custom Taxonomy Terms from within a Dropdown Select?]

 Unfortunately I still struggle with creating patches even though I have
 done it a few times in the past but each time I seem to have to start
 relearning from scratch. I seem to have a mental block for some reason on
 patches ([http://wordpress.stackexchange.com/questions/990/ '''can someone
 help me with this?''']) so I haven't gone ahead and written a patch but
 will tackle it if I get the task blessed.

 -Mike

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14777>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software