"Payload has transformed the way our clients manage content. It's an indispensable tool for any modern agency."
Microsoft chose Payload to tell the world about AI.
parent/child content modelling
hi all. i've got a content modelling question - thanks in advance!
i'm building a site which is a knowledge-base for our design system. i'm trying to create a type of page called a Foundations page. A Foundations page has no content of its own, but will have a number of child pages displayed as tabs. the tabs will have their own urls, so e.g.
foundations/typography/introductionfoundations/typography/patterns- etc
the url for the foundations page will redirect to the first tab, i.e. foundations/typography will redirect to foundations/typography/introduction.
my question is, how to model this.
i've tried creating a Foundations collection with a relationship field with a hasMany relationTo a Pages collection, which contains the sub-pages. the problem with this is that the pages then are re-usable, and it becomes possible to have a sub page sitting underneath multiple Foundations pages, which i'd like to disallow. it's also not possible to see from the child page what its parent is - potentially confusing to an editor if we have multiple pages with a title of "Introduction" say.
i can do it the other way round - a Pages document could have a relationship field with a relationTo the Foundations collection, but then the Foundations document doesn't know what its children are, and there's no way to order the children from the Foundations document.
the third thing i tried was to have a blocks field on the Foundations collection allowing the user to add the content for each tabbed page as a separate block directly on the Foundations document. this solves the above problems, but it means that the UI becomes unwieldy - the content for multiple (possibly quite long) pages will all be displayed on the same page. the blocks seem to be collapsed by default which makes it better, but if an editor un-collapses more than one it gets a bit confusing. considering everything though, i think this is the best option i've come up with.
are there any better ways of doing this? any thoughts gratefully received
(i did see this nested docs plugin which looks interesting, but i don't think fits my use case because i only want to allow one level of parent-child relation, and because the parent and child wouldn't fit into the same collection)
Selected Answer
Hi @Hives,
I would recommend using / reading more on the nested docs plugin.
With this plugin, you would create your content structure using just a Pages collection. You would create a Foundation page, add no content. Create a Typography page, and select Foundation as the Parent Page. You can then create pages for Introduction, Patterns etc and assign their Parent Page to Typography.
This plugin will satisfy many of the issues you listed above:
- Each page will know it's parent / child relations
- Content is separated out into different documents, so you don't end up with one unwieldy page
- You'll be able to use the parent / child data to set more readable titles like
Foundation > Typography > Introduction
I think this would be suitable for your use case but if I have missed something or you see a reason this wouldn't work for you - let me know and we can continue to discuss.
thanks! will take a look tomorrow and see how i get on
Star
Discord
online
Get dedicated engineering support directly from the Payload team.