WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#4070 closed enhancement (invalid)

rewrite get_posts to call WP_Query->get_posts, using temporary filters as needed

Reported by: kevinB Owned by: markjaquith
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: get_posts
Focuses: Cc:

Description

The get_posts function in post.php seems redundant and hinders plugin API consistency. Plugin functions filtering WP_Query->get_posts should not suffer the ignominy of unfiltered results sneaking out through a redundant, unhookable equivalent function. Why not just make get_posts wrap WP_Query->get_posts?

Attached patch rewrites get_posts to call WP_Query->get_posts. The arguments numberposts and category are remapped to posts_per_page and cat.

get_posts arguments which WP_Query->get_posts does not (yet?) support are include, exclude, meta_key, meta_value, post_parent. These are supported by way of temporary filters on posts_join and posts_where.

If the future development path involves upgrading WP_Query->get_posts to support these other args, get_posts can be simplified, ultimately to a 10-line wrapper.

Since WP_Query->get_posts already supports multiple category inclusion/exclusion, this solves #1625 too.

If this is not the direction y'all want to go, please say so and I will submit another ticket with new hooks in post.php~get_posts. But the wrapper approach seems cleaner to me. Why have two sets of hooks for the same query?

For sample usage, see themes\tarski\footer.php

Attachments (1)

includes~post.php~get_pages.diff (7.4 KB) - added by kevinB 7 years ago.
rewrites get_posts as a WP_Query->get_posts wrapper

Download all attachments as: .zip

Change History (7)

kevinB7 years ago

rewrites get_posts as a WP_Query->get_posts wrapper

comment:1 ryan7 years ago

get_posts() is usually used specifically because it avoids the hooks in WP_Query. Those hooks can screw things up when you want what is really in the DB. get_posts() also avoids the parse query overhead. Maybe the query guts in WP_Query::get_posts() could be moved into ::get_posts() which would then be called from WP_Query::get_posts(). That way the actual DB query functionality isn't duplicated. Don't know how doable that is.

comment:2 kevinB7 years ago

I know this patch was a little presumptuous on my part. Thought it was worth a try and I'll take no offense to having it canned or postponed indefinitely. Here are some observations to keep the conversation going.

There seems to be two sets of competing interest here:

  • features vs. performance
  • empowering plugins vs. guarding against them

I can see that get_posts is an efficient backdoor for diagnostic/utility tasks. My problem is that it's both unhookable AND a super easy call for themes, making it tough for an access control plugin to plug all the conventional holes.

Please consider #4073 as an alternate patch.

comment:3 rob1n7 years ago

Personally I use get_posts() when I want to display a "sub-query", such as recent posts in the sidebar. As Ryan says, I think this function should stay raw-from-the-DB, and we do have query_posts().

comment:4 kevinB7 years ago

I guess it comes down to a documentation issue for theme / plugin developers.

Themes which use get_posts to display "recent posts" sidebars will be incompatible with plugins that do access control by query filtering.

Themes which care to support such plugin functionality should use query_posts instead.

comment:5 kevinB7 years ago

  • Resolution set to invalid
  • Status changed from new to closed

comment:6 foolswisdom7 years ago

  • Milestone 2.2 deleted
Note: See TracTickets for help on using tickets.