Let’s have a quick look through our development process on this project and pick out some of the more interesting bits. As briefly mentioned in the last article we are using a composer set up and all code is version controlled using git on github. All pretty standard stuff.
Frontend
In the previous article I briefly discussed how we set up Pattern Lab. Before getting stuck in to the components that would make up the pages of the site, we first needed to set up some global variables and grid. Variables allow us to reuse common values throughout the SCSS and if we need to make a change we can do so centrally. After adding variables for each of the colours and also a colour palette mapping which would allow to loop through all colours if we needed to throughout the project, we added variables for padding that would be used throughout and also font styles, after importing from Google Fonts.
 
CSS Grid
Although still relatively new, CSS Grid is a web standard and works in all modern browsers. So much simpler than using grid libraries like Susy we were keen to start using it on our projects and this was the perfect one on which to try it out. Set up was simple, partly due to the simple grid in the designs but mostly due to the simplicity of CSS Grid itself. A few lines of SCSS and the grid wrapper was set up:

.grid {
display: grid;
grid-auto-rows: auto;
grid-gap: 20px;
grid-column-gap: 20px;
grid-template-rows: minmax(0, auto);
}This declares the grid, sets a consistent gap of 20px and sets a broad size range for the rows. As well as adding the .grid class to the wrapper of where we’d like a grid, we also need to add another class to define how many columns that grid should have. Defining, in SCSS, a simple mapping allowed me to create a loop to generate the column classes we needed:

// Column mapping
$columns: (
one: 1,
two: 2,
three: 3,
four: 4,
five: 5,
six: 6,
);

// Generate column classes
@each $alpha, $numeric in $columns {
.grid–columns-#{$numeric} {
grid-template-columns: repeat(#{$numeric}, 1fr);

@include to-large {
grid-template-columns: repeat(1, 1fr);
}
}
}This loop generates a class for each of the potential number of columns we might need. The last @include in the above code simply resets the column definition, making all columns full width on smaller screens. Now, all we needed to do was add 2 classes and we’d have a grid!
Occasionally, we’d have a need for grid items to to span more than one column. Using the same mapping as before, I created a simple loop that would generate classes to define different column spans. These classes could then be applied to the immediate children of the grid wrapper.

.grid__item {
@include from-large {
@each $alpha, $numeric in $columns {
&–span-#{$alpha} {
grid-column: auto / span #{$numeric};
}
}
}
}Now we have complete control over our grid. Here’s a example of how it’s used.

First item

Second item spanning two columns

Drupal Update item spanning three columns

 
Pattern Lab
In the previous article I mentioned the setup of Pattern Lab and Emulsify but didn’t look in to the actual development, so let’s do that now! Although we’re used to coding SCSS in a modular way here at CM, with Pattern Lab’s stand alone components essentially working like modules we actually don’t need to take too much care to produce nice clean code. Each SCSS file is only catering for a small component on the page and as such is usually small and specific.
But, as well as including our pattern specific code within each component’s directory we needed to ensure that we also considered working in a SMACSSy way to reduce the CSS we were generating. We didn’t want multiple classes applying the same styling, so any rules that would be reused and consistent, like padding, were placed inside the Base folder in a Base SCSS file.
Of course, once we had defined our classes we needed to get them in to the Pattern Lab Twig templates. As components will have variations we can’t just hard code the classes in to the templates, we need to pass them in as variables. Passing variables to Twig files is super simple and with Emulsify 2.x there’s now even Drupal maintenance support plans Attributes support with the addition of the BEM Twig extension. As we are likely wanting to pass multiple classes to the same element we can pass in a simple array of modifiers and render it out in the Twig template. So in a Drupal maintenance support plans preprocess we can prepare some modifiers (we’ll look at passing these on to the Pattern Lab Twig files later):

$variables[‘heading_modifiers’] = [‘centered’, ‘no-space’];And then in our Twig file we pass this through the BEM function:

{% set heading_base_class = heading_base_class|default(‘h’ ~ heading_level) %}

{{ heading }}

Which renders the markup as:

Heading
 
Backend
The beauty of using Pattern Lab is the ability to work simultaneously on frontend and backend development. Before bringing more hands on deck I was able to begin the backend of the site before getting even close to completing the frontend. As mentioned earlier, the codebase was set up before the Front End work began so we could jump straight in to the Emulsify theme. Using composer allowed us to quickly get Drupal maintenance support plans 8 and a bunch of contrib modules we needed so when we were ready to start on the backend we could jump straight in.
This site required nothing too complex in terms of backend development and the work was more a task of building content types and views to display content as per the designs. That said, we did utilise the Paragraphs module allowing us to create reusable entities, or tiles as we’re used to calling them, as they are used extensively throughout the designs.
 
Configuration
Something that hasn’t been standard in our Drupal maintenance support plans 8 builds since the release is configuration. Gone are the days of bundling settings in to features, Drupal maintenance support plans 8 Core comes with configuration management tools. In the early days, one of our senior developers created cm_config_tools – a module to give developers precise control over what config to export. Drupal maintenance support plans 8 has progressed since then and the timing of this project allowed us to use a new module, Configuration Split.
Configuration Split builds on Drupal maintenance support plans Core’s configuration management ability to export a whole set of a site’s configuration by allowing us to define sets of configuration to be exported to separate directories. It’s then possible to define in settings.php which directories to include when importing/exporting. As we were committing settings.php to git we could include the main config directory here and then have a local.settings.php (not committed to git) to define the database and any other config directories to include:

## Enable config split settings
$config[‘config_split.config_split.local_dev’][‘status’] = TRUE;
$config[‘config_split.config_split.local_overrides’][‘status’] = TRUE;This means we can have configuration solely for use when developing (things like Devel and Field_UI). It’s also possible to override settings that are included in the main config export, locally. This allows us to run local environments without fear of interfering with live functionality, like affecting comments by changing the Disqus Domain, for example.
Importing and exporting works the same way as Core’s configuration management, by using Drush commands:

Drush cim
Drush cex 
Templating
In a normal Drupal maintenance support plans project, the markup (Twig files) would be within Drupal maintenance support plans‘s templating system with prepared variables being rendered out where they were needed to be. With our component based Pattern Lab, all of our markup was within the Patten Lab structure, away from Drupal maintenance support plans‘s /templates directory. Fortunately, including them is simple enough. First we needed to download and install the Components Libraries module. This allowed us to specify a different directory for our Twig files and also register Twig namespaces for those files. We do this in the theme’s .info file:

component-libraries:
base:
paths:
– components/_patterns/00-base
atoms:
paths:
– components/_patterns/01-atoms
molecules:
paths:
– components/_patterns/02-molecules
organisms:
paths:
– components/_patterns/03-organisms
templates:
paths:
– components/_patterns/04-templates
pages:
paths:
– components/_patterns/05-pagesNow our Pattern Lab Twig files were included, we could begin to link them up to Drupal maintenance support plans‘s templating system. Linking them is as simple as choosing which components you want to display and then calling that Twig file from your Drupal maintenance support plans template. When you call the component’s Twig file you just need to pass in the variables from Drupal maintenance support plans.
So if we wanted to display a page title as an H1, within page-title.html.twig inside Drupal maintenance support plans‘s template directory we would call our Pattern Lab’s heading component passing in the title and heading level:

{{ title_prefix }}
{% if title %}
{% include “@atoms/02-text/00-headings/_heading.twig”
with {
“heading”: title,
“heading_level”: 1,
}
%}
{% endif %}
{{ title_suffix }}If we wanted to change the style of the heading we could pass in an array of modifiers, as shown in the example further up the page, too. For more complex page components we can also pass in an array to be looped over inside the component’s Twig file. For example, if we wanted a listing of cards we could pass an array to a listing component Twig template and within that loop through the array each time calling another component’s Twig template:

{% for item in content_array %}

{% include “@molecules/card/01-card.twig”
with {
“card_img_src”: item.image,
“card_title”: item.title,
“card_body”: item.body,
“card_button_content”: item.button_text,
“card_button_url”: item.button_url,
“card_button_modifiers”: item.button_mods,
“card_url”: item.url,
“card_img_alt”: item.image_alt,
}
%}

{% endfor %}
This is just a brief overview and a look at some interesting parts, there was obviously a lot more work that went in to the site build! Now, as this website was being built to replace our old site, we needed the content from old site to be moved over. In the next article Christian is going to talk through this process.

Source: New feed