Paragraphs Bundles is a suite of ready-made Drupal Paragraph types — layout columns, cards, carousels, accordions, tabs, modals, alerts and media grids — whose colours, borders, spacing and shadows an editor sets on a Display tab, without asking a themer for a line of CSS.
The suite was rewritten for version 2, and the rewrite changed things that matter before you upgrade. This page states what the code says today, read from the module source rather than from the project page: the paragraphs_bundles.info.yml file declares core_version_requirement: ^11.3 || ^12, and composer.json requires php: >=8.3. If your site is on Drupal 10, or on 11.0 to 11.2, version 2 will not install. That is the single fact most likely to change your plan for the afternoon.
What is actually in the package
The suite ships as a small parent module plus one sub-module per bundle family. Counted from the source on 14 September 2026, there are 26 sub-modules under modules/paragraph_bundle_*, and between them they define 39 paragraph types (39 distinct paragraphs.paragraphs_type.*.yml files). A twenty-seventh sub-module, Paragraphs Bundles AI, is optional and separate.
You enable only the families you use. A site that needs column layouts and cards enables three sub-modules and gets four or five paragraph types on the Add Paragraph button, not thirty-nine — an unfiltered list of every bundle is a usability problem, not a feature.
The declared dependencies, read from paragraphs_bundles.info.yml, are core's field, file, filter, link, media, options and text, plus three contributed projects: Paragraphs, Entity Reference Revisions and Field Group. There is no jQuery anywhere in the package — a search of every .libraries.yml and .js file in the suite returns no jQuery reference at all.
If you want to see a bundle being built before you install anything, the introduction tutorial walks through the first paragraph end to end, and the layout bundle tutorial covers one, two and three column sections.
Three things version 2 changed
Class names follow a BEM grammar now
Version 1 shipped names you could not predict: pb__accor-wrap, pb__caro-item, paragraph__inner. Version 2 renames them to a derivable grammar — pb-accordion, pb-carousel__slide, pb-ui-inner — with structural classes as pb-{block}__{element}--{modifier} and utilities as pb-u-{family}--{modifier}.
This is the change that breaks themes, and it breaks them silently. A selector that no longer matches does not throw an error; it simply stops applying. If your theme overrides Paragraphs Bundles classes, the migration map shipped in the module's docs/ directory is the thing to work through before you upgrade, not after.
Editor colours are stylesheets, not inline styles
Version 1 wrote the editor's colour choices into a style attribute. Twig's HTML escaping does not neutralise brackets, colons or semicolons inside a style attribute, so a crafted value could break out of the declaration. Version 2 writes one small CSS file per paragraph instead, and validates colours twice: the field type rejects anything that is not a hex literal or an r, g, b triplet, and the CSS builder re-validates independently, because config import and direct database writes bypass entity validation. A colour that fails emits no declaration at all.
The supported Drupal range moved
Version 1 used APIs that Drupal 12 removed, so the suite moved to the attribute-based plugin and hook APIs — which is why the floor is ^11.3. The upgrade is one-way and has a prerequisite: your site must already be on the last 1.x release.
What an editor can change on the Display tab
Take the One Column bundle, read from its shipped field configuration. The Display tab exposes background colour and hover, background opacity, text colour and hover, link colour and hover, border, border colour, border hover, border radius, margin, padding, box shadow, width, and a free-text extra CSS classes field. The Content tab holds title, title tag, title alignment and the body field.
The extra classes field is the pressure valve that keeps this maintainable. Its own help text says it best: the classes you type are added to the ones the paragraph already has, never replacing them. Put the same class on every One Column section and a single rule in your theme styles all of them — which is how you stop a site drifting into forty individually-coloured sections that nobody can rebrand later.
Responsive behaviour is handled in the shipped CSS on a five-step scale. Measured across the 70 stylesheets in the package, the breakpoints are 36rem, 48rem, 62rem, 75rem and 87.5rem — 576, 768, 992, 1200 and 1400 pixels. The same files also carry prefers-reduced-motion, prefers-contrast, forced-colors and print rules, which is unusual in a paragraph suite and worth knowing if accessibility is on your acceptance criteria.
Getting content in without typing it twice
The hard part of adopting a paragraph suite is rarely the first page — it is the eighty existing ones. PB Import creates nodes and paragraphs from a CSV file, and its info.yml declares core_version_requirement: ^11.3 || ^12, matching the parent. The CSV import walkthrough shows the file format.
One thing to decide before you import anything: whether a piece of content belongs in a paragraph at all. Reusable content that appears on many pages is usually a block, not a paragraph, and getting that wrong is expensive to unpick later — the reasoning is set out in blocks versus block content.
The optional AI sub-module, and why it is separate
Paragraphs Bundles AI lets an editor describe a section and have it created and filled, through the contributed AI module. It is deliberately a separate download, and its info.yml explains why in a comment: it declares core_version_requirement: ^11.3, without ^12, because it hard-depends on drupal/ai, which at the time of writing declares ^10.5 || ^11.2. A Drupal 12 site installs the suite and simply does not get that one sub-module. Nothing it creates is published for you — pages are created unpublished, or added as a new revision.
When this fits, and when it does not
It fits when editors need to build varied landing pages themselves and you would rather ship configuration than a component library. It fits badly when your design system is strict and every section must look identical — there, the freedom to set an arbitrary background colour is a liability, and a locked-down set of custom paragraph types serves you better. It is also the wrong tool if you are stuck on Drupal 10: version 2 will not install, and running version 1 on a site you intend to upgrade only defers the class-rename work. Weighing this against building your own paragraph types is an architecture decision, not a module choice, and it is the kind of call a Drupal developer should make with your content model in front of them.
Common questions
Will upgrading from 1.x change my content?
No field was renamed and no stored value was rewritten in the 2.0 release, and every bundle keeps its rendered structure. What changes is CSS class names and the ids on outer elements. Your theme is the thing at risk, not your content.
Do I have to enable all 26 sub-modules?
No, and you should not. Enable the families you will use; each ships its own optional configuration for its paragraph types, fields and displays.
Does it need a particular theme?
No. The suite is theme-agnostic and ships a neutral fallback. It also ships a theme bridge that maps its own --pb-* custom properties onto the region variables used by the Solo and APEX theme families, so editor colours and theme colours stop fighting over the same names.
How does it differ from W3CSS Paragraphs?
W3CSS Paragraphs is the older project this work grew out of. Paragraphs Bundles is the current suite and the one receiving the Drupal 11.3 and 12 work. If you are starting today, start here.
Can I still write my own CSS?
Yes, and for anything beyond per-section styling you should. The extra classes field is the intended hook. If you want per-element utility classes on top — exact padding, a custom grid — that is what UtiliKit does, and the two are designed to coexist.
Where to go next
Read the Paragraphs Bundles project page for the full bundle list and screenshots, or work through the video tutorials bundle by bundle. If you have an existing 1.x site and want the upgrade planned rather than attempted, that is a scoped piece of work — see Drupal services or send the site details and I will tell you what the class-rename pass will actually cost you.