volto-columns-block
Volto add-on
Features
This package gives you a block with columns. Each column is its own separate blocks container.

Getting started
Try volto-columns-block with Docker
git clone https://github.com/eea/volto-columns-block.git
cd volto-columns-block
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-columns-block to your Volto project
For Volto 18 and newer, create projects with Cookieplone. See the official Plone documentation: Install Plone with Cookieplone and Install an add-on in Volto 18 and 19.
-
If you do not already have a project, create one:
uvx cookieplone project cd project-title make install -
Install the add-on in your Volto project:
pnpm --filter <name-of-your-policy-add-on> add @eeacms/volto-columns-block -
Add the add-on to
volto.config.js:const addons = ['@eeacms/volto-columns-block']; -
Start Plone:
make backend-start make frontend-start -
Go to http://localhost:3000
-
Happy editing!
For legacy Volto 17 projects, keep using the yarn-based Volto 17 workflow.
Upgrade
Upgrading to 9.x
This version requires
Volto >= 17.18orVolto 18+. It removes the customEditBlockWrapperand uses Volto's built-in block chrome provided byBlocksForm.
Breaking changes
- Removed
EditBlockWrapper.jsx. Any code importingEditBlockWrapperfrom@eeacms/volto-columns-blockwill break. Use Volto's built-inEditBlockWrapperfrom@plone/volto/components/manage/Blocks/Block/EditBlockWrapperif you need a custom wrapper. - Moved the column-settings button into the block sidebar. The floating
column.svgicon button that appeared over each column in edit mode has been removed. Column settings are now accessible directly from the block sidebar via theColumnsWidget. ColumnsBlockSchemasignature changed.ColumnsBlockSchemanow receives a single object{ intl, formData }instead of justintl. Any code callingColumnsBlockSchema(intl)must be updated toColumnsBlockSchema({ intl, formData }).
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_URLSMTP_PORT(optional, defaults to25)SMTP_EMAILSMTP_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 secretscheck 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-reportartifact. 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:allowon the same line and include a short explanation in the pull request.const testPassword = 'admin'; //betterleaks:allowpassword: "admin" #betterleaks:allow
Do not add betterleaks:allow to real credentials.
Copyright and license
The Initial Owner of the Original Code is European Environment Agency (EEA). All Rights Reserved.
See LICENSE.md for details.