Make WordPress Core

Opened 11 years ago

Closed 10 years ago

#21986 closed enhancement (wontfix)

Roll sticky posts into MySQL query

Reported by: martinshopland's profile martinshopland Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.4.2
Component: Query Keywords: has-patch
Focuses: Cc:


The way that WP currently queries for sticky posts is quite long winded and prone to error. Sticky posts output behaviour is erratic when using pagination or ordering. I suggest that the sticky posts feature would be better served by being rolled into the MySQL query rather than trying to reconstruct the result set after the main query has run.

I have tested the attached patch against 3.4.2 and it works as expected. The query additions are performed on every page of home, rather than just the first, so that page boundaries behave as expected and that the sticky posts don't appear on subsequent pages. ignore-sticky-posts is honoured.

Attachments (1)

sticky_posts_query.patch (5.0 KB) - added by martinshopland 11 years ago.

Download all attachments as: .zip

Change History (6)

#1 @nacin
11 years ago

I believe the fact that sticky posts don't affect the number of posts per a page is deliberate. Everything else, not sure.

Performing multiple queries is often going to be faster than performing one super-loaded query. It's also easier to cache.

In trunk, some of this code has been changed, for the better:

#2 @martinshopland
11 years ago

Yes, sticky posts should not affect the number of posts per page but I also don't believe you should be limited to one page of sticky posts or that those posts should appear again on subsequent pages or that you shouldn't be able to control the order of sticky posts.

I may have to do some benchmark testing, I'll be surprised if the way it's done now is more efficient.

The code in trunk is a little more concise, arguably slightly less efficient, but the behaviour is the same.

#3 @martinshopland
11 years ago

Oh, I see what you're saying. On page 1 of home you get posts_per_page posts plus the number of sticky posts. I would guess this is so that the sticky posts are dealt with on the first page, that the whole thing doesn't need to be run again for subsequent pages and that the proper page boundaries are preserved, but I suppose it could've been designed this way. I don't mean to be disparaging towards WP or anything that you guys have done, I use it every day and I like it. Most of my installations are not blogs, I mostly use WP as a CMS system, I'm always bending it to new purposes, it was on one of those blog style installations, however, where this sticky posts issue began to niggle, the subsequent pages are loaded in using AJAX and it looks really weird having posts appearing again and not being able to control which of your sticky posts actually appears at the top.

Last edited 11 years ago by martinshopland (previous) (diff)

#4 @helgatheviking
10 years ago

Why shouldn't sticky posts effect the number of posts_per_page? If you want strictly 10 posts per page, but you have a sticky post, then you end up with 11 posts. That doesn't make sense to me.

#5 @wonderboymusic
10 years ago

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

#11950 should be the go-to for controlling stickies, as it has the most recent action. -1 for rolling up stickies into the main SQL statement. Stickies are grabbed using get_posts() which is highly-cacheable

Note: See TracTickets for help on using tickets.