Hierarchy in Wiki

[MorphBonehunter]

• Gitea version (or commit ref): 1.0.1
• Git version: 2.11.0
• Operating system: Arch Linux
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

This is an "clone" of gogs issue 3087
Supporting a (folder) Hierarchy in the Wiki is an good idea.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[lunny]

do you mean #822 ?

[MorphBonehunter]

@lunny: no, #822 is about table of content, this here is about "Subdirectorys" in wiki.
Maybe it is easier to explain if you could please take a look at gogs/gogs#3087 as this describes it realy well in my eyes.

[lunny]

@MorphBonehunter oh. I see.

[dakira]

Compared to Github this is actually a bug, I would say. I create subdirectories, in contrast to github, they're just irgnored, though.

[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 during the next 2 weeks. Thank you for your contributions.

[pinpox]

This would be greatly appreciated and probably not too hard to implement. Using a wiki with +300 pages is a pain without folders

[ghost]

Nice! That would be really great. I also have quite a few pages which isn't clear to read without folders.

[Cherrg]

Some modification on my script for #822 gives following:

This hijacks the page select/search and generates the page tree with this data.
The container is only shown on large screens >1760px -> there is no place for the container otherwise

Is more needed? Otherwise I could create an pull request. (If #822 is done)

[pinpox]

Some modification on my script for #822 gives following:

This hijacks the page select/search and generates the page tree with this data.
The container is only shown on large screens >1760px -> there is no place for the container otherwise

Is more needed? Otherwise I could create an pull request. (If #822 is done)

This is really nice, but not the whole thing. Having real folders allows to clone the wiki repo itself and work on it. This is actually quite usefull for lager wikis and makes import/export of .md files easy

[Cherrg]

done some coding, so its now possible to render wiki pages from directories. Create/update/delete pages works well. If an old page is updated, the page will be moved to subdirectory.

(Red is a is an error in repository -> file exists in old and new wiki file structure)

Images
currently the images are weird:

• external images: working
• use absolute path: working
• use relative path:
  • currently the path has to be relative to <giteaurl>/<user>/<repo>/<wiki>/ -> also on every wiki sub page
  • i could try to add some JS to rewrite relative urls on rendered wiki pages
    • I think thats a bad idea -> toggle JS on/off will enable/disable working images
      -> so there need to be an update on wiki renderer
      -> Any better suggestions?

Does anyone has a good idea where to place the 'table of pages/wiki tree' on small screens?

[Cherrg]

You could try it out on this branch: https://github.com/Cherrg/gitea/tree/gitea_wiki_page_toc
I will create an PR if #822 is done

[Cherrg]

Found some solutions for both questions, see images in pull request.

[ivptr]

Any update on this? This could be a good solution for migration from Confluence.

[lunny]

Any update on this? This could be a good solution for migration from Confluence.

You can find a PR in #7225 . But there are some different opinions about how to display the hierarchy tree.

[matthias-colt]

would be great to get this on the Plans for Gitea 1.19 #21598 at least, if it can be added in 1.18

[pcone]

Please consider hierarchical pages rather than a structure where folders and pages are treated differently.

By this I mean pages would have a tree structure with parents and children, but parent nodes have page content just like children do.

See the wiki system in Azure DevOps for an example of this behaviour.