Module 2.4 – Blocks and Layout

Blocks and Layout are where Drupal shifts power from developers to site builders and content editors. Acquia uses this module to test whether you understand editor empowerment, layout flexibility, and configuration-first design.

Many wrong answers come from hardcoding layout decisions in Twig or PHP instead of using Drupal’s block and layout systems.


What blocks are in Drupal

A block is a reusable piece of content or functionality that can be placed in different regions or layouts.

Blocks can be:

  • Custom blocks (content-based)
  • Plugin blocks (code-based)
  • Views blocks
  • Menu blocks

Blocks are not pages. They are building blocks used to assemble pages.


Where blocks are managed (UI anchors)

These URLs help anchor the concepts mentally.

Block library:

  • /admin/content/block

Block layout (theme regions):

  • /admin/structure/block

Custom block types:

  • /admin/structure/block/block-content

These paths are not for memorization, but help connect concepts to real Drupal usage.


Custom blocks vs plugin blocks

Custom blocks (Block Content)

Custom blocks are content entities.

Use custom blocks when:

  • Editors manage the content
  • Content needs revisions
  • Content may be reused

Examples:

  • Homepage announcement
  • Alert banner
  • Call-to-action text

Plugin blocks (Code-based)

Plugin blocks are defined in code.

Use plugin blocks when:

  • Content is dynamic
  • Content depends on logic
  • No editor input is required

Examples:

  • Logged-in user info
  • API-driven data

Acquia favors custom blocks unless code is required.


Layout and regions (traditional approach)

Themes define regions.

Blocks are placed into regions.

Example regions:

  • Header
  • Sidebar
  • Footer

This approach is global and theme-driven.


Layout Builder (modern approach)

Layout Builder allows per-page or per-entity layouts.

Key features:

  • Drag-and-drop layouts
  • Inline block placement
  • Per-content customization

Layout Builder shifts layout control closer to content.


Where Layout Builder is configured

Enable Layout Builder:

  • /admin/structure/types/manage/{content_type}/display

Layout Builder UI:

  • Manage display → Enable Layout Builder

Again, this is for conceptual anchoring, not memorization.


Site Builder perspective

Site builders:

  • Choose between regions and Layout Builder
  • Create reusable block types
  • Control layout without code

They optimize for editor flexibility and maintainability.


Frontend developer perspective

Frontend developers:

  • Style blocks and layouts
  • Create layout templates
  • Avoid hardcoded markup

Layout Builder changes how themes are structured.


Backend developer perspective

Backend developers:

  • Create plugin blocks when needed
  • Provide data to layouts
  • Avoid embedding layout logic in code

Blocks reduce the need for custom controllers.


Architect perspective

Architects evaluate:

  • Editorial freedom vs consistency
  • Performance implications
  • Reuse across pages

Layout Builder is powerful but must be governed.


Common exam traps in Module 2.4

  • Hardcoding layout in Twig
  • Creating content types for layout purposes
  • Writing custom controllers for page assembly
  • Ignoring block reuse
  • Avoiding Layout Builder without reason

Correct answers favor blocks and layout configuration.


Real scenario walkthrough

Scenario:
Marketing needs to change homepage sections without developer help.

Correct solution:

  • Use custom blocks
  • Place via Block Layout or Layout Builder

Incorrect solution:

  • Hardcoded homepage template

Key exam takeaways

  • Blocks are reusable building units
  • Custom blocks are preferred for editor-managed content
  • Plugin blocks are for dynamic logic
  • Layout Builder enables flexible layouts
  • Configuration comes before code

Practice check

  • Editor-managed reusable content: custom block
  • Dynamic logic-driven content: plugin block
  • Page-specific layout control: Layout Builder
  • Hardcoded layout: usually wrong