Some of my colleagues use Pimcore as PHP CMS where the idea of schemas and content is represented via “data objects”. One thing that I’m missing in Squidex is the possibility to hierarchically arrange contents with directories and subdirectories.
My feature request: Would you consider implementing an additional view for contents which consists of a tree view as a folder structure? Within each folder, you would be able to select the schema from which you are about to create new content.
My implementation suggestion: Each directory would need to a have an ID and a nullable parent ID. A content could have exactly one directory ID as optional value.
If you take another look at the Pimcore screenshot, you can see that they also have a “documents” item in their navigation accordion. Inside that accordion, you have another tree view that represents pages. So basically, Pimcore distinguishes between documents, data objects, (and assets).
I’m not sure how I can represent web pages like in a “classical” CMS in Squidex. As far as my knowledge of Squidex goes, each web page is a content which has one schema. We were just discussing how to add schemas for things like “persons”, “links” etc. Showing all of these schemas under a project’s content page would probably be too confusing. Therefore, we thought about a tree view.
So to directly answer your question: Create two trees, one for “pages” and one for “data objects”. Each content can only be in one directory (maybe you can add something like referenced content in the tree in the future, but not for the MVP). That way, we can differentiate between data (which can be structured arbitrarily. For instance, think of a company that has four teams. Each team provides different services, has different team members, etc. We’d prefer to have a directory for each of the four teams where each directory only contains the data objects / content for the respective team.
In the “documents” treeview, we could create a page / content for each team and reference the data objects / content from a schema that we only use for the page. I hope you understand that I’m trying to explain
I would keep the pages out for now. It is another topic and very frontend focused. But my experience is that today a piece of content is used in many different places.
Lets say you create a schema “hotel-offer” with a picture, a price and a headline. Something like “Paris 4*, 5 nights, only 200€”
Then this piece of content is used in many places, e.g. the homepage, landing pages, articles, blogs, mobile apps and so on.
Some of these decisions are made manually, but sometimes you only have static rules like “show the latest 5 offers” or so. These kind of rules can be made in the frontend directly and you just use the API go get these items.
But for landing pages you might want to optimize them, so I am thinking about something like a content builder, where you combine content pieces to a higher level content. You can already solve it with references now, so I am not 100% sure if this is needed.
I am not sure if trees are needed anymore for page navigation. If you have a lot of pages you have other rules anyway, e.g. in our hotel example
Theme (like beach, mountains)
Destinations
Hotels
or so. But then the navigation is not driven by the pages, but by the content.
The tree is more like a content organization structure, but the problem is that it a single dimension. But in our hotel example we have a lot of dimensions, e.g. destination, ratings, stars, # of beds and so on.
Yes, we discovered content references today and are refactoring everything like crazy In our cases, the schema on the highest level will be a “page” / “single content schema”.
In that particular case, yes. In my personal opinion, a content driven tree view would be very beginner-friendly if I think of non-technical customers using Squidex.
I don’t think that’s a problem at all On the contrary, it’s easy to understand for non-technical customers. Based on my experience over multiple CMS in the last ten years, most customers I’ve encountered think in page structures, e.g., “we need control X on page Y”. I’m not sure what’s the best way to have a project with > 20 schemas and tell the customer where to start editing content. But maybe we just need to come up with a better schema naming conventions
Yes, when your use case is content you are right. Some Squidex users also have other content types, e.g. hotels and products and so on and then pages do not work anymore.
In our cases, the schema on the highest level will be a “page” / “single content schema”.
