volto-eea-kitkat :chocolate_bar:

July 14, 2026 · View on GitHub

Volto Add-ons bundle - A known good set of Volto addons to be used within all EEA projects and beyond.

The eea.kitkat Plone add-on is the backend support for volto-eea-kitkat.

Upgrade

Upgrading to 33.x

This version line adds support for Volto 18 and is compatible with Volto 17+ projects.

Upgrading to 32.x

This version removes volto-chatbot dependency, thus you'll have to explicitly add it to your project's package.json if you still need it.

Upgrading to 25.x

This version adds support for Volto 17 and it is meant to be used with Volto 17+. It may work with Volto 16 but it is not fully backward compatible (especially in Teaser block, anchors, listing), thus upgrading volto-eea-kitkat to version 25+ implies also upgrading to Volto 17+.

Upgrading to 20.x

This versions comes with @eeacms/volto-tabs-block 17.x. See this package upgrade guide

Upgrading to 10.x

This version requires: @plone/volto >= 16.0.0.alpha.45 (Sentry removed from Volto Core).

Upgrading to 9.x

This version requires: @plone/volto >= 16.0.0.alpha.15 (volto-slate part of Volto Core).

Dropped dependencies (moved to Volto Core)

volto-slate
volto-block-toc

Volto EEA KitKat provides a set of generic Volto Add-ons and a Known Good Set of these add-ons versions to be used within your Volto projects without having to worry about which add-on version works best with another add-on.

While in other systems when you pin a package version to a specific number you will get that package version, in Javascript world is not that simple.

For this, Volto EEA Kitkat is using selective dependency resolutions. While this work as expected in most of the cases, you may still have some surprises.

Troubleshooting

Make sure your Volto project yarn.lock is not polluted. You can always reset your Volto project yarn.lock with:

 $ uvx cookieplone project
 $ cd project-title
 $ cp yarn.lock /path/to/my-volto-project/yarn.lock
 $ cd /path/to/my-volto-project
 $ yarn

Add-on resolutions don't work with workspaces (development mode), thus you'll need to define resolutions within Volto project. To tackle this issue, this Docker image automatically extracts resolutions from add-on and add them also to the Volto project before running tests.

Getting started

Try volto-eea-kitkat with Docker

  git clone https://github.com/eea/volto-eea-kitkat.git
  cd volto-eea-kitkat
  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-eea-kitkat 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-eea-kitkat": "*"
}

and volto.config.js:

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

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!

Release

See RELEASE.md.

How to contribute

See DEVELOP.md.

Secret Scanning

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
```

Do not add betterleaks:allow to real credentials.

Copyright and license

See LICENSE.md for details.

Funding

European Environment Agency (EU)