Preprocess functions are one of the most misunderstood but heavily tested areas in the Acquia Developer exam.
Acquia uses preprocess questions to check whether you:
- Understand separation of concerns
- Know how data reaches Twig
- Can choose preprocess over Twig logic
- Avoid performance and security mistakes
Many incorrect answers come from putting logic in Twig instead of preprocess.
What preprocess functions are
Preprocess functions run before Twig renders the template.
They:
- Receive a variables array
- Modify or add variables
- Prepare clean, presentation-ready data for Twig
They do not:
- Replace controllers
- Perform heavy business logic
- Query large datasets unnecessarily
Where preprocess fits in the render lifecycle
Flow:
- Controller or plugin builds render array
- Theme hook is resolved
- Preprocess functions run
- Twig template renders variables
- HTML response is sent
Preprocess sits between render array and Twig.
Naming convention\
Preprocess function names follow strict patterns:
THEME_preprocess_HOOK()THEME_preprocess_node()THEME_preprocess_node__article()
More specific preprocess functions run after general ones.
Exam signal:
If a question asks how to target a specific content type or view mode, naming matters.
Basic preprocess example
Add a custom variable to a node template.
function mytheme_preprocess_node(array &$variables) { $variables['is_featured'] = FALSE; }
Twig usage:
{% if is_featured %} <div class="featured">Featured</div> {% endif %}
Correct pattern:
- Logic in preprocess
- Twig remains clean
Preprocess vs Twig logic (very important)
Correct use cases for preprocess:
- Computed variables
- Conditional classes
- Formatting data
- Attaching libraries
Incorrect use cases:
- Access checks
- Database queries
- Replacing Views
Exam signal:
If Twig needs a new variable, preprocess is the answer.
Attaching libraries in preprocess
Libraries can be conditionally attached.
function mytheme_preprocess_node(array &$variables) { if ($variables['node']->bundle() === 'article') { $variables['#attached']['library'][] = 'mytheme/article'; } }
Why this matters:
- Avoids loading assets globally
- Improves performance
Adding CSS classes safely
Use attributes instead of hardcoding classes.
function mytheme_preprocess_node(array &$variables) { $variables['attributes']->addClass('node-custom'); }
Twig:
<div{{ attributes }}>
This preserves accessibility and extensibility.
Working with view modes in preprocess
View mode information is available.
function mytheme_preprocess_node(array &$variables) { if ($variables['view_mode'] === 'teaser') { $variables['is_teaser'] = TRUE; } }
Twig stays simple:
{% if is_teaser %} <div class="teaser-layout"></div> {% endif %}
Site Builder perspective
Site builders:
- Control view modes
- Configure field visibility
Preprocess respects site builder decisions and adapts presentation.
Frontend developer perspective
Frontend developers:
- Rely on preprocess for clean variables
- Avoid heavy Twig logic
Preprocess keeps templates readable and maintainable.
Backend developer perspective
Backend developers:
- Provide clean render arrays
- Avoid pushing logic into themes
Preprocess should not duplicate backend logic.
Performance considerations
Good preprocess:
- Lightweight logic
- Conditional asset loading
- Minimal computation
Bad preprocess:
- Loading entities repeatedly
- Complex loops
- Database queries
Exam signal:
Performance issues are often solved by reducing preprocess complexity.
Security considerations
Preprocess functions:
- Should not trust user input
- Should rely on sanitized data
- Should not bypass access checks
Twig auto-escaping still applies.
Common exam traps in Module 3.5
- Writing business logic in preprocess
- Querying the database
- Using preprocess instead of View modes
- Hardcoding markup
- Ignoring naming conventions
Correct answers favor clarity and separation.
Key exam takeaways
- Preprocess prepares variables for Twig
- Twig renders, preprocess prepares
- Naming determines scope
- View modes come first
- Logic stays minimal