Opened 10 years ago
Closed 10 years ago
#30778 closed enhancement (wontfix)
Extend WP_Query to allow for querys of posts with attachments with certain metadata
Reported by: | pampfelimetten | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.1 |
Component: | Query | Keywords: | |
Focuses: | Cc: |
Description
Currently, if you want to find posts with attachments with certain meta data, you have to use two different queries. One for all the attachments with the right metadata, then collect the parent Ids, and a second query where you set the 'postin' argument.
This works, but it is clumsy to solve this in php. It would be great if you could set off something like:
$args['post_type'] = 'post'; $args['post_status'] = 'publish'; $args['s'] = 'searchtext'; $args['child_query']['post_type'] = 'attachment'; $args['child_query']['post_status'] = 'inherit'; $args['child_query']['posts_per_page'] = '-1'; $args['child_query']['post_mime_type'] = 'audio';
This way, you could easily query for posts with certain attachment meta data, for example for a post with mp3s with a bitrate higher than 128kb.
Take a look at our site if you want to see a real life use case: http://cba.fro.at/search
Our users can set off quite complex querys with multiple metadata specification, some of which is saved as metadata of posts, some of which is saved as metadata of attachments of these posts. But us I said, we have to split it into two queries at the moment.
An interesting idea, but I'm not sure I see the value. If the idea is that the child_query will accept all params of
WP_Query
, then I suppose the internals would work like this: a secondaryWP_Query
object would be fired up, and either the SQL would be retrieved and put into a$wpdb->posts.ID IN
subquery on the main query, or the matching IDs would be fetched and parsed intopost__in
. Either way, you're saving little to no computational overhead. And if you're forced to assemble what amounts to a new array of query vars for 'child_query', then you're not really saving much time in PHP either. This would do the same thing:IMO, this is just as readable as the proposed 'child_query', and produces no overhead beyond what would presumably be required for 'child_query'.
Closing as wontfix, though if I've misunderstood, or if you have more details on how the proposed feature would be a significant improvement on the above, please feel free to reopen with those details.