Skip to content

Third-party plugins

We have conducted a quantitative and a qualitative analysis of third-party MkDocs plugins by analyzing the top 1,000 repositories on GitHub that use Material for MkDocs, as well as MkDocs' plugin catalog. From this, we have identified functionality that Zensical commits to provide natively.

Zensical Spark

Rather than simply reimplementing existing third-party plugins, we're taking a fresh approach:

Zensical Spark is our collaborative space where, together with our professional users, we reimagine these features from the ground up. We iterate over ideas with our members, validate design concepts, and ensure new functionality integrates seamlessly with Zensical's differential architecture.

Join us in building the next generation of documentation tools!

What we'll cover

We intend to implement the functionality provided by the following MkDocs plugins:

mkdocstrings

The mkdocstrings plugin provides support for building API documentation. We are fortunate to have the author or mkdocstrings, Timothée Mazzucotelli (aka @pawamoy), on our team and are working together to produce a Zensical module for API documentation.

There are several MkDocs plugins that serve to include information from the Git version control system in pages, specifically git-revision-date-localized, git-authors and git-committers, which allow to render source-related info on a page. All of this will be integrated natively into Zensical.

macros plugin

The macros plugin is quite versatile and serves a range of purposes united by the fact that part of the content of a page is computed. Zensical will offer this functionality through a much more flexible and powerful component system.

minify plugin

The minify plugin reduces the size of HTML, CSS, and JavaScript files before they are written to the output directory. Of course, Zensical will support this functionality natively, among other optimizations like image compression and downloading for self-hosting.

mike (versioning)

The mike utility allows documentation for multiple software versions to be managed. It is tied to publishing documentation on GitHub, and as mentioned above, we are looking forward to support more options for publishing your site.

Additionally, we believe other aspects of version handling could be improved, such as workflows for maintaining documentation for older but supported releases.

awesome-nav / literate-nav

The awesome-nav and literate-nav plugins provide similar ways to define navigation outside the configuration file, making navigation first-class content. They offer various methods to automatically construct navigation structure using glob patterns while providing control over aspects like sort order.

With Zensical, we're taking the opportunity to rethink navigation, offering significantly improved flexibility for authors in designing information architecture and modular navigation structures.

static-i18n

The static-i18n plugin provides support for authoring documentation in multiple languages and letting users switch between them.

Zensical will offer native support for multi-lingual sites. As with navigation, we will be taking the opportunity to rethink internationalization to ensure we design this functionality with enough degrees of freedom to cover the widest possible range of user needs.

Other plugins

For the above plugins, we can specify a concrete plan for how their features will be realized in the Zensical ecosystem. This is not an exhaustive list, which means we'll be moving more functionality into Zensical over time.

Of course, there are many more plugins that we cannot possibly all cover. This is why the module system is the top-most item on our roadmap besides aiming for feature parity. It will enable third parties to develop modules that extend Zensical's functionality, based on its powerful differential architecture.

We will, of course, continue to develop our roadmap and discuss possible changes with our members in Zensical Spark, maximizing user value at all times.