Our colleagues Nesta -Front-End leader in La Drupalera- and Enno -Front-End Drupal developer- teach in Drupal Dev Days Seville 2017 how to create your Sass/JS/CSS themes in case you have styles with common basic elements but different layouts, structures and contents in your multi-site installation. Such a challenge!
Dev Dives: Streamline document processing with UiPath Studio Web
Efficiently theming a multi-site Drupal 8 portal - Drupal Dev Days Seville 2017
1. Efficiently theming a multi-site
Drupal 8 portal
How a single Drupal theme can be used for a
complex multi-site Drupal installation
2. Hello everyone, we are...
Nesta (@Nesta_)
Technical Architect
and QA
8+ years working
with Drupal
Enno (@langelotz)
Frontend Developer,
SEO specialist
7+ years working
with Drupal
La Drupalera (@ladrupalera)
One of the premier Drupal
agencies in Spain with
headquarters in Seville.
3. Drupal 8
Multisite 3
Considering using a single theme for a Drupal 8
multisite environment
Critical points:
● similar branding and
styles?
● common navigation
elements?
● overlapping content?
Drupal 8
Multisite 2
Drupal 8
Multisite 1
Shared
code
Theme 1
Theme 2
Theme 3
4. Drupal 8
Multisite 3
Similarities for the individual sites can justify the use
of a single theme
Critical points:
● similar branding and
styles
● common navigation
elements
● overlapping content
Drupal 8
Multisite 2
Drupal 8
Multisite 1
Shared
code
Theme 1
5. Real life example: Sevilla FC
Highly visible futbol portal
> 500k visits/month
3 portals in a multisite
installation
13 different languages
6. Functional requirements for our single theme
Customer 1:
“We want everything to look the same, but portal 1 has an additional sidebar.”
Customer 2:
“We have a general company branding, but each department with its own
subsite has its own logo and colors.”
Customer 3:
“One of our portals has special content, which has its own design different from
our general style guide.”
7. Technical requirements
● Create custom CSS/JS for each portal of the multisite installation
● Don’t create unnecessary or duplicate CSS
● Have a technical solution for whatever design exception is thrown at us during
the development cycle
● Be able to modify styles for any region/page/node/block in any site at
any point in time without being worried about side effects
8. Rules, that help the team work together and create a
better product
● Empower your frontend developers to allow them making informed decisions
● Separate general components (your style guide) from block/page specific
design
● Have a specific task for the theme setup that solves basic theme foundations
such as grid, typography, variables, theme structure and common elements
● Talk to each other, so you can help each other out with reusable code
9. The Theme basis we work with
● Gulp/Grunt for CSS/JS creation
● No predefined framework like Bootstrap - we use individual external libraries
as needed. Examples:
○ Susy
○ Breakpoint
● Sass as our preprocessor of choice
● Sass archive hierarchy loosely based on SMACSS, but Drupal specific
10. Sass to the rescue
Sass allows us to import or write our
Code in small chunks and different
archives and then put it all together
for the final compilation into css.
For a single site installation,
everything is brought together in one
central file: main.sass
@import external libraries
@import utilities
@import base styles
@import layout
11. Using a strict Sass archive hierarchy
The theme defines the basic approach:
● Hierarchical structure of folders
● Archives for basic components
● Order of compilation
● Imported code
The frontend developer decides:
● Level of implementation: Page, view,
block, node, etc.
● Use of mixins and extends
Sass
External
Utilities
Base
Components
Layout
Blocks
Views
Pages
Nodes
13. Questions for the frontend developer
Main Content Sidebar
Header
Static
Block
View
Node
Footer
Decision Tree Example
Project Manager: “Apply the necessary styles to the sidebar!”
What is my content in the sidebar?
Custom block and view. -> Divide the tasks
Is my custom block used anywhere else on the portal?
No -> Create Sass file for the block, insert the styles.
Is my view using nodes or fields?
Node teasers.
Are the node teasers used anywhere on the side in a
different context?
No -> Create node teaser twig template and Sass archive.
Node
14. Workflow in abstract form
1. Receive the task
2. Analyze the situation
3. Define and create necessary Sass files to work on
4. Create/adapt mixins/extends/functions/variables
5. Create the specific styles
15. Creating and using the individual Sass archive
Example: Drupal Search block
Folder for the block Sass file: layout/blocks
.search-block-form = _block-search-block-form.sass
Important rule for determining the right context:
No styles allowed that cannot be inserted by using “.search-block-form” as the
first css class.
.page-node-15 .search-block-form <- We don’t want that!
16. Code example 2
Example Sevilla FC - Block Pasion Sevillista
Identifying and changing a Sass file
17. Taking care of the multisite optional styles
We will need optional styles for each subsite. Our main.sass file stops being the
all-including style file.
main.sass - Contains all basic styles
layout-default.sass - Contains the default layout styles
site1.sass - Contains only site-specific styles
The layout folder is duplicated for each subsite.
18. Where to put the code on multisite?
Decision Tree Example
Project Manager: “Apply the necessary styles to the sidebar!”
What is my content in the sidebar?
Custom block and view. -> Divide the tasks
Are the styles specific to one/several subsites or generally applicable ?
Specific to one side -> Use the Sass folder for the specific site
Is my custom block used anywhere else on the portal?
No -> Create Sass file for the block, insert the styles.
19. Further theme preprocess changes for multisite
Additional css classes for the <body> element can help adding specific styles
more easily.
<body> CSS class for:
● Subsite
● Language
● Node ID
20. Code example 3
a) Multisite folder structure example.
b) Adapted theme.libraries file to create the necessary multisite css.
c) Preprocess changes in the theme to add body classes
21. Room for optimization - get feedback from frontend
Don’t wait with the Sass/CSS until after Sitebuilding is finished!
Your frontend developer can help to shorten the process by pointing out simple
HTML changes that can be achieved by:
● Changing views to use global fields
● Creating custom node displays
● Adding css IDs/classes
● Changing the order of blocks/panels/paragraphs
● Adding or removing containers that are set with DS, Panels or similar