Display Modes are one of the most misunderstood yet heavily tested areas in the Acquia Drupal Developer exam.
Acquia uses this module to test whether you understand the difference between:
- Content structure
- Content editing experience
- Content presentation
Most wrong answers come from confusing these responsibilities.
What display modes mean in Drupal
In Drupal, the same content can be:
- Edited in different ways
- Displayed in different ways
- Reused in multiple contexts
Display modes allow this without duplicating content types or fields.
There are two main types:
- Form modes control how content is edited
- View modes control how content is displayed
Think of display modes as "lenses" applied to the same content.
Mental analogy (very important for recall)
Content type is the data model.
Form mode answers:
"How does the editor enter this data in this situation"
View mode answers:
"How does the user see this content in this situation"
Same content. Different lens.
Form Modes
What form modes are
Form modes control the editing interface for an entity.
They determine:
- Which fields are shown
- Field order
- Widget type
- Help text and grouping
Form modes do not affect frontend output.
Real-world form mode example
Scenario:
An Event content type is edited by two different roles.
- Content editors need a simple form
- Administrators need all fields
Correct Drupal solution:
- Default form mode for administrators
- Custom form mode (for example "Quick edit") for editors
Incorrect solution:
- Create a second Event content type
Acquia strongly favors form modes here.
How site builders use form modes
Site builders:
- Enable form modes
- Configure widgets per form mode
- Assign form modes per role if needed
They focus on usability and editor efficiency.
How backend developers interact with form modes
Backend developers:
- Usually do not hardcode form logic
- Respect configured widgets
- May alter forms using hooks if absolutely required
Form modes reduce the need for custom form code.
How frontend developers relate to form modes
Frontend developers usually do not theme form modes directly.
They may:
- Style form elements globally
- Style specific widgets
Form modes are mostly an editor-facing concern.
View Modes
What view modes are
View modes control how content is rendered on the frontend.
They determine:
- Which fields are shown
- Field formatters
- Field order
- Visibility of labels
View modes never change stored data.
Real-world view mode examples
Same Article content type:
- Full view mode for article pages
- Teaser view mode for listings
- Card view mode for homepage blocks
Same content. Different presentation.
Incorrect solution:
- Creating Article Teaser content type
How site builders use view modes
Site builders:
- Enable custom view modes
- Configure field formatters per view mode
- Control visibility without code
This is core Drupal site building.
How frontend developers use view modes
Frontend developers:
- Create Twig templates per view mode
- Style output consistently
- Avoid conditional logic
Example concept:
Instead of checking "if teaser" in Twig, use a teaser view mode template.
How backend developers use view modes
Backend developers:
- Load entities in specific view modes
- Return render arrays using view modes
- Avoid building custom markup
View modes integrate cleanly with the Render API.
Architect perspective
Architects prefer view modes because they:
- Reduce duplication
- Encourage reuse
- Support future changes
- Scale across features
View modes are a long-term design tool.
Field formatters vs widgets
Important distinction:
- Widgets are for editing (form modes)
- Formatters are for display (view modes)
Confusing these is a common exam trap.
Common exam traps in Module 2.2
- Creating multiple content types for different displays
- Using Twig conditionals instead of view modes
- Hardcoding field visibility in templates
- Using form modes to control frontend display
- Writing custom controllers instead of using view modes
Correct answers favor configuration-first solutions.
Real scenario walkthrough
Scenario:
A homepage shows Event cards with image and title only. The Event page shows full details.
Correct approach:
- Create Card view mode
- Configure fields for Card view mode
- Theme Card view mode
Incorrect approach:
- Duplicate Event content type
- Hide fields with Twig logic
This scenario appears frequently in Acquia exams.
Key exam takeaways
- Content types define data
- Form modes define editing experience
- View modes define presentation
- Same content should be reused
- Configuration comes before code
Practice check
- Which controls editor UI: form modes
- Which controls frontend display: view modes
- Should display differences create new content types: no
- Who benefits from display modes: editors, developers, architects