Parent page has_children should not require child pages parent setting

[ThomasNieto]

Is your feature request related to a problem? Please describe.
Right now, you have to set all child pages with the parent page. It would be nice if you could set the has_children to true and then no change to pages in the same folder automatically is a child of that page.

In the example in the docs: child pages, index.md is the parent and all ui-components pages should be an automatic child of index.md instead of requiring parent: config.

+-- ..
|-- (Jekyll files)
|
|-- docs
|   |-- ui-components
|   |   |-- index.md  (parent page)
|   |   |-- buttons.md
|   |   |-- code.md
|   |   |-- labels.md
|   |   |-- tables.md
|   |   +-- typography.md
|   |
|   |-- utilities
|   |   |-- index.md      (parent page)
|   |   |-- color.md
|   |   |-- layout.md
|   |   |-- responsive-modifiers.md
|   |   +-- typography.md
|   |
|   |-- (other md files, pages with no children)
|   +-- ..
|
|-- (Jekyll files)
+-- ..

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[max06]

Hello @ThomasNieto!

I'm not sure if this is doable. Jtd organizes the page structure only based on the frontmatter in the markdown files. The arrangement "on disk" is irrelevant.

Let's see if my colleagues have ideas about this.

[pdmosses]

I think the original design of the navigation structure in JtD was that it should be specified explicitly by front matter, and independent of the file system. Personally, I've always found it tedious and error-prone to specify so much front matter.

As I recently mentioned in a comment on PR #462:

I've also looked at Material for MkDocs, which has already implemented many of the features that we intend to support in JtD (multi-level navigation, i18n, versioned docs, toggled between color schemes, …). It seems that the navigation hierarchy there can either be left implicit in the directory structure, using file names as titles – with optional front matter to override the URL and/or the title displayed in the navigation panel – or specified in a single YAML file that associates titles with file names in the intended order and nesting. Jekyll provides variables such as page.path, and I don't see why any hacking would be needed to implement the same idea in JtD. There's also Docsy Jekyll, a port of the Hugo theme Docsy.

When PR #1244 is finished, I'm planning to take a closer look at how JtD could support (multi-level) navigation based on directory structure. But as I also mentioned:

I think we need an in-depth discussion of what we would like to implement before opening a new PR on this topic.

There's an open discussion #425 with the question "Navigation levels limitation?". My response is now outdated, but I think it would be easy enough to update it, as a starting point for a fresh discussion of our current ideas for multi-level navigation.

An alternative might be to revisit the open issue #219 on "Navigation doesn't work with grand-grand-children". However, the linear structure of an issue doesn't seem as convenient as a discussion with threads of comments on potential answers, and discussions have the possibility of sorting them by the date of latest activity.

[ThomasNieto]

I do find it tedious and error prone as well. In my use case I'm using a tool to build the API documentation for my C# project and I have to add that front matter manually on around ~50 pages.

[dluc]

here's an idea: #1409

[paddyroddy]

Related to this, it becomes tedious to specify grand_parent and parent - I would have thought just parent would be sufficient

[pdmosses]

Related to this, it becomes tedious to specify grand_parent and parent - I would have thought just parent would be sufficient

When all page titles are distinct, specifying just parent is indeed sufficient. But when the parent title of a page could refer to different pages, disambiguation is required.

See the preview of the docs for PR #1431 for the details of a complete proposal.