Idea of hierarchy level without an actual page

[Tak-MK]

Hi there!

Is there a way, or could be an option to add in the future, the option of having a hierarchy level without being a page?
For example, in the example of:
Tree -> Branch -> Leaf
All three levels have a page with contents, but I'd like to know if there would be a way of "Branch", for example, to be just a drop-down button, as in "it expands the hierarchy but doesn't open a page".

I don't know if I'm explaining it correctly 😬

Thanks a lot! :D

[Tak-MK]

Hi! (it seems your comment disappeared, something with GitHub I guess)

Yep! I'm using the arrow, but I was referring more like a folder as you said. As in "anywhere I press (arrow or name) it opens the hierarchy instead of a page".

Thanks! :D

[perber]

Hi,
Yes, I understand what you mean

One possible direction I’m considering is introducing a special node type that acts purely as a structural element—basically a “folder-like” item in the hierarchy.

Such a node would:

• only list its subpages
• have no own content
• be excluded from things like full-text search and metadata (author, timestamps, versioning)

That said, this touches some deeper design questions around navigation, linking, and overall consistency, so it’s something I want to think through carefully.

Just to set expectations: this isn’t something I plan to implement in the near future.
The focus is currently on different topics.

Thanks for your feedback! I appreciate it!

[Tak-MK]

Super nice!

Just an idea to reduce the overhead of coding everything:
What if there's a toggle when you're logged in that allows you to activate "folder mode", and the only thing it does is to make the arrow and text open the hierarchy? Ignoring the index.md as if you were only clicking the arrow as now.
Then it'd be adding to the search code to ignore the "folder mode" pages 🤔

Hope it helps! Thanks a lot! :D

[perber]

Thanks a lot for the idea.

I need to consider the index.md handling anyway, because my longer-term plan is to get rid of the internal tree.json. One possible outcome of that is that nodes without an index.md could naturally be represented as “folder/pagenode” instead of pages.

That approach would have some logical implications (navigation, linking, imports, etc.), but it could also lead to a cleaner model overall and better integration with plain Markdown structures.

Definitely something worth thinking through. Thanks again for sharing your thoughts!

[Tak-MK]

Oh, that's a pretty nice idea too. Thanks a lot again! :D I'll share if I come out with any other idea.

[perber]

Happy to get some feedback.

[perber]

@Hugo-Galley What do you think about that feature, from a user perspective? I would add a context menu for create folder and per default let the + button to create a page. (To keep the flow as it is)

Would it be also useful to you?

I also think about to keep the behaviour as it is and render a the list of subpages. (When you click then on a subpage, the tree expands anyway)

[Hugo-Galley]

@perber I think the idea could be interesting, especially to create some kind of “categories” in the wiki.
Technically, we can already achieve this using a page that acts as a node, but from a user perspective, the idea feels nice.

We just need to see how it would be integrated so it doesn’t add too many options and compromise LeafWiki’s simplicity.
Maybe something like a dedicated place, as you suggested — a conceptual menu, a checkbox, or a small UI addition.

I also saw in the comments above that this could help make the structure cleaner.
If it improves both usability and structure, I think that’s great.

So yes, it’s definitely a feature I’d like to use.
The idea is worth thinking about for sure. Thanks @Tak-MK :)

[perber]

Yes, the easiest option would be to mark the Page object as a Node. Which could be easily done, but this way for me it doesn't feels conceptual right and it will not allow an easy import of markdown files. But could be implemented without much effort and the impact to the current concept will be limited. (Besides UI changes / They have to be change in any approach.)

I think I would go with a different approach and support folders without a index.md file. This way of course markdown files need to be renamed to look like a slug, but that should be the only think which needs to be adjusted when importing files. The only thing is that the page_store & the tree_service need to support this model which is more complex and has a bigger impact.

I also thought a bit about the tree.json file.
The tree.json file will still remain as the Source of Truth for structure and metadata like creator, lastAuthor, createdAt, updatedAt, position. If we don't do it this way, we need to update the position in every file in the current tree, which will increase the IO load. I also think it will make sense to backup the tree.json file and later the revision files as well.