volto-taxonomy

July 14, 2026 · View on GitHub

Features

Edit collective.taxonomy entries via Volto Site Setup > Taxonomies

Getting started

Try volto-taxonomy with Docker

  git clone https://github.com/eea/volto-taxonomy.git
  cd volto-taxonomy
  make
  make start

Go to http://localhost:3000

make start now defaults to Volto 18. To run the same setup against Volto 17, use:

  VOLTO_VERSION=17 make
  VOLTO_VERSION=17 make start

Add volto-taxonomy to your Volto project

Make sure you have a Plone backend up-and-running at http://localhost:8080/Plone
```
docker compose up backend
```
Start Volto frontend

If you already have a volto project, just update package.json:

"dependencies": {
    "@eeacms/volto-taxonomy": "*"
}

and volto.config.js:

const addons = ['@eeacms/volto-taxonomy'];

If not, create one with Cookieplone, as recommended by the official Plone documentation for Volto 18+:
```
uvx cookieplone project
cd project-title
```

Install or update dependencies, then start the project:
```
make install
```
For a Cookieplone project, start the backend and frontend in separate terminals:
```
make backend-start
make frontend-start
```
For a legacy Volto 17 project, install the package with yarn and restart the frontend as usual.
Go to http://localhost:3000
Happy editing!

This repository uses the Betterleaks GitHub Action to scan the current repository content on every push and pull request. The scan uses the rules in .gitleaks.toml and uploads a betterleaks-report artifact when a finding is detected.

If the optional SMTP secrets are configured, failed scans also send an email to the last commit committer. The workflow expects these repository or organization secrets:

SMTP_URL
SMTP_PORT (optional, defaults to 25)
SMTP_EMAIL
SMTP_PASSWORD (optional if the SMTP server does not require authentication)

Port 465 is sent with direct TLS; other ports use the default SMTP handshake. The email includes a short finding summary from the redacted Betterleaks report, including the redacted matched line from each finding.

There are three common outcomes:

Everything is OK. The Betterleaks / Scan for secrets check is green and no action is needed. Regular references to runtime values are OK, for example:
```
const tokenFromCookie = req.universalCookies.get('auth_token');
```
A real secret was found. The check is red and the workflow log asks you to download the betterleaks-report artifact. Open the artifact from the GitHub Actions run and check the reported file, line and rule. Remove the committed value, move it to the proper secret store, and rotate it if it was exposed. A report entry looks like this:
```
{
  "RuleID": "secret-literal-assignment",
  "File": "src/config.js",
  "StartLine": 12,
  "Secret": "[REDACTED]"
}
```
The finding is a false positive. Keep the value only if it is clearly not sensitive, such as a test fixture, placeholder, or public example. Add betterleaks:allow on the same line and include a short explanation in the pull request.
```
const testPassword = 'admin'; //betterleaks:allow
```
```
password: "admin" #betterleaks:allow
```