How to remove documents from "Create New Document" menu in Sanity?

7 replies
Last updated: Jul 15, 2022
Hey everyone! I have used Sanity for a while, but I just noticed (after all these years) that the
Create New Document
icon on the top bar allows a user to create documents that I may not want created. For instance I have document types such as the
homePage
and
siteSettings
that I do not want to be created again... This hasnt been an issue for me or my clients, because I always tell them to create documents within the editor. I am wondering if its possible to remove the
Create New Document
icon or perhaps omit certain documents from that?
AI Update

Perfect! This is exactly what you need. You can control which document types appear in the global "Create New Document" menu using the newDocumentOptions configuration in your Studio config.

Here's how to hide specific document types like homePage and siteSettings from that menu. In your sanity.config.ts (or .js) file, add this configuration:

import {defineConfig} from 'sanity'

export default defineConfig({
  // ... your other config
  document: {
    newDocumentOptions: (prev, {creationContext}) => {
      // Filter out singleton document types
      const singletonTypes = ['homePage', 'siteSettings']
      
      return prev.filter(
        (template) => !singletonTypes.includes(template.templateId)
      )
    },
  },
})

This filters out your singleton documents from the global create menu while still allowing them to be accessed and edited through your Structure Builder configuration.

For a complete singleton pattern, you'll typically also want to set up your Structure Builder to show these documents with a fixed document ID. Here's a common pattern:

import {defineConfig} from 'sanity'
import {structureTool} from 'sanity/structure'

export default defineConfig({
  // ...
  plugins: [
    structureTool({
      structure: (S) =>
        S.list()
          .title('Content')
          .items([
            // Singleton documents with fixed IDs
            S.listItem()
              .title('Home Page')
              .id('homePage')
              .child(
                S.document()
                  .schemaType('homePage')
                  .documentId('homePage')
              ),
            S.listItem()
              .title('Site Settings')
              .id('siteSettings')
              .child(
                S.document()
                  .schemaType('siteSettings')
                  .documentId('siteSettings')
              ),
            // Divider
            S.divider(),
            // All other document types
            ...S.documentTypeListItems().filter(
              (item) => !['homePage', 'siteSettings'].includes(item.getId())
            ),
          ]),
    }),
  ],
  document: {
    newDocumentOptions: (prev, {creationContext}) => {
      const singletonTypes = ['homePage', 'siteSettings']
      return prev.filter(
        (template) => !singletonTypes.includes(template.templateId)
      )
    },
  },
})

The newDocumentOptions recipe shows more examples, including how to make this reactive based on the current user or creation context if you need more advanced filtering.

This approach gives you full control over what appears in that top bar menu while keeping your singleton documents accessible through the main navigation where you want them!

Show original thread
7 replies
Hi User. Yes, you can do this. One way is using actions , which are easier to implement but are experimental and will be deprecated soon (per those docs—I don’t know details on this). The second way is using initial value templates , which take a bit more to set up but this is the ā€œpreferredā€ method going forward.
Thanks for this
user A
... I may go with the actions since I can see how that works a bit better. I am a bit confused on how to implement omitting certain documents with the example provided within the initial value templates.
Though maybe I'll just figure that out as a future-proof solution
Sounds good. Sometimes a deprecation needs to be tomorrow’s problem. šŸ˜†
Lol maybe it will be deprecated in like 5-10 years? Just don't tell anyone about this issue ya know? šŸ˜
Actually
user A
I see there is an example of this on the Hydrogen Studio template...
user F
has a
constants.js
set up that feeds into
newDocumentStructure.js


https://github.com/sanity-io/sanity-shopify-studio/blob/c03de5e8d951ac737d5b0cd4a8a0b3e76b125a13/parts/newDocumentStructure.js
So I may just copy this!
Nice! Solving problems ahead of schedule.

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?