Paragraphs is one of the most powerful contributed modules in Drupal for building flexible, component-based content structures. Instead of creating rigid content types with fixed fields, Paragraphs allows editors to build pages using reusable content components such as banners, cards, galleries, accordions, and call-to-action blocks. In Drupal 10 and 11, Paragraphs integrates tightly with Twig templating, preprocess functions, libraries, and Layout Builder. From a frontend architecture perspective, Paragraphs is the bridge between structured content modeling and component-driven theming. Mastering Paragraphs means understanding how to model reusable components, override paragraph templates, and maintain performance and scalability in enterprise environments.

1. What Is Paragraphs?

Paragraphs is a contributed module that allows nested, reusable content components inside entities.

Instead of:

• One large body field

You create:

• Multiple paragraph types
• Each paragraph represents a component
• Editors assemble layouts dynamically

Install:

drush en paragraphs -y

2. Core Architecture

Content Type → Paragraph Reference Field → Paragraph Types

Example structure:

• Content type: Landing Page
• Field: field_sections (Paragraph reference, unlimited)
• Paragraph types:
  • Hero Banner
  • Card Grid
  • Text Block
  • CTA Section

This creates modular page building.

3. Creating a Paragraph Type

Admin:

/admin/structure/paragraphs_type

Example: Card

Fields:

• field_title
• field_description
• field_image
• field_link

Each paragraph type maps to a Twig template.

4. Paragraph Template Override

Template naming pattern:

paragraph.html.twig
paragraph--TYPE.html.twig
paragraph--card.html.twig

Example:

{{ attach_library('weeklydrupal_theme/card') }}

<div class="wd-card">
  <h3>{{ content.field_title }}</h3>
  {{ content.field_image }}
  {{ content.field_description }}
  {{ content.field_link }}
</div>

Best practice:

Render fields using content.field_name to preserve formatters and cache metadata.

5. Using Paragraphs with Components

Instead of writing markup inside paragraph template directly, reuse component templates.

Example:

{% include '@weeklydrupal_theme/components/card/card.html.twig' with {
  title: content.field_title,
  description: content.field_description,
  image: content.field_image,
  link: content.field_link
} %}

This keeps architecture consistent and reusable.

6. Preprocess with Paragraphs

Example:

function weeklydrupal_theme_preprocess_paragraph(&$variables) {
  $paragraph = $variables['paragraph'];

  if ($paragraph->bundle() === 'card') {
    $variables['card_type'] = 'primary';
  }
}

Twig:

<div class="wd-card wd-card--{{ card_type }}">

Preprocess keeps logic outside Twig.

7. Nested Paragraphs (Advanced)

Paragraphs can contain paragraph references.

Example:

• Card Grid paragraph
  • Contains multiple Card paragraphs

This enables:

• Flexible layouts
• Structured design systems

Be careful with:

• Deep nesting (performance impact)
• Cache complexity

8. Performance Considerations

Each paragraph is an entity.

Implications:

• Database queries increase with heavy nesting
• Caching becomes critical

Best practices:

• Use render caching
• Avoid unnecessary nesting
• Limit extremely deep structures

9. Paragraphs + Layout Builder

Two patterns:

1. Layout Builder only
2. Layout Builder + Paragraphs

Enterprise sites often:

• Use Layout Builder for structure
• Use Paragraphs for content components

Keep responsibilities clear.

10. Accessibility in Paragraph Components

Each paragraph component must:

• Use semantic HTML
• Provide alt text for images
• Ensure heading hierarchy
• Maintain keyboard accessibility

Accessibility is component-level responsibility.

11. Enterprise Modeling Strategy

Professional approach:

• Each paragraph = one UI component
• Do not mix unrelated fields
• Keep naming consistent
• Align with design system
• Document components

Avoid:

• Generic "Section" paragraph with too many optional fields
• Field overload

12. Common Mistakes

• Over-nesting paragraphs
• Mixing layout logic and content logic
• Hardcoding styles inside Twig
• Not using component libraries
• Ignoring cache performance

Interview Questions (Frontend Drupal)

1. What problem does the Paragraphs module solve?

Expected Answer:
It allows structured, reusable content components inside entities instead of relying on a single large body field.

2. How do you override a specific paragraph type template?

Expected Answer:
Create paragraph--TYPE.html.twig inside the theme’s templates folder.

3. Why should fields be rendered using content.field_name in paragraph templates?

Expected Answer:
To preserve field formatters, cache metadata, and access control.

4. What are performance risks with Paragraphs?

Expected Answer:
Deep nesting increases entity loading and query complexity, requiring careful caching strategy.

5. How does Paragraphs support component-driven theming?

Expected Answer:
Each paragraph type can represent a reusable UI component with its own template and assets.

6. When should you use Layout Builder instead of Paragraphs?

Expected Answer:
Layout Builder controls page structure; Paragraphs controls reusable content components. Use each according to responsibility.