Templating — Sphinx documentation

Templating is a method of generating HTML pages by combining static templates with variable data. The template files contain the static parts of the desired HTML output and include special syntax describing how variable content will be inserted. For example, this can be used to insert the current date in the footer of each page, or to surround the main content of the document with a scaffold of HTML for layout and formatting purposes. Doing so only requires an understanding of HTML and the templating syntax. Knowledge of Python can be helpful, but is not required.
Templating uses an inheritance mechanism which allows child templates files (e.g. in a theme) to override as much (or as little) of their ‘parents’ as desired. Likewise, content authors can use their own local templates to override as much (or as little) of the theme templates as desired.
The result is that the Sphinx core, without needing to be changed, provides basic HTML generation, independent of the structure and appearance of the final output, while granting a great deal of flexibility to theme and content authors.
Sphinx uses the Jinja templating engine for its HTML templates. Jinja is a text-based engine, inspired by Django templates, so anyone having used Django will already be familiar with it. It also has excellent documentation for those who need to make themselves familiar with it.
No. You have several other options:
You can write a TemplateBridge subclass that calls your template engine of choice, and set the template_bridge configuration value accordingly.
You can write a custom builder that derives from StandaloneHTMLBuilder and calls your template engine of choice.
You can use the PickleHTMLBuilder that produces pickle files with the page contents, and postprocess them using a custom tool, or use them in your Web application.
The default templating language in Sphinx is Jinja. It’s Django/Smarty inspired and easy to understand. The most important concept in Jinja is template inheritance, which means that you can overwrite only specific blocks within a template, customizing it while also keeping the changes at a minimum.
To customize the output of your documentation you can override all the templates (both the layout templates and the child templates) by adding files with the same name as the original filename into the template directory of the structure the Sphinx quickstart generated for you.
Sphinx will look for templates in the folders of templates_path first, and if it can’t find the template it’s looking for there, it falls back to the selected theme’s templates.
A template contains variables, which are replaced with values when the template is evaluated, tags, which control the logic of the template and blocks which are used for template inheritance.
Sphinx’s basic theme provides base templates with a couple of blocks it will fill with data. These are located in the themes/basic subdirectory of the Sphinx installation directory, and used by all builtin Sphinx themes. Templates with the same name in the templates_path override templates supplied by the selected theme.
For example, to add a new link to the template area containing related links all you have to do is to add a new template called layout.html with the following contents:
By prefixing the name of the overridden template with an exclamation mark, Sphinx will load the layout template from the underlying HTML theme.
If you override a block, call {{ super() }} somewhere to render the block’s original content in the extended template – unless you don’t want that content to show up.
The builtin basic theme supplies the templates that all builtin Sphinx themes are based on. It has the following elements you can override or use:
The following blocks exist in the layout.html template:
The doctype of the output format. By default this is XHTML 1.0 Transitional as this is the closest to what Sphinx and Docutils generate and it’s a good idea not to change it unless you want to switch to HTML 5 or a different but compatible XHTML doctype.
This block adds a couple of <link> tags to the head section of the template.
This block is empty by default and can be used to add extra contents into the <head> tag of the generated HTML file. This is the right place to add references to JavaScript or extra CSS files.
This block contains the relation bar, the list of related links (the parent documents on the left, and the links to index, modules etc. on the right). relbar1 appears before the document, relbar2 after the document. By default, both blocks are filled; to show the relbar only before the document, you would override relbar2 like this:
Inside the relbar there are three sections: The rootrellink, the links from the documentation and the custom relbaritems. The rootrellink is a block that by default contains a list item pointing to the root document by default, the relbaritems is an empty block. If you override them to add extra links into the bar make sure that they are list items and end with the reldelim1.
The contents of the document itself. It contains the block “body” where the individual content is put by subtemplates like page.html.
In order for the built-in JavaScript search to show a page preview on the results page, the document or body content should be wrapped in an HTML element containing the role="main" attribute. For example:
A possible location for a sidebar. sidebar1 appears before the document and is empty by default, sidebar2 after the document and contains the default sidebar. If you want to swap the sidebar location override this and call the sidebar helper:
(The sidebar2 location for the sidebar is needed by the sphinxdoc.css stylesheet, for example.)
The logo location within the sidebar. Override this if you want to place some content at the top of the sidebar.
The block for the footer div. If you want a custom footer or markup before or after it, override this one.
The following four blocks are only used for pages that do not have assigne