first of all thank you for working on this project. It’s certainly one of my favourite CMS’ out there for various reasons.
However, during my current website project I often think that a tree organization of content would be a great benefit and superior to the current system of simple singletons/collections. With the current system I see 2 possibilites for constructing content trees (think of making a homepage with sub sites.)
- One item links to a group of allowed children. But this only works with collections as childrens (not singletons). Also you would mostly need to use an addon (like Multiple Collection Link) and this method can get very chaotic and confusing for large trees as the relation to children is only visible when viewing a specific item.
- Organize the content tree in a json field (for example in a singleton) with ids. (Every object in the content has an id field.) This method is more manageable but you don’t have a check if the id in your tree really exists and a slug addon would be strongly recommended, too.
As I’m not really happy with both solutions I suggest to use a tree organization like the following two CMS’ for example: Processwire, Gentics Mesh. Instead of collections and singletons we have schemas. Defining a schema, is basically like a collection but there should be an option to allow children (-> every item from that schema can link to items from other schema, basically like the multiple collection link addon).
Instead of singletons, the schema definition could include a boolean which controls if mutiple schema items are allowed on the same tree level.
To an author/normal CMS user, the tree would be shown in a visual represention, where he can navigate through to edit and add items. In that way it’s way easier to identify and modify the structure of a website.
Additionally, it would be really great to have an “unique id” field for the schema which can be configured in a way that it must be globally unique or only unique in its individual current tree level.
The tree organization would also allow the organization like it’s currently handled, if someone does not need nested items: Then every schema would just not allow children.
Thanks for taking the time to read my request.