Twig is the primary language used in Drupal themes, and Acquia uses this module to test whether you:
- Understand what Twig is allowed to do
- Can read and reason about Twig code
- Know what should not be done in Twig
This module is not about memorizing syntax, but about using Twig safely, simply, and correctly.
What Twig is in Drupal (simple definition)
Twig is a template language used to convert render arrays into HTML.
Twig:
- Prints variables
- Loops over data
- Applies filters
Twig does not:
- Query the database
- Load entities
- Contain business logic
If a scenario pushes logic into Twig, it is usually the wrong solution.
How Twig fits into the render pipeline
Flow recap:
Render array → Theme hook → Twig template → HTML
Twig only sees what is passed to it.
Exam signal:
If Twig needs more data, the correct fix is preprocess, not logic in Twig.
Printing variables (most common usage)
Example: Print node title
<h1>{{ label }}</h1>
Key point:
- Twig auto-escapes output
- Safe by default
Working with the content variable
In entity templates, Drupal provides a content variable.
Example: Render all fields
{{ content }}
Example: Render a specific field
{{ content.field_image }}
Exam signal:
If a question asks how to output a field, this is the correct approach.
Conditional logic (allowed but minimal)
Twig allows simple conditionals.
Example: Check if a field exists
{% if content.field_image %}
{{ content.field_image }}
{% endif %}
Allowed use:
- Presence checks
- Simple conditions
Not allowed:
- Business rules
- Access control
Loops (lists and collections)
Twig supports loops.
Example: Loop through menu items
{% for item in items %}
<li>{{ item.title }}</li>
{% endfor %}
Exam signal:
If iteration is needed, Twig loops are appropriate.
Filters (transforming output)
Filters modify output safely.
Common filters:
|escape(automatic)|t(translation)|length
Example: Translate text
{{ 'Read more'|t }}
The |raw filter (security warning)
|raw disables escaping.
Example (dangerous)
{{ content.body|raw }}
Why this is risky:
- Can expose XSS
Exam signal:
If |raw appears, it is often the wrong answer unless explicitly justified.
Attributes object (Drupal-specific)
Drupal uses an Attributes object for HTML attributes.
Example: Add a class
<div{{ attributes.addClass('custom-class') }}>
Why this matters:
- Preserves accessibility attributes
- Avoids overwriting classes
Exam signal:
If modifying attributes, use attributes, not hardcoded HTML.
Template suggestions in practice
Twig templates are selected using suggestions.
Example filenames:
node.html.twignode--article.html.twignode--article--teaser.html.twig
Drupal picks the most specific available template.
Real scenario: Different markup for teaser vs full page
Scenario:
An Article teaser needs a card layout. Full page needs full content.
Correct solution:
- Create
node--article--teaser.html.twig - Use view mode configuration
Incorrect solution:
{% if teaser %}conditions in Twig
Real scenario: Adding a CSS class based on content type
Incorrect approach:
- Hardcoded conditionals everywhere
Correct approach:
- Add class in preprocess
- Use attributes in Twig
Twig remains clean.
Twig and performance
Good Twig:
- Simple printing
- Minimal logic
- Reused templates
Bad Twig:
- Heavy conditionals
- Large loops
- Inline scripts
Exam signal:
Performance issues are often solved by moving logic out of Twig.
Twig and accessibility
Twig should:
- Preserve semantic HTML
- Use provided attributes
- Avoid removing ARIA roles
Accessibility should not be broken by theming.
Common exam traps in Module 3.3
- Querying data in Twig
- Using
|rawwithout reason - Using Twig to hide fields
- Writing access logic in Twig
- Ignoring view modes
Correct answers favor simplicity and separation.
Key exam takeaways
- Twig is presentation-only
- Auto-escaping protects security
- Preprocess prepares data
- View modes control visibility
- Template suggestions control variation