Pro 4.x Looper Provider bug - Include sticky posts ignores post count setting

[connexxions]

Hi there,

I think this is a bug in the Query Builder Looper Provider.

When using the “Include sticky posts” setting, but also limiting the number of posts I want returned, the sticky posts seem to be added on after the count is done. For example, I just want to return 1 post, and if there is a sticky post then just return that one. But instead I am receiving the sticky post AND the next most recent post.

This is the Looper Provider setup:

And this is a test setup consuming the data and demonstrating the issue:

The second post should not be showing up as the post Count was set to 1.

Of course, I can set the consumer to only consume One, but it strikes me that doing that is potentially just a temporary plaster on the issue and so I thought I’d share it here!

Cheers

[alexander]

Hi @arthurodb,

Thanks for reaching out about this, and I really appreciate all the detail explaining what’s going on here.

I know it’s a bit strange, but that’s actually how WordPress queries are handled internally. The Query builder is a light wrapper around the arguments of the get_posts WordPress function, and by design if you enable sticky posts they are not considered part of the count when it comes to fetching posts.

WordPress starts by getting the number of posts you want (defaults to posts per page setting)then they prepend all the sticky posts in front which means if your count is 10 and your site has 2 sticky posts there will be 12 total posts to work with. I don’t know exactly why that decision was made, but I think it has something to do with making sure you get the same posts consistently when using pagination.

All that being said, our options would be to 1. Account for the offset, but that would be a breaking change for existing sites or 2. Add a new option to allowing users to opt into adjusting the offset - the problem here is this is already a fairly complicated set of controls and the more little things we add just increase the perceived complexity for new users.

My inclination at this point is to just leave this quirk alone and let WordPress do what it’s doing under the hood. You would get the same result if you were trying to code a theme and use the functions directly and custom code would be needed to account for the offset.

There are other options, but we’re veering off into custom development which gets outside the scope of support. So I can’t build this out for you fully, but I can rough out what I’d suggest to get started:

1. Set your Looper Provider to Custom
2. Set the hook to sticky_post_query
3. In the Params JSON editor add: { "count": 5 }
4. Use custom code like this:

add_filter( 'cs_looper_custom_sticky_post_query', function( $result, $args ) {

  $sticky = get_option( 'sticky_posts' );
  $stick_offset = is_array( $sticky ) ? count( $sticky ) : 0;
  $count = isset( $args['count'] ) ? $args['count'] : get_option( 'posts_per_page' );
  unset($args['count');

  return get_posts(array_merge( $args, [
    'numberposts' => $count - $stick_offset
  ] ) );
  
}, 10, 2 );

I’ve not actually tested out this code, but based on our previous conversations I’m sure you’ve got the development chops to get something working. Feel free to ask any questions if I was unclear on anything, or if you additional clarification.

[connexxions]

Hi @alexander,

I was totally unaware of that handling of sticky posts by WordPress! I think this may be one of the first times using it for a site in this particular way, pulling out just the sticky post to a separate section, so I hadn’t come across it before.

Thanks for your explanation and I totally understand your reasoning for leaving it as what WordPress core is generating. It makes sense to stick with their core behaviour for the most part.

Thanks also for providing the sketch of code for a Custom Looper Provider. I have been digging into the possibilities of the Custom providers elsewhere and have been absolutely loving the flexibility and power that it gives! Really appreciate all the work that you and all at theme.co do to continue improving the power of Pro!

[alexander]

You’re most welcome!

I was totally unaware of that handling of sticky posts by WordPress!

So was I until recently!

When we were building out proof of concept material I was scratching my head for a little while wondering why I had too many posts. I don’t see people actually using sticky posts all that often, so there’s been less opportunity to run into it.