Hey! I use Zola to build documentation sites.
I’ve run into a recurring problem, solved it for my internal use and now wondering if this is something worth contributing back upstream.
So I’ve been working on an audiences feature. The idea: tag content with named audiences in front matter, and each build declares which audiences it serves.
No audience overlap = content never generated.
This serves me well in a use-case where a complete set of docs is maintained for the project crew, a subset thereof is exposed to internal customers and yet another
subset is exposed to external customers.
Well, for two audiences, one could probably misuse Zola’s draft flag, which is binary (in or out) but I wanted something that is clearly meant to control: “expose content to this audience but not that”.
Here’s the sketch of the implementation:
- add
audiences: Option<Vec<String>>toConfigandSerializedConfig - add
audiences: Option<Vec<String>>toPageFrontMatterandSectionFrontMatter - modify
Site::load()to do some filtering whenconfig.audiencesis assigned. - filter pages/sections according rules:
- feature off by config → include item
- item is root section → include item (as it is critical)
- item has no audiences assigned → exclude with warning
- item has audiences which overlap with
config.audiences→ include item - item has audiences but no overlap → exclude item
- effect is simple:
- excluded pages are skipped
- excluded sections are skipped including their subtrees
As config.audiences is automatically available in all Tera templates and shortcodes, page/section content can be suppressed depending on the active audience(s). For example, we can suppress output of certain paragraphs which reference restricted pages/sections.
Would create a PR if there is interest in having this feature upstream.