Allow asciidoctor extensions when processing nav files and headers
There are several sites I'm aware of that have a section of documentation where the pages are all independent and need to be listed as an index, i.e. basically in alphabetic order. For instance the Apache Camel website has a "components" component where all the documentation is single pages each relating to one component. (there's a similar section in the user manual for eips). Currently the nav file for this is constructed by a script that scans the source directory, extracts the title, and outputs text into placeholders in a template.
It's easy enough to write a block macro to do this, using the content catalog as the source. This works nicely for having a list on a regular page, but the navigation builder blocks out all extensions from the asciidoc config. Why? An extension can certainly build the lists that end up in the nav, why is this prohibited?
Installing a global extension won't work, as at least the content catalog is needed to construct such a list.
The simplest solution is to just allow all the configured extensions to participate during nav building. Since there are a tiny number of nav pages compared to the whole site, this is likely to have a negligible performance impact. I can't see any downsides to this.
Alternatively, special configuration for nav extensions could be added to the playbook. This is a lot more work, but obviously possible.
And finally, an extensions parameter could be added to buildNavigation for use by custom pipelines. However, I suspect it would be more convenient to just fork antora at that point.
- added 18 July 2020:
Another use case for similar functionality is header processing. Antora now initially processes the document header (only) in order to make header attributes available for other pages. Other than the Antora include processor, no other extensions are registered. However, it's entirely reasonable to have an include processor that adds attributes from some other source than a direct include.