hierarchical-document-list
hierarchical-document-list copied to clipboard
Installation Issue
I'm a total newb at Sanity (and coming from C#, not super-familiar with typescript either) so this is more than likely my ignorance, but here goes
When I follow the installation instructions for this plugin, the first issue I hit is that deskTool is deprecated. Reading the docs I can see that deskTool has been superseded by structureTool so I replaced deskTool with structureTool in the example and no errors so all good I thought
I am using schemaTypes (I followed the "Day One with Sanity" course) but when I try and add hierarchyTree to the schema types element, I can't figure out the syntax. I ended up adding it like this: types: schemaTypes, hierarchyTree - it gave me an error when defining this as an array
When I look at Sanity Studio Structure, I have a node for Main Table of Contents, but when I click on it I get:
Invalid configuration The documentType passed to createDeskHiearchy isn't live editable. To continue using this plugin, add liveEdit: true to your custom schema type or unset documentType in your hierarchy configuration.
This is my sanity.config.ts file:
import { defineConfig } from 'sanity'
import { structureTool } from 'sanity/structure'
import { visionTool } from '@sanity/vision'
import { schemaTypes } from './schemaTypes'
import { media } from 'sanity-plugin-media'
import { deskTool } from 'sanity/desk'
import { createDeskHierarchy, hierarchicalDocumentList, hierarchyTree } from '@sanity/hierarchical-document-list'
export default defineConfig({
name: 'default',
title: 'xxxxxxx',
projectId: 'xxxxxxxxx',
dataset: 'production',
plugins: [visionTool(), media(), hierarchicalDocumentList(), structureTool({
// // NOTE: I'n V3 you MUST pass S and Context along to createDeskHierarchy as props
structure: (S, context) => S.list()
.title('Content')
.items([
...S.documentTypeListItems(), // or whatever other structure you have
createDeskHierarchy({
//prop drill S and context:
S,
context,
//configure plugin
title: 'Main table of contents',
// The hierarchy will be stored in this document ID 👇
documentId: 'main-table-of-contents',
// Document types editors should be able to include in the hierarchy
referenceTo: ['composer'],
// ❓ Optional: provide filters and/or parameters for narrowing which documents can be added
/* referenceOptions: {
filter: 'status in $acceptedStatuses',
filterParams: {
acceptedStatuses: ['published', 'approved']
}
}, */
// ❓ Optional: limit the depth of your hierarachies
//maxDepth: 3,
// ❓ Optional: subarray of referenceTo, when it should not be possible to create new types from all referenceTo types
//creatableTypes: ['composer']
})
])
}),
hierarchicalDocumentList()
],
schema: {
types: schemaTypes, hierarchyTree
},
})
Hi @tonyl-personal, I had a similar issue but resolved it by "spreading" my existing schema, since hierarchyTree is a document schema object, like this: types: [...schemas, hierarchyTree], which makes types an array only containing document type objects. I also found that referenceOptions in createDeskHierarchy was causing issues on my version so I removed it, by default it only shows published documents which fits my needs.
Stuck in the same place.
How can you make the documentType created by createHierarchicalSchemas liveEdit-able?
Anyone done any progress with this? Obviously it is supposed to work, since developers are working on it. Could any of them jump in to improve the docs for people to be able to use the plugin?
@doublejosh @westis I thought this was a case of the document not being created, but after switching datasets I realised that I hadn't configured it for both datasets.
Check that for all datasets you have the hierarchicalDocumentList() in your plugin configuration, and also hierarchyTree in the list of schema types.
It may also be worth deleting any documents of type 'hierarchy.tree' to give yourself a clean start.
Excited to try this plugin again!
Is it true that documents within the hierarchy must be liveEdit-able?
For example: if placing articles within a menu structure... those articles can't have normal publish versioning?