volto-tabs-block

Volto add-on

Features

IMPORTANT! Because this depends on @eeacms/volto-block-style, you should always load this addon as the last addon in Volto project configuration or after @eeacms/volto-block-style.

Getting started

Try volto-tabs-block with Docker

  git clone https://github.com/eea/volto-tabs-block.git
  cd volto-tabs-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-tabs-block to your Volto project

1. Make sure you have a Plone backend up-and-running at http://localhost:8080/Plone

   docker compose up backend

2. Start Volto frontend

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

  "dependencies": {
      "@eeacms/volto-tabs-block": "*"
  }

  and volto.config.js:

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

• If not, create one with Cookieplone, as recommended by the official Plone documentation for Volto 18+:

  uvx cookieplone project
  cd project-title
  

  Then install the add-on in your frontend project. For Cookieplone-based Volto 18 and 19 projects, Plone documents pnpm usage:

  pnpm --filter <name-of-your-policy-add-on> add @eeacms/volto-tabs-block
  

  Then add @eeacms/volto-tabs-block to the addons key in your project's package.json or declare it in volto.config.js.

1. 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.

2. Go to http://localhost:3000

3. Happy editing!

Upgrade

Upgrading to 10.x

This version requires Volto >= 17.18 or Volto 18+. It removes the custom EditBlockWrapper and uses Volto's built-in block chrome provided by BlocksForm.

Breaking changes

• Removed EditBlockWrapper.jsx. Any code importing EditBlockWrapper from @eeacms/volto-tabs-block will break. Use Volto's built-in EditBlockWrapper from @plone/volto/components/manage/Blocks/Block/EditBlockWrapper if you need a custom wrapper.
• Removed custom edit toolbar styles. The edit.less styles that powered the custom inner block toolbar have been removed. Inner blocks now use Volto's default block chrome.

Upgrading to 7.0.0

Version 7 introduces the following breaking changes:

• The templates are now variations of the default template, so if you have custom templates, you need to update them to be variations of the default template.
• All variations have schema enhancers, see https://github.com/eea/volto-eea-website-theme/blob/develop/src/index.js#L40 for example on how to customize the variation schema.
• Some defaults have been changed, see the schema.js files for any default values.
• Tabs now have the ability to reference an Image or use a Semantic UI icon within the tab title, even allowing the hiding of the text title.
• Responsive template no longer uses react-responsive-tabs styles but use accordion classes when it's transformed into accordion. Bring your own style for the accordion if you want to customize it.
• Cleaned up styling in favor of Semantic UI styling and to bring your own styling.
• Better i18n support for the block especially in edit mode.

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:

1. 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');

2. 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]"
   }

3. 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

The Initial Owner of the Original Code is European Environment Agency (EEA). All Rights Reserved.

See LICENSE.md for details.

Funding

European Environment Agency (EU)