22
Efficiently theming a multi-site Drupal 8 portal How a single Drupal theme can be used for a complex multi-site Drupal installation

Efficiently theming a multi-site Drupal 8 portal - Drupal Dev Days Seville 2017

Embed Size (px)

Citation preview

Efficiently theming a multi-site Drupal 8 portal

How a single Drupal theme can be used for a complex multi-site Drupal installation

Hello everyone, we are...

Nesta (@Nesta_)

Technical Architect and QA8+ years working with Drupal

Enno (@langelotz)

Frontend Developer, SEO specialist7+ years working with Drupal

La Drupalera (@ladrupalera)

One of the premier Drupal agencies in Spain with headquarters in Seville.

Drupal 8 Multisite 3

Considering using a single theme for a Drupal 8 multisite environmentCritical 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

Drupal 8 Multisite 3

Similarities for the individual sites can justify the use of a single themeCritical points:

● similar branding and styles

● common navigation elements

● overlapping content

Drupal 8 Multisite 2

Drupal 8 Multisite 1

Shared code

Theme 1

Real life example: Sevilla FCHighly visible futbol portal

> 500k visits/month

3 portals in a multisite installation

13 different languages

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.”

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

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

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

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

Using a strict Sass archive hierarchyThe 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

Code example 1Drupal 8 Sass Folder structure in Editor

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

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

Creating and using the individual Sass archiveExample: 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!

Code example 2Example Sevilla FC - Block Pasion Sevillista

Identifying and changing a Sass file

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.

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.

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

Code example 3a) 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

Room for optimization - get feedback from frontendDon’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

Thank you very much for your attention. Questions?