We got to the point where the old Drupal mantra of creating content first to see it later is not enough to suceed with content editors. Drupal is competing and replacing other CMS and platforms where the lack of flexibility is the problem #1 for content editors. They are expecting full flexibity on how content is created, displayed, approved and published. However this introduce a common problem for web developers and site builders: how can you provide this full flexibility without having to be constantly on the hook for further development or configuration. Modules like panels and panelizer, projects like Spark and distributions like panopoly and demo framework helped change the panorama in Drupal and the expectations that are set when sites are built. In this session we will look to a set of common problems and real examples when creating content and layout for pages with demanding editorial teams. We will look and evaluate common options and recipes. How can complex content and rich pages be structured ? Free HTML format in different fields? Structured data in complex fields? Use paragraphs or field collection? Different content items in different items/entities? How to glue it all together? How can indivual page layout be managed providing flexibility but also control? Rely on templating system and view modes? Use contrib modules like panels and panelizer or display suite? Mix several approaches and modules? How can I add any content to any page and choose its display ? How can I have a list of curated widgets ready to use by the content team to deploy anywhere or in any section? How can pages and sections be managed before approved and published? Use preview systems and inline editors? Use workbench or workflow for layout? Rely on more complex content staging systems? Use separated environments? These are daily problems that architects and developers face in every project. As a technical architect in Acquia it is uncommon a project where I am involved that does not need to solve one or more of these problems. In this session I will give some real examples and resume options and recipes that can be used to solve those problems today in Drupal 7 and look to Drupal 8 to explain how it can improve some of our possibilities and options and easy the life of one of our most important personas: the content editor.

2. Drupal architectures for
flexible content
Hernâni Borges de Freitas / @hernanibf
Site Building track

3. About me
Technical Team Lead Acquia EMEA
.PT
Drupal* many things
hernani.pt
Twitter.com/hernanibf

4. A typical web site for a CMS:
• Structured and fixed content: news items, job posts,
events.
• Same content structure and typically same layout.
• Flexible content: home pages, landing pages,
collection pages, rich pages.
• Content structure and layout vary per item and can
be changed by editors.

5. Today’s session:
• Architecture and patterns available for building a Drupal
site with flexible content:
• Content Architecture
• Layout Architecture
• Workflow
• Building an unified and comprehensible experience
for content editors

6. Meet the content editor:
• Wants to control most of the details how content
appears on the web site. Flexible content is a major need.
• He is a major stakeholder in websites where content is
king: media, entertainment, corporate websites.
• Tech savvy on his own way - does not accept technical
limits - if the system does not allow something, he will find
a way of doing it anyway.

7. Typical demands:
 Change website look and feel.
 Reuse content anywhere.
 Review / preview / approve / schedule content as it
will appear.
 Readapt site purpose on special events.
 CMS should be easy to understand, fast to
execute and free of problems 

8. Problem in Drupal:
 Disconnection between content and layout.
 Disconnection between site building and
content edition.
 Drupal mantra of create content first, and it will
display on different sections “automagically”.
 Lack of revisioning system in many pieces of
the puzzle (menus, taxonomy, blocks).

9. Breaking the problem

10. How to create a rich page?
http://paragraphs.site-showcase.com/demos/creme-caramel

12. Options
A. Free form HTML.
B. Structured inclusive content including all items.
C. Structured referenced content with references
among items.
D. Unreferenced content being added through
layout.

13. Option A - Free form HTML
 Typically this is never a good solution, but in theory
can give a lot of flexibility.
 Hard to maintain consistency.
 Hard to reuse content.
 WYSIWYG hard to use and manage even with
placeholders.
 Hard to avoid errors from Content Editors (CE’s)

14. Option B – Inclusive content
All content details are stored in the content item using
complex fields. Good for pages with lots of details
reused elsewhere.
Typical implementations:
• Compound fields (custom or contributed).
• Field collection module / Paragraphs module treat
the different entity as part of the host entity.

16. Option C – Referenced content
Different parts of content items are split in different
entities which are referenced from the main entity.
Typical implementations:
 Entity reference field with inline entity form.
 Extra modules like references dialog module can
help on browsing existing content.
 Back references to help glue content (CER).

17. Option C – Referenced content
Different parts of content items are split in different
entities which are referenced from the main entity.
Typical implementations:
 Entity reference field with inline entity form.
 Extra modules like references dialog module can
help on browsing existing content.
 Back references to help glue content (CER).

18. Breaking the problem

19. Manage individual page layout
How do I create a new rich page layout in Drupal?
Some options:
A. Core template system
B. Display suite
C. Panels / Panelizer

20. Template system
• Prepare different Drupal templates that are selected
depending on some attributes (node type, field,
etc..).
• Use display modes and template suggestions to
pick the correct template.

21. Display suite
View modes created by configuration. Drag and drop
fields with different formatters for different regions.
 Most of the layout/style can be done by site
builders.
 Good to maintain consistency between view modes.

23. Panels
• Customized layouts for different means, including
for entity layout.
• Support creation of pages with custom/fixed
layouts.
• Fits well with the idea of widgets than can be drag
and dropped and configured in different regions.

24. How to create pages with panels?
Different ways of creating pages:
• Create independent panels.
• Page manager with variants.
• Panel nodes.
• Panelizer

25. Panelizer
• Panel display associated with an entity.
• Panel displays available to be used as templates.
• Panelize an entity and add panes and fields to
different regions.
• Slick interface with Panels IPE.
• You can try in Panopoly or Lightning distribution.

26. Panes
• Configuration per instance where the pane is
present (e.g: A view that receives configuration that
depends from page to page.
• Fieldable Panel Panes (FAPE)
• Panels In place editor (IPE)
• Panopoly magic
• Panopoly widgets

27. Ctools content types

28. Breaking the problem

29. How to workflow content and
layout together?
• Content workflow is easy
• Workbench moderation / Workflow / …
modules
• Layout workflow is harder (!)

30. How to preview?
• Easier to achieve when rich content exists as a unit.
• Harder to achieve with lots of referenced content.
• Easier to achieve when layout stores all the needed
configuration and is associated with revisions
(panelizer).

31. Workflow of flexible content
Directly in production
• Limited if not well
addressed.
• Dependency on revision
system.
• Panelizer integrates with
with workbench moderation
(with patches) 
Different environments
• Tricky balance between
content and layout.
• Both need to be pushed
amongst environments.

32. Workflow of complex items
Directly in production
Modules like:
• Quick edit and panels in place
editor contextual links.
• Workbench or workflow
• Site Preview System.
Different environments
Modules like:
• Deploy module and
associated suite can ship
content together with
associated items.

33. Breaking the problem

34. Non-tech considerations (1/2)
• Content editors are amongst the most important project’s
stakeholders.
• They know the content and how the website will work after
architects and developers leave.
• They care about what they see and not how does it work.
• Should be involved from Discovery phase to User
Acceptance Testing.

35. Non-tech considerations (2/2)
• Content editors are used to previous systems and will want
to keep some old habits.
• Pilots and POCs are very good ways to expose end users
with what they will use.
• Distributions like lightning or panopoly are great inspirations
and models to start with.

36. Holistic view

37. About my work @ acquia
An architect in Acquia is responsible technical
solutions for clients during different phases.
• Discovery
• Solution/Specification
• Development phase
• Deployment

38. We are hiring
http://www.acquia.com/careers