LB Tabs & Accordion adds a single Layout Builder section plugin that splits its content into labelled sub-sections, displayed either as tabs or as an accordion.

Each sub-section is a real Layout Builder region, so an editor places any number of blocks into it exactly as in any core layout. The section configuration form lets a site builder pick the display mode, the number of sub-sections (1 to 10), their labels, and reorder them with core's #tabledrag.

Code to review

  • src/Plugin/Layout/TabsAccordionLayout.php — the Layout plugin: attribute definition, defaultConfiguration(), setConfiguration(), buildConfigurationForm() with an AJAX-rebuilt #tabledrag table, validateConfigurationForm(), submitConfigurationForm().
  • lb_tabs_accordion.module — hook_preprocess_layout() building the ordered sub-section list handed to Twig.
  • config/schema/lb_tabs_accordion.schema.yml — full config schema for the plugin settings.
  • tests/ — Unit, Kernel and Functional coverage (13 tests, 103 assertions).

How it differs from similar projects

Several modules already cover tabs and/or accordions in Layout Builder. The differences are deliberate, not accidental:

  • Layout Builder: Tabs and Accordion — the closest project. It depends on the contributed jquery_ui_tabs and jquery_ui_accordion modules (see its lb_tabs.info.yml and lb_tabs.libraries.yml on the 3.0.x branch), i.e. on jQuery UI, which core removed. This module ships no third-party library at all: interactivity is a small vanilla-JS Drupal.behaviors file per component, using core/once only.
  • Layout Builder Accordion — one block equals one accordion item, with the block title used as the accordion header. Here one region equals one sub-section, so a sub-section can hold several blocks, and its label is set explicitly in the section form rather than inherited from a block title.
  • Accordion for Layout Builder — scoped to the YMCA Website Services distribution; accordion only.
  • Layout Kit — a broad set of layouts (columns, tabs, accordions, "conmutator") with styling options. This module is the opposite trade-off: one layout, no styling options at all.

Two further design choices worth flagging for the review:

  1. No style options whatsoever — no colour, spacing, typography or free-form attribute fields. Styling is delegated to UI Styles (its ui_styles_layout_builder sub-module already adds class pickers to every section and region, including this one, with no code in this module) or to the active theme. Block restrictions are likewise delegated to Layout Builder Restrictions, which can target the stable region names subsection_1..subsection_10.
  2. Each display mode is a Single Directory Component (components/tabs/, components/accordion/), so its CSS/JS is attached only when that mode actually renders, and a theme can override either one independently via replaces: lb_tabs_accordion:tabs.

The markup follows the WAI-ARIA Authoring Practices Tabs and Disclosure patterns (role="tablist", role="tab", role="tabpanel", roving tabindex, aria-expanded). Inside Layout Builder's own edit screen the module detects core's in_preview signal and renders every sub-section at once, reusing core's region styling, so an editor can see which sub-sections already hold blocks without clicking through each tab.

Checklist

  • The project is a full project (not a sandbox), created and maintained under my individual account, with the code committed on the 1.0.x branch.
  • I do not already have the vetted role, and this is my only open application.
  • All code is my own, GPLv2-or-later, with no third-party assets (no vendored JS, CSS or fonts) — nothing that needs a licensing exception.
  • No version:, project: or datestamp: keys in the .info.yml, and no LICENSE.txt committed; both are left to the packager.
  • The repository contains a README covering introduction, requirements, recommended modules, installation, configuration, theming, an FAQ and maintainers, and the project page carries the same information.
  • The GitLab CI pipeline (.gitlab-ci.yml with OPT_IN_TEST_NEXT_MINOR and OPT_IN_TEST_MAX_PHP) is green on the branch head: pipeline 945043 — phpcs with Drupal + DrupalPractice, phpstan, cspell, eslint, stylelint, composer-lint, and phpunit across the three build matrices.
  • Automated tests: 13 tests / 103 assertions across Unit, Kernel and Functional levels; the Functional test drives the real "Manage layout" admin screens rather than only building objects programmatically.

Project link

https://www.drupal.org/project/lb_tabs_accordion

Comments

m.anoune created an issue. See original summary.

vishal.kadam’s picture

vishal.kadam
Location Mumbai
commented
Issue summary: View changes
avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

Thank you for applying!

Before giving links helpful to understand how the review process works, what to expect from a review, and what to do to avoid a review takes more time than needed, I would like to thank all the reviewers for the work they do.
These applications are volunters-driven, which also means it is not possible to predict when an application will be marked fixed and the applicant will get the permission to opt projects into security advisory policy. While we aim to make an application as quick as possible, it is also important for us that more people review the project used for an application. In this way, we make sure applications do not miss some important points that should be instead reported.
Applications are not meant to be complete debugging sessions that eliminate every existing bug, though. I apologize if sometimes applications seem to go into too-detailed reviews.

Please read Review process for security advisory coverage: What to expect for more details and Security advisory coverage application checklist to understand what reviewers look for. Tips for ensuring a smooth review gives some hints for a smoother review.

The important notes are the following.

  • If you have not done it yet, you should enable GitLab CI for the project and fix the PHP_CodeSniffer errors/warnings it reports.
  • For the time this application is open, only your commits are allowed.
  • The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status will not be changed by this application; once this application is closed, you will be able to change the project status from Not covered to Opt into security advisory coverage. This is possible only 14 days after the project is created.

    Keep in mind that once the project is opted into security advisory coverage, only Security Team members may change coverage.
  • Only the person who created the application will get the permission to opt projects into security advisory coverage. No other person will get the same permission from the same application; that applies also to co-maintainers/maintainers of the project used for the application.
  • We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.

To the reviewers

Please read How to review security advisory coverage applications, Application workflow, What to cover in an application review, and Tools to use for reviews.

The important notes are the following.

  • It is preferable to wait for a project moderator before posting the first comment on newly created applications. Project moderators will do some preliminary checks that are necessary before any change on the project files is suggested.
  • Reviewers should show the output of a CLI tool only once per application.
  • It may be best to have the applicant fix things before further review.

For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Status: Needs review » Needs work

The comparison with similar projects needs to be part of the project page.