Opened 6 years ago
Closed 15 months ago
#51796 closed enhancement (wontfix)
Raw post data instead of WP_Post instances
| Reported by: | screamingdev | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Query | Version: | |
| Severity: | normal | Keywords: | reporter-feedback |
| Cc: | Focuses: | performance |
Description
Within WP_Query::get_posts you find:
// Convert to WP_Post objects. if ( $this->posts ) { $this->posts = array_map( 'get_post', $this->posts ); }
This costs a lot of time when fetching a lot of posts (e.g. products, orders, etc).
It could be fasten up by fetching only the field "ids" but this is also bad because when we need the post_content then a "get_post( 123 )" would do another query.
To bypass all of this a new "fields operator" could be added:
if ( $this->posts && $q['fields'] !== 'raw' ) { $this->posts = array_map( 'get_post', $this->posts ); }
The SQL-Query would still fetch all data but we would prevent the data from going through the "get_post" stuff.
In times of Generator it is ridiculous to iterate over the same set of data multiple times. By receiving the raw data the developer can decide when to generate a WP_Post object.
Note:
filter = "raw" could imply "suppress_filters" = true because we no longer carry WP_Post objects. But it should be allowed by the developer to switch "suppress_filters = false" again because the stdObjects have almost the same structure as WP_Post objects. This means (in short):
if ( ! isset( $q['suppress_filters'] ) ) { $q['suppress_filters'] = ($q['filter'] === 'raw' ? true: false); }
Change History (5)
#3
@
6 years ago
What? It creates objects and runs through some filters.
Getting the raw data from the database can be enough in some scenarios (esp. for fetching a lot of posts, products, orders, etc).
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
What's the performance impact of this change?