WordPress should not unnecessarily query posts at page load

[junsuijin]

For plugins like BuddyPress, with pages that have no WordPress post content, a query for posts at load time creates unnecessary overhead. I've tested this patch (with WordPress MU) and it removes 3 queries on all pages when the 'NO_QUERY' constant is defined. A very quick scan of page load times also suggests about 20% in time savings on average.

Other plugins like shopping carts and any others that needn't query the WordPress posts table can benefit from this as well.

My previous means of achieving this effect was to simply return null to the 'posts_request' filter, which removes only 2 queries per page.

The devised method uses suggestions from azaozz and sivel, and allows for setting the definition of 'NO_QUERY' using the 'init' action hook. It also still allows for further querying of the posts at a later point if necessary.

I welcome further suggestions about the patch, and any other ways this could be accomplished more effectively.

Perhaps wp() shouldn't be called at all for those pages.

Replying to ryan:

Perhaps wp() shouldn't be called at all for those pages.

Possibly a good idea.

Whatever I think a filter to which you return false to disable stuff may be better here than a define.

We don't want to create something that people put into wp-config.php by accident defines should be reserved for things configured there IMHO

New patch that replaces the constant with a filter, and skips wp() as well.

It seems I may have misunderstood Ryan's suggestion. I have talked to junsuijin and he should be doing some testing and adding a new patch.

Building on ryan, westi, and sivel's work/suggestions, this new patch seems to further improve page loading times. More testing indicates that extra queries are caused by setting the 'wp_main' filter to false when site-wide post requests are made later on. This seems a case of benefitting the majority over the minority though, since the people that find the 'wp_main' filter set to false on a page where they want to include something like a site-wide posts widget, can just reset the filter to true.

For reference, here is the corresponding BuddyPress ticket:
​http://trac.buddypress.org/ticket/967

filter used, wp() circumvented, 'wp' hook left intact, commented

I don't think we should be calling the wp hook from two different places like that. I think I prefer this patch. Does this work for you?

I'd like to have the filter pass $query_vars also so that the $query_vars could be used as a way to determine if you should return false or not. I don't have a current use for this, but I see a possibility of it being helpful.

Replying to sivel:

I'd like to have the filter pass $query_vars also so that the $query_vars could be used as a way to determine if you should return false or not. I don't have a current use for this, but I see a possibility of it being helpful.

+1

That sounds very sensible.

The patch as it stands now causes the admin to say there are the correct number of posts/pages/attachments but "hides" them from view in the edit lists. I'm not saying this is bad or good. Just wondering what everyone else has to say about it. Should it be up to the developer to make sure they only filter for the front end by checking if is_admin() is true? Or do we want to assume that we always want to be able to see this in the admin? Or should we add a second filter for the admin? So we would have run_wp_main_front and run_wp_main_admin or something like that.

Sorry, I should have also stated that this is the result when running the filter using a plugin or in a themes functions.php without context to what is actually being called/loaded.

Replying to sivel:

Sorry, I should have also stated that this is the result when running the filter using a plugin or in a themes functions.php without context to what is actually being called/loaded.

I think if someone does this in a theme/plugin without checking the context then they deserve to be eaten by those dragons :-)

Adds $query_vars to the filter so that you can use that information to determine how you should return.

Adds $query_vars to the filter so that you can use that information to determine how you should return. (fixed grammatical error)

I know that BuddyPress hooks to 'wp' in several places. Not doing the 'wp' action simply because WordPress has not run its initial post-grabbing queries, will also break any other plugins that rely on that action hook.
Which is less desirable:
1) "[not] calling the wp hook from two different places?"
2) forcing those who choose to return false to the 'run_wp_main' filter to do_action_ref_array( 'wp', array( (object) array() ) ) (likely in whatever function they use to set the 'run_wp_main' filter to false)?

I don't know what BuddyPress uses the wp hook for but I think the following is what we should achieve.

• We are trying to stop something running so we should just stop that.
• We should not duplicate do_actions or expect plugins to run them if they use the new hook - If we do this I think we have failed.

Therefore it looks like we need to understand if wp is the hook BuddyPress should be using on these pages and we need to move the new filter into the wp.main() function or whether BuddyPress should be hooked in to something else.

See Also: #12256

robots.txt requests cause WordPress to query the database for all the homepage posts. It'd be good if there was perhaps a query var to short circuit the internal querying and instead perhaps fake a page template... Or probably better to just offer an appropriate hook.