Tag support [Feature request]

Feature idea

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):

---
title: My Document
summary: A brief description of my document.
authors:
    - Waylan Limberg
    - Tom Christie
date: 2018-07-10
some_url: https://example.com*
tags:
    - dev
    - python
---

So it will create a endpoint http://mkdocs.org/tags/dev and http://mkdocs.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.

Related issues

There was already #759 and #1411.

In the old #759 issue, waylan and d0ugal said this feature was out of scope right now.
The feature request was severely lacking of argumentation and why this must be a core feature.
In this issue, waylan also said this feature would be better as a plugin (because he didn't see the need/use case for it to be in core) but this was before version 1.0 and the API was not existing yet. So at this time it was not even possible to make a plugin.
This issue was forgotten.

In the more recent #1411, plugin through the API is now possible and waylan said that frontmatter (meta-data) will allow a plugin to retrieve tags.
Bit he still suggest to create a plugin and don't see the need for tag support to be part of MkDocs. He also suggest it can be a theme dependant feature.

Why this would be a great feature?

I good real life example will be better to understand than pages of theoretical argumentation.

Imagine I want to build a hacking documentation with a tree like that (for, let's say, my OSCP exam preparation):

- Admin # Machines from the Admin network, containing a write-up for each machine
  - Machine 1 # tags: [eop,windows]
  - Machine 2 # tags: [network,linux]
  - ...
- Cheat sheets # for various topics
  - Elevation of Privilege # tags: [eop]
  - Metasploit # tags: [exploit]
  - MS SQL Server # tags: [mssql,windows]
  - Network # tags: [network]
  - PWK/OSCP Specific
  - Pivoting # tags: [pivoting,network]
  - ...
- Connectivity
  - Machines
  - PWK Lab
  - Remote desktop
  - ssh-hostkey # tags: [ssh]
- Dev # Machines from the Dev network, containing a write-up for each machine
  - Machine 1
  - Machine 2
  - ...
- Exam
  - Exam specific
  - ...
- IT # Machines from the IT network, containing a write-up for each machine
  - Machine 1
  - Machine 2
  - ...
- Public # Machines from the Public network, containing a write-up for each machine
  - Machine 1
  - Machine 2
  - ...
- Tools
  - Nmap # tags: [network,scanner]
  - John the ripper # tags: [cracking,password,hash]
  - gcc # tags: [compilation,exploit]
  - dnsrecon # tags: [osint,dns]
  - dnsenum # tags: [osint,dns]
  - cmsmap # tags: [cms,web]
  - ncat # tags: [backdoor,network,scanner]
  - recon-ng tags: [osint]
  - snmpwalk # tags: [snmp,network]
  - snmpbrute # tags: [snmp,network]
  - onesixtyone # tags: [snmp,network]
  - ...

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 teh 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 teh keywork but actually talking about it) when the tag feature will be manual so there will be only exact matches.

Why this shouldn't be theme dependant?

First of all this mean you will have to choose between:

1. A nice looking theme you love but which doesn't not implement tag support
2. An ugly theme you have but with the cool tag support

This will also mean that each theme creator will have to implement its own tag support, resulting in:

1. Much work for theme creators as they have to implement this feature
2. Duplicate efforts: instead of working on the theme they will have to work on features and the feature will be implemented several times
3. Incompatibility between:

• Themes with tags support and theme without tags support
• Themes with tags support between them as each theme will have its own way top implement it
• In general a full theme inconsistency

And finally why would a theme creator will implement a feature not provided by the core API?

And theme should be themes (CSS) not providing half the feature of the product.

Why this shouldn't be plugin based?

By making a plugin for providing this feature:

• Themes don't add supports for dozens and dozens of plugins, but tags support requires a theme handling it (to place the tag link on the page and special theme for the tag list page, and maybe a tag cloud on the sidebar) else it won't be usable
• Plugin quality is more likely to be less good than the core
• Plugin will be maintained by a third party, so it won't necessarily be update each time and quickly after MkDocs update. It may even never be maintained.

So in the end very few themes will support tags as a theme creator can't provide support for all plugins.
Imagine you want to create a Hexo theme, you definitely won't add support for the currently 295 existing hexo plugins.

Conclusion

Saying that it should be a plugin or theme dependant is killing the feature:

• The community is not big enough so that someone skilled already created a plugin or a theme
• The problems mentioned above (so if someone in the feature creates a plugin/theme either nobody will use it or lot of people will use some but great compatibility issues will arise)

So now, I wish everybody as understand the need of tag support (every static site generator has support for it so why no documentation static site generator has it?) and this feature to be part of the core. (I also hope you won't insta-close this issue as a wontfix).