@mwidmann ah, you know what, I think we set ignore_sticky_posts to true by default as part of the model-layer branch, before you had your PR in.

So now we have it here: https://github.com/wp-graphql/wp-graphql/blob/develop/src/Data/Connection/PostObjectConnectionResolver.php#L117

And here: https://github.com/wp-graphql/wp-graphql/blob/develop/src/Data/Connection/PostObjectConnectionResolver.php#L152-L158

The latter is from your PR. . .the former is from the model-layer branch, prior to your PR.

I think we might want to actually remove the former and stick with your PR.

So that sticky posts will be respected for the first query, but not the subsequent 🤔

If you remove it from here does it bring back the behavior you expect?

@mwidmann so, as far as how GraphQL loads data, it actually does a very similar thing to WP_Query.

When you execute a WP_Query, it makes one initial query for just the IDs, then it looks to see if those IDs are in the cache or not. If they are cached, it pulls the object from the cache. If they're not, it does another SQL request to get the full object.

WPGraphQL is doing the same thing, just spread across multiple WP_Queries for more improved performance.

Any WP_Query argument should still work the same as it would normally, including ingnore_sticky_posts

The issue, in this case, is just that we had added it as a default arg on the feature branch before you added your version (which is more elegant than just turning off sticky posts altogether 😂)

I think if you can confirm removing the instance that sets it to true restores the behaviour you would expect, you can open a PR for that and we can get it merged.

@jasonbahl sadly this doesn't solve the issue as it lies deeper than this. The querying of the posts to fetch has been changed, so that you first only fetch the ids of the posts that would be fetched for the query and then, based on this list, you fetch the actual post objects for the keys you gathered.

When you pass in the fields => ids query_param when fetching the posts, wp-query handles this case much sooner and returns way earlier than where the sticky posts are added. I linked the lines in 5.1.1 source code of wp-query.

When you then load the list of items based on the ids you idenfied in the first query the original context is missing, so removing ignore_sticky_posts in PostObjectsLoader wouldn't solve this issue either.

The issue has been introduced in de3dd63.

I'm too unfamiliar with the new DataLayer's functionality to figure out what might be a good solution to it, sadly.

We're thinking maybe adding a field isSticky for some contexts (easy), and being able to sort by sticky in others (harder). More discussion is needed though for sure

There's an open PR attached here, but there are some nuanced details to this. Needs deeper discussion.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically closed because it has not had recent activity. If you believe this issue is still valid, please open a new issue and mark this as a related issue.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

From today's Office Hours:

Assuming #863 can't be dusted off to work well enough with cursor pagination, we could use an isSticky where arg and relegate this handling to the frontend. E.g.

query StickyPosts( $first: Int, $after: ID  ) {
  stickyPosts: posts( first: $first, after: $after, where: { isSticky:true } ) {
    pageInfo {
      ...PageInfoFrag
    }
    nodes {
      ...PostFrag
    }
  }
}

query Posts( $first: Int, $after: ID ) {
  posts( first: $first, after: $after, where: { isSticky: false } ) {
    pageInfo {
      ...PageInfoFrag
    }
    nodes {
     ... postFrag
   }
 }

and then paginate via the frontend, first through StickyPosts until pageInfo.hasNextPage is false, and then through Posts.