Hierarchical tag support #5175

New Issue

OVERLORD · 2026-02-05T09:46:13+03:00

OVERLORD commented

2026-02-05 09:46:13 +03:00

Originally created by @DoctorRetromaker on GitHub (Feb 10, 2025).

Describe the feature you'd like

As books are structured in a real hierarchy -«books» -> «chapters» -> «pages»-, in order to go deeper with «tag hacking», I suggest to respect the tags inheritance up to down.

Used in this way, the «global tag hacking» should be made at «book» level -tags set in the book attributes should be added to the section of every «chapter»-

Tags set for each «chapter» should be inherited for every «page», along with the global «book» and the specific «page» ones.

Describe the benefits this would bring to existing BookStack users

Customization could be easier setting «tag hacking» in a hierarchical way, so for a global hack, the user only needs to ad a tag at «book» level, instead of repeat the tag for each page.

Same when the hacking is only need to be applied al «chapter» level.

Currently, "tags" are stored as a "per entity" attribute, so there is no one-to-many relationship between tags; it might be a good time to change this management and establish a real one-to-many relationship between "tags" and "entities".

Can the goal of this request already be achieved via other means?

I don't think so

Have you searched for an existing open/closed issue?

I have searched for existing issues and none cover my fundamental request

How long have you been using BookStack?

3 months to 1 year

Additional context

The main drawback is setting up a method for inheritance:

The easy way is to copy all the tags from the "parent" object when any item is created; this could affect the result for which the tags were originally intended: tagged searches
After checking DB content, pages are stored without <HTML>, <HEAD> nor sections, so these must be added at «rendering time»; depending on how the tag search algorithm has been implemented, adding the legacy tags within the rendering process avoids any collision between both mechanisms, search and hacking

Originally created by @DoctorRetromaker on GitHub (Feb 10, 2025). ### Describe the feature you'd like As books are structured in a real hierarchy -«books» -> «chapters» -> «pages»-, in order to go deeper with «tag hacking», I suggest to respect the tags inheritance up to down. Used in this way, the «global tag hacking» should be made at «book» level -tags set in the book attributes should be added to the <BODY> section of every «chapter»- Tags set for each «chapter» should be inherited for every «page», along with the global «book» and the specific «page» ones. ### Describe the benefits this would bring to existing BookStack users Customization could be easier setting «tag hacking» in a hierarchical way, so for a global hack, the user only needs to ad a tag at «book» level, instead of repeat the tag for each page. Same when the hacking is only need to be applied al «chapter» level. Currently, "tags" are stored as a "per entity" attribute, so there is no one-to-many relationship between tags; it might be a good time to change this management and establish a real one-to-many relationship between "tags" and "entities". ### Can the goal of this request already be achieved via other means? I don't think so ### Have you searched for an existing open/closed issue? - [x] I have searched for existing issues and none cover my fundamental request ### How long have you been using BookStack? 3 months to 1 year ### Additional context The main drawback is setting up a method for inheritance: 1. The easy way is to copy all the tags from the "parent" object when any item is created; this could affect the result for which the tags were originally intended: tagged searches 2. After checking DB content, pages are stored without <HTML>, <HEAD> nor <BODY> sections, so these must be added at «rendering time»; depending on how the tag search algorithm has been implemented, adding the legacy tags within the rendering process avoids any collision between both mechanisms, search and hacking

OVERLORD added the 🔨 Feature Request label 2026-02-05 09:46:13 +03:00

OVERLORD closed this issue

2026-02-05 09:46:15 +03:00

OVERLORD commented

2026-02-05 09:46:16 +03:00

@Hallsie commented on GitHub (Feb 14, 2025):

Question: Are the tags "hard coded" meaning you cannot change them?

For example if we are in the shelf: Woodworking Book: Cabinets Chapter: Doors and let's just say those are also tags then when I create a page in the Doors chapter it will have Woodworking, Cabinets, Doors tags and obviously I can add more. Are you suggesting that those would be hard coded in there? Let's say for example I have a page that I want to put in there that is about Hinges and I want to use an include {{@65}} for that page. Can I remove the tags because it doesn't really go or are they stuck because inheritance would force them?

Another example would be temporary tags that I use to remind myself of things I wish to do like in a chapter I may have a tag that says "add pictures" to let me know that I need to come back and add pictures to this chapter but the page I am moving into the chapter may not need that and I don't want it.

@Hallsie commented on GitHub (Feb 14, 2025): Question: Are the tags "hard coded" meaning you cannot change them? For example if we are in the shelf: Woodworking Book: Cabinets Chapter: Doors and let's just say those are also tags then when I create a page in the Doors chapter it will have Woodworking, Cabinets, Doors tags and obviously I can add more. Are you suggesting that those would be hard coded in there? Let's say for example I have a page that I want to put in there that is about Hinges and I want to use an include {{@65}} for that page. Can I remove the tags because it doesn't really go or are they stuck because inheritance would force them? Another example would be temporary tags that I use to remind myself of things I wish to do like in a chapter I may have a tag that says "add pictures" to let me know that I need to come back and add pictures to this chapter but the page I am moving into the chapter may not need that and I don't want it.

OVERLORD commented

2026-02-05 09:46:18 +03:00

@DoctorRetromaker commented on GitHub (Feb 15, 2025):

Yes, one implementation option is to inherit all father tags ... other approach is to use a hardcoded syntax similar to "hack-......." and only inherit these kind of tags, despite this last option sounds excessively tricky and unclear for user ... I think the main problem at the implementation level will be how to handle hierarchical changes, that is, how to transfer a change at the parent level to children and grandchildren.

I think tags inheritance is a help to do «tags hacks», for example, when a global hack would force to add those «hacking-tags» on each page along the book by hand ..

Regarding your example, there is no option to "add pictures" at chapter or book level, so this kind of tags are page level ... isn't?

To avoid "hack-tags" showed in "tags-search", I'm, using a CSS "display:none" applied to classes starting "tag-name-hack....."

@DoctorRetromaker commented on GitHub (Feb 15, 2025): Yes, one implementation option is to inherit all father tags ... other approach is to use a hardcoded syntax similar to "hack-......." and only inherit these kind of tags, despite this last option sounds excessively tricky and unclear for user ... I think the main problem at the implementation level will be how to handle hierarchical changes, that is, how to transfer a change at the parent level to children and grandchildren. I think tags inheritance is a help to do «tags hacks», for example, when a global hack would force to add those «hacking-tags» on each page along the book by hand .. Regarding your example, there is no option to "add pictures" at chapter or book level, so this kind of tags are page level ... isn't? To avoid "hack-tags" showed in "tags-search", I'm, using a CSS "display:none" applied to classes starting "tag-name-hack....."

OVERLORD commented

2026-02-05 09:46:21 +03:00

@Hallsie commented on GitHub (Feb 17, 2025):

Regarding your example, there is no option to "add pictures" at chapter or book level, so this kind of tags are page level ... isn't?

There is an option for "Book Tags" as well as "Chapter Tags" but generally I tag the pages and not book/chapter. If I were doing an import though of something then I may want to use that if say pictures were not coming in via copy/paste etc. Even then I could still just do it on each page.

@Hallsie commented on GitHub (Feb 17, 2025): > Regarding your example, there is no option to "add pictures" at chapter or book level, so this kind of tags are page level ... isn't? There is an option for "Book Tags" as well as "Chapter Tags" but generally I tag the pages and not book/chapter. If I were doing an import though of something then I may want to use that if say pictures were not coming in via copy/paste etc. Even then I could still just do it on each page.

OVERLORD commented

2026-02-05 09:46:23 +03:00

@Hexodus commented on GitHub (Jun 24, 2025):

I back this request. The current tag behaviour isn't logical. If I apply a tag on the book level, I expect it to be inherited/present also in the chapter and page as well.

My current use case:
I wrote a frontend script to add references from Zotero. As I also write in different languages, the references need to be adjusted to the book's language. So I thought to use a content tag on the book level (locale: fr) and expected it to be present on every level of this book. But unfortunately, it's not being rendered anywhere else except on the book level.

That's a bummer – global tags or tag inheritance would have so much more utility.

@Hexodus commented on GitHub (Jun 24, 2025): I back this request. The current tag behaviour isn't logical. If I apply a tag on the book level, I expect it to be inherited/present also in the chapter and page as well. My current use case: I wrote a frontend script to add references from Zotero. As I also write in different languages, the references need to be adjusted to the book's language. So I thought to use a content tag on the book level (locale: fr) and expected it to be present on every level of this book. But unfortunately, it's not being rendered anywhere else except on the book level. That's a bummer – global tags or tag inheritance would have so much more utility.

OVERLORD commented

2026-02-05 09:46:24 +03:00

@ssddanbrown commented on GitHub (Jun 24, 2025):

I've assigned #5217 to the next feature request as I've been meaning to add that for a while.
That should address the need in customization/hack use as requested here, and as mentioned in #5476.

Otherwise I wouldn't be keen on changing up tags themselves with inheritance, especially just for hack/customization use, and therefore I'm going to close this off with the view of #5217 being the implementation approach for the fundamental needs here.

@ssddanbrown commented on GitHub (Jun 24, 2025): I've assigned #5217 to the next feature request as I've been meaning to add that for a while. That should address the need in customization/hack use as requested here, and as mentioned in #5476. Otherwise I wouldn't be keen on changing up tags themselves with inheritance, especially just for hack/customization use, and therefore I'm going to close this off with the view of #5217 being the implementation approach for the fundamental needs here.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#5175