WordPress 6.8 REST API returns all sticky posts regardless of per_page setting

[se8820726]

Hi

If you install two fresh WordPress instances—one with version 6.7.2 and another with version 6.8—
and then create 10 posts in each, making 4 of them sticky,
and call this API on both:

/wp-json/wp/v2/posts?per_page=2

In version 6.7.2, it correctly returns only 2 posts.
However, in version 6.8, it returns all sticky posts and ignores the per_page parameter.

This means that if I have around 5,000 sticky posts on my site, calling this API could cause my site to crash.

I can solve this problem by using sticky=false in request query params:

/wp-json/wp/v2/posts?per_page=2&sticky=false

However, when sticky=false is not explicitly set in the request, it should not return all sticky posts—it should still respect the per_page parameter.

I think this is still a bug.

Even if per_page is not provided, it still should not return all sticky posts—there should be a default limit in place.

Others can easily crash my site just by calling this endpoint:

/wp-json/wp/v2/posts

[abcd95]

Hi @se8820726, and thanks for the ticket.

I've been able to reproduce the problem exactly as you described. The issue occurs because in 6.8, when requesting posts with the per_page parameter but without specifying the sticky parameter, the system prepends all sticky posts to the result set without respecting the pagination limit.

I've created a patch that ensures the per_page parameter is properly respected in all cases. The solution adds a check to ignore sticky post behavior when pagination is requested, but no explicit sticky preference is specified.

Let me know if the patch tests well for you.

[se8820726]

Replying to abcd95:

Hi @se8820726, and thanks for the ticket.

I've been able to reproduce the problem exactly as you described. The issue occurs because in 6.8, when requesting posts with the per_page parameter but without specifying the sticky parameter, the system prepends all sticky posts to the result set without respecting the pagination limit.

I've created a patch that ensures the per_page parameter is properly respected in all cases. The solution adds a check to ignore sticky post behavior when pagination is requested, but no explicit sticky preference is specified.

Let me know if the patch tests well for you.

in your patch with this request is there a default limit ?
/wp-json/wp/v2/posts?sticky=true

this request should not return all sticky posts.

[abcd95]

Replying to se8820726:

/wp-json/wp/v2/posts?sticky=true

This will respect the pagination parameter if set, but will not return all the sticky posts. If no pagination is set, then it defaults to min(10, total sticky posts).

[se8820726]

I tested. it is ok. thanks

[wildworks]

I identified that this issue occurred as a result of [59801]. I think this issue should be fixed in 6.8 minor release.

[SirLouen]

Test Report

Description

❌ This report can't validate the indicated patch works completely as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8727.diff

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 135.0.0.0
• OS: Windows 10/11
• Theme: Twenty Fifteen 4.0
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ The reported issue is solved with the patch
2. ❌ There is a more general issue that this patch is not handling, see additional notes for more info

Additional Notes

• The problem is correlated with this ticket #63307
• Sticky posts have gone wild in 6.8 after #59801 as @wildworks suggested.
• I've added some unit tests here: ​https://github.com/WordPress/wordpress-develop/pull/8731
• The solution, introduced in this patch, only sorts this very specific case. But the per_page limit is actually working fine, the only problem is that the ignore_sticky_posts is adding sticky posts on top of any REST API query for posts, this is why it's surpassing the limit.
• Conclusion: If the general issue is solved, all the tickets regarding this topic will be solved.

Marking this as duplicate, follow patch release in #63307