Orderable Document List plugin order not reflected in front-end query results

12 replies
Last updated: Jan 28, 2026
This is an open question since it's Official plugin but, as a plugin, maybe not considered for Support ( I am still on a free plan as well )
I worked up the Orderable Document List and it works amazingly well, truly, in the Studio itself, and even in queries -- but when my documents change order, that change isn't reflected in front page code. At first I thought, maybe caching? But

• the array inside the document (reordering lists of references) updates instantly, and
• I can confirm no caching is set in my Client or the hosting service for the front end.
I am wondering what I should be looking for where even GROQ thinks it's fine but the returned query results aren't. The array comes to me not reflecting the change, and since it's a unique order of their choosing I can't correct for it once received.


EDIT: Thanks to Geoff I learned that I needed to include the ordering field from the schema in the list of returned projections, instead of just calling for it in the order() function. Thought I'd post an update for anyone else learning.
AI Update

Great question! You've actually discovered a common gotcha with GROQ queries and ordering fields. The solution you found with Geoff's help is exactly right, and it's worth explaining why this happens.

When you use the order() function in GROQ, the ordering happens on the backend, but GROQ doesn't automatically include the field you're ordering by in your projection. This is particularly important with the Orderable Document List plugin, which uses a special orderRank field to maintain custom ordering.

The Problem

The orderRank field exists in your documents and GROQ can use it for sorting, but if you don't explicitly include it in your projection, it won't be returned in the results. This can cause issues with:

  • Live queries: When the order changes, the query re-runs and returns results in the new order, but without orderRank in your projection, you might not see consistent ordering
  • Caching layers: Some systems cache based on the returned data structure, and without orderRank, they can't detect that ordering has changed

The Solution

You need to include the orderRank field (or whatever ordering field your schema uses) in your projection, not just in the order() function:

// āŒ Won't reliably reflect order changes
*[_type == "myDocument"] | order(orderRank) {
  _id,
  title,
  // orderRank not included
}

// āœ… Properly includes ordering field
*[_type == "myDocument"] | order(orderRank) {
  _id,
  title,
  orderRank  // Include this!
}

This ensures that:

  1. The ordering field is part of your returned data structure
  2. Changes to document order are reflected in the actual field values
  3. Any caching or change detection mechanisms can properly identify when order has changed

Why This Matters

As noted in the GROQ pipeline components documentation, the order component sorts array elements, but projections define which fields to return. These are separate operations, and the order component doesn't automatically modify your projection to include the ordering field.

Thanks for posting your solution as an edit—this will definitely help others who run into the same issue with the Orderable Document List plugin or any custom ordering fields!

Show original thread
12 replies

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?