DEV Community: Michael Scherr

Switching from SASS to PostCSS

Michael Scherr — Sun, 31 Mar 2019 18:28:25 +0000

Ever since PostCSS came out, I've exclusively used it for Autoprefixer. I didn't really dig into the power of PostCSS and how it could actually be a comparable solution to SASS.

This article will go into depth about my skepticisms, and how I was able to find solutions using PostCSS.

The Push

What originally considered me to switch was my interest in Tailwind CSS. I love the ideas of utility libraries, but found it difficult to sell to other developers. However, we've been looking for ways to optimize development time, so Tailwind felt like a good choice. It's built with PostCSS in mind, so I at least wanted to give it a try.

Previous Approach

My previous approach was a mix of SASS, BEM, ITCSS, & SMACSS. They solved the following issues:

SASS - variables, loops, imports, nested selectors, etc
BEM - reduce specificity and allow for easier additions / modifications to code
ITCSS - (same as BEM), but also allows for an inverted triangle hierarchy for specificity gets more and more specific.
SMACSS - used mostly for modifier classes, like .js-is-active, .has-posts, etc.

This worked really well for me. I saw the power of utility libraries, but figured I would let them evolve and try them out later.

The Switch

I won't bore you with the details, but I went through many iterations like:

PostCSS only, no plugins besides Tailwind
PostCSS + SASS
PostCSS only, with Tailwind and other complementary plugins

The core issue with the PostCSS + SASS approach was the inevitable duplication. For example, these situations can't work together:

/**
  * cannot set $font-size-px-base in PostCSS
  * since SASS gets run first, so would have
  * to duplicate code
*/
@function rem($pixels, $context: $font-size-px-base) {
  @if (unitless($pixels)) {
    $pixels: $pixels * 1px;
  }
  @if (unitless($context)) {
    $context: $context * 1px;
  }
  @return $pixels / $context * 1rem;
}

/**
  * can't use Tailwind variables
  * in the SASS function `scale` since
  * SASS runs before PostCSS
*/
.selector {
  font-size: scale(font-size, theme('fontSize.lg'), theme('fontSize.xl'));
}

/**
  * Interpolation was also a nightmare
  * I couldn't figure out how to make
  * something like this work
  * even with PostCSS Simple Vars
*/
.selector {
  $path: theme('path.theme');

  background-image: url($(path)/test.png);
}

Final Solution

The final solution involved PostCSS only, with Tailwind and other complementary plugins.

When I thought about it, I was really using SASS for:

imports
mixins
functions
variables
nested selectors - rarely, but nice to have, especially for pseudo selectors
loops - very rarely, but nice to have

PostCSS has solutions for all of these once I realized the power of their plugin system. Furthermore, I found out some plugins, like for functions and mixins, allow you to inject Javascript functions into PostCSS. I was sold.

Imports

PostCSS Imports gives the exact same functionality as SASS Imports, so it was an easy switch.

@import 'tailwindcss/base';

@import 'tailwindcss/components';
@import 'components/btn';

@import 'tailwindcss/utilities';

Functions

PostCSS Functions allows you to write functions IN JAVASCRIPT and inject them into PostCSS. IN JAVASCRIPT. I LOVE JAVASCRIPT.

// functions.js

let settings = require('./settings');

let rem = (pixels, context = settings.defaults.fontSizePxBase) => {
  pixels = parseFloat(pixels);

  let result = pixels / context;

  return `${result}rem`;
};

module.exports = {
  rem,
};

Mixins

PostCSS Mixins is the same deal as PostCSS Functions.

// mixins.js

let placeholder = (mixin, immediateSelector = true) => {
  let vendors = [
    '::-webkit-input-placeholder',
    ':-moz-placeholder',
    '::-moz-placeholder',
    ':-ms-input-placeholder',
  ];

  return vendors.reduce((prev, vendor) => {
    let selector = immediateSelector ? `&${vendor}` : vendor;

    prev[selector] = {
      '@mixin-content': {},
    };

    return prev;
  }, {});
};

module.exports = {
  placeholder,
};

Other Notable Plugins

PostCSS Nested - offers SASS nesting
PostCSS Simple Vars - offers simple variables to be used in selectors, etc
PostCSS PurgeCSS - removes unnecessary CSS based on file globs you pass in
CSSNano - minify CSS
Autoprefixer - remove unnecessary prefixes based on your browser support

Example PostCSS Config File

// postcss.config.js

let functions = require('./functions');
let mixins = require('./mixins');

module.exports = function(context) {
  /**
   * context comes from what you pass
   * into `gulp-postcss`, omitting detailing here
   * since `gulp` is an implementation detail
   */
  let { options } = context;

  let plugins = [
    require('postcss-import')({
      path: [options.paths.components, options.paths.styles, 'node_modules'],
    }),
    require('tailwindcss')('./tailwind.config.js'),
    require('postcss-functions')({
      functions,
    }),
    require('postcss-mixins')({
      mixins,
    }),
    require('postcss-nested'),
    require('postcss-simple-vars'),
    require('autoprefixer'),
  ];

  return {
    plugins,
  };
};

I hope this at least got you interested in PostCSS and what it's powerful plugin system can provide for your next project.

Building a Simple Chrome Extension

Michael Scherr — Sat, 16 Feb 2019 19:59:00 +0000

I decided to make my first experimental Chrome Extension. My colleague came up with a really simple idea to implement, so I decided to give it a try.

The Functional Requirement

Create a Chrome Extension that will output a small colored square in the top left corner of a page, alerting you of which type of domain (i.e. .dev, .stage) you're on. These domains and colors will be managed on an Options Page.

Options Page

The environments and their corresponding color should be managed on a Options Page, allowing you to add / remove any number of entries.

Active Tab

The small square should only appear on domains that match entries the user has added on the Options Page.

The square's background color will reflect the current entry.

Getting Started

I originally followed this tutorial to get started.

Every extension needs to have a manifest.json. For a full list of options, visit their official documentation.

Below is a bare bones example of a manifest.json.

{
  "name": "Environment Flag Example",
  "version": "1.0",
  "description": "Environment Flag Example Extension",
  "manifest_version": 2,
  "background": {},
  "permissions": [],
  "options_page": "",
  "content_scripts": []
}

Notable Settings

Background Scripts

Documentation

Extensions are event based programs used to modify or enhance the Chrome browsing experience. Events are browser triggers, such as navigating to a new page, removing a bookmark, or closing a tab. Extensions monitor these events in their background script, then react with specified instructions.

We'll be using background scripts to add an event listener to the onInstalled event.

This will allow us to run code when the extension is installed. We'll use this event to add some default entries for the Options Page.

{
  "background": {
    "scripts": ["background.js"],
    "persistent": false
  }
}

Why is persistent marked as false? As the documentation states:

The only occasion to keep a background script persistently active is if the extension uses chrome.webRequest API to block or modify network requests. The webRequest API is incompatible with non-persistent background pages.

Permissions

Documentation

To use most chrome.* APIs, your extension or app must declare its intent in the "permissions" field of the manifest.

For example, if you would like to use Chrome's Storage API, you'll have to request permission for storage.

{
  "permissions": ["storage"]
}

Options Page

Documention

This entry will tell Chrome which html file you would like to use for the Options Page for your Extension.

{
  "options_page": "options/options.html"
}

You would access this page by clicking on Options in the menu dropdown for your Extension.

Content Scripts

Documention

Content scripts are files that run in the context of web pages. By using the standard Document Object Model (DOM), they are able to read details of the web pages the browser visits, make changes to them and pass information to their parent extension.

Essentially, any script you would like to actually run on a given page, needs to leverage this api. In our example, we'll be injecting a colored square in the top left corner of the active tab.

"content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["content/content.js"]
    }
  ]

I also recommend watching the video on Content Scripts and Isolated Worlds for a better understanding of what's going on behind the scenes.

We'll also need to update our permissions to use the activeTab:

{
  "permissions": ["storage", "activeTab"]
}

Complete `manifest.json`

{
  "name": "Environment Flag Example",
  "version": "1.0",
  "description": "Environment Flag Example Extension",
  "manifest_version": 2,
  "permissions": ["storage", "activeTab"],
  "background": {
    "scripts": ["background.js"],
    "persistent": false
  },
  "options_page": "options/options.html",
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["content/content.js"]
    }
  ]
}

Let's Get Coding

The entire codebase is available in my github repo.

Bonus - for the purists out there, I made a branch with no dependencies.

Installation

Installing a development extension is pretty well documented already, so I won't be going over it here.

Go ahead and follow their official documentation.

Background Script

The first thing we should do is set some default data using chrome's storage api.

The two methods you need to know about for this tutorial are:

chrome.storage.sync.set({ key: value }, function() {
  console.log('Value is set to ' + value);
});

chrome.storage.sync.get(['key'], function(result) {
  console.log('Value currently is ' + result.key);
});

The second parameter for each method is a callback function once the storage operation is complete. We'll be leveraging this in Vue to update internal state.

Let's open up background.js and add an event for when an extension is installed:

// background.js

chrome.runtime.onInstalled.addListener(function() {
  /**
   * lets add a default domain
   * for our options page
  */
  chrome.storage.sync.set(
    {
        config: [
            {
                domain: 'docker',
                color: '#2496ed',
            },
        ],
    },
    null
  );
}

In the code above, we are doing the following:

add a new key to the storage object called config
add one entry into config for a domain ending with docker

Options Page

For my tech stack, I decided to go with Bootstrap 4, Vue JS, Webpack, & native ES6 Javascript. I chose these because I'm comfortable with them, but feel free to choose your own.

For the purposes of this tutorial, I won't be explaining much about Vue, since it's an implementation detail, and not necessary to build an extension.

For a dependency free implementation, checkout this branch.

The options.html page is very simple:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta content="width=device-width, initial-scale=1.0" name="viewport" />
    <meta content="ie=edge" http-equiv="X-UA-Compatible" />
    <title>Environment Flag Options</title>
    <link
      crossorigin="anonymous"
      href="https://stackpath.bootstrapcdn.com/bootstrap/4.1.3/css/bootstrap.min.css"
      integrity="sha384-MCw98/SFnGE8fJT3GXwEOngsV7Zt27NXFoaoApmYm81iuXoPkFOJwJ8ERdknLPMO"
      rel="stylesheet"
    />
  </head>
  <body>
    <main>
      <div class="container  py-5">
        <div class="col-sm-8  offset-sm-2">
          <div id="app"></div>
        </div>
      </div>
    </main>
    <script src="../dist/options.bundle.js"></script>
  </body>
</html>

Go ahead and review the options folder before we continue. It's a pretty standard Vue application.

Let's review some of the notable Vue code. Options.vue is where most of the magic happens with leveraging the chrome api.

// options/Options.vue

{
    data() {
        return {
            /**
             * empty array to be used to store
             * the chrome storage result
             */
            config: [],
        };
    },
    mounted() {
        /**
         * once the component mounts
         * lets call the storage api
         * and request our `config` key
         * 
         * on our callback, lets call a method
         * to set our internal state
         */
        chrome.storage.sync.get(['config'], this.setConfig);
    },
    methods: {
        setConfig(storage) {
            /**
             * set our internal state
             * with the result from the
             * chrome api call
             */
            this.config = storage.config;
        },
    },
}

In the code above, we are doing the following:

setting internal state for a key called config, and assigning it to an empty array
on the mounted() method, we are requesting the key config from the storage api
on the callback function, we call a method called this.setConfig
setConfig() assigns our internal state to what is returned from the chrome api

We then have two methods for altering the chrome storage state:

{
    deleteEntry(index) {
        /**
         * remove the entry at a specific index
         * from our internal state
         */
        this.config.splice(index, 1);

        /**
         * update the chrome storage api
         * with the new state
         */
        chrome.storage.sync.set(
            {
                config: this.config,
            },
            null
        );
    },
    addEntry(entry) {
        /**
         * add an entry to our internal state
         */
        this.config.push(entry);

        /**
         * update the chrome storage api
         * with the new state
         */
        chrome.storage.sync.set(
            {
                config: this.config,
            },
            null
        );
    },
}

After implementing these methods, the final Options Page looks like this:

I know, it's nothing fancy… but that's not the point. Get out there and have some fun! You'll notice I added a edu domain, go ahead and add that now if you would like.

Content Script

Now that we have an Options Page with a way to add / delete entries, let's now implement the small square that will appear in the top left corner of valid domains.

To do this, we need to use the content script we discussed before. Let's go ahead and open up the content/content.js file.

// content/content.js

/**
 * lets first request the `config` key from
 * the chrome api storage
 */
chrome.storage.sync.get(['config'], ({ config }) => {
  /**
   * lets see if the `window.location.origin`
   * matches any entry from our
   * options page
   */
  let match = config.find((entry) => {
    let regex = RegExp(`${entry.domain}\/?$`);

    return regex.test(window.location.origin);
  });

  /**
   * if no match, don't do anything
   */
  if (!match) return;

  /**
   * lets create the style attribute
   * by building up an object
   * then using join to combine it
   */
  let node = document.createElement('div');
  let nodeStyleProperties = {
    'background-color': match.color,
    height: '25px',
    left: '5px',
    opacity: 0.5,
    'pointer-events': 'none',
    position: 'fixed',
    top: '5px',
    width: '25px',
    'z-index': '999999',
  };
  let nodeStyle = Object.entries(nodeStyleProperties)
    .map(([key, value]) => {
      return `${key}: ${value}`;
    })
    .join('; ');

  /**
   * apply the style to the node
   * and a class flag (doesn't do anything)
   */
  node.setAttribute('style', nodeStyle);
  node.setAttribute('class', 'chrome-extension-environment-flag');

  /**
   * append the node to the document
   */
  document.body.appendChild(node);
});

Conclusion

Now, when I go to an edu domain, I see the following in the top left corner:

I hope this tutorial at least got you interested in Chrome Extensions. We only scratched the surface. Feel free to use any of the code in my repo for any purpose.

Let's Encrypt Server Certificate via DNS Challenge

Michael Scherr — Thu, 31 Jan 2019 02:29:00 +0000

Have you ever wondered if it was possible to obtain an Server Certificate before you migrate a website? I always assumed the DNS had to be switched before the certificate validation could take place. I've come to find there are more options available.

The Scenario

My company is currently in the process of moving all of our client production sites to a new server. Part of that effort is ensuring all sites be placed on https.

Server Certificate Challenges

Let's Encrypt offers domain-validated certificates, meaning they have to check that the certificate request comes from a person who actually controls the domain. They do this by sending the client a unique token, and then making a web or DNS request to retrieve a key derived from that token.

There are two main options to obtain a server certificate:

HTTP Challenge - Posting a specified file in a specified location on a web site
DNS Challenge - Posting a specified DNS record in the domain name system

HTTP Challenge

This is usually handled by adding a token inside a .well-known directory in your web root. Certbot can then confirm you actually control resources on the specified domain, and will sign a certificate.

DNS Challenge

This approach requires you to add specific DNS TXT entry for each domain requested. This is useful when you haven't switched DNS yet, but want to issue a certificate in anticipation (for testing).

For more information on challenges, visit certbot's documentation.

Setup

We'll be discussing the DNS Challenge approach for the rest of the article.

In the examples below, I'll be using Apache & Ubuntu 16.04 following this guide. To find documentation for your specific web server / operating system, go to certbot's homepage.

First we need to install certbot along with all necessary dependencies.

# run as root

apt-get update \
    && apt-get install software-properties-common \
    && add-apt-repository -y universe \
    && add-apt-repository -y ppa:certbot/certbot \
    && apt-get update \
    && apt-get install -y python-certbot-apache

Configuration

I won't be going over wildcard domains here, but they are an option. Refer to their documentation.

We now need to tell certbot which domains we would like to issue a certificate for. Remember to add each subdomain individually.

Since we may have multiple vhosts per server, we decided to use the --manual & certonly flags.

# run as root

# replace with your domain
# add all relevant subdomains
certbot --manual --preferred-challenges dns certonly \
    -d yourwebsite.com \
    -d www.yourwebsite.com \          # don't forget www binding
    -d staging.yourwebsite.com \      # example subdomain
    -d staging.stage1.yourwebsite.com # example long subdomain

Challenge Prompts

Once you run the command above, it will prompt you to add a DNS TXT record for each specified domain. It will look like this:

Please deploy a DNS TXT record under the name
_acme-challenge.yourwebsite.com with the following value:

[random-string-of-characters]

Before continuing, verify the record is deployed.
(This must be set up in addition to the previous challenges; do not remove,
replace, or undo the previous challenge tasks yet. Note that you might be
asked to create multiple distinct TXT records with the same name. This is
permitted by DNS standards.)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Now here's the important part. You need to remove the base url from each record name, like so:

requested name from certbot	actual name to add in `DNS`
`_acme-challenge.yourwebsite.com`	`_acme-challenge`
`_acme-challenge.www.yourwebsite.com`	`_acme-challenge.www`
`_acme-challenge.staging.yourwebsite.com`	`_acme-challenge.staging`
`_acme-challenge.staging.stage1.yourwebsite.com`	`_acme-challenge.staging.stage1`

Once you add the DNS TXT records, and click Continue through each challenge prompt respectively, the validation should pass.

Press Enter to Continue
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/yourwebsite.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/yourwebsite.com/privkey.pem
   Your cert will expire on 2019-04-24. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Updating Your VHost

Now that we have a valid certificate, we can update our vhost:

# inside the 443 binding

SSLEngine On
SSLCertificateFile /etc/letsencrypt/live/yourwebsite.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourwebsite.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/yourwebsite.com/chain.pem

Then restart Apache:

sudo apachectl configtest

# if syntax ok
sudo apachectl restart

Bonus: Setup Auto Renewal

We'll leverage the crontab of the root user to automatically renew certificates that will expire soon.

# run as root

# edit the crontab
crontab -e

Then add the following two lines at the bottom:

# every Monday at 2:30am
30 2 * * 1 /usr/bin/certbot renew --deploy-hook "service apache2 reload" >> /var/log/letsencrypt/le-renew.log

The certbot will try and renew any certificates marked for renewal once a week. We then use the --deploy-hook to only reload apache if necessary.

Special thanks to Daniel McCarney for the updated crontab code.

Daniel McCarneyFollow

My Terminal Setup

Michael Scherr — Sun, 20 Jan 2019 16:30:23 +0000

I thought I'd share my current terminal setup. Over the years, I've been able to optimize my workflow. This allows me to:

find information quicker
reduce the time I spend searching for commands
become more comfortable with cli's in general
look like a badass

My evolution has been interesting over the years. In the beginning, I was that developer who used every plugin imaginable (for the ['terminal', 'IDE', 'etc']). Then I watched this video from MPJ about productivity in the workplace. I then started scaling back to where I am now.

App

I use macOS 99% of the time, so my go to app is iTerm2.

Installation

You can download it from iTerm2's website, or install through Brew Cask:

pro tip: Brew Cask is amazing, it can install and manage all of your Mac applications through a simple cli.

brew cask install iterm2

Oh My ZSH

I've experimented with other shell's like fish, but they were always too abstracted, or were too complicated.

Installation

# if you don't have zsh installed
brew install zsh

# install oh my zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

Theme

I use the robbyrussel theme. It gives me git information, which is perfect.

It also trims the directory path, so you only see the current directory. This avoids obnoxiously long folder paths taking up valuable space.

# ~/.zshrc
ZSH_THEME="robbyrussell"

Plugins

I only use a few plugins:

z - native plugin, don't need to install
zsh completions
zsh autosuggestions

Installation

# zsh completions
git clone https://github.com/zsh-users/zsh-completions \
    ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-completions

# zsh autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions \
    ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

Then update your ~/.zshrc:

# ~/.zshrc

plugins=(
  z
  zsh-completions
  zsh-autosuggestions
)

autoload -U compinit && compinit

Then source your configuration:

source ~/.zshrc

Bonus: Keyboard Bindings

# ~/.zshrc

bindkey -e

# allows you to use the `option + [left, right]` key
# to skip words in a command you're writing.
bindkey '\e\e[C' forward-word
bindkey '\e\e[D' backward-word


# allows you to use the `[up, down]` key on a partial command
# to search your bash history for similar commands
bindkey '\e[A' history-search-backward
bindkey '\e[B' history-search-forward

Conclusion

I do believe there is a happy medium between no tooling, and too much tooling. You can have enough to be dangerous, but not enough to overwhelm you.

For a more in depth overview of what I use on a daily basis, checkout my Uses page on my website.

Drupal 8.x - What I've Learned

Michael Scherr — Sun, 13 Jan 2019 19:39:07 +0000

If anyone has solutions to any of the issues I describe below, please feel free to leave a comment.

I've now developed two production sites with Drupal 8.6. This post will cover what went wrong, how my team fixed them, and then some best practices from what we've learned through trial and error.

The first site, in hindsight, was a complete disaster. There's nothing worse than learning Drupal (or anything for that matter) through trial and error while developing a production website. I knew nothing about rendered entities, view modes, etc. I constantly battled with the templating. We abused the [theme].module hooks, instead of using custom modules to handle functionality.

The second site was much better, although I imagine there is so much more to learn. Our biggest issue was how to effectively use views when using the ajax functionality. Our decision to not make certain taxonomies have actual pages (aka have an accessible alias), led to many problems when trying to filter them in certain views.

Localization continues to be a huge issue. If you've ever developed with Drupal, you know it's insanely frustrating configuring and outputting localized content correctly.

Best Practices (from my experience)

Language Configuration

Trust me when I say this:

Figure out your localizations ahead of time.

You should know before development:

all the languages + language codes you'll be using
what the original language will be for all content

Scenario:

Say you are told the site will be in Canadian English (en-CA) and Canadian French (fr-CA). Then a couple weeks before deployment, once all content pop is mostly complete, they want to change the language code from en-CA => en.

Here is the problem:

There doesn't seem to be a way to change the language code once it has been added. Additionally, all content that has the previous language code as the original language can't be changed either. Even if you delete the orignal language node translation, you still cannot assign another translation as the original language.

Ok fine, so you add the new language code, content pop all of the nodes again with the new language… and run into another problem. All content in a translation that is not the original language that has a repeatable number of values, cannot exceed the original language's number of entries.

How did we fix this? We haven't. We've thought about updating the database through SQL statements, but please share your thoughts if you have a better way.

Install Drupal Core w/ Composer

Do yourself a favor and use Composer to install Drupal Core. Upgrading core is now as simple as:

composer outdated drupal/*

composer update drupal/core --with-dependencies
drush updatedb
drush cr

More information is available on their website.

Install Modules w/ Composer

Same deal as with core, instead run:

# example
# composer require drupal/[module_name]

composer require drupal/better_exposed_filters

Bonus: Awesome Modules

Paragraphs - just like ACF for Wordpress
Better Exposed Filters - adds more options to the advanced section of views
Twig XDebug - add debug points in your twig files (requires XDEBUG to be installed and configured on the server; might do another blog post about this)
Path Auto - auto generate / update node aliases
Views Reference Field - use with the paragraphs module; allows a view to be injected anywhere on the page
Devel - for debugging
Yoast SEO - for SEO; content pop for meta tags
Drupal Media - in core as of 8.4, just install it; adds a much better UX experience for handling media

Use the `Drupal Console` & `Drush` Executables

Installation Instructions (Use Composer)

To install via composer, run:

# drupal console
composer require drupal/console:~1.0 \
    --prefer-dist \
    --optimize-autoloader

# drush
composer require drush/drush

Common usage:

# usage
./vendor/bin/drupal [command]
./vendor/bin/drush [command]

# cache rebuild
./vendor/bin/drush cr

# show watchdog log
./vendor/bin/drupal watchdog:show

# install module
./vendor/bin/drupal module:install [module_name]

# generate module
./vendor/bin/drupal generate:module

Setup Drupal for Local Development

Follow this tutorial to make your local development so much easier.

Use View Modes

View Modes allow you to define multiple ways (aka templates) to show the same type of content. The two native view modes are full and teaser. You can accomplish 95% of what you need with those two view modes alone.

Imagine this scenario: You have a content type of Case Study. A case study can appear as a single page (full), inside a view grid (teaser), and also as a featured case study on another page (featured).

You can customize the display of each view mode individually. For example, let's say the teaser outputs the title and description, but hides the image you've set up. However, the image should be shown on the featured and full view modes.

This allows us to leverage 3 different templates and customize the output:

node--case-study.html.twig
node--case-study--teaser.html.twig
node--case-study--featured.html.twig

Use Rendered Entities

Let me save you hours of frustration. Use rendered entities whenever possible. As I understand it, a rendered entity is the output of an entity through its selected view mode.

Imagine the case study featured example from above. You add a new field to the Basic Page content type for a reference to a case study. In the manage display of the Basic Page, you can change the format of the case study reference to Rendered Entity, and select the featured view mode.

This allows for far less code duplication. You are keeping the rendering of entities separate from the nodes that reference them.

Pro tip: you can also use the rendered entity and a specific view mode as the format for a view. Additionally, in scenarios when you have cannot use the content format, you can add a field called Content: Rendered Entity that you can reference this way:

{{ fields.rendered_entity.content }}

Use the Media Module

Yes, it's still experimental, but we haven't had any issues with it. It makes uploading, selecting, and deleting media much easier.

Conclusion

Drupal is very powerful. It allows you to add complex relationships and fields to structure any kind of content. However, there is some higher level functionality that is paramount to understand and implement. Leveraging view modes, rendered entities, and other best practices will help you become a better Drupal developer.

This post ending up being way longer than I intended. There are more best practices and tips that didn't make it into this post. Any comments with new insight or solutions are always welcome.

DEV Community: Michael Scherr

Switching from SASS to PostCSS

The Push

Previous Approach

The Switch

Final Solution

Imports

Functions

Mixins

Other Notable Plugins

Example PostCSS Config File

Building a Simple Chrome Extension

The Functional Requirement

Options Page

Active Tab

Getting Started

Notable Settings

Background Scripts

Permissions

Options Page

Content Scripts

Complete manifest.json

Let's Get Coding

Installation

Background Script

Options Page

Content Script

Conclusion

Let's Encrypt Server Certificate via DNS Challenge

The Scenario

Server Certificate Challenges

HTTP Challenge

DNS Challenge

Setup

Configuration

Challenge Prompts

Updating Your VHost

Bonus: Setup Auto Renewal

Daniel McCarneyFollow

My Terminal Setup

App

Installation

Oh My ZSH

Installation

Theme

Plugins

Installation

Bonus: Keyboard Bindings

Conclusion

Drupal 8.x - What I've Learned

Best Practices (from my experience)

Language Configuration

Install Drupal Core w/ Composer

Install Modules w/ Composer

Bonus: Awesome Modules

Use the Drupal Console & Drush Executables

Installation Instructions (Use Composer)

Setup Drupal for Local Development

Use View Modes

Use Rendered Entities

Use the Media Module

Conclusion

Complete `manifest.json`

Use the `Drupal Console` & `Drush` Executables