A Drupal content model is not a diagram for developers; it is the set of choices editors must make every time they publish. This guide helps you shape content types and fields around real editorial work so structure improves reuse without making routine publishing harder.
Start with content jobs and relationships
Interview editors about what they create, update, approve, and reuse. Separate distinct jobs such as an event, article, service, and person when they need different fields or lifecycle rules. Shared visual appearance alone is not a reason to merge two editorial concepts. Drupal Views contextual filters.
Map relationships explicitly: an article may reference an author and topics; an event may have a venue, dates, and registration link. Decide whether each relationship is reusable content, taxonomy, or a simple field.
Make fields answer a real question
For every field, write what the editor enters, who consumes it, whether it is required, and how it is validated. Choose stable machine names and clear labels. Avoid adding fields “for later” without an owner; empty optional fields accumulate and weaken consistency.
Use reusable entities or references when information has its own lifecycle. Use taxonomy for controlled classification that powers navigation, filtering, or reporting. Keep presentation choices out of the content model where possible.
Design the authoring and review path
Set permissions and moderation states around actual roles. Test the form as an editor, including help text, required indicators, preview, and correction after rejection. A content type that is technically flexible but confusing in the authoring screen is not a useful model. See also Content types and fields.
Create sample content and review the resulting page, feeds, search results, and API output. Confirm fields have sensible empty behavior and that accessible labels and headings do not depend on editors inventing markup.
Validate before migrating or scaling
Prototype a few representative records and edge cases. Check whether Views, search, translations, and APIs can use the model as intended. Document field definitions and ownership so future developers understand why the structure exists.
A good model is discoverable and maintainable. When the editorial task changes, revise the model deliberately, plan data updates, and check downstream displays before releasing the change.
What would you do?
Which editorial field in your CMS creates the most confusion today—and what job should it actually support? Share your experience in the comments.
Have a related project in mind? Talk with Acorn.
Share your perspective