Content modeling is the foundation of every Drupal site. If the content model is wrong, everything built on top of it becomes fragile.
Acquia gives heavy weight to this module because it reveals whether a developer understands Drupal as a content management framework, not just a page builder.
Most Site Building exam questions are indirectly testing content modeling decisions.
What content modeling means in Drupal
Content modeling is the process of translating real world concepts into Drupal entities.
In Drupal, this usually means:
- Choosing content types
- Defining fields
- Defining relationships
- Planning reuse and future change
Drupal expects content to be structured, reusable, and independent of presentation.
Content types represent real world objects
This is where site builders define the core data model of the site. Every decision here affects editors, frontend theming, backend code, and future scalability.
A content type should represent a real, meaningful thing.
Examples of good content types:
- Article
- Event
- Organization
- Person
- Policy
Examples of poor content types:
- Homepage teaser
- Sidebar item
- Blue card
- Layout section
If a name describes appearance instead of meaning, it is probably not a content type.
Site Builder perspective
From a site builder standpoint, content modeling answers these questions:
- What information do editors need to enter
- How often will content change
- Who manages the content
- How will content be reused
Site builders focus on:
- Field types
- Field labels and help text
- Required vs optional fields
- Editor usability
They should avoid creating content types just to solve layout needs.
Frontend developer perspective
Frontend developers rely on good content modeling.
They expect:
- Predictable fields
- Consistent data structures
- Reusable view modes
Poor content models force frontend developers to:
- Add conditional logic in templates
- Handle missing data inconsistently
- Duplicate styling logic
A strong content model simplifies theming.
Backend developer perspective
Backend developers interact with content types through the Entity API.
They expect:
- Stable field names
- Clear relationships
- No hard-coded assumptions
Good content modeling reduces the need for:
- Custom database tables
- Manual queries
- Data migrations later
Acquia expects developers to respect the content model rather than bypass it.
Architect perspective
Architects evaluate content modeling for long-term impact.
Key architectural concerns:
- Can this content be reused in new features
- Can it scale to new requirements
- Can it be translated
- Can it be migrated
Architects prefer fewer, flexible content types over many narrow ones.
Fields and field types
Fields define the properties of a content type.
Choosing the correct field type affects:
- Validation
- Display options
- Performance
- Future extensibility
Real example
Event content type fields:
- Event title (Text)
- Event date (Date)
- Event description (Long text)
- Hosting organization (Entity reference)
- Event image (Media reference)
Fields define the properties of a content type.
Common field types:
- Text
- Long text
- Integer
- Decimal
- Boolean
- Date
- Entity reference
- Media reference
Choosing the correct field type affects:
- Validation
- Display options
- Performance
- Future extensibility
Field storage vs field instance
Drupal separates:
- Field storage (data definition)
- Field instance (usage on a content type)
This allows the same field to be reused across content types.
Exam insight: Reusing field storage is preferred over duplicating fields.
Cardinality
Cardinality defines how many values a field can store.
Examples:
- One author
- Multiple tags
- Multiple images
Setting correct cardinality early prevents data and UI issues later.
Acquia questions often test whether cardinality has been considered.
Entity reference relationships
Entity reference fields connect one entity to another entity.
Entity reference should be used whenever data has its own meaning and lifecycle.
Entity reference fields connect content types.
Common relationships:
- Event references Organization
- Article references Author
- Policy references Department
Use entity references when the relationship is meaningful and reusable.
Do not flatten relational data into text fields.
Taxonomy vs content types
Taxonomy is used for classification and controlled vocabularies.
Real taxonomy examples
- States vocabulary
- 50 terms representing US states
- OSHA offices vocabulary
- Regional offices
- Area offices
- Topics vocabulary
- Safety topics
Taxonomy terms are reused across content and are ideal for filtering and grouping.
Comparison example
States should be taxonomy terms, not content types.
Reasons:
- Fixed, controlled list
- Used for classification
- No complex fields required
Organization should be a content type, not taxonomy.
Reasons:
- Has its own data
- Needs multiple fields
- May be referenced across the site
Acquia frequently tests this decision point.
This is a frequent exam decision point.
Use taxonomy when:
- Data is used for classification
- Values are shared across content
- Editors choose from a controlled list
Use content types when:
- Data has its own lifecycle
- Data has multiple fields
- Data may be referenced elsewhere
Acquia heavily tests this distinction.
Revisions and moderation
Content types can support:
- Revisions
- Workflows
- Content moderation
Real examples
Enable revisions when:
- Content is regulated
- Content changes must be audited
- Multiple editors are involved
Example use cases:
- OSHA policies
- Safety regulations
- Public guidance documents
Governance requirements strongly imply revisions and moderation in exam scenarios.
Content types can support:
- Revisions
- Workflows
- Content moderation
If content requires approval or auditing, revisions should be enabled.
Exam insight: Governance requirements imply revisions and moderation.
Multilingual considerations
Ask early:
- Will this content be translated
- Are fields translatable
Changing translatability later is expensive.
Architectural thinking includes multilingual planning.
Common exam traps in Module 2.1
- Creating multiple content types for display differences
- Using taxonomy to store rich data
- Storing relationships as plain text
- Ignoring revisions and workflows
- Over-modeling with too many content types
Correct answers favor simplicity and reuse.
Example scenario walkthrough
Scenario: A site manages safety events hosted by organizations.
Correct model:
- Event content type
- Organization content type
- Entity reference from Event to Organization
Incorrect model:
- Organization name as plain text
- Separate Event types per organization
This scenario appears frequently in different forms on the exam.
Key exam takeaways
- Content types represent real world entities
- Fields define structure, not presentation
- Relationships should use entity references
- Configuration comes before custom code
- Think about future reuse
Practice check
- When do you create a content type: when modeling real data
- When do you use taxonomy: for classification
- When do you use entity reference: for relationships
- Who benefits most from good content modeling: everyone