Closed noraj closed 1 year ago
There are keywords in page configuration (https://hyperbook.openpatch.org/configuration/page) but they are used only for SEO, they could be re-used for that purpose displayed on each page and generating a tag index.
This sounds like a great feature and your explanation on how it should work is very reasonable. I will try to work on an implementation starting next week. 👍
Currently we have terms, which will show in the glossary (https://hyperbook.openpatch.org/elements/glossary). I will try to think about what both will differentiate or if I could combine them.
I think the glossary feature does cover this use-case. Here are the steps to reproduce the docker documentation.
a-page.md
# A Page
🏷: :t[standards], :t[compliance], :t[security]
Then you have to create three pages in the glossary folder:
glossary/standards.md
# Standards
A brief description.
glossary/compliance.md
# Compliance
Another brief description.
glossary/security.md
# Security
All about security.
At the end of each glossary page, all referenced sites will be displayed.
I have a few remarks:
hyperbook.md
glossary to hyperbook2.md
and change the frontmatter to name: Hyperbook2
I get a 404 on http://localhost:3000/glossary/hyperbook2. (I was using the CLI getting started install). Update:I needed to remove vdirectory.book.json
and vdirectory.glossary.json
to make it work so those files are recreated because even killing and re-lauching npx hyperbook dev
doesn't work.:t[hyperbook2]
in the content instead of a node in the frontmatter. One doesn't necessary want to display it in the content, also it doesn't make tags re-usable for other features or plugins. It also prevent from making a theme where the tags are automatically displayed on a specific place.It looks like the actual implementation of glossary is a glossary and does not really answer the tag need.
Adding tags (keywords) in frontmatter (meta-data) will generate a page referencing all pages containing this page.
Example:
In frontmatter you add (in YAML for example):
So it will create an endpoint http://example.org/tags/dev and http://example.org/tags/python referencing, respectively, all pages containing the dev tag and the python tag.
Then on the page of the documentation where there is such a tags frontmatter, the page will contain some tag link #dev and #python respectively referencing the previously mentioned endpoints.
Example on my blog using Hexo:
Why
Imagine I want to build a hacking documentation with a tree like that (for, let's say, my OSCP exam preparation):
So I want to be able to search for a keyword (tag) like snmp and see all machines write-up where I attacked snmp, all cheat sheets explaining snmp stuff, all tools I can use to exploit snmp, etc.
Without tag support this is impossible.
One could say: "But there is already the search feature parsing the content of pages" yeah but this is automatic and introduce a lot of false positive (content containing a keywork but not really about it) and false negative (content not containing the keywork but actually talking about it) when the tag feature will be manual so there will be only exact matches.
I could also provide argumentation Why this shouldn't be theme dependent or plugin based. Some big companies like Docker, Joomla, or the Mozilla foundation are using documentation with tags.