Hugo released version 0.43 adding built-in asset post-processing. As our team wraps up development of a free page-builder theme that utilizes Forestry.io, Netlify, and Hugo, we were thrilled to replace our asset processing tasks with Hugo’s pipeline.

The addition of built-in asset pipeline support allowed us to simplify our build process and reduce potential conflicts caused when deploying with Netlify. Here’s how we replaced our Gulp tasks with Hugo’s new asset pipeline to add SASS support and to concatenate, minify, and fingerprint JS and CSS.

Built-in SASS support

Since Hugo previously did not provide built-in support for SCSS, Gulp was commonly used for SCSS generation. This wasn’t ideal for us because the build and deploy process with Netlify would sometimes encounter issues. As a result, we would just commit processed assets instead of using Netlify to build assets.

Using SCSS with Hugo in 2018

Sass provides many benefits that simplify theme development. For example, it enables the use of variables for CSS values.

$font-stack:    Helvetica, sans-serif;
$primary-color: #333;

body {
  font: 100% $font-stack;
  color: $primary-color;
}

This is especially useful for theme development when user’s are able to define these variables themselves and quickly change the style of a theme.

Partial Sass files allow you to better organize your CSS. These files, which use a leading underscore, are then imported and combined into a single file.

Note: you must use the extended version of 0.43 for Sass support.

1. In your theme folder or the top-level of your project add an assets folder to store your SCSS:

By default, resource objects live in the /assets/ directory (you will most likely need to add this folder).

2. Add a main.scss file to your scss directory:

3. In main.scss, import your partial SCSS:

If you define variables that are used in other partial files, you must import that partial file first. For example, we use a file called _variables.scss to define fonts and colors.

4. Generate the resource:

{{ $styles := resources.Get “scss/main.scss” | toCSS }}

You can learn more about the resource functions within #4854. This seems to provide more context then the release page.

For example, resources.Get creates a new resource object based on a path to a file within the /assets directory.

In the code snippet above, resources.Get generates a file in the resources directory:

5. Reference the newly generated SCSS file:

{{ $styles := resources.Get “scss/main.scss” | toCSS }}

<link rel=”stylesheet” href=”{{ $styles.Permalink }}” media=”screen”>

Appending .Permlink to the styles variable generates the URL needed to reference the scss file in our resources directory.

Cache-busting using fingerprinting

Cache busting allows you to force the browser to re-download files that are usually cached. CDN’s like Cloudflare and a user’s browser will cache certain resources like stylesheets to reduce page load time. This means that a user might not see newly committed stylesheet updates unless the browser cache is cleared.

If you are using Cloudflare, you’d need to enable development mode and clear the Cloudflare cache before committing your stylesheet update so that user’s browsers do not cache Cloudflares cached version of your stylesheet :).

Fingerprinting generates a unique hash when you recompile your stylesheet. This means that the file name changes every time you commit your stylesheet. Cloudflare and the user’s browser will re-download the asset since the name changed.

We can also minify our stylesheet to reduce the file size. Resources functions like toCSS, minify, and fingerprint can be chained!

6. Add fingerprinting and minification to your stylesheet:

{{ $styles := resources.Get “scss/main.scss” | toCSS | minify | fingerprint }}

7. Add .Data.Integrity to fingerprinted resources.

<link rel=”stylesheet” href=”{{ $styles.Permalink }}” integrity="{{ $styles.Data.Integrity" media=”screen”>

According to this issue, Data.Integrity should be added to fingerprinted resources to provide verification that changed files are not malicious.

Overwriting your theme’s SCSS

If you have an assets folder in the top-level of your project and an assets folder in your theme directory, Hugo will prioritize the top-level directory over the theme directory. This means that you can overwrite theme files without modifying the theme directory. This is similar to how Wordpress child themes work.

assets
  └── scss
  |   └── _accordian.scss
themes
  └── pancakes
  |   └── assets
          └── scss
              └── _accordian.scss

In our particular scenario, we plan to release a free, open source builder theme as a git submodule. This will allow us to push theme updates. However, we can provide user’s with guidance on how to safely overwrite theme layouts and scss files without conflicting with theme updates.

Combining JS files

Hugo 0.43 added resources.Concat, which means that we can combine JS files without using a bundler.

Directory priority is still the same:

assets
  └── js

themes
  └── pancakes
  |   └── assets
          └── js

JS within the top-level assets folder will overwrite identically named JS within the theme assets folder.

1. Create resources out of your JS files in your assets folder:

{{ $vendor := resources.Get "js/vendor/jquery.min.js" }}
{{ $customjs := resources.Get "js/main.js" }}

2. Create an array using slice:

{{ $scripts := slice $vendor $customjs | resources.Concat "app.js" | minify | fingerprint }}

In this example, resources.Concat generates the filename “app.js” in the resources directory. Files are combined based on the argument order.

Chain minify and fingerprint to reduce page load time and force a cache refresh.

3. Link to the generated resource

<script type="text/javascript" src="{{ $scripts.Permalink }}" integrity="{{ $scripts.Data.Integrity }}" media="screen"></script>

Make sure you use integrity to verify the authenticity of files that use a hash (like fingerprinted files).

Hugo’s bright future

This new version of Hugo added a few other fantastic features, such as image processing and the ability to use Go within resources.

Resize, crop, and re-sample programmatically.

A user uploaded image via a CMS like Forestry.io could now result in several generated resources, such as a cropped or scaled thumbnail.

For example, a cropped thumbnail for a blog archive page:

A full-size version of the image for the actual blog post:

Cropped thumbnails are essential for a blog and are a standard for content management systems like Wordpress. A blog archive page needs to use cropped or scaled down versions of the post’s featured image to avoid horrendous page load speed from downloading several full-size images.

One work around for this problem is to upload two variations of the featured image, but now we can simply include image processing within the layout!

Using Go within resources

This requires further exploring, but this likely means that you could use page or site-level variables to manipulate stylesheets. Users could potentially use front matter to define Sass variables (though you have to be careful with this approach). This is particularly game-changing if you overlay a CMS like Forestry.io and use Data files to provide Wordpress-like theme options. Users could have direct access to modifying the look and feel of their theme without writing any code.

Bridging the gap

Static site generators are increasingly becoming more accessible to non-developers. The latest update from Hugo will enable normal users to benefit from the speed and functionality of Hugo without writing a line of code themselves.

• Netlify’s one-click deploy enables simple deployment of Hugo with a pre-installed theme. It also enables contact forms for static sites and simple one-click SSL install.
• Forestry.io gives users a familar and easy to use interface while allowing developers to provide simple fields for modifying layouts and styles.
• Hugo’s fast build time, markdown shortcodes, newly added asset pipeline, image processing, and ability to modify stylesheets using front matter, make it a worthy static competitor to Wordpress.

What’s missing?

This combination allows us to produce a one-click deploy theme that integrates with Forestry.io to provide users with a flexible page builder similar to Wordpress page builders like Divi, Visual Composer, and Beaver Builder.

In the coming weeks we will release a free, open source Hugo theme that enables users to easily build page layouts without writing a line of code or using Git.

Follow me on Twitter: https://twitter.com/BenBozzay

How to cache-bust and concatenate JS and SASS files with Hugo in 2018 was originally published in Fullstack Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hugo 0.43 added the ability to execute a resource as a Go template, meaning template variables can now be used to modify stylesheets.

With the addition of Hugo Pipes comes default support for SASS/SCSS. One of the biggest advantages of using SCSS is the ability to define variables that are used throughout your stylesheet and organize styles into partial files.

The addition of resources.ExecuteAsTemplate in 0.43 means that we could, for example, use our config file to define the values for our SCSS variables!

Using Hugo’s variables or params in SCSS files could allow a non-technical user to use a CMS like Forestry.io to easily change styles without any understanding of stylesheets or SASS.

Furthermore, we could significantly reduce the size of our stylesheet by conditionally importing SCSS (more on this in the next tutorial).

As our team wraps up development of Pancakes Builder (an open source builder theme for Hugo), we were thrilled with this particular release. Our original solution for user-defined styles was to inline some styles. Now, we’ve refactored the theme to use template variables to define our SCSS variables.

The theme also contains numerous elements like sliders, accordions, contact forms etc.. However, a user will probably not use all supported elements. Our styles and JS are now conditionally included based on the elements in use.

How to use template variables within SCSS

Refer to my last tutorial on how to use SASS with Hugo in 2018 and Hugo’s new resource functions.

1. Add template support to your stylesheet

We’ll add template support to main.scss, which imports our partial SCSS.

{{ $styles := resources.Get “scss/main.scss” | resources.ExecuteAsTemplate “style.main.scss” . | 
toCSS | 
minify | 
fingerprint }}

Note: it does not seem like you can currently use this method with partial SCSS files (such as _variables.scss).

resources.Get creates a new resource object based on a path to a file in the /assets directory. Then, we use resources.ExecuteAsTemplate with the resource type prepended to the name of the file. We add . to pass the context (more on this later). We then chain the toCSS function (to compile our SCSS to CSS), minify (to reduce file size), and fingerprint for cache-busting.

In the code snippet above, resources.Get generates a file in the resources directory:

We can now link to the newly generated resource:

<link rel=”stylesheet” 
href=”{{ $styles.Permalink }}” 
integrity=”{{ $styles.Data.Integrity }}” 
media=”screen”>

Make sure to use Data.Integrity with fingerprint (here’s why).

2. Add Sass variables to main.scss

Since we can’t use template variables within our partial files, but we can use them within our main.scss file, we simply need to define our variables at the top of main.scss (above any imported files).

3. Create Hugo variables or params

We could use .Params (in our config file), Data files, or even page variables within our stylesheet. It’s best to define site-wide variables in the config file or data files.

• Using config.toml:

In our config file we add a few params: container_size with a value of 1080px and container_size_wide with a value of 1350px.

Now we include these values in main.scss using .Site.Params:

{{ .Site.Params.container_size | default "1100px" }}

Since we will reference our $container style variable throughout our template, we do not want an empty value.

On the off chance that a user does not set a value for the variable, the default value will be used. It is critical that you have fallbacks for style variables that use template variables/params!

In our _layout.scss file we reference our SCSS variable as normal, but it’s now based on the value for the param in .config.toml!

• Using a data file and YAML/front matter

Our data file “colors” will be used to set the primary color variable used in our SCSS files.

Our data file has several fields:

We’ll referenceprimary_color using:

{{ .Site.Data.color.primary_color | default "#7a8288" }}

Now our $primary-color SCSS variable is based on the value for the primary_color variable in our data file!

Limiting potential values and maintaining valid variables

We can use default to provide a fallback for empty values. However, we also need to make sure that only supported values are used.

For example, our color fields require a # if a hex value is used. We don’t want to preprend this to our template variable because the user might decide to use rgba instead.

We can use field types in a CMS like Forestry to control field values based on the field type.

For example, we can use the color picker field to generate a hex code with the # automatically added:

We could also limit supported values using a select drop down field:

What’s next?

The next tutorial will cover how to signficantly reduce CSS and JS file sizes by conditionally including CSS based on the components used on the page. Follow me on Twitter to get notified when the next tutorial is ready!

How to use Hugo template variables in SCSS files (in 2018) was originally published in Fullstack Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today we’ll learn the best way to create a grid to easily display content, like Wordpress posts, with minimal media queries required for the responsive views.

We frequently see websites using a multi-row setup to organize similar content:

<div class="row">
  <div class="col">
    ...
  </div>
  <div class="col">
    ...
  </div>
</div>

<!--next row-->
<div class="row">
  <div class="col">
    ...
  </div>
  <div class="col">
    ...
  </div>
</div>

Using multiple rows complicates the responsive layout significantly:

Notice how extra whitespace is created in responsive views due to columns being seperated into rows. The columns don’t fill up the remaining space, so some screen sizes have an odd looking whitespace.

On mobile, some columns appear to have a bigger vertical whitespace because of the row’s margin-bottom. This looks sloppy!

We could adjust the media queries for the rows and columns, but this requires a lot of tweaking to get right.

Using flexbox, we can easily create a responsive grid:

In many situations, you’d want to use Ajax-load-more or filters to dynamically display content on a page, so a grid-layout would be needed.

For example, as part of our web presence overhaul for {code}, Open Source at Dell Technologies, we created a page for dynamically displaying posts based on filter and sorting options.

We created a grid layout so that posts could easily be appended without breaking the layout. In this tutorial, you’ll learn how to re-create this post grid.

Creating the responsive grid

Making the grid items responsive is easy using Flexbox.

Let’s examine the wrapping elements:

<div class="container">
      <div class="grid-row">
        ...

All of our grid-items (columns) are wrapped with one row and one container.

.container {
  max-width: 1335px;
  margin: 0 auto;
}

.grid-row {
  display: flex;
  flex-flow: row wrap;
  justify-content: flex-start;
}

Our container CSS sets the total max-width. Using display: flex, our grid-row stretches to the full size of the container.

We use flex-flow: wrap to designate that child divs (our columns/grid-items) should wrap if they exceed the width of the row. Then, flex-flow: row means our grid-items will flex from left to right. If we used flex-flow: column, our child divs would flex from top down.

Then, we use justify-content: flex-start because we want our grid-items to line up next to each-other at the start of the row.

Creating the grid item

Each grid-item should have identical height, so we set a height of 550px:

.grid-item {
  height: 550px;
  flex-basis: 20%;
  -ms-flex: auto;
  width: 259px;
  position: relative;
  padding: 10px;
  box-sizing: border-box;
}

On desktop views, we set a flex-basis of 20% for each grid-item. This means that 5 grid-items will display on the same level. The 6th grid-item will wrap to the next “row” since we are using flex-wrap: wrap in our grid-row.

We set a width of 259px for certain browsers that require a width to be defined. However, the actual width is set by flex-basis.

Media Queries

We only need a few media queries on our .grid-item. We just need to define the flex-basis on each desired screen-width.

Based on the content within our grid-items, we used these media queries:

.grid-item {
  height: 550px;
  flex-basis: 20%;
  -ms-flex: auto;
  width: 259px;
  position: relative;
  padding: 10px;
  box-sizing: border-box;
}

@media(max-width: 1073px) {
   .grid-item {
    flex-basis: 33.33%;
  }
}

@media(max-width: 815px) {
  .grid-item {
    flex-basis: 50%;
  }
}

@media(max-width: 555px) {
  .grid-item {
    flex-basis: 100%;
  }
}

On the smallest screen-width, we use a flex-basis of 100% to make our grid-item the full-width of the grid-row.

If you’re building for mobile-first, you should adjust your CSS this way:

.grid-item {
  height: 550px;
  flex-basis: 100%;
  -ms-flex: auto;
  width: 259px;
  position: relative;
  padding: 10px;
  box-sizing: border-box;
}

@media(min-width: 1073px) {
  .grid-item {
    flex-basis: 33.33%;
  }
}

@media(min-width: 815px) {
  .grid-item {
    flex-basis: 50%;
  }
}

Our .grid-item defaults to a flex-basis of 100% unless the screen size is a large tablet or a laptop/desktop.

With either approach, we only need to change the flex-basis for a few screen-widths to achieve a grid.

Cross-browser support

The CSS in this tutorial doesn’t cover all of the vendor prefixes required when using flexbox. If you’re using a build tool, make sure you use PostCSS with autoprefixer to automatically add all the required vendor prefixes. You can also generate these vendor prefixes by pasting your CSS into an autoprefixer tool like this one.

Finishing up

View the full source code, which also includes the styles for the content in each grid-item and the hover/grow effects. Follow me on Twitter for more upcoming tutorials, like achieving a perfect page speed score in Google PageSpeed insights.

How to Create a Flawless Responsive Post Grid with Flexbox was originally published in Fullstack Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the best ways to optimize a website for load speed is to inline critical CSS and defer loading of non-critical CSS. Google PageSpeed insights refers to this optimization as “eliminating render-blocking JavaScript and CSS in above-the-fold content.”

You can achieve a much faster load speed by inlining styles required to render the top area of your website in the <head> of each page’s HTML:

However, extracting critical CSS for larger websites with many unique page layouts is easier said than done.

As we work on the initial release of Pancakes Builder, a free visual website builder for Hugo, we had to solve the issue of achieving a fast page load speed for every variation of a page that a user might decide to build.

Pancakes Builder leverages a modular design where sections are stacked to construct the actual layout and content. For non-templated pages that are built with stacks of sections, we had to solve some pretty substantial optimization issues:

• Normally, a user has to download the entire stylesheet before the page is rendered and this causes a noticeable delay in the first page load.

Solution: Inline critical CSS so that the render blocking CSS loads with the page’s HTML. Then, load non-critical CSS asynchronously.

• Some users of Pancakes Builder will build websites that never use elements supported by the builder — accordions, sliders, etc.. We don’t want to bundle styles for unused components.

Solution: Generate a cacheable site-wide stylesheet composed only of the styles of all non-render blocking sections.

Creating a Modular Layout

Modular layouts allow a user to build a unique page by stacking sections. If we adjust our Hugo theme to use a modular layout we can do a lot of cool stuff.

To create a modular layout, we’ll adjust our template to use partial files to build pages by stacking sections.

Sections are partial files with a predefined layout.

We can then use front matter, or another preferred method, to designated what sections appear on our page and in what order.

For example, the Forestry content management system supports building flexible layouts using their blocks widget, which basically provides a simple UI for repeating front-matter fields:

The page front-matter for these blocks would probably look like this:

blocks:
  - template: "hero-section"
  - template: "body-copy"
  - template: "hero-section"
  - template: "media-feature"
  - template: "media-feature"
  - template: "media-feature"
  - template: "call-to-action"

Partial files with pre-built layouts are then added based on the template name in the front-matter:

{{ range .Params.page_sections }}
    {{ if eq "hero-section" .template }}
        {{ partial "blocks/hero" . }}
    {{ end }}
    {{ if eq "call-to-action" .template }}
        {{ partial "blocks/cta" . }}
    {{ end }}
{{ end }}

We can apply this same concept to generating the critical and non-critical styles associated with the used blocks across our website.

1. Build a flexible layout with front matter

In our page front matter, we add a range called “stacks” with a few templates:

---
title: "Home Page"
stacks:
- template: header-builder
- template: hero-builder-section
- template: contact-builder-section
- template: footer-builder

These templates will be used to specify partial files. Notice that we are even including the header and footer in our range. This is because we will use this range to extract CSS from all used sections.

We can then create a loop of sections in our main layout file:

// Check if the "stacks" key exists in our front matter

{{ if .Params.stacks }}

// Iterate through each stack
{{ range $index, $stacks := .Params.stacks }}

{{ if in .template "header" }}
<header>
  ...
</header>

{{ else if in .template "section-hero-image" }}
<section>
  <div class="hero">
    ...
  </div>
</section>

{{ else if in .template "section-form" }}
<section>
  <form>
    ...
  </form>
</section>

{{ else if in .template "footer" }}

<footer>
...
</footer>
...

The display order of the sections on our page will match the order in our front-matter. For the purposes of this tutorial, I have not included many different section variations.

2. Add classes to HTML

We’ll need to append a unique class to each section in our HTML. Let’s generate a few unique classes:

1. One class designating the template name used in our front matter. We’ll need this for our base styling (styles used for multiple sections).
2. One class with the unique section identifier. We’ll need this for our non-critical stylesheet and to apply unique styles to a single section.

In our range we’ll add the .Scratch values to generate classes for each section.

{{ range $index, $stacks := .Params.stacks }}

{{ $.Scratch.Set "section_base" .template }}

{{ $section_style := print $index "-" .template }}
{{ $.Scratch.Set "section_style" $section_style }}

{{ $.Scratch.Set "page_hash" .UniqueID | urlize }}

{{ $id := print "section-" $index }}
{{ $.Scratch.Set "section_id" $id}}

{{ if in .template "header" }}
<header id="{{ $.Scratch.Get "section_id" }}" class="{{ $.Scratch.Get "section_base" }} c-{{ $.Scratch.Get "section_style" }} p-{{ $.Scratch.Get "page_hash" }}">
  ...
</header>
{{ else if in .template "section-form" }}
<section id="{{ $.Scratch.Get "section_id" }}" class="{{ $.Scratch.Get "section_base" }} c-{{ $.Scratch.Get "section_style" }} p-{{ $.Scratch.Get "page_hash" }}">
  <form>
    ...
  </form>
</section>
...

We use .Scratch instead of normal variables so we can easily access these variables in our partial files and change their values from within our partials.

Since we’ve attached an index to our range (think of this as a “counter”), we can generate a section_id based on the order of our section within the range:

{{ $id := print "section-" $index }}
{{ $.Scratch.Set "section_id" $id}}

The output will look like this: section-1.

We can also create a general class based on our section-template used for our base CSS:

{{ $.Scratch.Set "section_base" .template }}

The output will look like this: section-form.

For specific section styling, we’ll create another scratch called section_base that prepends “c” with the index number and template name:

{{ $section_style := print $index "-" .template }}
{{ $.Scratch.Set "section_style" $section_style }}

The output will look like this: c-2-section-form.

We’ll create a scratch called page_hash with the page UniqueID and add this unique identifier to each section in our range:

{{ $.Scratch.Set "page_hash" .UniqueID | urlize }}

This is necessary so we can target unique sections on other pages.

Example output in the HTML:

<header id="section-0" class="c-header-builder p-123sdf6521341dsfa">
...
</header>

<section id ="section-1" class="form-builder-section c-1-form-builder-section p-123sdf6521341dsfa">
...
</section>

In our stylesheet, we can use .form-builder section {…} to add the base styles for our form. We can then use .p-123sdf6521341dsfa.c-1-form-builder-section {…} in our stylesheet to target the unique styles for a specific form-builder section on a specific page.

We can uniquely target sections in our stylesheet while applying base styles if needed:

/*base header style*/
header {
  background: #ffffff;
  height: 80px;
}

/*override the base color for this particular page and section*/
.c-0-header-builder.p-123sdf6521341dsfa {
  background: #efefef;
}

Later in this tutorial, we will use template variables to specify these classes automatically:

header {
  background: #efefef;
  height: 80px;
}

/*header style for this particular page and section*/
.c-{{ $.Scratch.Get "section_class" }}.p-{{ $.Scratch.Get "page_hash" }} {
  background: #efefef;
}

Now that our HTML is generated, we can focus on generating styles.

Generating our critical inline style

We create partial files for a typical section and unique elements. The folder structure looks something like this:

partials
├── sections
│   ├── section
│   │   ├── style.html
│   │   ├── base.html

• Style.html: contains the unique style for a specific section and overrides the base style.
• Base.html: the standardized base style of our section. The default color, size, etc.

Our overall strategy is to iterate through each section on each page. We’ll then grab the individualized section style for each section. Then, we will include the base.html only once. and the base style for whatever elements are in use in that section.

1. Create css_gen.html with section styles

Let’s start by creating a partial layout file that contains our generated CSS. We’ll use Hugo pipes to generate a resource from this file later on.

We’ll include this partial file in our inline header style (for critical css) and our non-critical stylesheet that we load asynchronously.

Add this partial between <style> tags in the head and footer of your site:

<style>{{ partial “site/css_gen.html” (dict “page” . “global” $ ) }}</style>

We’ll then pass the current context using dict so that we can use page-level and global variables in our partial file. We can now access page context (“the dot”) using .page and global context ($) using .global.

Normally, outside of a partial file we can access page params with {{ .Params }}. In our css_gen partial file, however, we will access page params with {{ .page.Params }}.

Our css_gen.html file will start by looking similar to the main layout file with our section loop:

// get each page
{{ range $index, $stacks := .page.Site.Pages }}

// check if the "stacks" key exists in our front matter

{{ if .Params.stacks }}

// iterate through each stack
{{ range $index, $stacks := .Params.stacks }}

// set a section ID based on the index
{{ $.page.Scratch.Set "section_index" $index }}

// set one class based on the front matter template value
{{ $.page.Scratch.Set "section_base" .template }}

// set a class with index prepended
{{ $section_style := print "c-" $index "-" .template }}
{{ $.page.Scratch.Set "section_style" $section_style }}

// set a class with page uniqueID
{{ $.Scratch.Set "page_hash" .UniqueID | urlize }}

{{ if in .template "header" }}
{{ partial "sections/header/style.html" (dict "page" . "global" $ ) | safeCSS }}

{{ else if in .template "section-form" }}
{{ partial "sections/section-form/style.html" (dict "page" . "global" $ ) | safeCSS }}

{{ else if in .template "footer" }}
{{ partial "sections/footer/style.html" (dict "page" . "global" $ ) | safeCSS }}
...

The main difference is the included style partial files, which use dictto pass the context and safeCSS to designate safe output.

In our page front matter, we can designate some styles for our specific section:

stacks:
  - template: "header"
  - template: "section-form"
    background-color: "#efefef"
  - template: "footer"

Our style.html for section-form looks like this:

{{ if .page.background_color }}

.{{ .global.page.Scratch.Get "section_class" }}.p-{{ .global.page.Scratch.Get "page_uniqueid" }} {
  background-color: {{ .page.background_color | default "#ffffff" }};
}

{{ end }}

You can use default values, isset, with, and other Hugo functions to control default and conditional stylesheet content.

Output:

.c-1-section-form.p-123sdf6521341dsfa {
  background-color: #efefef;
}

2. Add base styles to css_gen.html

Base styles are only included once, while section styles are included each time a style is used for a particular section. We can use .Scratch to “activate” a base style and include the style outside of our range:

{{ range $index, $stacks := .page.Site.Pages }}
{{ if .Params.stacks }}
{{ range $index, $stacks := .Params.stacks }}
...

{{ else if in .template "section-form" }}
{{ partial "sections/section-form/style.html" (dict "page" . "global" $ ) | safeCSS }}

{{ $.page.Scratch.Set "form_base_css" true }}
...
// End of stacks range
{{ end }}
// End stacks conditional
{{ end }}
// End of page range
{{ end }}

// Include the base CSS for the form section only once
{{ if eq ( $.page.Scratch.Get "section_base_css" ) true }}
{{ partial "sections/section-form/base.html" (dict "page" . "global" $ ) }}
{{ end }}
...

Using .Scratch, we can choose to include the base CSS if the section exists. Scratch allows us to specify a variable within our range and pass that value outside of the range.

3. Specify critical and non-critical CSS

Our current css_gen file doesn’t specify critical or non-critical CSS. To do this, we need to limit our range to the first 2 sections for our critical CSS. Our non-critical CSS range will need to a range greater than 2. Since we want to use the same css_gen file and avoid duplicating work, we’ll need to adjust our current stacks range.

Don’t Repeat Yourself is the perennial mantra of the software developer. It doesn’t mean you should never do the same thing twice, but instead refers to having a single, authoritative source of truth for every piece of information used in your software. — DJ Walker

Let’s adjust where we include our partial file. In our head where we specify inline critical CSS:

{{ $.Scratch.Set "is_critical" true }}

{{ $env := getenv "HUGO_ENV" }}

{{ if or (.Site.IsServer) (eq $env "") }}

<style>{{ partial "site/css_gen.html" (dict "page" . "global" $ ) | safeCSS }}</style>

{{ end }}

We add a new scratch allowing us to pass a true/false value to our partial file.

We include an environment variable so that we can check if we’re in production or staging and then output different content. We use .IsServer to check if we’re using hugo server locally. We’ll use this more later on, but for now just know that there are certain functions we only want to use in our staging and local environments.

In our footer file where we include non-critical CSS:

{{ $.Scratch.Set "is_critical" false }}

{{ partial "site/css_gen.html" (dict "page" . "global" $ ) }}

// For IsServer just inline the style

{{ $env := getenv "HUGO_ENV" }}

{{ if or (.Site.IsServer) (eq $env "") }}

<style>{{ partial "site/css_gen.html" (dict "page" . "global" $ ) | safeCSS }}</style>

{{ end }}

In our footer, we set is_critical to false. We’ll add a conditional statement within our range:

// Get this current page UniqueID
{{ $this_uniqueid := .page.UniqueID | urlize }}
{{ range $index, $stacks := .page.Site.Pages }}

// Get the unique ID for each page
{{ $page_uniqueid:= .UniqueID | urlize }}
{{ if .Params.stacks }}
{{ range $index, $stacks := .Params.stacks }}

// Check for true/false value in outer template
{{ if eq ($.page.Scratch.Get "is_critical") true }}

// Get the styles for this page with an index of 0 and 1
{{ $.page.Scratch.Set "style_index" (and (eq $this_uniqueid $page_uniqueid) (le $index 1)) }}

// Non-critical CSS
{{ else }}

// Get the styles for all sections on all pages with an index greater than 1
{{ $.page.Scratch.Set "style_index" (gt $index 1) }}

{{ end }}

// Our condition is now based on a scratch value
{{ if $.page.Scratch.Get "style_index" }}

// Include partial files
...

Two UniqueIDs are added so that we can get the inlined critical CSS. Then, we use the is_critical scratch value to specify our style_index scratch value.

The conditional for our critical CSS looks like this:

...
{{ if and (eq $this_uniqueid $page_uniqueid) (le $index 1) }}
...

{{ else if in .template "section-form" }}
{{ partial "sections/section-form/style.html" (dict "page" . "global" $ ) | safeCSS }}

{{ $.page.Scratch.Set "form_base_css" true }}
...

If the Unique ID of this page equals the Unique ID in our current range, the resulting style.html and base.html for sections 0 and 1 will be inlined in the <head> of our template.

The condition for our non-critical CSS looks like this:

...
{{ if gt $index 1 }}
...

{{ else if in .template "section-form" }}
{{ partial "sections/section-form/style.html" (dict "page" . "global" $ ) | safeCSS }}

{{ $.page.Scratch.Set "form_base_css" true }}
...

style.html and base.html for all non-critical sections on all pages are included.

Using PostCSS and asset pipelines in production

Now that we’ve generated our HTML and set up our critical and non-critical CSS generation, we can focus on processing our CSS using Hugo’s resource functions.

1. Create critical and non-critical stylesheets

In assets/scss/ we’ll create a critical and non-critical stylesheet with the same partial file included:

// in assets/scss/critical.scss and assets/scss/non-critical.scss

{{ partial “site/css_gen.html” (dict “page” . “global” $ ) }}

Note: make sure you place your files in the assets directory since we are using Resource functions. Also, Resource functions respect Hugo’s lookup order, so you can place the associated assets in your theme assets folder or the top-level assets folder.

2. Set up Hugo Pipes

Let’s go back to our head where we include our critical CSS:

{{ $.Scratch.Set "is_critical" true }}
{{ $env := getenv "HUGO_ENV" }}

// Inline uncompressed styles if we're in a dev environment
{{ if or (.Site.IsServer) (eq $env "") }}
<style>{{ partial "site/css_gen.html" (dict "page" . "global" $ ) | safeCSS }}</style>
{{ end }}

// Inline minified and PostCSS styles if we're in production or have set a testing param
{{ if or (eq $env "production") (eq .Site.Params.postcss_testing true) }}

// Generate a resource and inline the resulting processed CSS
{{ $critical := resources.Get "scss/critical.scss" | resources.ExecuteAsTemplate "style.critical.scss" . | toCSS |postCSS | minify }}

// Display the content from our resource
<style class="critical">{{ (slice $critical | resources.Concat "style.scss").Content | safeCSS }}</style>

{{ end }}

We can use Hugo pipelines to generate a CSS resource from our HTML so we can minify our output and add vendor prefixes. Otherwise our inlined CSS will have significant whitespace and won’t be minified. If we’re using hugo server we’ll just inline the HTML instead of processing a resource each time we save the site.

I recommend adding a postcss_testing parameter so you can test the critical and non-critical CSS processing in your dev environment.

If you don’t care about vendor prefixes, you can probably just avoid this step entirely (only for critical CSS) and use the new (0.47) minify flag to compress your HTML.

Let’s go back to our footer where we include our non-critical CSS:

{{ $.Scratch.Set "is_critical" false }}
{{ partial "site/css_gen.html" (dict "page" . "global" $ ) }}
{{ $env := getenv "HUGO_ENV" }}

// Inline the style if we're in a dev environment
{{ if or (.Site.IsServer) (eq $env "") }}
<style>{{ partial "site/css_gen.html" (dict "page" . "global" $ ) | safeCSS }}</style>
{{ end }}

// Include a link to the non-critical stylesheet in production
{{ if or (eq $env "production") (eq .Site.Params.postcss_testing true) }}

{{ $noncritical := resources.Get "scss/noncritical.scss" | resources.ExecuteAsTemplate "noncritical.scss" . | toCSS | postCSS | minify | fingerprint }}

<link rel="stylesheet" href="{{ $noncritical.Permalink }}" media="screen">

{{ end }}

Our non-critical stylesheet reference is similar, but we include a link to the stylesheet instead of inlining it. Additionally, we use fingerprint for cache-busting. For a more comprehensive tutorial on Hugo pipes, read this tutorial from Regis.

Sample critical output with PostCSS:

Notice that sections 0 and 1 are included and have the same pageID.

Non-critical stylesheet with PostCSS, fingerprint, and minify:

Notice that sections with an index greater than 2 are included and there are many different page IDs referenced in the stylesheet.

Wrapping up

In this tutorial I’ve included a more simplified version of building sections with stacks of sections (blocks, partial files etc.).

As I’m developing Pancakes Builder, I actually include only one partial section layout instead of multiple pre-built section layouts (like section-form). Then, I use front-matter to make each section completely unique. I pull out base and individual styles for each element included in each section:

partials
├── section
│   ├── style.html
│   ├── base.html
├── elements
│   ├── element
│   │   ├── style.html
│   │   ├── base.html

This method allows for some pretty cool stuff, such as overlaying a visual builder that generates the front-matter required to build each partial layout.

Follow me on Twitter: https://twitter.com/BenBozzay

How to Automatically Generate and Inline Critical CSS with Hugo Pipes was originally published in Fullstack Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

If your website has poor domain authority due to lack of backlinks, it may seem impossible to attract any significant traffic from search engines like Google. If you’re launching a new website or trying to get more out of your current low-rated website, your strategy does not necessarily need to depend on link building.

This year, we overhauled the SEO of a poor performing website that had been around for several years. The website had 17 articles with a good mix of long-form content, but it had no backlinks.

Initially, it might seem like the problem was a lack of link-building. However, in just 3 months, we grew organic traffic by over 400% — from 450 to 2300/month — without any link building or adding any additional content.

Instead of focusing on link building, we re-worked the website to focus on what Google prefers in 2018.

Google’s AI looks for UX indicators

RankBrain is Google’s automated approach to adjusting search results based on user behavior.

RankBrain focuses on how users interact with the results and adjusts the ranking of content that provides the best user experience.

It’s one of the main reasons that it’s possible to rank for content without backlinks. RankBrain adjusts the necessity for backlinks depending on the keywords a page is optimized for.

In our situation, we noticed a large gap in useful content on the SERPs for keywords we wanted to rank for. Using a user experience tool called Fullstory, we also saw a clear need to overhaul the existing content on the website.

Bounce rate due to UX issues and relevancy

Google analytics allows us to see the time on page and bounce rate for most users, so we could clearly see that some content either didn’t match the search intent (explained later in this article), or it wasn’t useful to the user.

We used Fullstory to watch session replays (literally watching someone read the content) so that we could see where a user lost interest. These observations helped us identify poor performing content.

Meta descriptions should appeal to the right user

The existing meta descriptions were over-optimized for keywords and not particularly appealing to humans, which probably lead to a low click through rate. Meta descriptions should focus on appealing to the user the page is positioned for.

Topic and keyword research

After taking an initial topic and breaking it down into a keyword matrix, we were able to generate a list of new focus keywords and topics that would appeal to the target audience. Then, we adjusted the existing information architecture to use the SEO silo approach.

In short, it’s important to create content focused on specific topics, group that content, and then link between related content. Identifying content gaps for specific search terms allowed us to find better focus keywords and semantically related keywords that we could rank for without backlinks.

Targeting based on intent

Keyword research and content strategy should always examine the SERPs for a specific search term. Modern search engines personalize results by various factors like location and device (mobile/desktop).

However, Google serves different types of personalized search results based on search intent.

A search phrase like “buy running shoes” usually displays results for nearby stores based on the user’s location.

While a search phrase like “best laptops 2018” yields different types of results — mostly websites that compare recently released laptops.

Modern technical SEO isn’t just about robots

Technical SEO used to focus almost entirely on how search engines could understand a website. In 2018, technical SEO also includes user experience factors.

Websites need to be leaner, not just faster

Google prioritizes fast, mobile-friendly websites in the search results because those websites offer a better user experience.

The wide availability of high-speed internet means that most users are able to quickly load most websites, but Google is still pushing for websites to use lean development practices.

One reason this is so important is that most users are browsing on mobile phones on limited data plans.

Google is pushing for a leaner, faster web, so it makes sense that the ranking algorithm would prioritize these leaner websites. In fact, a leaner approach is important enough to Google that they launched an Open Source initiative called AMP, which is a lean approach to developing for mobile.

Accelerated Mobile Pages (AMP)

AMPs are lightweight versions of your existing web pages. AMP isn’t the same as responsive design: it’s about only serving critical resources required to render the page for the mobile user.

With so many users browsing the web on phones, Google prefers AMP websites in mobile search results.

In addition to the ranking benefit, mobile users are more likely to notice a search result with the AMP tag:

Google doesn’t want websites to just implement responsive design frameworks, they want websites to reduce how much unnecessary “stuff” a user has to download to read a page. That’s where AMP comes in, and it’s definitely a ranking factor.

Securing the web

Security is a big deal in 2018 and it’s another factor Google takes into account when ranking a website. It’s one of the reasons that a SSL certificate is important.

Google directly stated that HTTPS is a “lightweight signal… while we give webmasters time to switch to HTTPS.” This was back in 2015. In 3 years, HTTPS has become the standard protocol and it’s safe to say that it’s a stronger factor now.

In 2018, Google started marking websites without a SSL certificate as “not secure.”

Focusing on maintaining website security also mitigates the chances of a catastrophic SEO event: a SERP security warning and potential delisting of a website.

SEO in 2019 and beyond

As Google continues to use AI to improve search and personalize results, you can future proof your SEO efforts by focusing on user experience and content positioning.

Specifics regarding the case study mentioned in this article available on request. For obvious reasons, we cant make identifying information public. Contact me if you need help with your SEO strategy.

Follow me on Twitter: https://twitter.com/BenBozzay

How to Increase Search Traffic for a Low Rated Website in 2018 was originally published in Fullstack Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

Fraud has stained the crowdfunding community in general, but has especially impacted disease-related crowdfunding campaigns.

In February, a Florida family was charged with faking their child’s brain cancer to raise financial support for bogus medical costs. In another story, a woman attracted over $10,000 in donations using a false cancer claim.

When it comes to crowdfunding for disease, verifying the authenticity of the campaign is absolutely necessary. Trust and authenticity allow struggling families to raise more money from the general public.

Childhood cancer deserves better crowdfunding

Due to lack of federal funding, the childhood cancer community relies on crowdfunding and generous support from cancer foundations like Arms Wide Open.

Generic crowdfunding platforms do not verify the legitimacy of a fundraiser until after it is reported as fraudulent. Transaction fees also reduce the actual amount of funds raised.

A crowdfunding platform should focus on a specific niche so that the fundraisers benefit from the network effect of the platform.

Verified crowdfunding with Wordpress

We partnered with Arms Wide Open to build a crowdfunding platform focused on the childhood cancer niche. Our #1 goal was to create a system that made it easy to only publish verified fundraisers and allow families to keep 100% of the raised funds.

For this particular project, we decided to use WordPress to power the website.

We developed a simple, multi-step submission process that helped users easily submit the required verification information along with their campaign description.

During the campaign creation process, the user must enter in medical information that allows a volunteer to verify a child’s diagnosis.

Arms Wide Open manually approves and verifies each campaign individually, so a custom submission process was critical to their needs. Once a user submits their campaign for approval, the admin can easily publish the campaign after the medical information is verified. This provided a simplified administrative process, enabling foundation volunteers to easily manage the website.

Since users have ownership over their campaign, we decided to create a simplified dashboard providing an overview of useful statistics about the user’s published campaigns such as progress towards goals, share counts, contributors and more.

Simplifying the user dashboard to only show relevant information significantly reduced support requests and provided users with a quick snapshot of their overall fundraiser performance.

With most users typically submitting fundraisers while in a hospital on a mobile device, it was critical the entire process was simplified for mobile.

Most users were referred by Facebook, so adding a one-click login with Facebook that immediately directed to the fundraiser creation page streamlined the process for mobile users.

Impact

To date, Helping Hands campaigns have raised over $450,000 for childhood cancer patients and their families. Arms Wide Open covers all transaction fees to ensure families keep 100% of any funds raised. Helping Hands is completely free and all costs are completely covered by Arms Wide Open. For every $10,000 raised, Arms Wide Open covers approximately $300 in transaction fees.

Follow me on twitter https://twitter.com/BenBozzay. Check out my latest project, a content filter.

Solving Crowdfunding Fraud with WordPress was originally published in Fullstack Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

Thoughtful logo design requires a designer to distill the essence of a brand into shapes and colors. In an overly crowded marketplace, one of the most important features of a brand is the ability to stand out and be memorable.

A successful logo is memorable and tells a compelling story about your brand without using any words

Enhancing a logo through animation further sets a brand apart from the competition. An animation can elegantly expand on your brand’s story.

The Fullstack Digital logo animation represents the 3 layers of services we offer: brand, web, and market.

In this tutorial I will show you how to recreate the Fullstack Digital logo using CSS animations.

Let’s start with animating the furthest left SVG shape as that is what appears first in the animation. Here is the starting code for the logo:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100%" height="100%" viewBox="0 0 792 519">
  <polygon class="clss-1" points="265.46 519 0 385.28 151.88 0 462.25 0 265.46 519"/>
  <polygon class="clss-2" points="430.34 519 322.94 464.08 499.23 0 627.12 0 430.34 519"/>
  <polygon class="clss-3" points="595.22 519 487.76 464.08 664.1 0 792 0 595.22 519"/>
</svg>

Each polygon shape within the SVG is defined by a class, .clss-1 being the polygon on the left, .clss-2 in the center, and .clss-3 on the right.

SVG order

The current order of the polygon shapes within the SVG will not work as the middle and right shapes would be in front of the left shape when we need them to be behind it.

Using the z-index CSS property will not work as the SVG Rendering Model states. SVGs will render elements in the order as they appear, so we will need to simply rearrange the order the of the polygon shapes like so:

...
  <polygon class="clss-3" points="595.22 519 487.76 464.08 664.1 0 792 0 595.22 519"/>
  <polygon class="clss-2" points="430.34 519 322.94 464.08 499.23 0 627.12 0 430.34 519"/>
  <polygon class="clss-1" points="265.46 519 0 385.28 151.88 0 462.25 0 265.46 519"/>
...

Animating the shapes

To create the animation, we use the CSS @keyframes rule. We can then name the animation and apply the transform property. Let’s start with animating the furthest left SVG shape as that is what appears first in the animation. For instance, we will need to create an animation that causes the left SVG shape to appear from the left side.

The animation will be broken down using percentages. 0% being the start of the animation and 100% being the end. We will have the shape expand and move to the left using the transform property with translate() and scaleX() functions:

@keyframes widthAni {
  0% {
    transform: translate(-30%, 0) scaleX(0);
  }
  20%, 75% {
    transform: translate(0, 0) scaleX(1);
  }
  95%, 100% {
    transform: translate(-30%, 0) scaleX(0);
  }
}

Calling the animation

Since the left shape is defined as .clss-1, we will apply the widthAni animation to run infinitely for 4 seconds and set the transform-origin by adding this to the CSS:

.clss-1 {
  animation: widthAni 4s ease-in-out infinite;
  transform-origin: center right;
}

Animating the rest

Only the left shape was animated and now all that is left is to animate the other two shapes.

Like the first one, the middle and right shape will use @keyframes rule with the transform property to animate. They will also use the opacity property during some parts of the animation to hide and appear:

@keyframes springOut {
  0%, 20% {
    transform: translate(-21%, 0%);
    opacity: 0;
  }
  21% {
    transform: translate(-20.5%, 0%);
    opacity: 1;
  }
  27% {
    transform: translate(-4.75%, 0%);
    opacity: 1;
  }
  31%, 55% {
    transform: translate(0%, 0%);
    opacity: 1;
  }
  67% {
    transform: translate(-20.5%, 0);
    opacity: 1;
  }
  68%, 90%, 100% {
    transform: translate(-21%, 0);
    opacity: 0;
  }
}

@keyframes springOutAgain {
  0%, 20% {
    transform: translate(-41.5%, 0%);
    opacity: 0;
  }
  21% {
    transform: translate(-41%, 0%);
    opacity: 1;
  }
  27% {
    transform: translate(-9.5%, 0%);
    opacity: 1;
  }
  31%, 55% {
    transform: translate(0%, 0%);
    opacity: 1;
  }
  67% {
    transform: translate(-41%, 0%);
    opacity: 1;
  }
  68%, 90%, 100% {
    transform: translate(-41.5%, 0%);
    opacity: 0;
  }
}

And apply the animation to their respective shapes. The animations play infinitely for 4 seconds:

.clss-2 {
  animation: springOut 4s ease-in infinite;
}

.clss-3 {
  animation: springOutAgain 4s ease-in infinite;
}

The animation is not infinite on the homepage of our website.

Vendor prefixes

For simplicity, the code above does not use any vendor prefixes. You will want to include them while working with CSS animations and @keyframes. In doing so, the animation will render properly within supported browsers.

For example, the widthAni animation for .clss-1 would have vendor prefixes like this:

@-webkit-keyframes widthAni {
 0% {
   -webkit-transform: translate(-30%, 0) scaleX(0);
   transform: translate(-30%, 0) scaleX(0);
 }
 20%, 75% {
   -webkit-transform: translate(0, 0) scaleX(1);
   transform: translate(0, 0) scaleX(1);
 }
 95%, 100% {
   -webkit-transform: translate(-30%, 0) scaleX(0);
   transform: translate(-30%, 0) scaleX(0);
 }
}

@keyframes widthAni {
 0% {
   -webkit-transform: translate(-30%, 0) scaleX(0);
   transform: translate(-30%, 0) scaleX(0);
 }
 20%, 75% {
   -webkit-transform: translate(0, 0) scaleX(1);
   transform: translate(0, 0) scaleX(1);
 }
 95%, 100% {
   -webkit-transform: translate(-30%, 0) scaleX(0);
   transform: translate(-30%, 0) scaleX(0);
 }
}

Conclusion

View it live on the Fullstack Digital homepage, or check out this codepen:

If you’d like to easily build blazing fast websites with flawless layouts, we’re releasing a free visual website builder soon. It’s a great alternative to Wordpress. Sign up for early access below:

When I’m not writing, I’m helping businesses go further, faster at Fullstack Digital. We provide digital brand strategy, design, development, and marketing for forward-thinking companies. Check out some of our work here.

How to create an animated logo with SVG and CSS animations was originally published in Fullstack Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this tutorial I will show you how to create a neat SVG background animation using CSS animation. This pattern was built for the Pancakes Builder landing page. Pancakes is an upcoming free website builder for Hugo, a powerful static site generator.

Creating the SVG

Start off by making a straight line with the <line> tag wrapped in the <svg> tag like this:

<svg width="100%" height="100%" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" preserveAspectRatio="xMidYMid">
  <line x1="0" y1="15" x2="100%" y2="15" />
</svg>

The width and height should be to 100% since the SVG will need to be stretched to fit the screen width and height. On <line>, the x1 and x2 values are defined as the horizontal starting and ending points of a line, while y1 and y2 are the vertical starting and ending points. The current values will create a simple, straight line that fills the screen width at 100%.

To create the dashes, we will use the stroke-dasharray property. The first value is the stroke size and the second is the space in between each dash. Let’s use CSS to define the values 66 and 16 to start like so:

line {
  stroke: #f4f4f4;
  stroke-dasharray: 66, 16;
}

Now you should have one simple dashed line. To increase the line stroke weight and give it rounded edges, you can define them with CSS:

line {
  ...
  stroke-width: 10;
  stroke-linecap: round;
  ...
}

Time to create the pattern. Adjust the code in the <svg>:

<svg width="100%" height="100%" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" preserveAspectRatio="xMidYMid">
  <defs>
    <pattern id="pancakes-pattern" x="0" y="0" width="100%" height="200" patternUnits="userSpaceOnUse">
      <line x1="0" y1="15" x2="100%" y2="15" />
    </pattern>
  <rect x="0" y="0" width="100%" height="100%" fill="url(#pancakes-pattern)"></rect>
</svg>

With CSS, set the height of <svg> to 100vh. The pattern will then cover 100% of the current viewport height. However, you will notice that there are some blank space in the pattern.

At this point it is just all about calculating how much space for each <line> on each row by changing the y1 and y2 values. Starting from the first <line> having y1 and y2 values of 15, add 25 each time for each row. In this instance, the next few <line> tags would look like the following:

...
      <line x1="0" y1="40" x2="100%" y2="40" />
      <line x1="0" y1="65" x2="100%" y2="65" />
      <line x1="0" y1="90" x2="100%" y2="90" />
...

Keep adding the values until the pattern does not have anymore blank space.

Nesting the <pattern>

To add the colored area to the pattern, the <svg> code is edited to be:

<svg width="100%" height="100%" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" preserveAspectRatio="xMidYMid">
  <defs>
    <pattern id="pancakes-pattern" x="0" y="0" width="100%" height="200"  patternUnits="userSpaceOnUse">
      <line x1="0" y1="15" x2="100%" y2="15" />
      ...
      <line x1="0" y1="215" x2="100%" y2="215" />
    </pattern>
    <pattern id="logo" x="0" y="0" width="100%" height="200" patternUnits="userSpaceOnUse">
      <line x1="0" y1="15" x2="100%" y2="15" />
      ...
      <line x1="0" y1="215" x2="100%" y2="215" />
    </pattern>
  </defs>
  <rect x="0" y="0" width="100%" height="100%" fill="url(#pancakes-pattern)"></rect>
  <rect x="22%" y="27%" width="250" height="150" fill="url(#logo)"/>
</svg>

And add this to the CSS:

#logo line {
  stroke: #ffd05e;
}

Animating the <pattern>

Using CSS animations, we can use the stroke-dashoffset property to animate the lines. First, set the <line> to have a value for stroke-dashoffset:

line {
  ...
  stroke-dashoffset: 82;
}

Then create a @keyframes rule and set the stroke-dashoffset to 0:

@keyframes lineMove {
  to {
    stroke-dashoffset: 0;
  }
}

Finally, use the CSS :nth-child selector for the <line> tag. Define them with odd and even values and have the even value play the animation in reverse like this:

line:nth-child(odd) {
  animation: lineMove 2s infinite linear;
}

line:nth-child(even) {
  animation: lineMove 2s infinite linear reverse;
}

Wrapping Up

Here is how the SVG code should look when completed:

<svg width="100%" height="100%" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" preserveAspectRatio="xMidYMid">
  <defs>
    <pattern id="pancakes-pattern" x="0" y="0" width="100%" height="200" patternUnits="userSpaceOnUse">
      <line x1="0" y1="15" x2="100%" y2="15" />
      <line x1="0" y1="40" x2="100%" y2="40" />
      <line x1="0" y1="65" x2="100%" y2="65" />
      <line x1="0" y1="90" x2="100%" y2="90" />
      <line x1="0" y1="115" x2="100%" y2="115" />
      <line x1="0" y1="140" x2="100%" y2="140" />
      <line x1="0" y1="165" x2="100%" y2="165" />
      <line x1="0" y1="190" x2="100%" y2="190" />
      <line x1="0" y1="215" x2="100%" y2="215" />
    </pattern>
    <pattern id="logo" x="0" y="0" width="100%" height="200" patternUnits="userSpaceOnUse">
      <line x1="0" y1="15" x2="100%" y2="15" />
      <line x1="0" y1="40" x2="100%" y2="40" />
      <line x1="0" y1="65" x2="100%" y2="65" />
      <line x1="0" y1="90" x2="100%" y2="90" />
      <line x1="0" y1="115" x2="100%" y2="115" />
      <line x1="0" y1="140" x2="100%" y2="140" />
      <line x1="0" y1="165" x2="100%" y2="165" />
      <line x1="0" y1="190" x2="100%" y2="190" />
      <line x1="0" y1="215" x2="100%" y2="215" />
    </pattern>
  </defs>
  <rect x="0" y="0" width="100%" height="100%" fill="url(#pancakes-pattern)"></rect>
  <rect x="22%" y="27%" width="250" height="150" fill="url(#logo)"/>
</svg>

And the CSS:

svg {
  height: 100vh;
}

line {
  stroke: #f4f4f4;
  stroke-width: 10;
  stroke-linecap: round;
  stroke-dasharray: 66, 16;
  stroke-dashoffset: 82;
}

line:nth-child(odd) {
  animation: lineMove 2s infinite linear;
}

line:nth-child(even) {
  animation: lineMove 2s infinite linear reverse;
}

#logo line {
  stroke: #ffd05e;
}

@keyframes lineMove {
  to {
    stroke-dashoffset: 0;
  }
}

That’s it! This is my first article here on Medium and I wanted to share my process on how I made this SVG line animation background. Referencing the MDN Web Docs and Using SVG with CSS3 and HTML5 (O’Reilly) helped me with understanding and creating this animation.

When I’m not writing, I’m helping businesses go further, faster at Fullstack Digital. We provide digital brand strategy, design, development, and marketing for forward-thinking companies. Check out some of our work here.

Creating an animated dashed line background with SVG and CSS was originally published in Fullstack Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using GitHub to Sync 100 Projects on Dell’s Open Source Website

Companies like Docker, Google, and Facebook contribute to the open source community by showcasing noteworthy projects. Google’s Open Source website lists various open source projects, typically including a basic project overview, links to documentation and resources, and the main website and GitHub repository.

As part of our web presence overhaul for {code}, Open Source at Dell Technologies, we transformed the way open source projects were curated and showcased on their website.

Where we started

1. Updates: Showcased projects were manually added with HTML/CSS, meaning a developer was required each time a new project was added. {code} showcases hundreds of projects, so this process created a significant bottleneck.
2. Tiles/Images: Project images had to be manually generated by a graphic designer.
3. Search/Explore: Projects weren’t searchable and filtering options were limited to tags.
4. Landing Pages: Projects didn’t have landing pages. {code} wanted to help projects lacking a main website by providing them with a landing page.

The result

1. Updates: Projects were now automatically imported and GitHub stats synchronized in real-time. Non-technical users could easily add projects from the WordPress dashboard.
2. Tiles/Images: Project images were easily generated using CSS gradient backgrounds and the project logo, so a graphic designer wasn’t needed.
3. Search/Explore: Users could now search projects and filter/sort with more options like GitHub stats.
4. Landing Pages: Project landing pages were auto-generated and included real-time information and stat synchronization.

Since no Wordpress plugins existed with this functionality, we developed our own plugin integrating Github with Wordpress.

Synchronizing projects as Wordpress custom post types

We decided to import Wordpress projects as custom post types in order to display projects using Wordpress queries.

In order to add a project, the admin simply needed to enter a link to the GitHub repository:

All project information would be imported as custom fields, custom taxonomies, and content in the text editor:

Once projects are imported, the GitHub page readme file and stats are checked for changes every 15 minutes and then updated if there are any changes, thanks to the GitHub API:

This meant that each project always provided a real-time count of forks, contributors, and stars while importing readme file changes:

Project readme files were imported as markdown to the Wordpress text editor and we used filters to convert the markdown to HTML on the front-end. This meant the original format was maintained and didn’t require any manual formatting:

In some cases, project readme files were incomplete or lacked formatting. For these specific cases, the admin could simply override the readme import and use a manually created description instead:

The text editor content would not be overwritten when the project information was synchronized again.

Searching and filtering the custom post type

We utilized customized versions of FacetWP and SearchWP to create an Ajax-powered project page with searching and filtering based on the imported metadata.

Showcasing featured projects with an interactive 3D grid

A static image was originally used for the community projects banner on the home page. This meant that the banner needed to be updated every time a featured project was swapped out.

We decided to replace this banner image with an interactive 3d grid to make the website feel more unique and to simplify any changes to the featured projects in that section.

The {code} Community and its programs now have a better way to showcase noteworthy projects in the open source community. We continued with automating the site by creating another plugin that synchronized their entire Mobilize.io online community, automatically creating pages on their website for each user.

How to showcase your community automatically with Wordpress

If you’d like to use the Github to Wordpress plugin mention in this article, contact us at hello@fullstackdigital.com

Using GitHub to Sync 100 Projects on Dell's Open Source Website was originally published in Fullstack Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

Following Docker & Dell Technologies to strategic & automated community building

Teams like Docker, Honeybook, Prezi, {code} by Dell Technologies, and Etsy manage large communities of likeminded people. For those that have programs that promote industry leaders, there is one persistent question:

How do we show gratitude to our members, especially the leaders, for contributing & leading the community?

Why teams showcase community members

Free swag, shoutouts, speaking slots etc. are always good. However, providing something tangible which members can refer to with pride, share with colleagues, and help advance their careers, has proven to be a meaningful solution for many of the teams mentioned above. For example, Docker and {code} by Dell Technologies have dedicated programs that promote the work and advocacy of the members/leaders, and establish an ecosystem of individuals who improve and advance their industries. They showcase these leaders on their website for three reasons:

1. Promotion & Celebration: promoting them as as individuals in their respective community — based solely on their contributions. Title or Company does not matter.
2. Camaraderie: individuals who may seem like competitors based on their respective organization affiliation are now part of the same community, all pushing for the same goal: bringing the best out of their respective community/industry.
3. Advancement: proof of program/community participation accelerates opportunities to advance someone’s career.

How to automatically display community members on a Wordpress website

There are many challenges that come with managing those communities & programs and several tools that lend a hand, such as Facebook or Google Groups, Discord, Discourse, and even email marketing tools like Mailchimp.

Forward thinking teams, like those aforementioned, all use Mobilize.io: a community social space, member directory and outreach center, combined. We came across this tool while working on a project, and realized its true power when it comes to communities. Using a simple WordPress plugin, you can display community members from Mobilize on your website, by group, and keep their profile information in sync! Here’s how:

1. Sign-up for the Mobilize.io Enterprise Plan — why enterprise plan? You’ll need an API key to retrieve & sync your users.
2. Install the Mobilize.io for Wordpress Plugin — built by us, used by {code} and completely free!
3. Follow this guide

Here’s what you can do with the plugin:

Sync Data: Automatically synchronize new and inactive Mobilize community members.

Make Member Profile Pages: Synchronize profile page content on a regular basis.

Segment By Group: Supports groups and group-specific custom fields. Good for different types of groups like programs, communities, partners, etc.

Display Anywhere: List community members using shortcodes or a standard WordPress query. Easy!

Customize: Display custom fields using shortcodes with enhanced options, such as separating/ joining field values and conditional content. Good for showing any custom fields you’ve added in Mobilize.

Looking ahead

The evolution of community management is inspiring, and we hope that we can continue to contribute and advance it. If you’d like any help integrating this with your company/team/project website, we’re always available!

Shoutout to Jonas Rosland and the rest of the (existing) {code} team @ Dell Tech for their collaboration with Fullstack on this project. Disclaimer: We’re not partnered with or affiliated with Mobilize.io, nor is this post sponsored by them.

When I’m not writing, I’m helping businesses go further, faster at Fullstack Digital. We provide digital brand strategy, design, development, and marketing for forward-thinking companies. Check out some of our work here.

Follow me on twitter https://twitter.com/allendjal

How to showcase your community automatically with Wordpress was originally published in Fullstack Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.