WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 18 months ago

#33519 closed enhancement (duplicate)

Additional choices for 'fields' parameter

Reported by: flixos90 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Query Keywords: has-patch
Focuses: Cc:
PR Number:

Description

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.

Attachments (1)

33519.patch (2.2 KB) - added by sebastian.pisula 3 years ago.
4.7-alpha-38779

Download all attachments as: .zip

Change History (10)

#1 @DrewAPicture
4 years ago

  • Keywords needs-patch added

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.

Last edited 4 years ago by DrewAPicture (previous) (diff)

#2 @flixos90
4 years ago

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

#3 @boonebgorges
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

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?

#4 @flixos90
4 years ago

@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.

Last edited 4 years ago by flixos90 (previous) (diff)

@sebastian.pisula
3 years ago

4.7-alpha-38779

#5 @sebastian.pisula
3 years ago

  • Keywords has-patch added; needs-patch removed
  • Resolution duplicate deleted
  • Status changed from closed to reopened

This ticket was mentioned in Slack in #core by sebastian.pisula. View the logs.


3 years ago

#7 @netweb
3 years ago

  • Milestone set to Awaiting Review

#8 @flixos90
3 years ago

  • Keywords close added

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.

#9 @ocean90
18 months ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from reopened to closed

Duplicate of #19866.

Note: See TracTickets for help on using tickets.