page tree manager [feature request]

[Kilian]

An important part for a CMS for me is the ability to add and remove pages as well as organise them into a page tree (so I can add eg a page "our vision" below an "about us" page with the slug /about-us/our-vision) that, ideally, also allows me to move pages around the page tree.

This page tree could then be used to generate both a menu for use around the site (so that you don't have to manually do that), as well as the ability to automatically generate a sitemap.xml.

This is limiting the use of netlify-cms for e.g. SMB websites which very often require the ability to add, remove and move pages without developers getting involved (due to costs or time requirements). Are there plans, or ways, to add such a page management feature?

This ticket is related to ticket #513, which discusses some of the same issues with collections.

[erquhart]

I'm going to set aside the menu and sitemap concerns and first focus on page creation. To do what you're describing, I would expect that you'd have an "About" collection in your configuration, so editors can add whatever pages they like. Again, besides the menu and sitemap, why wouldn't this work for your use case?

[Kilian]

That only lets you manage the single leaf of a subtree. I need people to be able to also add new top level pages, as well as add new pages below the ‘vision’ page and any other page in any other part of the tree, theoretically ad infinitum. In other words: I want to be able to edit the whole page tree through a cms without intervention by a developer.

…

On 6 Mar 2018, at 21:40, Shawn Erquhart ***@***.***> wrote: I'm going to set aside the menu and sitemap concerns and first focus on page creation. To do what you're describing, I would expect that you'd have an "About" collection in your configuration, so editors can add whatever pages they like. Again, besides the menu and sitemap, why wouldn't this work for your use case? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[erquhart]

Okay, I understand you're look for an open ended structure. How would you expect to set boundaries or ensure the right kinds of pages end up in the right place?

[Kilian]

Most CMS systems seem to do this by decoupling the website structure (page tree) from the contents of individual pages. So you can make a page tree like this:

• home
• about us
  • ourvision
• news
• contact

Which are all "pages" (defined as "having a slug and a position in the tree"). You can then add the "blog" collection to the "news" page. The blog collection would then provide further uri fragments for news/2018/, news/2018/january/ and news/2018/january/my-exiting-article/.

[erquhart]

Right, I'm more looking for a concrete example of a static site generator that can read site structure from a file somehow. Know of any?

[Kilian]

I don't. I'm coming from a full-fledged CMS and looking to move to a static site for all its benefits. I've been looking at other static site CMS systems and they don't seem to have an easy way for a generic page tree either.

I think you can get a way towards this by:

• Having a menu/page tree editor separate from actual pages (like wordpress) that has a name, (autogenerated?) slug and maybe an 'app' field. This file could be loaded in to generate a menu, and coupled with something like a 'current'[1] object could provide 'active' state. This can be collection, or a 'page' with a custom widget?
• Have a 'pages' collection apart from other structured content collections
• provide a mapping so that the generated page tree URI fragment serves the right pages-or-other-collections file

I'm pretty sure the first two are already possible with netlify-cms, but the latter might be dependent on the info a static site generator has? Or, netlify-specific, maybe it can be done with a _redirects file?

[1] like Harp:http://harpjs.com/docs/development/current

[erquhart]

Yep, it's the mapping that's the issue. Netlify specific won't really help us either, we need a general approach that will work across static site generators and hosting platforms.

SSG's typically expect your content to be structured in the way the resulting site should be structured. Hugo, as probably the most used SSG with Netlify CMS, allows customization of things like slugs, but actually disallows content being moved to different sections of the site by any method except relocating the file itself in the source. Also consider that, if customizing destination were possible through frontmatter, every file in a collection would need to be changed when a collection is moved in the "page tree".

The issues here are quite similar to those facing the custom content ordering feature request (#475). They're both features that SSG's don't really support, and would require the ability to alter entire collections of files in a single operation.

As in that ticket, the best approach that comes to mind is one that we haven't actually tried in practice yet - extending CMS functionality into the build somehow, by reading a data file as you mentioned and perhaps moving things based on that.

[zipang]

Hi @erquhart !
I'm wandering through these issues to try to help..

In this argumentation, it's seems like you want to restrict the functionalities available in Netlify CMS because of some limitations of static site generators.. like.. finding the correct template to render a file ?
I think it's not a good approach : because, regarding of the domain he is asked to work on, the developer will always choose the tools that are suitable for the job.

So, configuring a static site generator is not such a big deal in my opinion and my guess is that, if we are able to store inside our front matter a (configurable) information like : collection: posts or layout: posts when adding a new content file inside the tree, then, any static site generator, even the dumbest one should be able to use the posts template to render this file. If not, well.. that's an issue with their system, not ours !

But on the contrary, if i have a static site that contains structured content inside a tree hierarchy (that's allways the case for me), and i cannot configure Netlify CMS to edit this content, well.. i'll not be able to use Netlify CMS !
So... that 's the limitation we have here to address ! 😁

[erquhart]

@zipang this issue isn't about helping static site generators figure out which template to use, it's about the structure of the output. Netlify CMS is built to work with static site generators, and SSG's generally determine output placement based on the location of source files.

The CMS config file is a critical piece of the puzzle - it's a single source of truth and it allows a CMS instance to be defined in a single static file. If we don't allow the locations of collections to be defined there, as you've suggested elsewhere, then admins would be required to set up the CMS via UI, which would be a massive step backwards.

At the core of this feature request is the ability to edit the CMS configuration within the UI. It's a big job to tackle, one with widespread impact. For example, how to ensure against collisions across instances when a single actor makes a config change that affects everyone. The result could be an inability to programmatically resolve underlying Git conflicts, or even data loss.

That said, we definitely intend to allow configuration editing via UI (see #341). Once that's in place, changing the locations of collections, which would be the underlying operation of the page tree manager being requested, would mostly require UI work.

If we had a new API allowing the addition of arbitrary new interfaces, similar to what's discussed in #1193, a feasible extension could offer a drag and drop interface to do what's being described here. It may require some work on the backend API as we don't really have a concept of moving/renaming files yet, but could be as simple as delete + create.

So, all of that to say, I agree with the spirit of this request, it's just not something we can easily pull the trigger on. If you'd like to contribute toward making this a reality, #341 is the place to start.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[erezrokah]

I think this can be covered using #3716.
The approach will be to infer the site structure based on the location of files in the repo.
An example for that is https://about.gitlab.com/handbook/.
An advantage for that approach is that it doesn't require any kind of mapping.

Please comment if still relevant