Content Releases Configuration

Sometimes you want to omit certain fields or add certain information when duplicating documents. It's now possible to programmatically modify the created document when duplicating a document. This can be achieved by setting the mapDocument option when executing the duplicate document operation, or by passing a prop of the same name (mapDocument) to the system duplicate document action component.

mapDocument is a function that receives the duplicated document as its only parameter, and should return a new object representing the duplicated document that will be created.

Here's an example demonstrating how a custom duplicate document action could be used to omit a field (slug) from the duplicated document:

// sanity.config.js

import {defineConfig} from 'sanity'
import {structureTool} from 'sanity/structure'
import {schemaTypes} from './schemas'
import {createCustomDuplicateAction} from './actions'

export default defineConfig({
  name: 'default',
  projectId: '<project-id>',
  dataset: 'production',

  plugins: [
    structureTool(),
  ],
  document: {
    actions: (actions) => actions.map((actionItem) => 
      actionItem.action === 'duplicate' 
      ? createCustomDuplicateAction(actionItem) 
      : actionItem
    ),
  },
  schema: {
    types: schemaTypes,
  },
})

import {type DuplicateDocumentActionComponent} from 'sanity'

export function createCustomDuplicateAction(
  originalAction: DuplicateDocumentActionComponent,
): DuplicateDocumentActionComponent {
  return function CustomDuplicateAction(props) {
    return originalAction({
      ...props,
      mapDocument: ({slug, ...document}) => document,
    })
  }
}

Sometimes you want to work iteratively on a Content Release and stage changes to the same set of documents. You can now duplicate a release from the overview page by clicking on the '...' button and select 'Duplicate release'.

This will create a new release copying the original release's title, description, release type and publish date. New versions of all documents in the original release will also be created.

Duplicating a locked and scheduled release will create a new active release, which can be rescheduled.

• Fixes issue where a document location resolver state was incorrectly duplicated across multiple Presentation instances.
• Fix for an issue where documents marked as to be unpublished in a release show an empty document form title preview. Now the document form will show the current title of that document.
• Fixes an issue in where users with no dataset read permissions were seeing an error toast on load.
• Fixes an issue in where the studio dev command will get blocked if using auto update in a non interactive environment.

Say goodbye to late-night content deployments and "DO NOT PUBLISH" in titles. Content Releases introduces a better way to plan, preview, and coordinate content changes – working the way your code deployments do. Available for Growth plans and above. Read the launch post to learn how teams use it to transform their content workflows.

npm i sanity@latest @sanity/assist@latest @sanity/vision@latest

Content Releases is enabled by default in this version of Studio and beyond. You can disable it by adding the following to your studio configuration:

// sanity.config.ts|js
// ...
export default defineConfig({
  // ...
  releases: {
    enabled: false
  }
})

To ensure compatibility, we suggest upgrading all official Sanity plugins and tools, such as Presentation and AI Assist, to the latest versions.

This release pairs with the release of API version 2025-02-19. The two involve some breaking changes that affect highly customized studios, and potentially third party libraries. Here are areas to look out for when evaluating your codebase.

• API version 2025-02-19 includes changes to the perspective system. Starting with this version, the majority of APIs and official clients now use published as the default perspective.
• The raw perspective, previously the default, now returns published, draft, and version documents.
• If your codebase relies on checking paths for drafts.**, this could cause unexpected behaviors.
  • Content Releases and API version 2025-02-19 and above introduce the versions.** ID prefix. We suggest relying on perspectives instead of path matching whenever possible.
  • We've introduced a utility library, @sanity/id-utils, to help handle multiple ID formats.
  • You can opt in or out of receiving versions.** documents as needed by adjusting your API version, either in the client or within Structure Builder's DocumentList.
• If using client.listen, you'll need to forward includeAllVersions=true in order to listen for version and draft document changes.
• Plugin authors that wish to support Content Releases will need to use 2025-02-19 or later as the API version. See the plugin migration guide for additional details.
• Ensure any custom implementations of the client in Studio that make use of useClient set the correct apiVersion and perspective (2025-02-19 and raw respectively) as needed to support releases and version documents.
• Support for versions in webhooks is coming in the future, but not yet supported. Webhooks can query release state, but not the version documents themselves.

Many APIs that rely on perspective have been updated. See the API v2025-02-19 changelog for additional details and suggestions.

• Some success toast messages have been removed to streamline the Studio UI. These removals have been made where there is a reasonable expectation the operation will succeed immediately and reliably (for example, when copying a value to the clipboard). Error toast messages remain as they were before.
• Adds the v2025-02-19 API version to Vision's dropdown
• It's now possible to drag and drop inline objects in the Portable Text Input
• Improved document header for documents with many versions