REST API: Returns incorrect post when querying by slug if sticky posts exist

[wpmudevsupport13]

It was mentioned here by one of the reddit users ​https://www.reddit.com/r/Wordpress/comments/1k106qz/wordpress_68_bug_with_rest_api_posts_pulling/
And it seems the issue can be easily replicated:

1. Create new post: /test-post
2. Open this in a browser: ​https://example.com/wp-json/wp/v2/posts?slug=test-post

At this point, multiple values will get the post slug and ID.

3. Create another new post: /second-test and make that post sticky

Visit again ​https://example.com/wp-json/wp/v2/posts?slug=test-post, and this time, many values will get that /second-test slug and ID, where it should still show /test-post.

If you create multiple sticky posts, the ​https://example.com/wp-json/wp/v2/posts?slug=test-post will get the slug and ID from the sticky post that has the newest published date.

[nikunj8866]

I've verified this issue and can confirm it is reproducible in WordPress 6.8. When querying /wp-json/wp/v2/posts?slug=test-post, the response includes data from newer sticky posts, which should not happen.

[nikunj8866]

I tested the same steps on WordPress 6.7.2, and the issue does not occur there. The correct post is returned when querying by slug, even with sticky posts present.

[nikunj8866]

I've identified that the issue in WordPress 6.8 appears to have been introduced in the following commit:

​https://github.com/WordPress/wordpress-develop/commit/f71d5f06b2e3327c40bfb6102fec5d37ee87faef#diff-48cfdad3b747164ac4b6857186399519dabf913026235575b00ebe5b0dc7169bR250-R347

…osts exist issue

Trac ticket: https://core.trac.wordpress.org/ticket/63307

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

## Unlinked Accounts
The following contributors have not linked their GitHub and WordPress.org accounts: @nhatkar@….

Contributors, please ​read how to link your accounts to ensure your work is properly credited in WordPress releases.

To understand the WordPress project's expectations around crediting contributors, please ​review the Contributor Attribution page in the Core Handbook.

Please use @nikunj8866 WordPress profile.

[SirLouen]

Patch Test Report

Description

❌ This report can't fully validate that the tested patch works as expected.

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

Environment

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

Actual Results

1. 🟠 The issue is resolved with the patch but new issues arise

Additional Notes

The intention of that parameter is to keep sticky on top by default in the main REST json result
​http://localhost:8889/wp-json/wp/v2/posts
By changing this param, you solve this issue, but now the sticky post won't appear on top of the full post list, which is the intention of such.

[nikunj8866]

@SirLouen Thank you for the detailed test report and for highlighting the side effect introduced by the patch.

It does change the default behavior of sticky posts being prioritized at the top of the main REST response (/wp-json/wp/v2/posts), which was an intentional feature.

So for users who are specifically querying posts by slug and need consistent results regardless of sticky status, the recommended approach is to use the ignore_sticky=true parameter. For example: /wp-json/wp/v2/posts?slug=test-post&ignore_sticky=true

[SirLouen]

Replying to nikunj8866:

It does change the default behavior of sticky posts being prioritized at the top of the main REST response (/wp-json/wp/v2/posts), which was an intentional feature.

In my test it was the other way around. With the patch, the sticky posts disappear from top positions in /posts

[nikunj8866]

@SirLouen When someone uses specific filters like slug, author, status, include, etc., they usually expect to get only the exact matching posts. Right now, if there's a sticky post with a newer date, it can wrongly appear instead of the correct post—for example, when using ?slug=test-post.

We suggest that when these kinds of filters are used, API should automatically ignore sticky posts (unless the user specifically wants them). This would help make the results more accurate and avoid confusion for developers using the API.

Let us know what you think about this. We’re happy to help with a patch or more suggestions if needed.

### Summary
This PR updates the WordPress REST API to ignore sticky posts when specific filters are used (like slug, include, author, etc.), unless explicitly overridden.

By default, /wp-json/wp/v2/posts continues to return all posts, including sticky ones, as expected.

### Trac Ticket
https://core.trac.wordpress.org/ticket/63307

### Testing

1. Create a sticky post (sticky-post) and a non-sticky post (test-post).
2. Request: /wp-json/wp/v2/posts?slug=test-post Only test-post should be returned.
3. Request: /wp-json/wp/v2/posts?slug=test-post&ignore_sticky=false Still only test-post is returned.
4. Request: /wp-json/wp/v2/posts All posts are returned, sticky posts appear first (default behavior).

Let me know if you'd like changes or additional tests.

[ankitmaru]

Hello,
PR submitted: ​https://github.com/WordPress/wordpress-develop/pull/8730

Fixes an issue where sticky posts could appear in REST API results even when using specific filters like slug.
Adds ignore_sticky support and defaults to ignoring sticky posts when exact filters are used.

Let me know if any changes are needed.

[SirLouen]

Replying to nikunj8866:

Let us know what you think about this. We’re happy to help with a patch or more suggestions if needed.

As I commented in my Test Report, you are not solving the issue, you are just hindering it.

If you do this, for example, with your patch:

​http://localhost:8889/wp-json/wp/v2/posts?slug=test-post&ignore_sticky=false

It will return the post "test-post" and all the sticky posts. This is not the expected behavior, because you are not addressing the real problem that is being caused.

Sticky posts are meant to be shown just on listing queries, not on individual records queries.
And sticky posts should be displayed by default on listings, unless explicitly specified with the given filter, not the opposite.

@wpankit this is a little refactored verrsion including PHPCS standards:

// Automatically ignore sticky posts when specific filters are used, unless explicitly requested.
$specific_filters = array( 'slug', 'author', 'author_exclude', 'include', 'exclude', 'parent', 'parent_exclude' );

foreach ( $specific_filters as $filter ) {
        if ( isset( $request[ $filter ] ) && ! empty( $request[ $filter ] ) ) {
                if ( ! ( isset( $request['ignore_sticky'] ) && $request['ignore_sticky'] ) ) {
                        $args['ignore_sticky_posts'] = true;
                }
                break;
        }
}

Although, I'm not convinced it needs a little more work, I will provide a test report in the Ticket

[SirLouen]

Patch Test Report

Description

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

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8730.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

Bug Reproduction Steps

• Using URL like:

1. ✅ Single post: ​https://example.com/wp-json/wp/v2/posts?slug=test-post
2. ✅ All posts: ​https://example.com/wp-json/wp/v2/posts
3. ❌ Template listings (i.e., Author): ​https://example.com/wp-json/wp/v2/posts?author=1 => If the author has an sticky post, it should appear in first position

Actual Results

1. ✅ For the condition in the reporting post, this patch solves
2. ❌ Some other scenarios are not solved.

Additional Notes

I think that the only affecting filter is slug. The other filters should return the "stuck" post if there is a sticky post among the filtered results. Examples: If there are 10 posts, 2 of which are sticky

1. If the user is using "exclude" with one of the sticky posts, it should return, the other sticky post on top, and the other non-sticky posts in the bottom
2. If the user is using "include" with one sticky post and one non-sticky post, it should return, first the sticky one and second the non-sticky one, regardless of the ordering selected.

Conclusion for the correct behavior:
For anything listing ⇒ If the listing has sticky posts the should go first
For anything single ⇒ Just show the single post.

I'm going to be adding some unit tests so whoever builds the patch, takes all this into consideration.

I'm adding some unit tests for whoever is willing to this patch they most be compliant

Add these tests and run: npm run test:php -- --group 63307

[SirLouen]

Removing this auto-keyword

[SirLouen]

#63339 was marked as a duplicate.

[SirLouen]

@audrasjb (or any other committer that reads this)
Can you add priority Milestone 6.8.1 to this regression?
It has been reported in other posts like #63339 as a regression of [59801]

This is to:
1) prepare a revert as a potential option
2) Demonstrate that [59801] is the root cause.

Includes unit tests from #8731
Reverts [59801].

Core Trac: https://core.trac.wordpress.org/ticket/63307

[jorbin]

Confirmed using @SirLouen's tests that this is caused by [59801] so cc @peterwilsoncc, @audrasjb, @danielbachhuber, @joemcgill, @johnbillion, @jorbin (it's a me!), @mamaduka, @rmccue who all worked on that along with @spacedmonkey and @TimothyBlynJacobs who worked on ​the related GB PR

It should absolutely be fixed in 6.8.1, even if that means reverting [59801] which I would like to avoid if possible.

RE: The two proposed solutions -

​https://github.com/WordPress/wordpress-develop/pull/8713 - I don't think this is feasible since it will cause sticky posts to need to be explictly requested which is a change in behavior (it's a bit concerning that no tests failed though)

​https://github.com/WordPress/wordpress-develop/pull/8730 - Something along these lines makes sense to me, though I would like for each of them to have some sort of test. I also think that this should use the WP_Query params, not the rest API version.

[SirLouen]

Replying to jorbin:

Confirmed using @SirLouen's tests that this is caused by [59801] so cc @peterwilsoncc, @audrasjb, @danielbachhuber, @joemcgill, @johnbillion, @jorbin (it's a me!), @mamaduka, @rmccue who all worked on that along with @spacedmonkey and @TimothyBlynJacobs who worked on ​the related GB PR

It should absolutely be fixed in 6.8.1, even if that means reverting [59801] which I would like to avoid if possible.

RE: The two proposed solutions -

​https://github.com/WordPress/wordpress-develop/pull/8713 - I don't think this is feasible since it will cause sticky posts to need to be explictly requested which is a change in behavior (it's a bit concerning that no tests failed though)

​https://github.com/WordPress/wordpress-develop/pull/8730 - Something along these lines makes sense to me, though I would like for each of them to have some sort of test. I also think that this should use the WP_Query params, not the rest API version.

I would need to recheck but from what I remember neither of these two solutions worked with my test (and the main reason of why I did such test, to help the guys to build the right fix)

[karthikeya01]

​https://github.com/WordPress/wordpress-develop/pull/8713 - I don't think this is feasible since it will cause sticky posts to need to be explictly requested which is a change in behavior (it's a bit concerning that no tests failed though)

I want to add that until 6.7.2 the REST API doesn't include sticky posts on top. It used ignore_sticky_posts=1 for all get_items requests.

Introducing sticky posts also causes issues in pagination mentioned in the ticket https://core.trac.wordpress.org/ticket/63339

[Mamaduka]

Thanks for the ping, @jorbin!

If I'm not mistaken, the actual behavior is coming from WP_Query. It's an old and odd behavior that we have to maintain for backward compatibility. These "gotchas" are also mentioned in the documentation.

Now that we have fixed the sticky post display for the REST API, it also inherits the same query behavior.

The resolution should honor the original REST API behavior for posts collection, while maintaining support for sticky posts. I've included a similar case for the post__in filter, but unfortunately, other cases slipped my mind. See: ​https://github.com/Mamaduka/wordpress-develop/blob/f01ff83ac372867253e4e757c5843add4ef83bd9/src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php#L341-L347.

Regarding #63339. This is expected behavior; unless ignored, the sticky posts are prepended to the first page results, ignoring the per_page parameter. It was a bug stopping the Query block from working correctly in the editors.

[jorbin]

Thanks @Mamaduka!

I think the challenge is that the wp/v2/posts endpoint has now also been around for a long time with it's own "old and odd behavior" that we need to be careful with.

I think the best path is that in 6.8.1, keep the ignore_sticky_posts param that was added, but change the default in the rest API to true which will restore the behavior that the endpoint had from 4.7 -> 6.7. The Query Block can be modified to call the endpoint with ignore_sticky_posts set to false. We can then look at adding a new endpoint (wp/v3/posts? wp/v2/wp_query?) in 6.9 that more closely resembles WP_Query. This would honor the original REST API behavior for posts collection, while maintaining support for sticky posts.

This builds off the work in #8713 and #8731.

Core Trac: https://core.trac.wordpress.org/ticket/63307

[spacedmonkey]

Replying to jorbin:

Thanks @Mamaduka!

I think the challenge is that the wp/v2/posts endpoint has now also been around for a long time with it's own "old and odd behavior" that we need to be careful with.

I think the best path is that in 6.8.1, keep the ignore_sticky_posts param that was added, but change the default in the rest API to true which will restore the behavior that the endpoint had from 4.7 -> 6.7. The Query Block can be modified to call the endpoint with ignore_sticky_posts set to false. We can then look at adding a new endpoint (wp/v3/posts? wp/v2/wp_query?) in 6.9 that more closely resembles WP_Query. This would honor the original REST API behavior for posts collection, while maintaining support for sticky posts.

+1 to this.

[SirLouen]

Replying to jorbin:

Thanks @Mamaduka!

I think the challenge is that the wp/v2/posts endpoint has now also been around for a long time with it's own "old and odd behavior" that we need to be careful with.

I think the best path is that in 6.8.1, keep the ignore_sticky_posts param that was added, but change the default in the rest API to true which will restore the behavior that the endpoint had from 4.7 -> 6.7. The Query Block can be modified to call the endpoint with ignore_sticky_posts set to false. We can then look at adding a new endpoint (wp/v3/posts? wp/v2/wp_query?) in 6.9 that more closely resembles WP_Query. This would honor the original REST API behavior for posts collection, while maintaining support for sticky posts.

I don't think this is a good idea entirely: [59801] should be reverted, as It's still buggy and needs more development. I've been looking into the code to find a quick fix, but it's not going to be as quick as I thought.

The solution of setting the default ignore_sticky to true keeps the added functionality troubles provided by [59801] alive.

Basically, if you change the URL param behavior, all sticky posts will return (regardless of whether they match the query or not). We could argue that it's weird to add "ignore_sticky=false" to the slug param, but for any other param it will also break the results as it does with slug and it's not that weird to use this. The sole scenario where "ignore_sticky" makes sense (and to which it seemed to be tested), was against the regular no-parameters query. Probably not defaulting ignore_sticky and working from there could be the solution code-wise. But many extra tweaks have to be made to avoid delivering a half-cooked buggy solution.

So basically, my argument is that the "ignore_sticky" is partially broken, and it should be reverted for now.

[SirLouen]

After bumping my head with the wall to death yesterday for a good while, suddenly, a thought came to my mind: How WP_Query is actually handling ignore_sticky_posts?

And I got to this conclusion: #63360

The big problem here is related with WP_Query itself when using the __in query args (which happen to be the main query args that the REST API is using). For example, the name query arg works great, but the post_name__in generates this problem.

Maybe I'm wrong at some point, but reverting [59801] feels definitely the best option and for now, eliminate the use of stickiness, to have time for 6.8.2 not only looking into this, but looking into WP_Query in general, over ignore_sticky_posts behavior feels required.

[jorbin]

Unless you can demonstrate a way that the behavior of the rest endpoint and WP_Query are returning different results besides the fact that there are different defaults for sticky posts, it is working as expected. I've pushed up a few test changes that show they are working the same.

[SirLouen]

Replying to jorbin:

Unless you can demonstrate a way that the behavior of the rest endpoint and WP_Query are returning different results besides the fact that there are different defaults for sticky posts, it is working as expected. I've pushed up a few test changes that show they are working the same.

If you go to #63360 you can see a plugin I've uploaded, that clearly demonstrates this. I've separated into a different ticket, because the real issue is WP_Query not this. Current unit tests are incomplete. Before adding new unit tests that contemplate this, I have uploaded that plugin for first-line testing.

But still, I left this ticket because you need to do something before 6.8.1 RC1 and as I say, the safest bet is a regression here.

[jorbin]

In 60197:

REST API: Change posts endpoint to ignore_sticky=true by default

This restores the 6.7 and below behavior for the posts endpoint which did not include sticky posts by default.

Follow-up to [59801].

Props nikunj8866, SirLouen, ankitmaru, wildworks, karthikeya01, Mamaduka, spacedmonkey, jorbin.
Fixes #63307. See #35907.

[desrosj]

[60197] looks good for backport.

[jorbin]

In 60200:

REST API: Change posts endpoint to ignore_sticky=true by default

This restores the 6.7 and below behavior for the posts endpoint which did not include sticky posts by default.

Follow-up to [59801].

Reviewed by desrosj.
Merges [60197] to the 6.8 branch.

Props nikunj8866, SirLouen, ankitmaru, wildworks, karthikeya01, Mamaduka, spacedmonkey, jorbin.
Fixes #63307. See #35907.