Additional choices for 'fields' parameter

[flixos90]

When using the 'fields' argument in the get_terms() function, there are several useful options that can be specified to get the exact return values needed (in addition to complete term objects it is possible to get ids, id=>parent, names, count, id=>name and id=>slug).

A similar functionality exists for post queries (like in get_posts()), however it doesn't provide the same value like its term-related equivalent (since in addition to complete post objects, it is only possible to request ids or id=>parent). The most important thing I am missing is something like id=>title, which would be especially useful for custom dropdowns or listings, but there might be other options that could be supported as well.

I will gladly write a patch for this issue after I have received some feedback.

[DrewAPicture]

Hi @flixos90,

I think adding 'id=>title' would be an interesting idea and worth the effort to write a patch for consideration. After quickly grokking the source for WP_Query, it seems like it would be relatively straightforward enhancement.

Edit: We would need unit tests to go along with it. See Tests_Query_Results in tests/query/results.php for a starting point.

[flixos90]

Okay great, I should be able to write a patch (and hopefully unit tests too) tomorrow.

[boonebgorges]

This ticket is pretty much a duplicate (albeit more specific) of #19866, which was marked wontfix after some discussion. In a nutshell, additional fields parameters that modify the SELECT clause of the SQL query wreak havoc with persistent caches: either (a) they bypass the cache altogether, or (b) they require separate cache buckets, which takes up space and makes invalidation more complicated. See https://core.trac.wordpress.org/ticket/19866#comment:6 and the follow-up discussion.

flixos90, is there any reason why the following doesn't work for your purposes?

$posts = get_posts( array( ... ) );
foreach ( $posts as $post ) {
    $options .= '<option value="' . esc_attr( $post->ID ) . '">' . esc_html( $post->post_title ) . '</option>';
}

Is your concern about performance?

[flixos90]

@boonebgorges, it's not that your example doesn't work. My issue is not about performance either, it is rather about convenience. The purpose of the id=>title however would be to receive an array that can immediately be passed to one of the many custom-fields/settings-pages frameworks out there (most of which accept an array of 'value' => 'label' for options in dropdowns), so we could have a dropdown of posts there. I have been writing foreach loops over and over that transform a WP_Post array into an array of 'ID' => 'post_title', so I would say this enhancement is not critical, but it would certainly make things quicker for developers.

Since it is only a convenience enhancement, after hearing your thoughts and reading the discussion I see it is probably not worth the effort to put it into WP_Query.
My question now is: would it be possible to implement this functionality directly into the get_posts() function (not the method in WP_Query)? We could check for the 'fields' argument there, and if it is set to something like 'id=>title', we would "memorize" that, overwrite the value to an empty string and then execute the usual query. The query result would then be transformed to the desired return value directly in the get_posts() function. This way we would not conflict with any existing logic, but still have a way to implement the enhancement.

[sebastian.pisula]

4.7-alpha-38779

[flixos90]

Thanks for the patch @sebastian.pisula!

I have however started to agree with @boonebgorges, I think adding this functionality will easily bust cache and could cause other related problems for very little benefit. Therefore I suggesting re-closing this as duplicate.

[ocean90]

Duplicate of #19866.