Contributing to the theme

This theme is a Quarto brand extension that provides a set of defaults and customisations on top of the base Bootstrap theme. It is used across DP-Next websites, so when making changes, be careful to avoid breaking things downstream.

Before adding custom CSS or JavaScript, check whether your change can be achieved through the theme files or existing Quarto or Bootstrap options—custom code can introduce accessibility issues and is harder to maintain.

Before you start

We recommend opening an issue to discuss proposed changes before working on them, especially for larger or more complex additions.

Theme structure

The theme lives entirely inside _extensions/dp-next-theme/. The two most important files are _brand.yml and _extension.yml.

`_brand.yml`

Controls the visual identity of the theme: fonts, colours, and custom CSS rules. Edit this file to change the theme’s appearance. We use fonts from Bunny, a privacy-friendly alternative to Google Fonts. See Quarto’s Brand Elements page for available options.

`_extension.yml`

Defines the theme metadata and site-wide defaults. The contributes section is where you can set defaults for all sites using the theme like the navbar logo, favicon, or footer text.

Adding logos

Logos live in _extensions/dp-next-theme/logos/. Add new logos there, then reference them in _extension.yml (for navbar or favicon) or directly in .qmd files in repositories using the theme.

Contributing changes

When contributing, make a pull request with your changes. For an introduction to the pull request and commit conventions we follow, see these chapters in the Seedcase guidebook:

Development setup

To test changes locally, clone the dp-next-theme repository and install the following tools:

The easiest way to install uv and just is with pipx:

pipx install uv rust-just

Then set up the pre-commit hooks with:

just install-precommit

Run just to see all available commands. The most common one is just run-all, which runs all checks and tests including building the site locally to check for errors.

Commits and pull requests

When committing changes, try to follow the Conventional Commits standard for your Git messages. This lets us auto-generate releases using Commitizen. If your commits don’t follow this convention, we’ll revise the pull request title before merging—we use squash merges, so all commits in a pull request are squashed into one.