mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-08 03:09:39 +03:00
Support more sublevel in chapters #90
Closed
opened 2026-02-04 16:39:29 +03:00 by OVERLORD
·
65 comments
No Branch/Tag Specified
development
further_theme_development
l10n_development
release
llm_only
vectors
v25-11
docker_env
drawio_rendering
user_permissions
ldap_host_failover
svg_image
prosemirror
captcha_example
fix/video-export
v25.12.3
v25.12.2
v25.12.1
v25.12
v25.11.6
v25.11.5
v25.11.4
v24.11.4
v25.11.3
v25.11.2
v25.11.1
v25.11
v25.07.3
v25.07.2
v25.07.1
v25.07
v25.05.2
v25.05.1
v25.05
v25.02.5
v25.02.4
v25.02.3
v25.02.2
v25.02.1
v25.02
v24.12.1
v24.12
v24.10.3
v24.10.2
v24.10.1
v24.10
v24.05.4
v24.05.3
v24.05.2
v24.05.1
v24.05
v24.02.3
v24.02.2
v24.02.1
v24.02
v23.12.3
v23.12.2
v23.12.1
v23.12
v23.10.4
v23.10.3
v23.10.2
v23.10.1
v23.10
v23.08.3
v23.08.2
v23.08.1
v23.08
v23.06.2
v23.06.1
v23.06
v23.05.2
v23.05.1
v23.05
v23.02.3
v23.02.2
v23.02.1
v23.02
v23.01.1
v23.01
v22.11.1
v22.11
v22.10.2
v22.10.1
v22.10
v22.09.1
v22.09
v22.07.3
v22.07.2
v22.07.1
v22.07
v22.06.2
v22.06.1
v22.06
v22.04.2
v22.04.1
v22.04
v22.03.1
v22.03
v22.02.3
v22.02.2
v22.02.1
v22.02
v21.12.5
v21.12.4
v21.12.3
v21.12.2
v21.12.1
v21.12
v21.11.3
v21.11.2
v21.11.1
v21.11
v21.10.3
v21.10.2
v21.10.1
v21.10
v21.08.6
v21.08.5
v21.08.4
v21.08.3
v21.08.2
v21.08.1
v21.08
v21.05.4
v21.05.3
v21.05.2
v21.05.1
v21.05
v21.04.6
v21.04.5
v21.04.4
v21.04.3
v21.04.2
v21.04.1
v21.04
v0.31.8
v0.31.7
v0.31.6
v0.31.5
v0.31.4
v0.31.3
v0.31.2
v0.31.1
v0.31.0
v0.30.7
v0.30.6
v0.30.5
v0.30.4
v0.30.3
v0.30.2
v0.30.1
v0.30.0
v0.29.3
v0.29.2
v0.29.1
v0.29.0
v0.28.3
v0.28.2
v0.28.1
v0.28.0
v0.27.5
v0.27.4
v0.27.3
v0.27.2
v0.27.1
v0.27
v0.26.4
v0.26.3
v0.26.2
v0.26.1
v0.26.0
v0.25.5
v0.25.4
v0.25.3
v0.25.2
v0.25.1
v0.25.0
v0.24.3
v0.24.2
v0.24.1
v0.24.0
v0.23.2
v0.23.1
v0.23.0
v0.22.0
v0.21.0
v0.20.3
v0.20.2
v0.20.1
v0.20.0
v0.19.0
v0.18.5
v0.18.4
v0.18.3
v0.18.2
v0.18.1
v0.18.0
v0.17.4
v0.17.3
v0.17.2
v0.17.1
v0.17.0
v0.16.3
v0.16.2
v0.16.1
v0.16.0
v0.15.3
v0.15.2
v0.15.1
v0.15.0
v0.14.3
v0.14.2
v0.14.1
v0.14.0
v0.13.1
v0.13.0
v0.12.2
v0.12.1
v0.12.0
v0.11.2
v0.11.1
v0.11.0
v0.10.0
v0.9.3
v0.9.2
v0.9.1
v0.9.0
v0.8.2
v0.8.1
v0.8.0
v0.7.6
v0.7.5
v0.7.4
v0.7.3
0.7.2
v.0.7.1
v0.7.0
v0.6.3
v0.6.2
v0.6.1
v0.6.0
v0.5.0
Labels
Clear labels
🎨 Design
📖 Docs Update
🐛 Bug
🐛 Bug
:cat2:🐈 Possible duplicate
💿 Database
☕ Open to discussion
💻 Front-End
🐕 Support
🚪 Authentication
🌍 Translations
🔌 API Task
🏭 Back-End
⛲ Upstream
🔨 Feature Request
🛠️ Enhancement
🛠️ Enhancement
🛠️ Enhancement
❤️ Happy feedback
🔒 Security
🔍 Pending Validation
💆 UX
📝 WYSIWYG Editor
🌔 Out of scope
🔩 API Request
:octocat: Admin/Meta
🖌️ View Customization
❓ Question
🚀 Priority
🛡️ Blocked
🚚 Export System
♿ A11y
🔧 Maintenance
> Markdown Editor
pull-request
Mirrored from GitHub Pull Request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/BookStack#90
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ducheneo on GitHub (Apr 6, 2016).
Originally assigned to: @ssddanbrown on GitHub.
It should be interesting if we could use at least one more level of sub-chapter in a book.
Collapsible sections are also interesting.
@ssddanbrown commented on GitHub (Apr 6, 2016):
Hi @ducheneo, I agree with collapsible sections, They're already open and requested on #78.
The extra level of grouping is an interesting topic. I would rather not add this feature and here's why:
Initially when building BookStack I allowed a system of highly nested pages. I was following the system that confluence used. From a development perspective this was tricky to support, Not impossible by any means but added extra complication whenever there was a listing or when working out relation trees.
From a user perspective things were fairly hard to navigate. Allowing a high level of nesting means you can only show part of a grouping, or tree structure, at a time which meant you only see a snapshot of a whole and it becomes easier for content to stay hidden. It also means there was no standard grouping system or clear separation of levels.
At that point I changed BookStack to a 2 tier grouping, Books & Chapters. I very much like this level of grouping as it can be related to the way we store content in books, It's familiar and simple while allowing a good level of organisation. It also forces you to keep the wider organisation of the content from going out of control. I feel that adding an extra layer of chapters would break this simple relation to books. On top of that there will always be someone that wants an extra layer, no matter how many layer are implemented.
I do understand the need for an extra dimension of organisation/categorisation through which will be added by the attribute-value system proposed in #48.
I'll keep this issue open and also I'm open to further discussion as the community may have a very different opinion to me but I do really like the core Book/Chapter/Page structure of BookStack.
@nwalke commented on GitHub (Apr 7, 2016):
We definitely like the Book/Chapter/Page structure. This is why we're using BookStack.
@ducheneo commented on GitHub (Apr 7, 2016):
Hi Dan, I can understand your point of view.
The point is that the nature of our documentation is deeply hierarchical, and 3 levels of grouping would be more appropriate. The display of the navigation tree could remain unchanged, by replacing the collapsible with "number of page" with the sub-chapter title. And if most people find the actual structure fine, adding the extra level as an option could satisfy everyone (but certainly tricky to implement).
@cpressland commented on GitHub (Apr 12, 2016):
Well, this is an awkward one. While I love the idea of being able to have chapters within chapters, I imagine it'll quickly become as overly complex as Sharepoint or a Filesystem. The current system forces the people and teams adding content to BookStack to be creative, rather than ending up with one page in a large number of chapters.
vs
Personally, I'm happy with the current design. Maybe a tagging system would be better for this? I'll ask a few people in the office for their opinions on this and report back.
@cpressland commented on GitHub (Apr 15, 2016):
Maybe we should be considering "sub-chapters" as "paragraphs".
So you have a Book for an Application Support Team, inside you have Chapters by product type such as "Financing", inside "Financing" you can have Paragraphs such as "QuickBooks" or "GnuCash" and then Pages inside said Paragraphs.
For what we're using Bookstack for at the moment, this'd probably fit quite well. I've sat down with a few people and the general consensus is this is what we want going forward.
@riorii commented on GitHub (May 13, 2016):
+1 with having 1 sublevel more. Like Subchapters. 1 sublevel more would be sufficient.
@fredericmohr commented on GitHub (Jun 6, 2016):
I'm not sure if another sub level is such a good idea as, but what might be a good idea is to have the option of displaying only part of a page directly and have the other parts in different sections (sort of virtual pages inside a page).
[book 1] -> [chapter 1] -> [page 1]
If [page 1] get's really long, show everything just before the second [h1] headline and include a pagination. It would still be possible to load everything at once and handle only displaying the content via javascript. That would make it easier to structure content into sections using headlines without getting pages that are way too long.
This would also go great along with a table of contents feature (not a complete book toc but a per page toc). Just my 2 cents.
PS: Obviously this would have the downside of [ctrl]+[f] search not working as well, since only part of the content is shown. Maybe include a page search?
@AkibaWolf commented on GitHub (Jun 30, 2016):
+1 for paragraphs.
@relu-xz commented on GitHub (Sep 8, 2016):
+1 for subchapters
My team is using Bookstack as wiki, I'm the admin and believe me, this feature will be useful because we have a lot of chapters and pages and it's becoming a nightmare...as @riorii said, one sublevel more will be sufficient.
@haynes11 commented on GitHub (Dec 29, 2016):
+1 for subchapters. I agree with your reasoning, and the fact that people will always want an "extra layer" but I think one sub-level more would solve a lot of the problems I have with using this as a wiiki.
@DeviantEng commented on GitHub (Mar 2, 2017):
+1 for one more level here; not asking for full on nesting, but just 1 more level.
EDIT: Maybe instead of sub-chapters/sections/paragraphs, another level could be added above Books; such as collections? Could possibly do that as tags. I.E., a collection (or tag) of ClientA, with multiple Books underneath for that client. Those Books would have the same existing (optional) Chapters and Pages.
@salmiery commented on GitHub (Mar 4, 2017):
+1 Yeah, it would be very cool to have more levels of nesting, maybe with the option to define what those levels are called per book.
+1 on DeviantEng on the level above for book collections. Would be cool to be able to group your books by category.
@ssddanbrown commented on GitHub (Mar 4, 2017):
Just as an update, Since it's almost been a year since my last comment, I am keeping this in mind as I'm refactoring any parts of BookStack and keeping entity references generic to help support more levels in the future. Then it'll be a case of just sitting down one weekend and finishing this off, Maybe once exports have been fleshed out and the search has been fixed (#271).
In terms of structure, A level above a book would be better to fit in with the understanding of the books/chapter/page structure but from an app/coding/architecture point a lot has been built around books being the top of the chain so it would require more effort.
@shelbyallenfranks commented on GitHub (May 10, 2017):
As mentioned in #337, I think that the concept of "book shelves" would be a really nice way of achieving this extra level of categorization without straying too far from the simplistic nature of BookStack. Having this extra level would be a great way of being able to link users to a specific set of books that are closely related.
However, if this is difficult to achieve from a coding point of view, perhaps an easier approach to this might be to allow applying tags to books in the same way that these can currently be applied to individual pages?
@mardeu commented on GitHub (Jul 27, 2017):
+1 for subchapters too
@VyBui commented on GitHub (Aug 17, 2017):
+1 for subchapters
@Starow commented on GitHub (Sep 28, 2017):
+1 to be able to regroup books into bookshelves 👍
@Ethanb00 commented on GitHub (Sep 28, 2017):
-1 for subchapters (I think it breaks the elegance of the existing structure)
+1 for bookshelves
@genxlee commented on GitHub (Nov 9, 2017):
+1 for subchapters
@CodeBrauer commented on GitHub (Nov 15, 2017):
What about ordering/sorting pages/chapters? Issue #257 may be closed but ordering pages is still an issue. I saw there is already field "priority" in the pages tables, but I think there is no option to set it?Nevermind. It's just Books > "3 Dot menu" > Sort
@AbijeetP commented on GitHub (Dec 1, 2017):
Would prefer bookshelves myself.
@snics commented on GitHub (Jan 22, 2018):
+1 for subchapters
@gojj-se commented on GitHub (Jan 25, 2018):
+1 for bookshelves (and permissions on those)
-1 for subchapters (if choosing is needed, otherwise both)
@pierre-le commented on GitHub (Mar 12, 2018):
+1 for either bookshelves or subchapter, this is merely a semantic issue.
This feature would be great, especially when Bookstack is used in company environments where you need to manage and categorize massive amounts of knowledge.
@d-sko commented on GitHub (Apr 30, 2018):
bookshelves and subchapters are both very useful. But if I had to choose, bookshelfes would be more important to me. I also like @fredericmohr´s idea of adding a pagination for head tags
(could be done similar to mediawiki, where a pagination is generated if there are more than n headings), which could be a replacement for subchapters.oops, just saw that this is already implemented@mendiromania commented on GitHub (May 3, 2018):
+1 there's no reason not to gonna make my own clone with it
@CaptnBook4Git commented on GitHub (Jun 17, 2018):
I support this idea. But instead of an subchapter, i like the idea of bookshelves/collections. I use Bookstack for writing down stuff from university. And it is horrible to sort it like i need it. I would just need that one layer more to get out of the chaos. (I have a book for every main topic, then inside the book i use chapters for the main chapters in this topic, but one chapter has more than 50 pages with at least a minimum of 3 different subtopics. So this is chaos. I could do this all in different books, but then there is no red line anymore to learn them, i have to re-sort them, everytime i want to learn an old topic)
I would also like to know what going on now with this topic. It is now 2 years old, so many people want this, nobody is against this idea... so what is going on?
@ssddanbrown commented on GitHub (Jun 22, 2018):
@iBooster This issue is not being ignored, I promise. It's just that this is no small task and will require a lot of fundamental re-working of BookStack to be done properly due to the core role that Books currently play.
Time is not free, All contributors are helping in their own time. As per the latest blog post (Next steps section) I am looking to plan out how to go about this as part of this release cycle.
@ssddanbrown commented on GitHub (Jun 24, 2018):
I've been thinking about this a little more, Thought it would be good to plan out a proposal. I've got some time off in a couple of weeks where I could crack on to get this done. Here's the proposal:
BookShelves
I thought the many-to-many relationship would give BookShelves a unique ability, rather than being a clone of the Book entity. It's like how, in the physical world, you could have copies of a Book on different BookShelves.
Any feedback on the above is appreciated.
@CaptnBook4Git commented on GitHub (Jun 24, 2018):
That would be awesome!
@Abijeet commented on GitHub (Jul 2, 2018):
@ssddanbrown - A few questions / notes,
@ssddanbrown commented on GitHub (Jul 29, 2018):
Sorry for my late reply @Abijeet.
@aljawaid commented on GitHub (Jul 29, 2018):
@ssddanbrown
My input.... (using bookstack for a very small business how-to manual)
Bookshelves makes sense to be added as a feature. It should NOT be mandatory, as some books (supervisor/manager only) can be offshelf whilst staff books can be on a bookshelf. Hope that gives you an idea. Then again, some could argue that have a supervisor-only bookshelf. That could work too.
Having access to a bookshelf should be optionally password-protected.
Would be good to have the related books listed in a popup (if too many) but all related books should be mentioned.
Exporting of a bookshelve would be fantastic, with a exported list of books and then the option to print them in order into a single pdf (so bookshlelf + books = one pdf)
@msaus commented on GitHub (Aug 3, 2018):
nice :)
@MrKhalidJ commented on GitHub (Aug 4, 2018):
@ssddanbrown
Interesting idea. adding one more level of depth might help organization more.
one suggestion though: bookshelves should accept pages directly without requiring it to be part of a book first.
here's how I'm thinking of applying this in my department so you might get a better view of my idea:
we are a small IT department. I'm trying to centralize our documentation papers using bookstack.
so I'm thinking of having one shelf for the networking team, one for sysadmin team, one for helpdesk team and so on.
a number of subjects don't need more than one paper, and not all subjects are related to be grouped into one book or chapter. so having pages alongside books on bookshelves might make it better for not having to use books for every little subject just so you can add it to a shelf.
that's my feedback. hope it helps shape the idea further. 😃
@nvnvnvnvn commented on GitHub (Aug 8, 2018):
Any reason not to add another layer at the same time?...Could have Bookcase, then bookshelf, then book, chapter, pages.
@ssddanbrown commented on GitHub (Aug 8, 2018):
@nvnvnvnvn Yeah, Extra build effort, extra systems to maintain, additional system and UX complexities, Extra testing needed.
I've given my thoughts on extra levels in general here:
https://github.com/BookStackApp/BookStack/issues/95#issuecomment-206509825
For BookStack, I do think there should be a limit. Someone will always want 'one more level'.
@carlospauluk commented on GitHub (Aug 17, 2018):
Ok, but what about an index for page sections?
@mendiromania commented on GitHub (Sep 9, 2018):
working demo for those who can't wait
https://github.com/mendiromania/BrainStack
run this sql
https://gist.github.com/mendiromania/e323f6532531d9cf125e8f9b33c6067e
and in books manually update the bookshelf_id with the id of the bookshelf
edit:

added a migration for the sql and a bookshelf option in the book editor
@guyinpv commented on GitHub (Sep 11, 2018):
I was just editing my books and thinking, it would be cool to have bookshelves once you start to get a lot of books. Then boom I see this on the roadmap, excellent!
To me, the shelves are little more than a folder system. I have a lot of books, so now I just want to organize some books in this folder and some in that folder etc. But keeping with the theme of Bookstack, I though, bookcases. It's a logical thing to do.
Like others have said, a bookcase in my home can hold anything, so maybe it can hold books, but it could also hold directly, just pages.
For permissions, it's obvious things like, access to the entire book case or not. But then this could get tricky if you allow a book to exist in multiple bookcases. Existing in multiple places sounds more like tags and categories, not necessarily bookshelves. Maybe bookshelves themselves can have a reference system.
In real life bookshelves could categorize books alphabetically or topically. For BookStack, you could have a structure like this, it could even be auto-generated based on alpha, or based on tags.
I think most use cases would have shelves relating to departments in a company. The IT dept, the media dept, etc. But automatic shelves would be a neat concept. A bookshelf for all books and pages created per-user. This is Zack's shelf, for example. Or shelves based on tags or alpha as mentioned.
The bottom line is, after only about 9 or 12 books, it's already a bit much to look at. At the very least I think after about 12 books, the grid view should get smaller. Instead of 3 blocks wide it could adjust to 4 blocks wide with smaller thumbnails. Maybe even 5 blocks wide if you have over 30 books.
OR, do the shelves, but it must be visually pleasing to do shelves. The whole idea is to reduce visual clutter and make it a little easier to browse books. We should still have a "view all books" view, just to avoid clicking in and out of shelves, kind of like looking at my Amazon Kindle, you can view the entire list of books, that should always be available. But shelves could simply be an alternative to grid and list view for those of us who want to organize our books into "folders".
@ssddanbrown commented on GitHub (Sep 20, 2018):
Just to provide an update, I'm coming to the final steps of the build of this in #947, Just have to implement some testing. I'm hoping I can get this done and then wrap up the next release by the end of this weekend.
Please note the initial release with bookshelves will be focused on the core functionality as in my proposal above, Most of the design and UI is simply copied from the 'Book' UI.
I plan on doing a UI update soon after which should provide bookshelves a slightly more unique & focused design & user-experience. This will also aim to improve the efficiency of the UI in many areas so may align it closer to what you are thinking about @guyinpv.
I'll have a think about having pages within a BookShelf. If this is something you want please create a new issue for it for more focused discussion.
@ssddanbrown commented on GitHub (Sep 21, 2018):
#947 has now been merged into master so I will now close this pull request. As my message above, Expect a new release soon with Bookshelves included.
@willc commented on GitHub (Dec 2, 2018):
It looks like Shelves were implemented since this thread was closed, and that puts BookStack on par with OneNote as far as levels of categorization/organization go (not that we need to compare this to OneNote, necessarily).
But after using this app for a few days and starting to port over years of content from OneNote, I am thinking that just one more level of depth (sub chapters) would make a huge positive impact on being able to organize everything just so.
I don't think it needs to become a slippery slope towards supporting/coding infinite levels of content. But based on all the comments and support for just one more level above, I think it would be a really good feature to have.
@phylogram commented on GitHub (Apr 13, 2020):
When I go to my library, there are so many books with nested chapters (not only subchapters), and many of them are great books. I was looking for writing software, which does not dictate organizational logic.
@ssddanbrown commented on GitHub (Apr 13, 2020):
@phylogram Then, to be bluntly honestly, BookStack is probably not the platform you're looking for. An opinionated structure is at the core of the platform.
@JoeIzzard commented on GitHub (Jan 14, 2022):
Just to throw my hat in on the issue. I think Subchapters would provide added benefit to Bookstack for the reason of Permissions management.
I am currently documenting our systems using Bookstack. Each department is given a Shelf, with each App or Topic existing as a Book. If multiple departments use an app we can share it in multiple shelfs. Using JumpCloud as an example (We use it for account management), we have the book set to be viewable by everyone. It includes information on resetting passwords and how to access the user portal.
I then have a chapter explaining LDAP, and how to enable a user in the LDAP directory. This chapter can be viewed by Managers. In the same chapter it would be good to then go one more level for system configuration. This information should only be viewable by Admins. The additional level would give us the flexibility of documenting very large interconnected systems with complex permission structures easily and from everything I have documented so far, one additional level would solve a lot of the issues.
Another example is License Servers for an app. I could break it out into another book, but ideally I would be able to document the License Server for app A, in the app A book. The additional level would give more control of that very large topic.
I've seen some talk of Sections in these discussions and think that could work well as a way to maintain the link to books and this additional level. Some very long or varied books include sections of chapters. This could provide the same function as a sub-chapter, but instead placed above a chapter giving you:
I have opened another issue (#3167) As a potential work around for not having another layer but still getting the same permission control of content, although that would also be a nice feature on its own.
@tvogt commented on GitHub (May 4, 2022):
I'd also like one additional level, as outlined above by JoeIzzard. This structure can actually be found in many paper books.
@KnightNine commented on GitHub (Mar 28, 2023):
has anyone suggested "non-collapsable chapter separators which can be nested?" simply being a grouping mechanism for chapters that is seen on the Book level without needing a whole page dedicated to displaying chapters within this sublevel.
I mean the Book>Chapter>Page makes sense for novels but for manuals it would help to be able to group chapters by subject.
Right now I'm running into an issue where I have a "Lore Encyclopedia" Book for and I want a chapter for "Items" and within it would be categories of items like "Weapons & Tools", "Miscellaneous", and "Equipment", though ideally these would also be chapters unless I want a single bloated page containing every "Weapon And Tool" across my entire project, which I don't.
As the outermost level of categorization I'd rather dedicate shelves to specific projects I'm working on:
It would be annoying to have books for specific parts of the encyclopedia.
The only way around this that I can see is to add a prefix to define the chapter category like "Items- Weapons & Tools" and "Items- Miscellaneous". Though it would probably be better to split up my encyclopedia into different books since I wouldn't need to add this ugly prefix as much for my 3 broad categories.
@baevga commented on GitHub (Apr 16, 2023):
Yes, i'm sure that having one more level will play a very good role in wiki organization
@eskapdk commented on GitHub (Jun 15, 2023):
i'd also like if bookstack have one additional level like sub-chapters / section / other.
i'm using bookstack for my project in applications government wiki, it's used by two user there is public (like user of my apps for access on apps user guides) and private user (techincal user like technical witers, PM and others for acces on technical documents).
it will be great if have one level like sub chapters / section / other, because in my old user guides and tech docs (it's using PDFs) its have leves like book -> chapter -> sub chapter -> pages, and current bookstack book -> chapter -> pages, i would be greatly appreciate if the current bookstack hace more at least one sub-chapters
Or if it's cannot be done because all reasons above, can you suggest bookstack hack if i will add some chaptes, please?
thank you
@komoricodrutz commented on GitHub (Jun 20, 2023):
7 years after this topic was opened (and almost 3 years after I switched to Linux), I stumbled upon BookStack in my until now endless search for a FOSS alternative to OneNote.
It is wonderful, it ticks almost all my checkboxes, however, the possibility of adding more nesting levels is something that I also consider extremely useful.
My current workaround is to add a chapter without pages as a "section title" to be able to more easily follow the structure, but the multiple nesting function would make it a lot easier to sort your articles.
Thank you!
@MKHIII commented on GitHub (Sep 25, 2023):
It would be so helpful to have an additional layer of organization. I am migrating an entire Confluence Space to BookStack and am having extreme difficulties. I cannot create links in the chapter descriptions (as you can link to headings, other pages, etc on pages themselves) and simply being able to create a chapter index would be helpful. Honestly, it should automatically do this as you add pages to a chapter. A section or a sub-chapter would be really helpful as well. Also...a link list that can be sorted containing all books on a shelf, or chapters in a book, or pages within a chapter that occurs automatically and can be sorted OR at least the ability to put links in the description section of these. As well as having just one more level of organization...
@jinjaghost commented on GitHub (Oct 19, 2023):
+1 for one more level.
The Shelf > Book > Section > Chapter > Page would be a perfect fit for many users.
@yblis commented on GitHub (Nov 7, 2023):
Hello :)
Given that we are in the context of a 'book', why not simply add:
This sequence outlines the hierarchical organization of books within a library, starting from the broadest category (the library itself) and narrowing down to the individual pages within a book.
@canklamassono commented on GitHub (Dec 20, 2023):
As this Topic has been discussed a lot already - why not give an option to Enable another Layer (Like Sections/Subchapters) etc. This has to be done and isn't enabled by default, therefore it wouldn't contradict the general mindset of keeping it simple except for when the User has the special need to make it more complicated.
I really don't get why even after Shelves have been introduced, this optional setting for more Layers isn't available yet. Obviously people will continue to ask for it.
@ssddanbrown commented on GitHub (Dec 20, 2023):
I wouldn't want to add an option that changes the core structure and focus of BookStack, especially just for only when users have a "special need" for it. I generally avoid making things options in that manner due to the eventual complexity they introduce.
Generally my view on extra layers remains much unchanged from my original comment in this thread. I specifically built to a fixed level system for the usability/UX/design goals of BookStack, and each layer impacts those goals while adding complexity. Therefore I don't really have any intent to expand on this within the official project.
That's not to say there's not a desire or need in some use-cases, it's just that I don't want to alter/maintain BookStack with this specific change to meet those desires/use-cases and, as demonstrated above, adding another layer will likely still result in a request here for just one extra level.
@canklamassono commented on GitHub (Dec 21, 2023):
Thank you for the quick reply and reasonable answer. Even though you're not going to add this to the core, is there a possibility for you to disclose how this could be achieved (if there actually is a straightforward way) if someone wanted to implement this by themselves?
@KnightNine commented on GitHub (Dec 23, 2023):
@ssddanbrown I don't understand how it could be seen as a "special need", it is quite natural that you'd want an extra layer of categorization to pages mirroring how many categories and sub-categories of information (how much depth) the subject you're trying to document has.
the solution you provided for this extended categorization functionality doesn't seem to be relevant to organizing the branches of a subject which I believe this is on the topic of. Tags are more for labeling the relationships between pages/chapters/shelves.
I still suggest infinite categorization at the Chapter level but in a simplified way that is title only and non-collapsible, so that there isn't any folder bloat and it's all visible at once. People will always be asking for another layer of categorization, so the only solution I see is to give them infinite categorization in a way that isn't overly complex. On the back end it can simply function the same way as tags but only relevant to the layer the page exists on, where you add the category as a label of the page without actually nesting the data and then displaying it as if it were nested.
@Lbsl commented on GitHub (Jan 10, 2024):
I'm trying to move team's knowledge share docs from other system (showdoc) to BookStack, but the old system has much deeper structures so it's very hard to do the migration, it will be much more helpful if BookStack can support recursive nested chapters
@UAnton commented on GitHub (Jan 18, 2024):
+1
@JohnShield commented on GitHub (Mar 6, 2024):
Thanks Dan for creating bookstack,
It's a great tool and I'm impressed by how well it runs and been thought out.
Background
I've been trialing Bookstack for use as the wiki for my company, specifically in scope for the engineering department. The main shortfall I'm seeing is the hierarchy depth feels like a bad fit for my use case.
The regular hierarchy is:
Department->Projects->Discipline Teams->Major System Components->Sub-components->Sub-Sub-Components->Document Category->Documents
Attempt at mapping Hierarchy to Bookstack
In an attempt to organize the data, I've been adding the additional hierarchy levels into the name of books, chapters and pages. It's been okay at the book level, as the first 3 layers of hierarchy are organisational and not useful for everyday work. However, it's a rather messy outcome at the chapter and page level. It's difficult to find the information you want within the large number of chapters and pages and their long names.
This is our current layout, when trying to map it to Bookstack:
Shelves -> Department: (IT department, Engineering Department, Company Policies, etc)
Books -> Projects: (Various paid customer projects)
Books (Artificial naming) -> Discipline Teams: (Artificial naming of books to avoid chapters for this) (Software, Hardware, Firmware, etc)
Chapters -> Major components: (Interfaces, Digitial Signal Processing, Peripheral Chips, Formal Verification Testing)
Chapters (Artificial naming) -> Sub-components: (Ethernet Interface, Chip Configurations, User Interface)
Pages -> Sub-component (Overview, Design Descriptions, Sub-component interfaces, Sub-Sub-Components)
Pages (Artificial naming) -> Sub-Sub-Components (Overview, Design Descriptions, Sub-Sub-component interfaces)
Pages (Artificial naming) -> Document Category (legacy pages, test data, design exploration, test setup)
Pages (Artificial naming) -> Documents (Individual instances of the categories)
Discussion
My observations while trying to flatten the hierarchy. The organizational/company hierarchy isn't useful day to day. However, it needs to be there to avoid different teams and departments from tripping over each other. I think it could be replaced by a simple top level jump page, to different groupings of shelves or to specific books.
However, the organizational/company separation also needs to be kept separate otherwise the listing of shelves and books would end up very cluttered.
The 3 levels of hierarchy for system components I think is critical for documentation of my engineering work. The problem is the short page names often are misleading about what the contents contain. Often times there's a page named "Decoder .... ....", which is a correct description of what it is, but there's actually 3 different parts of the system that also match that description. The most important bit of information is what is the major component or function the decoder is part of, which is part of the heirarchy. Similarly staff will often make a page called "verification test results" or something with similar naming, which can be around 20 A4 pages of content. The length of the content requires it's separated into its own page, and the naming of the page requires some hierarchical information about what it relates to.
This common problem of similar names being used for different parts of the system also degrades search capability, making hierarchy more important. Tagging pages sounds like an alternative solution, but our systems are large and complex enough that it's difficult to know what tag to look for. Stepping down through the hierarchy from the high system level down to the detail of components is more intuitive. Furthermore, the hierarchy sometimes needs to change names, to help differentiate between components that were originally similarly named. Hierarchy changes makes that quick, updating all the tags on every page would be very slow.
Reading your prior thoughts on hierarchy, I feel the different perspectives are related to use-case:
Seeking and Advice
Do you have any advice on how to better organise our pages on bookstack? Trying to add artificial extra levels of hierarchy as part of the naming convention has been very awkward.
Suggestion
Two potential suggestions.
I think if the staff organisational separation could be done as a separate hierarchy system. That would leave the engineering teams to start at the shelves level. Using Bookstack's 3 levels purely for the system design, would be doable. The engineering team requirement is around 4 levels, so only minor inconvenience would be experienced bringing that down to 3 levels.
The other suggestion is to allow for around 4 depth hierarchy between pages. I agree there are many situations, where having the deep hierarchy is just letting people shoot themselves in the foot. This is especially the case where the wiki is being used at the small scale. However, it is limiting the scale that Bookstack can be used in, for the reasons I explained above.
Best Regards,
John Shield
@JohnShield commented on GitHub (Mar 6, 2024):
Hi Dan,
Another suggestion. In theory, you could get some artificial "Visual Hierarchy" simply with how you display the pages and chapters, by adding a simple option to indent the chapter/page colored bar. See the image below.
Visually it can provide the understanding of a level or two of extra hierarchy to the reader.
This has the drawback that if you move the parent page it doesn't move the subpages, so the content producers need to be conscious of page relationships when they move pages. It also can become confusing when there are 2 or more levels of visual hierarchy with 7 or more pages involved, as you can't minimize the visual hierarchy to reduce the page clutter.
Best Regards,
John
@WirtsLegs commented on GitHub (Mar 13, 2025):
This is definitely something I would love to see and is really the only thing holding me back from migrating to bookstack, otherwise the app looks and feels great and I would love to adopt it.
Regardless of what the levels are called the classic hierarchical approach to storing knowledge works extremely well, confluence is popular for a reason, some people get a little page-nest-happy but I've also seen a lot of spaces with 10+ layers that are all appropriate.
In one of my current use-cases I'm looking at documenting a large set of SOPs for which the current nesting limits simply won't work, really in every usecase I have in mind I'd likely need to go have more layers than bookstack supports.
@hakancunier commented on GitHub (Apr 10, 2025):
Come on! You should enable multiple levels this is really a must, then unwilling people don't have to use it. This is not a developers or system designers issue, it's content editors issue.
@zib-ctrl commented on GitHub (May 21, 2025):
At least one or more level would really be necessary.
The presentation of the navigation is a design problem that can be solved.
Without wanting to diminish the valuable / great work of the developer of this tool, the current basic layout of the navigation still has potential for improvement (e.g. why does the number of subpages have to be displayed as a separate menu item)?