标签：#sanitycms

Sanity's hotspot and crop system works well when all the pieces line up — but if your rendered image is ignoring the focal point you set in Studio, one of four things is almost certainly wrong. None of them are subtle bugs; they're all configuration mistakes that are easy to miss and easy to fix. The four causes (and their fixes) 1. fit is still set to clip instead of crop This is the most common cause. The @sanity/image-url builder defaults to fit('clip') , which scales the image to fit inside the requested dimensions without cropping anything. Hotspot data is only applied when the builder is told to crop — that is, when it cuts the image down to the requested dimensions, centering the cut on the focal point. Fix: always chain .fit('crop') when you pass .width() and .height() . // src/lib/sanity-image.ts import imageUrlBuilder from ' @sanity/image-url ' import { client } from ' ./sanity-client ' const builder = imageUrlBuilder ( client ) export function urlFor ( source : SanityImageSource ) { return builder . image ( source ) } // Usage — hotspot will only apply if fit is 'crop' const url = urlFor ( image ) . width ( 800 ) . height ( 600 ) . fit ( ' crop ' ) // <-- required for hotspot to do anything . auto ( ' format ' ) . url () Without .fit('crop') , Sanity's CDN receives no crop instruction and the hotspot coordinates are silently ignored. 2. Missing options: { hotspot: true } on the schema field If the image field in your Sanity schema is not configured with hotspot support, Studio never renders the focal point UI, and the hotspot and crop keys are never written to the document in the first place. The URL builder can't use data that isn't there. Fix: add options: { hotspot: true } to every image field where editors need focal control. // schemas/post.ts export default { name : ' post ' , type : ' document ' , fields : [ { name : ' coverImage ' , type : ' image ' , options : { hotspot : true , // <-- enables the focal point UI in Studio }, }, ], } After adding

Sanity vs Directus is a comparison that comes up more than you'd expect on technical forums in 2026, usually from teams who already have a Postgres database running and are wondering why they'd pay for a separate content lake when Directus can wrap what they have. It's a fair question. These two tools solve adjacent problems but from genuinely different starting points, and the right choice depends heavily on whether your content is primarily relational data or editorial content. What each tool actually is Sanity is a hosted content platform. Your content lives in Sanity's managed "content lake" — a document store with real-time collaboration, a CDN-backed asset pipeline, and GROQ as the query language. You define schemas in code, deploy a customisable Studio, and talk to Sanity's API from your Next.js app. You do not manage infrastructure. Directus is an open-source data platform that wraps any existing SQL database — Postgres, MySQL, SQLite, MS SQL — and exposes it through a REST API, a GraphQL endpoint, and a web-based admin UI. Schema changes happen in the admin UI (or via migrations), and your data stays in your own database. You can self-host entirely or use Directus Cloud. That distinction — hosted content lake vs database-wrapper — drives nearly every practical difference between them. Data ownership and where your content lives With Sanity, your content lives in Sanity's infrastructure. You can export it via the export API, but you are operationally dependent on Sanity's uptime and their CDN. For most product teams that's fine — Sanity has been reliable and their SLA on Growth/Enterprise tiers is solid. But if you're in a regulated industry, have strict data residency requirements, or your client contract requires them to own the database, it's a real constraint. With Directus, the database is yours from day one. You point Directus at a Postgres instance on your own infrastructure (or a managed one like Supabase, Neon, or Railway), and Directus adds the API

Sanity Embeddings semantic search in Next.js is one of those features that looks complicated from the outside but is surprisingly lean to wire up once you understand the moving parts. This post covers the current native Embeddings feature built into Sanity datasets — not the older Embeddings Index API, which Sanity is sunsetting. If you found a guide that talks about a separate embeddings-index resource you have to provision via the Management API, it is stale; skip it. What Sanity Embeddings actually is Sanity's native Embeddings feature lets you mark document types for vector indexing directly inside your dataset. Sanity handles the embedding model and the vector store; you never manage a separate service. Queries use a dedicated sanity.embeddings.query GROQ function that takes a natural-language string and returns documents ranked by semantic similarity. The feature is available on Growth and Enterprise plans as of mid-2026. The workflow has three parts: Configure which document types get indexed (dataset setting or the Embeddings pane in Sanity Studio). Run a semantic query from your Next.js route handler using the Sanity client. Render the results in a search UI component. Setting up the embeddings index in your dataset Go to Manage → your project → Embeddings (or open the Embeddings pane inside Sanity Studio if your plan surfaces it there). Create an index, give it a name (e.g. site_search ), and select which document types and fields to embed. For a blog you would typically pick post with fields title , excerpt , and body (plain text extracted from Portable Text). Sanity backfills existing documents automatically. New and updated documents are re-embedded on publish via an internal webhook — you do not configure that yourself. There is no code required for the indexing step. The index name you choose here ( site_search ) is what you will pass in the GROQ query. Querying embeddings from a Next.js route handler Create a route handler that accepts a search term,