Oct 10 2019
Oct 10

For several years, Google has leveraged Drupal as the primary tool for developer portals built for its popular Apigee Edge API platform. With the introduction of the production-ready Drupal 8 distribution in May 2019, an announcement was made that support for the D7 platform would expire in 12 months. Concurrent with that announcement we know that D7 end-of-life will occur in November of 2021. This means that many Apigee portals will need to make the move to Drupal 8 or Apigee’s integrated portals in the near future.

In this article, we will walk through the steps to migrate Apigee portals from Drupal 7 to 8. The first decision you will need to make is whether to upgrade your existing custom build or move to the new Drupal 8 kickstart distribution. To help guide this decision, let’s first take a look at what the Apigee distribution for Drupal 8 has to offer and why you would want to leverage this platform.

Apigee Developer Portal Kickstart (D8)

The Apigee documentation site has excellent instructions on how to set up a developer portal using their Drupal 8 distribution. We will take a quick look at the features that come with the newest install profile.

Apigee homepage

Apigee Kickstart Homepage screenshot

 

The Apigee distribution once again has a nice out-of-box experience. This time around the base theme leverages a Bootstrap base theme that makes it easy to brand and customize your site.

The content types you see will be familiar: Article, Basic page, FAQ, Forums, and a new Landing page content type. Video, images, and audio are now more appropriately Media types in Drupal 8. The SmartDocs content type is gone in favor of a new API Doc type that supports the OpenAPI format (see below).

API doc

API doc screenshot

Adding content is now more flexible in Drupal 8 with the implementation of Paragraph types. Paragraphs allow you to add different components onto the page in any order you like. See the homepage example below.

Apigee paragraphs

Apigee Paragraphs screenshot from Homepage

In Drupal 8, Apigee also added some new block types. Blocks are still useful for components that need to live on more than one page.

Apigee block type

Apigee block types screenshot

The great thing about Apigee’s distribution is that it also includes sample content which makes getting set up a breeze. 

For organizations setting up a portal for the first time, leveraging this distribution is the way to go. For portals being upgraded from Drupal 7, this is more of a judgment call. If your portal has been heavily customized it might be better to move forward with a traditional Drupal 8 upgrade which we will cover under Custom Migrations. If, however, your organization’s portal previously had taken advantage of out-of-box functionality, then it makes sense to migrate content to Apigee’s D8 project which we will walk through next.

Migrating to Apigee Kickstart D8

The maintainers of the Apigee kickstart distribution have supplied a module to make migrations as painless as possible. The apigee_kickstart_migrate sub-module provides the Migrate module configuration that maps Drupal 7 content to their newer Drupal 8 counterparts. Again, this is most helpful for portals that did not heavily customize content in Drupal 7. Included in this sub-module are instructions on how to run the migrations and how to extend migrations with custom fields.

The following table shows how content is mapped from the Drupal 7 portal to Drupal 8.

Drupal 7 (Devportal)

Drupal 8 (Kickstart)

Content Types

Article (article)

Article (article)

title

title

body

body

field_keywords

field_tags

field_content_tag

field_tags

Basic page (page)

Basic page (page)

title

title

body

body

FAQ (faq)

FAQ (faq)

title

title

body

field_answer

field_detailed_question

-

Forum topic (forum)

Forum topic (forum)

title

title

body

body

taxonomy_forums

taxonomy_forums

Comment Types

Comment (comment)

Comment (comment)

author

author

subject

subject

comment_body

comment_body

Taxonomy

Forums (forums)

Forum (forums)

name

name

Tags (tags)

Tags (tags)

name

name

Custom migrations

When would you go with a custom Drupal 8 upgrade over leveraging the Kickstart project? 

Where you run into trouble with distributions in Drupal is when you lean on so many customizations that the distribution gets in the way more than it saves time. In those instances, it’s better to stick with your own custom implementation.

The Mediacurrent team recently released the Migrate Pack module to make things easier for developers. This module has been tested against several sites and distributions including the Apigee Drupal 7 install profile.

Migrate pack module

The approach here would be to install Migrate Pack and the two additional Apigee modules in lieu of leveraging the distribution. The two key Apigee features you will need are the Apigee API Catalog and Apigee Edge modules. All of these projects should be installed using Composer.

If your theme was built custom in Drupal 7, then it will need to be manually ported to Drupal 8’s Twig-based theme engine. The other option is to instead borrow the Bootstrap-based theme included with Apigee’s distribution. It should be said that if the latter approach is taken, it might be better to migrate everything to the new Kickstarter rather than cherry picking the theme.

Next Steps

Apigee has very good support and documentation to get you started on moving to Drupal 8. For issues and bugs specific to the Drupal distribution, the Github project issue queue is the best place to look. The Migrate Pack module also has its own issue queue on Drupal.org should you run into problems.

Mediacurrent has logged over 100,000 hours in Drupal 8 development, many of which are Drupal 7 to 8 upgrades. We would love to work with you on your next project. 

Please visit our contact page to get in touch or hit me up on Twitter to talk more. We also have comments below to gather your feedback and questions.

Oct 02 2019
Oct 02

Mediacurrent works with a variety of customers across many verticals to build secure Drupal applications. We sometimes encounter strict hosting policies, including on-premise requirements.

One of the great benefits of decoupling Drupal from the web frontend is the ability to move Drupal’s CMS to a secured environment that is only accessible from a VPN or private network. Statically generated frontends like Gatsby further reduce vulnerabilities to provide a robust security architecture overall.

This article will outline three options for securing Drupal, two of which include hosting the CMS behind a Firewall only accessible by a user on a secured network. The third option is the more common alternative that provides some security but does not completely lock down the CMS.

 All options provide added security benefits over a traditional hosted Drupal application. Let’s weigh the pros and cons of each approach. 

Option 1 - Self-hosted

self-hosted option with Gatsby, Jenkins, Gitlab, Drupal

The first option runs completely on self-hosted hardware, which could be stood up on-premise if so desired. While this type of approach is becoming increasingly rare, there are still contracts in the government and financial space that require all self-hosted applications. 

This method will keep Drupal locked down on a web server behind a firewall that only privileged CMS users can access. GitLab is a great choice when Git repositories need to be self-managed but still require robust features that GitHub, BitBucket and GitLab’s cloud offerings provide. 

A Jenkins server can be stood up to handle the automation of Gatsby builds. This includes compiling the artifacts that will be deployed to the public web server on the right-hand side. For deployments, a read-only Git deploy key is a secure way of grabbing the latest Gatsby release.

Pros:

  • Ability to completely lock down the CMS environment and Git repositories

Cons:

  • Must maintain web servers, Gitlab server, and automation (Jenkins)
  • Most expensive solution to stand up and maintain

Why you would use this solution:

  • Strict security requirements
  • On-premise requirements for servers

Option 2 - Self-hosted + Cloud

self-hosted Drupal setup with cloud

The second option keeps the CMS web server behind a firewall while leveraging Cloud services for the rest of the architecture. As with the first solution, only privileged users will be able to access the CMS server. In this scenario, a Cloud Git service like GitHub will host the Gatsby source files and Netlify’s static host will run the compiled website. Netlify’s CLI can be used by the webserver behind the file server to rebuild artifacts when content is updated. A Jenkins server is a good way to handle the automation of Gatsby builds.

Pros:

  • Relatively straightforward to set up
  • An easier solution to maintain than completely self-hosted
  • Saves cost over a self-hosted solution
  • Leverage great features from Netlify (High availability, A/B testing, etc.)

Cons:

Why you would use this solution:

  • Balance security while leveraging Cloud
  • A desire for CMS to be completely locked down from outside access

Option 3 - Private with Cloud

private hosting with cloud

The last solution will not use a Firewall but instead obscure access to the webserver and in some cases add basic auth for additional protections. A CDN is recommended for inline images so that media is server from a service like Cloudfront instead of directly from the server. This method will leverage a Drupal managed host provider like Acquia or Pantheon.

Pros:

  • Able to use image CDN for inline Media
  • Can add light protections like basic auth
  • No server maintenance
  • Managed host providers provide enterprise support and features

Cons:

  • Server is still publicly accessible, so less secure than solution behind firewall

Why you would use this solution:

  • CMS does not need to be locked down
  • Security through obscurity, CMS server not indexed which shields from most attacks

Inline Images

One challenge with Gatsby is that it won’t automatically handle inline images coming from Drupal’s CMS. Gatsby does convert images that are served from Drupal’s JSON:API but it does not do anything with image paths that exist in say the body Wysiwyg HTML for any particular page. 

One option is to use the TUI Editor module that converts these images to Gatsby image assets: https://www.drupal.org/project/tui_editor

Another option would be to integrate the Drupal Amazon S3 module. This can be combined with Amazon Cloudfront to serve inline images from a secure server. Whenever a file gets saved it would be pushed up to Amazon S3 through an API and then made publicly available by Cloudfront. The AmazonS3 module allows developers to rewrite image URLs to the publicly accessible URLs that will be served by Gatsby.

Your Feedback

We hope that you have found this article helpful. Want to know more? Talk to our team of experts to discuss a solution that works for your organization.

Comments or questions? Hit me up at @drupalninja

Oct 01 2019
Oct 01

Meet Gatsby, an open source React-based framework for building super fast websites and apps. 

In this episode, we talk with Jason Lengstorf to discuss the GatsbyJS project and what it solves.

Audio Download Link

Project Pick:

https://gatsbyjs.org

Interview

  • What's your role at Gatsby, when did you start?
  • How did you get involved in the project? 
  • What did you do before Gatsby?
  • What is Gatsby?
  • How do you feel about the response from the community about Gatsby?
  • Did you think it would take off as it has?
  • Why should an org choose it over a traditional CMS?
  • What separates Gatsby from other static site generators?
  • What features is the team currently working on?
  • Closing comments

Links: 

Sep 16 2019
Sep 16

The Problem with Upgrades

One of the more challenging tasks when upgrading Drupal from version 6 to 7 to Drupal 8 is the upgrade/migration process. We already know that themes and modules have to be rebuilt or otherwise ported when upgrading, but even migrating content can be a time-consuming chore.

The great news is that Drupal 9 might be the last big Drupal upgrade you ever have to deal with thanks to its backward-compatibility. That said, let’s zoom in on the problem at hand and address how we can make the last big upgrade you’ll ever be tasked with go more smoothly.

Errors halt migration

What can be frustrating about upgrading from Drupal 7 to 8 is that during the process there is a good chance your new Drupal 8 build will run into a field, entity or plugin that it doesn’t understand. This can lead to uncaught exceptions which then leads to an error and an incomplete migration. 

In some cases, you find the right contributed module or patch that will add a migration path for the configuration in question and the error is resolved on the next pass. More often than not, however, you will find that no such path exists and you have to deal with the error yourself. This could entail either updating the migration yml config to skip or reroute the configuration, perhaps by writing a custom migrate plugin. It’s possible you have to repeat this step multiple times until you have addressed each error that prevents a successful migration.

One problem with Drupal upgrades is that by default it assumes you want to upgrade everything from your Drupal 6 or 7 site. The Drupal upgrade will try to migrate some configuration that is honestly rarely needed, such as theme and system configuration. It’s more typical that developers will want a subset of the content and configuration from the previous version of Drupal.

Introducing Migrate Pack

migrate pack logo

We decided to take a different approach with migrations, particularly the early stage where you are trying to get through that first pass successfully. It’s this step where you want to grab as much content and configuration “as-is” into Drupal 8 so that you can start engineering the new site in earnest.

Migrate Pack’s Approach

The Migrate Pack module, hosted on Drupal.org, is an opinionated solution with the goal to capture 80% of the content and configuration you need without errors and without manual intervention.

Migrate Pack, first of all, will skip about half of the migration configuration that typically gets imported and then discarded as a way to cut down on the “cruft” that might weigh down a migration. This configuration can be overridden to further dictate which migrations will be included or skipped.

Next, this feature will attempt to avoid some common errors with things like invalid links or entity bundles that don’t exist. Rather than halt the migration with a fatal error, a notice will get logged which can be reviewed after the process is completed. 

Finally, Migrate Pack uses configuration to skip entities and bundles that do not have a known migration path. This again allows for the migration to complete with warnings being logged along the way. All of these settings can be customized per project. We think this results in a smoother process overall.

Using Migrate Pack

By leveraging Composer we hope to bundle the various modules you’ll need to get started quickly, even if you do not have a lot of experience with migrations.

The usage for this project is fairly straightforward. The first step is requiring the feature using Composer to download the module and all of its dependencies:

$ composer require drupal/migrate_pack

Once that is done you will enable the module to enable those dependencies:

$ drush en -y migrate_pack

While Drupal can be migrated through the UI, it’s usually easier to use drush commands provided by the migrate_upgrade module (which we enable by default). The drush “migrate:upgrade” command adds the configuration you will need. Below is a common example of the full command with parameters. You will want to examine your options with the “--help” parameter the first time you run this command.

$ drush --yes migrate:upgrade --legacy-db-key drupal7 --legacy-root sites/default/files --configure-only

After Drupal 8 generates the migrate configuration you can test drive a full migration or limit the migration in any number of ways. The “--all” command will attempt to execute all migrations, example below:

$ drush migrate:import --all

With Migrate Pack’s overrides you should have fewer errors (hopefully none) on the path to a successful first pass at migration.

Finally, it’s time to export your configuration. This can be done with the drush “config-export” command (see below):

$ drush config-export -y

The idea is that now the work begins to remap configuration, integrate custom plugins and any other development required to complete the desired full migration. As mentioned, Migrate Pack has its own settings.yml that will be exported to your configuration which can be adjusted as needed. If you run into any errors or problems along the way we recommend you create issues in the project issue queue.

Next Steps

We think that this feature can be a great tool to bust through errors that typically hamper a Drupal upgrade.  We would love for you to give this module a try and help make it more robust so that Drupal developers can complete migrations faster with fewer headaches along the way.

For issues and roadmap be sure to check out the project page and issue queue for the latest updates.

Got general feedback or questions? Use the comments below or hit me up on Twitter @drupalninja 

Sep 10 2019
Sep 10

open waters

In this episode, we talk with Mediacurrent's Mario Hernandez about why training is so important for web teams to grow and stay competitive. And yes, we are once again interviewing one of the hosts. 

Audio Download Link

About Mario 

In addition to his position as Head of Learning, Mario is a Senior Front End Developer with over 15 years of Drupal experience. He and I actually started on the same day, 5 years ago. Mario is a regular speaker and trainer at tech conferences including Drupal Camps and DrupalCons. He is a co-host of the Open Waters podcast and an active participant in the Drupal core project and other open source projects. Prior to Mediacurrent, Mario also has over 10 years of experience in the Federal Government.

Project Pick

Apollo GraphQL

  • Server
  • Client
  • Platform

Interview: 

The best way to learn is to teach. 

  1. How did you get started with Drupal and front end development in general?
  2. How did you get started doing training?
  3. What is your favorite part of training people?
  4. Is Mediacurret’s training limited to only events and/or only Drupal?
  5. How do you think training is most effective when working with a client’s internal development team?
  6. In addition to FE training, does Mediacurrent offer training in other areas?  Yes! We offer training in Accessibility, SEO, Back End, Digital Strategy, GatsbyJS and more
  7. How can organizations interested in our training offerings get more information?
Sep 09 2019
Sep 09

Rain logo updated

Mediacurrent created the Rain Install Profile to build fast, consistent Drupal websites and improve the editorial experience. Rain expedites website creation, configuration, and deployment.

Overview

The Mediacurrent development team uses a Composer project template that extends the official Drupal Composer template to add Rain projects as well as additional tools and scripts.

Our template by default leverages a fork of DrupalVM which will provision the local environment. Note that Docker-based environments such as Lando or DDEV could be used as an alternative to Vagrant.

In this tutorial, we will walk through each step to get you up and running quickly. Below, you can also watch a narrated tutorial video to see these steps in action.

Installation instructions

First, you will want to create a repository wherever you typically host your Git projects (e.g. Github, Bitbucket or Gitlab). Once you have that setup you can clone Mediacurrent’s repo and point the origin back to your Git repo. The example command below illustrates how this is done.

Example:

git remote set-url origin [email protected]:mediacurrent/shortcode_project.git

Next, you will want to initialize the project. You can do that by running the following commands with your local host name and IP (see example below).

Example:

composer install

composer drupal-scaffold

./scripts/hobson project:init example.mcdev 192.168.50.4

Finally, to build the project and run the install you can simply run the following build command to execute the composer install and Drupal install:

./scripts/buid.sh

Note that this command does require Mediacurent’s Vagrant environment in order to work. If you are using an alternative local environment you would run composer install, followed by the drush site install command instead of running the build script.

Once you get a full install working with the sample profile that’s been provided you will want to follow the project README documentation for further setup instructions. Remember to commit all of your files and push up to your Git’s origin. That’s it!

Questions or comments? Let me know at https://twitter.com/drupalninja/.

Aug 30 2019
Aug 30

In this 5-part series, take a deep dive into universal design concepts in the context of creating component-based systems for dynamic web content. Get a birds-eye view of the inner workings of user experience (UX) architecture. Brand strategy, user psychology, objective methodology, and data-driven decisions come together, guided by timeless fundamental ideas, to construct today’s digital journeys.

a dancer mid-split

The Art of Setting Type for Dynamic Systems

It is the typographer’s task to divide up, organize, and interpret this matter in such a way that the reader will have a good chance of finding what is of interest to him.

- Emil Ruder

In the 1950s, Swiss typographer and graphic designer Emil Ruder was involved in developing the International Typographic Style. Cleanliness, objectivity, and the use of “the grid” are key features of this approach which still plays a major role in design today.

In 2006, Oliver Reichenstein said,

Web Design is 95% Typography.

And while faster connection speeds have allowed us to provide more media-rich experiences, text-based information is still vital - and the only thing that devices like Google, Alexa, and assistive technologies for the differently-enabled “see.”

Today, the timeless challenge of how to visually present text-based information is as formidable as it’s ever been. Contemporary design decisions take into account the experiences of billions of potential users, located anywhere in the world, in front of screens of all sizes, with a wide range of backgrounds, situations, and abilities. 

Fortunately, standards such as those for Heuristic Evaluation, the W3C’s Web Content Accessibility Guidelines and user testing tools such as the System Usability Scale and the Single Ease Question have provided an objective structure to inform the creative works of designers today.

Fast, Scalable, Legible Type Styling

Guiding principles for font selection and implementation 

Limit the number of fonts 

In the name of consistency, efficiency, and optimized load times, consider combining two harmonious fonts that create a visual hierarchy. Two is considered an ideal number for fonts. Choose a font with enough members in its family to allow design options, however. A font with light and black versions, as seen on some of Google’s best fonts, will provide a versatile UI toolkit.

Most brand standards contain definitions for print and well as web fonts. In the absence of such standards, a review of mission and vision statements can guide you to a font that reflects the brand identity.

Use a responsive type scale

Responsive modular typography scales, when designed and implemented, are an easy way to preserve visual hierarchy across the various screen widths of devices. A modular type scale is a series of type sizes that relate to each other because they increase by the same ratio. 

Mediacurrent Rain typography example shows Raleway and Merriweather fonts

Example of how responsive typography looks across various breakpoints on Mediacurrent’s Rain demo site.

 

Avoid All Caps for headings and paragraph text

Not only have studies shown text formatted in All Caps decreases reading speed by 10-20%, but this styling presents substantial barriers for users with dyslexia. According to the latest estimates, that is 15-20% of the population.

When headings are less than around 25 characters, all caps is still considered readable for everyone. All caps can also be a valid choice for short navigation titles and concise button copy.

Avoid Italics for headings and paragraph text

A first-time user may spend seconds on your website, not minutes, and as reading speed is dependant on legibility, styling is of paramount importance for all users. In terms of accessibility, italicized letters are nearly illegible to some with reading issues.

Addressing accessibility concerns is a great investment that provides an opportunity to bring in objective best practices to increase usability, readability, and visual impact for all users, opening up your website to a larger audience.

Modern, Readable, Accessible Type Styling 

Guiding principles for line and paragraph spacing

Look to the gold standard for accessibility

Because Section 508 compliance is currently attuned to the A and AA Level WCAG 2.0 guidelines, the AAA Guidelines are sometimes left out of the conversation. The guidelines around line and paragraph spacing, however, are especially easy to incorporate. Because they improve the experience for all users, they are well worth considering. 

a diverse group of people laughing

Avoid justified text

People with certain cognitive disabilities have problems reading text that is both left and right justified. The uneven spacing between words in fully justified text can cause "rivers of white" space to run down the page making reading difficult and in some cases impossible. Text justification can also cause words to be spaced closely together so that it is difficult for them to locate word boundaries.

Implement a maximum width for containers of heading and paragraph text

For people with some reading or vision disabilities, long lines of text can become a significant barrier. They have trouble keeping their place and following the flow of text. Having a narrow block of text makes it easier for them to continue on to the next line in a block. Text blocks must be no wider than 80 characters. 

When determining how to limit the width of a responsive text block, it can be helpful to use a character counting tool. Or try advanced math! The Golden Ratio Typography Calculator generates suggestions for your entire type hierarchy based on the Golden Ratio: a pattern found in nature that is inherently pleasing to the human eye.

Provide ample line spacing for paragraph text

People with some cognitive disabilities find it difficult to track text where the lines are close together. Providing extra space between lines and paragraphs allows them to better track the next line and to recognize when they have reached the end of a paragraph. Provide line spacing that is at least 1.5 (a space and a half) in text blocks and spaces between paragraphs are at least 1.5x line spacing.

In the first post of this series, we discussed the advantages of generously-sized type comfortably line-spaced within a width-restricted column. Not only does this approach align with that of today’s best-in-class websites and provide a comfortable, welcoming reading experience, it is universal design that is accessible and all-inclusive.

Preparing to Reach a Global Audience

Scratching the surface of localization

Designing type for Right To Left (RTL) languages

Arabic is the 4th most popular language globally and 60% of Arabic speakers prefer browsing internet content in Arabic. Aligning text to the right side is key, and so is upsizing the font to preserve text readability. Factoring in the shorter length of words as most Arabic words. Read more about web design for RTL languages.

Dubai.ae screenshot

Example of RTL language typography on dubai.ae.

Accommodating translated text

Character counts expand or contract according to language. Expect a 15 - 30% expansion when translating English to Spanish or Portuguese, for example. When planning to translate English to Chinese or Japanese, however, expect variation. Read more about typography for translated text here.

Planning for character-based languages

Written Japanese, for example, consists of thousands of characters across four character sets: hiragana, katakana, kanji and the Latin alphabet. Japanese users perceive carelessly designed websites as reflective of brand quality. They describe products as “unnatural”, “foreign”, and “suspicious.” The work to get from unnatural to perfect is not hard. Read more about standards for presenting Japanese text on the screen.

Applying and Iterating Type Systems

Continuous improvement based on user feedback

After carefully selecting type styles representative of the brand experience, applying them with accessibility in mind, defining parameters within responsive components, and perhaps including specifications for translated type, what comes next?

We take these specs and build a living style guide to catalog the site’s elements and components. Having the building blocks all in one place not only ensures consistency but allows developers to rapidly adjust or efficiently leverage the existing pieces to create more complex components.

A living style guide makes it easier to add new patterns to meet your needs and the needs of your users that arise as “the rubber hits the road” when content editors begin using the site and feedback is collected from users, ideally through methodical tests.

Technology has evolved rapidly since pioneers like Emil Ruder developed the Swiss style, and is always offering new challenges for designers. But happily, this evolution has allowed us to collect data to objectively guide our practice and to create, share, and continuously improve standards for accessibility and usability, allowing us to meet the challenge of designing with confidence for the global audience. What a great time to be a designer!

In the next installment, we’ll cover pattern libraries/ living style guides in greater detail. We’ll discuss how style libraries ensure a consistent experience and make ongoing enhancements much easier. Learn about the steps it takes to build an emotion-rich, brand-true user journey within the restricted structure of a website built to last for years displaying dynamic, user-entered content.

Aug 29 2019
Aug 29

usability testing and great government UX webinar

Crafting UX - for the people, by the people 

Mass.gov takes a data-informed approach to site decisions. An open ear to constituent feedback ensures a "wicked awesome" user experience. So it's no surprise that when the site’s navigation needed improvement, user testing became a guiding light.

In our upcoming webinar, hear how Mediacurrent teams with Mass.gov on a user testing strategy leveraging Drupal 8 and Google Optimize. 

Join our webinar

Watch how to deliver a constituent experience that is discoverable, accessible, and truly “for the people, by the people.” Join us on September 18, 2019, at 2:00 EDT to follow along with our process. Learn tips to user test your way to better website UX. 

Register for the webinar.

You'll learn

  • Our approach to testing and gathering user feedback
  • The A/B testing variants we used to steer site navigation and layout
  • Deep dive into testing with Google Optimize 

Presenters

  • Clair Smith, Senior Front End Developer, Mediacurrent
  • Becky Cierpich, UX/UI Designer, Mediacurrent

We hope to see you there!

Aug 20 2019
Aug 20

Welcome to Mediacurrent’s Open Waters, a podcast about open source solutions. In this episode, we catch up with Cristina Chumillas. Cristina comes from the design world and is passionate about front-end development. She works at Lullabot (though when we recorded this, she worked at Ymbra) and has been involved in the Drupal community for years, contributing with code, design, and organizing events. Her contributions to Drupal Core are mainly focused on front-end, design and UX. Nowadays, she's a co-organizer of the Drupal Admin UI & JS Modernization Initiative and a Drupal core UX maintainer.

Audio Download Link

Project Pick

 Claro

Interview with Cristina Chumillas

  1. Tell us about yourself: What is your role, who do you work for, and where are you from?
  2. You are a busy woman, what events have you recently attended and/or are scheduled to attend in the near future?
  3. Which Drupal core initiatives are you currently contributing to?
  4. How does a better admin theme UI help site owners?  
  5. What are the main goals?
  6. Is this initiative sponsored by anyone? 
  7. Who is the target for the initiative? 
  8. How is the initiative organized? 
  9. What improvements will it bring in a short/mid/long term?
  10. How can people get involved in helping with these initiatives?

Quick-takes

  •  Cristina contributed to the Out Of The Box initiative for a while, together with podcast co-host Mario
  • 3 reasons why Drupal needs a better admin theme UI: Content Productivity, savings, less frustration
  • Main goals: We have 2 separate paths: the super-fancy JS app that will land in an undefined point in the future and Claro as the new realistic & releasable short term work that will introduce improvements on each release.
  • Why focus on admin UI?  We’re focusing on the content author's experience because that’s one of the main pain points mentioned in an early survey we did last year.)
  • How is the initiative organized? JS, UX&User studies, New design system (UI), Claro (new theme)
  • What improvements will it bring in a short/mid/long term? Short: New theme/UI, Mid: editor role with specific features, autosave, Long: JS app. 

That’s it for today’s show, thanks for joining us!  Looking for more useful tips, technical takeaways, and creative insights? Visit mediacurrent.com/podcast for more episodes and to subscribe to our newsletter.

Aug 08 2019
Aug 08

For most Drupal projects, patches are inevitable. It’s how we, in the Drupal community, share code. If that scares you, don’t worry-- the community is working hard to move to a pull/merge request workflow. Due to the collaborative nature of Drupal as a thriving open source community and the always growing ecosystem of contrib modules, patches are the ever-evolving glue that can hold a site together.  

Before Drupal 8, you may have seen projects use drush make which is a Drupal specific solution. As part of the “get off the island” movement,  Drupal adopted existing dependency manager Composer. Composer does a decent job alleviating the headaches of managing several sites with different dependencies. However, out of the box Composer will revert patched core files and contrib modules and it is for that reason composer-patches project was created. In this blog post, we are going to review how to set up composer-patches for a composer managed project and how to specify local or remote hosted patches.

The setup

In your favorite command line tool, you will want to add the composer-patches project:

composer require cweagans/composer-patches:~1.0 --update-with-dependencies

With this small change, your project is now set up for success because composer can manage your patches. 

Local patches

Sometimes you will find that you need patch contrib or core specifically for your project and therefore the patch exists locally. Composer-patches can apply that patch for you, we just need to tell it where it is.  Let’s look at an example project that has core patch applied and saved locally in the project root directory ‘patches/core-invalid-config-structures.patch’:
    ...
    "extra": {
      "patches": {
        "drupal/core": {
          "Core Invalid config structures ":"patches/core-invalid-config-structures.patch"
        }
      }
    }

In your composer.json, you will want to add an “extra” section if it doesn’t already exist.  Composer-patches will take the packages listed in “patches” and try to apply any listed patches. In our above example, the package we are patching is “drupal/core”. Patches are declared as follows:

“Patch description”: “path to patch file”

This information will be printed on the command line while composer tries to update the package which makes it important to summarize the patches purpose well.  If you would like to see what this looks like in the wild, take a look at our distribution Rain which leverages a couple of contrib patches.

After manually updating composer.json, it is always a good idea to run composer validate to confirm the json syntax is right.  If you get the green success message run composer update drupal/[projectname], e.g. composer update drupal/core to have the patch applied. 

You will know that the patch is applied based on the output:

patch output

As you can see, the package getting patched is removed, added back and the patch is applied. 

Note: Sometimes I feel like I have to give composer a nudge, always feel comfortable deleting /core, /vendor, or /modules/contrib, but if you delete composer.lock know that your dependencies could update based off your constraints.  Composer.json tracks our package dependencies at certain version constraints while composer.lock is the recipe of computed versions based off those constraints. I have found myself running the following:

rm -rf core && rm -rf modules/contrib && rm -rf vendor
composer install

Remote Patches

When possible we should open issues on Drupal.org and post patches there. That way, the community can work together to solve a problem and usually you’ll get a more reliable, lasting solution. Think about it this way - would you rather only you or your team review a critical patch to your project or hundreds of developers?

To make composer-patches grab a remote patch make the following changes:
    ...
    "extra": {
      "patches": {
        "drupal/core": {

          "#2925890-10: Invalid config structures ":"https://www.drupal.org/files/issues/2018-09-26/2925890-10.patch"
        }
      }
    } 

The only change here is rather than the path to the local patch, we have substituted it for the URL the patch. This will have a similar success message when applied correctly:

remote patches

Tips 

So far, I’ve shown you how to get going with composer-patches project but there are a lot of settings/plugins that can elevate your project.  A feature I turn on for almost all sites is exit on patch failure because it is a big deal when a patch fails.  If you too want to turn this feature on, add the following line to your “extras” section in your composer.json:

"composer-exit-on-patch-failure": true,

I have also found it helpful to add a link back to the original issue in the composer.json patch declaration. Imagine working on a release and one of your patches fail but the only reference you have to the issue is the patch file url? It is times like these that a link to the issue can make your day.  If we made the same change to our example before, it would look like the following:

 "drupal/core": {
          "#2925890-10: Invalid config structures (https://www.drupal.org/project/drupal/issues/2925890)" : "https://www.drupal.org/files/issues/2018-09-26/2925890-10.patch"
        }

Conclusion

Composer-patches is a critical package to any Drupal project managed by Composer. In this blog I showed you how to get started with the project and some of the tips and tricks I’ve learned along the way. How does your team use composer-packages? Do you have a favorite setting that I didn’t mention? Feel free to drop a comment and share what works for you and your team.

Aug 07 2019
Aug 07

Decoupled Drupal 8 and GatsbyJS webinar

How did the City of Sandy Springs, GA improve information system efficiency with a unified platform? Our webinar shows how we built this city on decoupled Drupal 8, GatsbyJS, and Netlify.

We explore how a “build-your-own” software approach gives Sandy Springs the formula for faster site speed and the ability to publish messages across multiple content channels — including new digital signage.

What You'll Learn

  • The City of Sandy Springs’ challenges and goals before adopting Drupal 8 

  • How Sandy Springs manages multi channel publishing across the website, social media, and a network of digital signage devices. 

  • Benefits gained from Drupal 8 and GatsbyJS, including: a fast, reliable site, hosting costs, and ease of development for their team.  

Webinar Recording and Slides 

We Built This City (On Drupal 8) from Mediacurrent

Speakers

Jason Green, Visual Communications Manager at City of Sandy Springs, and Mediacurrent Senior Director of Front End Development Zack Hawkins share an inside look at the project.

Jul 26 2019
Jul 26

Rain logo updated

The Mediacurrent team is excited to formally introduce Rain, an enterprise-grade Drupal install profile. Two years in the making, our team has spent countless hours developing these tools internally and deploying them to our client projects.

Our goal with this post is to share with the broader Drupal community, explain why we created Rain, and share how it can benefit your organization. We welcome feedback.

What is Rain? 

The Rain installation packages the best solutions the Drupal community has to offer so that organizations can build sites faster. We have used Rain internally for the last two years, making improvements along the way prior to its release as an open-source project.

Made by Mediacurrent

We designed the Rain install profile with the goal to capture features that overlap all verticals and projects of every size and scope. As part of the development process, we examined features and content patterns from successful client projects over the past three years. Through our research, we found many content features and module configurations did, in fact, apply to projects across the spectrum. Our focus has been to build Rain with the features that create the best admin and authoring experience we can provide for our clients and the open-source community.

Mediacurrent believes strongly in open source solutions, so we have released all of our project tooling to the community. For more information on the tools we have publicly released please visit the Mediacurrent Development Tools page for more information and links to our projects.

Who is Rain for?

It’s a full-time job to simplify processes on the backend and deliver a consistent, high-impact customer experience. Mediacurrent created the Rain Install Profile to make these jobs easier. 

Clients using Rain today include large B2B Enterprise, Higher Education, and Non-profit organizations. The Rain distribution is flexible enough to serve large and small organizations alike. For large enterprise builds, the install profile will reduce overhead and take advantage of reusable features even if the project overall is a highly-customized implementation. Smaller, more budget-conscious organizations have the opportunity to reuse even more out-of-box functionality for further savings. The end result is a fully branded, enterprise-grade Drupal solution for your organization

What makes the Rain Install profile different?

At DrupalCon this year, co-worker Justin Rent and I presented on the idea of “Content Patterns.” This presentation gives a window into the challenges we were facing and our approach to addressing those challenges. In short, we believe to have long-term success as an agency we need to pool together best practices and take advantage of repeatable patterns. While every project we work on is unique in some way, we also see many shared problems that could benefit from common-sense solutions. As an organization, we made a commitment to build tools that would address those problems and share them with the community.

We borrowed from other distributions, Acquia Lightning and Thunder CMS which are both great projects in their own right. We did, however, add our own twist. 

Our approach

1. Package and configure common modules

We package popular contributed modules like Metatag and many others that focus primarily on authoring and admin experience. Our installation comes with “sensible defaults” that offer a great out of box experience while saving developer and administrative time.

2. Offer flexible content features to jump-start development

Rain offers a variety of content features, including content types and paragraphs, not found in most distributions. These features are all optional and offer the opportunity to jump-start development. 

We believe our approach to content architecture gives editors a consistent, flexible interface for managing content. At the same time, it helps developers get going faster while being fully configurable. 

3. Ship with an extendable base theme and style guide

Rain ships with an excellent starter base theme.  This offers several advantages but is not required (see our GatsbyJS + Rain webinar for a “decoupled" option).

The theme ships with a base style guide that includes the most common components you’ll find on a website. These components provide basic styling and markup that saves development time. The components are intended to be branded to match the design requirements of a given project. Additionally, all Paragraph features are pre-integrated with the base theme and style guide to once again save development time and reduce costs. The net result -- the development team gets a running start on a new project instead of constantly reinventing the wheel.

Next steps

We would love to hear feedback from you. What features are your pain points, what features would you like to see? Interested in working with Mediacurrent? Contact us for a live Rain demo or for more information about our services. 

Jul 23 2019
Jul 23

Rain logo updated

Mediacurrent created the Rain Install Profile to build fast, consistent Drupal websites and improve the editorial experience. Rain expedites website creation, configuration, and deployment.

In the last developer tutorial, we covered how to customize and develop Drupal sites using Rain’s base install profile. This week, we will dive into theming to help frontend developers update the look and feel of the Rain starter theme.

As usual, if you have a question or comment feel free to reach out at @drupalninja

Sub-theme or clone?

The first thing to note is that you can use the Rain install profile with or without the included Rain theme package. The “rain_theme” project exists as its own Composer project which is included by default but can be easily removed. That said, there are benefits to using the Rain Theme as a base theme or starter. The primary benefit is that Paragraphs are integrated with a dozen or so pre-built components that can be easily customized and save you time. 

If you do choose to leverage the base theme, you need to decide whether or not to use Rain Theme as a “parent theme” or as a starter. We highly recommend you do not. This way, you gain full control over the theme and do not need to worry about downstream updates. Leveraging Rain theme as a parent theme can cut down initially on files and code but parent themes in Drupal can be restrictive and cumbersome at times. Ultimately, the decision is yours. With the “clone” approach you can grab everything and rename it or grab only what you want. Anything you don’t use can be discarded.

Using the style guide

The Rain Theme project includes a KSS-based living style guide that has a host of pre-built Twig components that can be integrated with Drupal theme templates.

KSS Style Guide

KSS style guide Example

In the previous step, we mentioned that we recommend cloning the theme so that you can fully control and customize any of these components. The idea is that developers waste less time rebuilding and re-styling the same common components on every new build. Instead, Drupal themers get a head-start while still having enough control of the theme to meet the design requirements of the project.

Working with the popular KSS node project is straightforward. For more information on how to compile and develop with KSS node, visit the project page at https://github.com/kss-node/kss-node.

Even if you are new to KSS, you will find making updates is easy. The “npm run build” command will compile all of your theme assets, as well as the style guide.

Component Integration

The main way components are integrated into Drupal templates is through includes found in Paragraph templates.

Rain Theme Paragraphs Twig Templates

Rain Theme Paragraphs Twig templates screenshot

Using the Components module to define the “@components” namespace, you can see an example below where field markup is passed in as parameters to the component Twig file. You will also that it’s in these templates where we typically attach a library (more on that in a bit). Of course, this is all ready to customize and any time you add or modify fields you will need to adjust templates or components accordingly. JavaScript and CSS are for the most part encapsulated in their corresponding component which keeps things organized. We do recommend you enable the “Twig debug” option in your Drupal services.yml to make it easy to find which templates are being used on any given page.

Rain theme quote paragraph template

Rain Theme Quote Paragraph template

Libraries

Out of the box, we have included many libraries that style components and include vendor libraries where appropriate. Note that these libraries reference compiled CSS and JavaScript found in the “dist” folder of the theme.

Rain theme libraries

Rain Theme Libraries screenshot

Additional Theming Helpers

In addition to the pre-configured templates, style guide and libraries included with Rain, we also ship a few helper modules to make theming easier. 

The “Twig Field Value” module makes it simpler to pull out values from fields and the “Twig Tweak” module adds several utility methods. For a full list of those functions with information visit the “Cheatsheet” documentation page on Drupal.org. As mentioned earlier, the “Components” module is also included and enabled by default in order to allow namespaces to be defined in our theme.

Wrap-up

In this article, we showed frontend developers how to leverage the Rain base theme and style guide. Our recommendation is to clone the theme folder and customize our pre-built components to match your project’s unique requirements. We also covered how to integrate Drupal theme templates with components and define custom libraries. Finally, we covered a few helpful theming modules that ship with Rain and save development time.

In the next (and final) Rain tutorial, we will wrap up this series with a focus on content creation for authors.

Was this information helpful? Let us know! https://twitter.com/drupalninja/

Jul 22 2019
Jul 22

Rain logo updated

Mediacurrent created the Rain Install Profile to build fast, consistent Drupal websites and improve the editorial experience. Rain expedites website creation, configuration, and deployment.

In our previous article, we walked through each feature of the Rain Install Profile with tips on how to use and configure each feature. In today’s tutorial, we zoom in on some technical aspects that backend developers will need to understand to properly develop against the Rain distribution.

Have a question or comment? Hit me up at @drupalninja

Post-install configuration

The last article, What’s New in Rain 3.0, gives some basic instructions on how to install Rain successfully. The Drupal project template repository also gives additional details on how to fully set up the entire project, including the local environment. Here we will cover what developers should do next once they have successfully installed Rain for the first time.

Creating a sub-profile

By default, the Mediacurrent Drupal project template includes a core patch that allows for profiles to inherit features and configuration from a parent profile. This follows a similar pattern to base themes and sub-themes in Drupal. The project template also bundles with it a sample profile (“mis_profile”) to demonstrate how to set up sub-profiles. The screenshot below illustrates the new yml syntax that will enable the “base profile” inheritance.

sub profile

Do I need to create a custom install?

You might ask - Why mess with a custom install profile at all? You certainly don’t have to. You could simply run mis_profile or the base Rain profile as-is and then start making your customizations. That said, many organizations take the approach of creating a custom install profile for each project. This can be handy for encapsulating configuration, install functions and other aspects related to the project. Mediacurrent takes this approach, and we highly recommend other organizations implementing Drupal applications do the same.

To get started, simply rename the “mis_profile” folder to your project name, then search and replace any instances of the “mis_profile” text string in your project. Once this is done you can remove the reference to mis_profile in composer.json as it will no longer be needed. From that point on, when you run build.sh your config.yml will instruct the installer to use your custom profile.

sample profile

Files included in sample mis_profile

Exporting configuration

The easiest way to get started with Rain is to run the ./scripts/build.sh command once your initial sub-profile is set up from the previous step. The base Rain installation will configure common modules covered in the Rain Admin and Authors Overview article. All of the content features will be left disabled initially but can easily be enabled through Drush or the “Admin Modules” page. Once you have the initial configuration set, it’s generally best practice to export that configuration to a version-controlled folder. In your local settings file you should have a line that is commented out by default that looks like the following:

# $config_directories['sync'] = $app_root . '/profiles/mis_profile/config/sync';

The line should have the name of your profile. Once you uncomment out that line you can run drush cex -y using your local site alias. This will export your configuration to your install profile folder (also considered best practice but not required). Now, every time you execute ./scripts/build.sh Drupal will create the site using your exported configuration. We love this approach because it ensures project developers are sharing the same configuration and it pairs nicely with automated tests.

example sync folder

Example sync folder from Gatsby Drupal 8 demo

Customizing Content

The content features that ship with Rain can be easily customized. Custom paragraph types are integrated with the Rain base theme (“rain_theme”) which means that changes to Paragraphs often require updates to Twig templates as well. The Rain theme is optional but adds the benefit of pre-configuring Paragraphs to map to components provided in the theme’s style guide. We will cover theming with Rain more in-depth in the next article.

optional content features

Optional content type features

 

paragraphs pop up

Add Paragraphs pop-up dialog

Maintenance

The Rain install profile takes the role of a quick starter and package manager. This is a similar approach to other distributions like Acquia Lightning. What this means is that after install, developers will own their site’s configuration and primarily leverage Rain’s Composer updates (if desired) for package dependencies. The main project Composer contains references to the base Rain distribution as well as the “Rain Features” package, both of which have their own Composer files that pull in Drupal contributed modules. The benefit of delegating this work to Rain is that modules are continually tested together as a package and include patches where needed. This can dramatically cut down on the work on the part of the “consumer” of Rain versus managing these dependencies on your own.

When updating mediacurrent/rain and mediacurrent/rain_features be sure to check the UPDATE.md file included in the main Rain project repository. This document includes instructions on how to upgrade when significant updates are made. This could include a major version change or updates after a Drupal core minor version is released. Note that Drupal core minor versions often require some refactoring, such as removing a contributed dependency that was ported to core.

Continuous Integration

Mediacurrent uses Bitbucket as our Git service of choice which means that we leverage Bitbucket’s Pipelines to execute CI tests. In our Drupal project template, we include a sample pipelines files that can be leveraged or refactored to match yml syntax for other Git repositories like Github or Gitlab.

Detaching

How married are you to Rain post-install? The answer is not too much. If you wanted to detach from Rain Composer you could easily back out the Composer dependencies, copy over what you need to your main project Composer and remove the reference to Rain’s base install profile in your custom profile’s info.yml file. From that point on, you will be managing dependencies on your own but still have the option to leverage stand-alone projects like Rain Theme or Rain Admin.

In some cases, developers will want to use the base Rain project but not the corresponding Rain Features project. The rain.install does not include any of the optional features from that project which means that you can simply remove “rain_features” from Composer in instances where you will not utilize those features.

Mediacurrent Rain projects

Mediacurrent Rain projects

Local Environments

Mediacurrent currently uses a DrupalVM based local environment bundled with scripts for managing builds and deployments. These packages are included under “require-dev” in your project Composer and are not required to use Rain. If you have another environment you prefer such as Lando or DDEV you can back out these dependencies from your project Composer.

Drupal VM

Deployments

Most Drupal web hosts (e.g Acquia, Pantheon, etc.) have their own git repository they use for deploying artifacts to the server. This includes all the actual Drupal files that make up core, contributed modules and libraries. We don’t want our source git repository to store artifacts or conform to the folder layout required by the web host. Instead, we execute deploy commands to build the artifacts from Composer and commit them to the appropriate destination git repository. To make that process easier we have some additional configuration to add to our config.yml file that instructs how and where code should be deployed.

The key aspects to both the Acquia and Pantheon configuration is pointing the release repo to the appropriate git URL provided by your host, the name of the host and the release drupal root directory. Our examples use Acquia and Pantheon but also support generic git artifact repositories like AWS.

Acquia config:

project_repo: [email protected]

release_repo: [email protected]:mcABCProject.git

release_drupal_root: docroot

deploy_host: Acquia

Pantheon config:

project_repo: [email protected]

release_repo: ssh://codeserver.dev.YOUR_UUID_VALUES.drush.in:2222/~/repository.git

release_drupal_root: web

deploy_host: Pantheon

Additionally, for Pantheon, you will need to add a pantheon.yml file to the root directory with the following values:

api_version: 1

web_docroot: true

php_version: 7.1 (or latest PHP version supported)

This command also needs to be run in order to clean up the Pantheon git repo prior to our first deployment:

rm -r README.txt autoload.php core example.gitignore index.php modules profiles robots.txt sites themes update.php vendor web.config

Now we are ready to build and deploy for the first time. We do this with two commands, one to build the artifacts and one to push files to the release git repository.

Example (using Pantheon):

./scripts/hobson release:build Pantheon develop

./scripts/hobson release:deploy Pantheon develop -y

After you have deployed code to Acquia or Pantheon you should be able to run a clean install using either the sample Rain child install profile (mis_profile) or cloned profile you have created (see Rain README for more details).

Final Thoughts

We hope this article helps developers get up and running smoothly with the Rain install profile and Drupal project template. At this point, you should be fairly comfortable installing Rain, creating a custom profile, exporting configuration, deploying to a Drupal host and maintaining Composer. As a package, Rain was designed to be flexible as possible to allow developers to customize their applications without being locked into a prescribed way of configuring Drupal.

Jul 18 2019
Jul 18

Rain logo updated

Mediacurrent created the Rain Install Profile to build fast, consistent Drupal websites and improve the editorial experience. Rain expedites website creation, configuration, and deployment.

In this article, we will walk through each of the main features that ship with the Rain distribution. This tutorial is intended to help content authors and site administrators get set up quickly with all that Rain has to offer.

Have a question or comment? Hit me up @drupalninja on Twitter.

Content Moderation

A question we often hear when working with a client is, “how can Drupal help to build a publishing workflow that works for my team and business?"

Drupal 8 marked a big step forward for creating flexible editorial workflows. Building on Drupal 8's support for content moderation workflows, Rain comes pre-configured with a set of Workflow states. The term “states” refers to the different statuses your content can have throughout the publishing process - the four statuses available by default are “Draft”, “Needs Review”, “Published” and “Archived.” They can be easily enabled for any content type. As with everything in Drupal, these states and workflows are highly configurable. 

Once enabled, using content moderation in Drupal 8 is straightforward. After you save a piece of content, initially it will default to the “Draft” status which will remain unpublished. The “Review” status also preserves the unpublished status until the current edits get published. What’s great about Workflow in Drupal 8 is that you can make updates on a published piece of content without affecting the published state of that content until your changes are ready to be published. The video below demonstrates how to enable workflow and see draft updates before they are published.

[embedded content]

To review any content currently in a workflow state you can click on the “Moderated Content” local task which is visible from the main Admin content screen (see below).

Admin content screen

Revisions

As a best practice, we recommend enabling revisions for all content. This allows editors to easily undo a change made by mistake and revisions keeps a full history of edits for each node. By default, all of Rain’s optional content features have revisions enabled by default. As illustrated below once you have made a save on a piece of content, the “Revisions” tab will appear with options for reviewing or reverting a change.

Rain Drupal Content Moderation - Revisions

Media Library

Coming soon to Drupal core is an overhauled Media library feature. In the meantime, Drupal contrib offers some very good Media library features that are pre-configured in Rain. The Rain media features are integrated with most image fields including the “thumbnail” field on all content type features that ship with Rain.

The video below demonstrates two notable features. First is the pop-up dialog that shows editors all media available to choose from within the site. Editors can search or browse for an existing image if desired. Second is the drag-and-drop file upload which lets the editor user drag an image onto the dialog to immediately upload the file. 

[embedded content]

 

Media Library

WYSIWYG Media

Media is commonly embedded within the WYSIWYG editor in Drupal. Rain helps improve this experience by adding a button which embeds the Media library feature to be used within WYSIWYG. The key difference between the Media library pop-up you see on fields versus the pop-up you see within WYSIWYG is that here you will have an option to select the image style. The video below illustrates how this is done.

[embedded content]

embed media

WYSIWYG Linkit

Another WYSIWYG enhancement that ships with Rain is the integrated “Linkit” module that gives users an autocomplete dialog for links. The short video below demonstrates how to use this feature.

[embedded content]

Content Scheduling

A common task for content editors is scheduling content to be published at a future date and time. Rain gives authors the ability to schedule content easily from the content edit screen. Note that this feature will override the Workflow state so this should be considered when assigning user roles and permissions. The screenshot below indicates the location of the “Scheduling options” feature that appears in the sidebar on node edit pages.

node edit

Clean Aliases

Drupal is usually configured with the ability to set alias patterns for content. This will create the meaningful content “slugs” visitors see in the browser which also adheres to SEO best practices. Rain’s approach is to pre-load a set of sensible defaults that get administrators started quickly. The video below demonstrates how an admin user would configure an alias pattern for a content type.

[embedded content]

XML Sitemap

By default, the Rain distribution generates a sitemap.xml feed populated with all published content. For editors, it can be important to understand how to exclude content from a sitemap or update the priority for SEO purposes. The screenshot below indicates where these settings live on the node edit page.

xml sitemap

Metatag Configuration

The default configuration enabled by the Rain install profile should work well for most sites. Metatag, a core building block for your website’s SEO strategy, is also enabled for all optional content features that ship with the Rain distribution. To update meta tags settings on an individual piece of content, editors can simply edit the “Meta tags” area of the sidebar on the edit screen (see below).

Metatag in Drupal

Google Analytics

Enabling Google Analytics on your Drupal website is a very simple process. The Rain distribution installs the Google Analytics module by default but the tracking embed will not fire until an administrator has supplied a “Web Property ID.” The Google Analytics documentation shows you where to find this ID. To navigate to the Google Analytics settings page, look for the “Google Analytics” link on the main admin configuration page. Most of the default settings will work well without change and the only required setting is the “UA” ID highlighted below.

Google Analytics

Enabling Content Features

Rain comes with many optional content features that can be enabled at any time. This includes content types, vocabularies, paragraphs, search and block types. Enabling a content feature will create the corresponding content type, taxonomy, etc. that can then be further customized. Any paragraph feature that is enabled will be immediately visible on any Rain content type that has enabled. Watch the video below to see an example of how to enable these features.

[embedded content]

Enabling Content Features

Wrapping Up

Mediacurrent created Rain to jump-start development and give editors the tools they need to effectively manage content. All features that ship with Rain are optional and highly configurable. We tried to strike a balance of pre-configuring as many essential modules as possible while still allowing site administrators to own the configuration of their Drupal site.

In the next tutorial, we will “pop open the hood” for Drupal developers to explain in technical detail how to build sites with Rain.

Jul 09 2019
Jul 09

open waters

In this episode of Open Waters, we talk with our own Bob Kepford, creator of the weekly newsletter The Weekly Drop, to discuss Open Source Serverless solutions.  Bob presented this topic at DrupalCon Seattle and it was very well received.  You can catch the recording on the DrupalCon site.

Audio Download Link

Pro Project Pick: Serverless Framework

Interview with Bob Kepford

  • The big question: What is Serverless?
  • What are the 4 pillars of serverless?
  • What are the advantages and disadvantages?
  • What do I have to know to get started?
  • As a site owner, why would I consider using serverless?
  • What are the security implications when using serverless?
  • Who are the big players who are adopting and/or providing serverless solutions?

Subscribe

Apple PodcastsStitcher | Google Podcasts

Jun 17 2019
Jun 17

open waters

Mediacurrent is proud to announce the launch of our new podcast with the release of our pilot episode. Open Waters is a podcast exploring the intersection of open source technology and digital marketing. It’s made especially for CMO's, Directors and Managers of Marketing, technology, and digital strategy.

Our Purpose

We think open source is an ocean of opportunity to maximize your martech investment. 

We encourage you to listen and learn about using open source technology and forward thinking marketing strategy to generate and convert leads, improve security, increase speed to market, and identify the ROI of your digital investments. Our goal is to educate about the challenges and solutions we see with our own clients and in the market.

Welcome to Open Waters - Episode 0 

Dive in to our pilot episode!

Audio Download Link

In this episode:

  • New format, shorter but more frequent episode release schedule.
  • We're taking a different direction from our Mediacurrent Dropcast, no longer focused strictly on Drupal. Instead, we will be talking about the business benefits of open source software.
  • We are going to change up some sections. A little less news, and more about solutions.
  • We will probably still do the Pro Project pick from our Dropcast

Upcoming Episodes:

  •  Ben Robertson, who presented at the GatsbyJS Days conference in December, will join us to talk about the benefits of Gatsby JS.
  • Mario Hernandez will be on the podcast to talk about our upcoming expanded training for components. 
  • We’ll have an episode to talk about how to choose a CMS, whether it’s Drupal, WordPress, or any of the other bazillion options.
  • Bob Kepford, you may have heard of him, will be on to talk about serverless 101 and the problems it can solve.
  • We will have Jason Lengstorf from Gatsby on to talk about the project.
  • And much, much more.

Subscribe to Open Waters 

New episodes will be released tri-weekly on Tuesdays.

How Can I Support the Show?

Subscribe, leave a review, and share about us on social media with the hashtag #openwaterspodcast. Have an idea for a topic? Tweet at our hosts Mark Casias, Bob Kepford, and Mario Hernandez. Be sure to subscribe in your favorite podcast platform. Links to follow.

Jun 17 2019
Jun 17

Drupal 8 to Drupal 8

Drupal 9’s release is just around the corner. If you are on Drupal 8, then you are well on your way to Drupal 9 readiness. The planned release date for Drupal 9 is June 2020 with Drupal 8 and Drupal 7 reaching end of life in November 2021. Drupal 8’s new release cycle allows a straightforward upgrade path but developers no longer get the benefit of rearchitecting for the new version. Thinking about architectural decisions, technical debt, and clean site building now will help your Drupal 9 transition and success.

Upgrade to minor releases

The simplest way to prepare for Drupal 9 is by staying up to date on Drupal’s minor release cycle. New features roll out every 6-months and each release adds new functionality plus can deprecate contrib modules (workbench moderation in favor of content moderation, media in favor of core media, panels in favor of layout builder, etc). Drupal 8.7 came out on May 1 while Drupal 8.8 is planned for December 4.

With each minor release, the following should be considered in your deployment process:

Consider soon-to-be-deprecated code

Run `drupal-check` to validate what deprecated code exists in your repository or use the GUI based Upgrade Status module. Create tasks in your backlog to remove these over the following 6-months. Check custom code but also key contrib modules utilized. If deprecations are found in contrib, create an issue then patch the deprecation.

Look ahead to Drupal 9 core

Review the release notes and see what core features can take the place of something you’re using contrib or custom to achieve. Evaluate updating to the core solution. Removing custom code or contrib in favor of core ensures long term support and automated testing. Example: Are you still running contrib media? Work to upgrade this to core media.

Talk to your editors and site builders

Ask them, “What is the one thing we could do or stop doing to make your day to day better?” Work to include this feedback over your next few sprints. Yes, this won’t make your Drupal 9 upgrade easier, but it will ensure team support for Drupal across your organization. Preparing for Drupal 9 includes keeping connected to the overall team’s needs.

Audit Site Building

Drupal’s power lies in how easy it is to add fields, make customizations, and tag on new features — without ever touching code.   

Drupal’s pain lies in how easy it is to add fields, make customizations, and tag on new features — without ever touching code.

Since the core codebase and configuration will not change in Drupal 9, these customizations can add bloat, cause regression risks, and slow performance. 

Regularly check in on your content types, site configuration, and fields to see what can be deprecated, removed, or done in a more reusable way. Things to look for include:

  • Fields added for a one-time event that now sit dormant

    • Think about removing this field completely or utilize an existing block, field, or paragraph to achieve the results.
  • Content types with little to no content added

    • Is this content type still needed? Could you instead create a more generalized content type utilizing paragraphs or layout builder to allow more customization of one-off page creation requests?
  • Out-of-date help text

    • Help text is often forgotten about by power uses. But what happens when a new teammate joins the organization? What about when someone takes a vacation? Ensuring up-to-date help text, consistent field titles, and reasonably organized fields on content types are all ways to support an intuitive admin interface

Automation

In past versions of Drupal, a new major release meant any work to automating processes would grind to a halt as these would need to be recreated for the next major version. Since Drupal 9 will no longer require tearing down and rebuilding your project, any improvement made to automation will give you more time to focus on features, your editors, and your organization’s mission. No stakeholder wants to hear they can’t have a new feature because of the latest security release or a botched release. Give your team confidence to releases and features by automating testing today.

Two aspects of automation should specifically be focused on:

Releases

Every part of a release that can be automated should be. This allows for releases to happen more often with less risk.

  • Aim to create a release process that is not dependent on a single person
    • When a security risk opens up and your release engineer is on vacation, can someone quickly and reliably execute the release?
  • Take one step at a time.
    • Automate one step at a time and improve over time. Don’t try to make everything happen at once.
  • Look at what continuous integration your hosts uses.
    • Leverage something you already have existing through your host or Git provider versus building from scratch.

Testing

Every developer loves squashing technical debt. Every product owner cringes when those two words are mentioned. Technical debt never ends and can take hundreds of hours away from feature development. Though automated testing can’t change that, it can help to prevent rework and regressions as code or features are updated. Similar to automating releases, automating testing provides more confidence in your site’s stability and performance with each test added. 

There are a variety of testing infrastructures to look at but Drupal Core provides PHPUnit tests out of the box and a testing infrastructure for them. Behat integrates well for quick smoke tests after releases to ensure that core pages or links work as expected.

  • Start small.
    • Try to make a simple hello world test and expand to an easy, and somewhat trivial check after a release.
  • Scale up smoke tests.
    • Add in new tests over time for items you check in a smoke test manually after each release. Soon you’ll have your smoke testing fully automated and can start implementing regression tests and testing in all future code.

Plan Strategically for Drupal 9 

Upgrading to Drupal 9 will be an easier process than ever before but will not equal a clean slate to start from. Decisions made today will affect your site for years to come. Throughout your day-to-day, think of the following:

  • Stay up to date on Drupal Minor Upgrades (8.7, 8.8, etc.).
  • Audit your site building to ensure it applies globally, remove one-off fields and deprecated features.
  • Automate your releases and smoke/regression testing.

If you have questions about how to build a strategy for a successful transition to Drupal 9, we’re here to help. Drop us a line.

Jun 14 2019
Jun 14

What’s the one big challenge that marketers and CMO’s we partner with  are facing this year? It’s really tough to put a finger on just one. Proving impact on revenue, marketing team staffing, personalization, and marketing-IT alignment are among the hurdles voiced in discussions that Mediacurrent’s sales team are having with prospects and clients. We are finding CMO’s are pressed more than ever to show marketing’s value while the complexities and opportunities sprouting within digital continue to evolve. Let’s dive into each challenge and uncover what makes these hurdles difficult to jump — and the tools or approach that can help marketers overcome them.

Proving Impact on Revenue

Probably not surprising that last year Gartner surveyed where CMOs were spending marketing budgets. They found marketing budgets shrunk slightly year over year since 2016 while a higher percentage of budgets are being allocated to digital. The pressure is on for marketers to prove how specific marketing campaigns and investments directly contribute to an organization’s revenue. Owners and shareholders want more specificity in understanding how much budget to allocate to higher revenue generating activities. Furthermore, marketers need to react faster to fluctuating market conditions that impact customer experience.

How can you attribute revenue to specific marketing activities and demonstrate ROI so you can invest and optimize in the right activities? There are a number of SaaS tools available and most implement a specific approach to measure marketing attribution and achieve granular ROI tracking. 

  • Motomo - offers a GPL-licensed on-premise web analytics stack.
  • Bizible - analytics and multi-touch revenue attribution.
  • Terminus / Brightfunnel - product suite that offers account-based marketing analytics and sales insights.
  • Conversion Logic - cross-channel attribution with AI-powered insights and budget forecast simulations.
  • Allocadia - a marketing performance management platform that offers revenue attribution and insights into marketing budget allocation.
  • Full Circle Insights - product stack that tracks marketing and sales attribution, built as a native Salesforce App.
  • Google Attribution - formerly called Adometry, it’s now part of the Google Marketing Platform.
  • Salesforce CRM - ROI tracking can be enabled with additional campaign configuration.
  • Domo Digital 360 - full suite of analytics, funnel, and ROI tracking.
  • VisualIQ - strategic measurement, multi-touch attribution, audience analysis, and predictive insights.
  • Oracle Marketing Cloud - integrated suite of tools that include analytics, marketing automation, content/social marketing, and data management.

Because each tool specializes in a specific aspect of ROI tracking, you will need to do some research to understand which tool best fits your organization. Most of the tools listed above implement some form of attribution tracking that will help achieve more robust ROI calculations. Our Director of Marketing Adam Kirby gives a helpful overview of  how marketing attribution works, in his MarTech West slide deck. Organizations we speak with often need help from consultants and agencies to understand how to optimally configure their martech stack with ROI tracking tools. This need coincidentally brings us to the next challenge marketer’s are facing...

Staffing Teams - The Right Blend

Organizations are becoming more careful to find the proper balance between internal team staffing and engaging help from an outside agency. In the early 2010’s, there was a movement within Fortune 2000 companies to bring more expertise in-house. As martech complexity evolved into the latter part of this decade, organizations are realizing that exposure to new technologies and approaches is limited with their in-house teams. By engaging with a wide spectrum of industries, clients, and projects, agencies provide a broad view into the martech landscape that in-house teams don’t have. What’s the right blend? It depends on the vertical. Organizations with one large website typically outsource at least half of their digital marketing. Higher Ed and Government have longer procurement cycles and, consequently, need at least 75% of their overall marketing team to be full-time in-house.

Not only is outside help needed by in-house teams to stay informed, budget scrutiny is forcing CMO’s to seek off-shore development help. However, they are finding off-shore falters when technology projects aren’t being led by one or more on-shore architects who maintain a project’s integrity between on-shore stakeholders and off-shore teams. These technical liaisons are critical to off-shore development success. We see too many organizations assume if off-shore developers demonstrate technical competency, they should be fully capable of leading an implementation. Yet, those organizations fail to consider the strength of influence local culture has on communication dynamics and the perception of requirements by off-shore teams.

Personalization

Another challenge marketers are targeting is how personalization can impact KPIs and produce a higher ROI percentage compared to other digital marketing efforts. In 2017, the concept of personalization was buzzing while marketers were trying to understand what it takes from a content and labor effect to implement. After GDPR went into effect a little over a year ago, personalization efforts have to take into account how GDPR laws impact customer data acquisition and retention, making the implementation of personalization trickier and more complex with respect to data analysis and the ability to capitalize on personalization opportunities. Tools like Acquia Lift, open source marketing automation platform Mautic (recently acquired by Acquia), Triblio, and Optimizely Web Personalization offer slightly different perspectives on personalization. 

When evaluating if you’re ready for personalization, here are eight considerations that will dictate success when carefully planned or potential failure if not addressed:

  1. Do you have enough content that’s written for each persona your personalization effort needs to target?
  2. Do you have content creators who can continually create new and evergreen content?
  3. Do you have KPIs defined to track the performance of your personalization efforts?
  4. Is your martech stack compatible with personalization technologies that fit your business model?
  5. Do accurate, fresh data metrics exist in usable forms? Is data structured uniformly and exclusive of redundancies that might skew its meaning?
  6. How do data privacy laws impact the efficacy of a personalization initiative? Can enough of the right user data legally be captured to supply the initiative?
  7. Are data governance guidelines in place that ensure data integrity stays intact well beyond the implementation phase of a personalization initiative?
  8. Finally, is your department or organization committed to investing time and energy into personalization? It’s a long game and shouldn’t be misinterpreted as an off-the-shelf-set-it-and-forget-it type of content solution.

If you’re starting a personalization strategy from ground zero, Mediacurrent Senior Digital Strategist Danielle Barthelemy wrote a quick guide to creating a content strategy with personalization as the end-goal. Danielle illustrates how a sound personalization strategy positively influences purchase intent, response rate, and acquisition costs. 

Marketing-IT Alignment

In order for digital marketing execution to be as effective and efficient as possible with initiatives like ROI tracking and personalization, it’s imperative for marketing and IT teams to collaborate cohesively.  A frictionless environment is critical for marketers to meet the immediacy of an ever-increasing market speed. In some organizations, these two departments are still maintaining competing interests in relation to policy, security, infrastructure, and budget. Example scenarios include  strict IT policies that can stifle speed-to-market, cowboy marketers all but ignoring technical security when implementing new tools, and executives missing the budgetary discord that echoes when both departments operate in their own silos.

These independent agendas must be meshed together into one for the betterment of the organization. But how? 

  • Learn how to empathize by understanding each other’s goals and challenges across departments. Define a shared list of KPI’s and time-bound each.
  • Schedule weekly touch point meetings between IT and marketing leaders.
  • Conduct a quarterly tools review to understand the “why” behind tools that each department uses.
  • Demonstrate discipline-specific concepts that require collaboration from the other department. For instance, show IT how marketing attribution works and what’s required of them to make it successful. Or, show marketing what a normalized database is and how it will help marketing be successful by reducing duplicate data.

Marketing ROI: An Ongoing Challenge

Overall, the challenges CMO’s are asking us about as we move into the latter half of 2019 are heavily rooted in accurately tracking ROI and putting tools in place to boost it. While marketers have been challenged with proving ROI for years, digital has evolved to a point where tools and systems exist that embolden marketers to aggressively pursue understanding where their money is best spent. For most organizations, there are still talent hurdles to overcome and knowledge gaps to fill to properly implement martech and systems that accurately track ROI. 

How about you — what challenges are your marketing department working to solve this year? Have you found the right in-house to agency team blend? Have you had success with ROI tracking and personalization?

Jun 05 2019
Jun 05

On Twitter, in Slack, on Discord, in IRC, or wherever you hang out with other developers on the internet, you may have heard some formulation of the following statements:

  • React doesn't support accessibility
  • React makes websites inaccessible
  • People should write accessible HTML instead of React
  • React is ruining the internet

There's a somewhat common misperception that JavaScript frameworks and web accessibility don't mix. React, being one of the largest JavaScript libraries, is often the target. 

In my career, however, I have had the interesting experience of being introduced to accessibility and ReactJS at around the same time. I found tooling in React that helped me learn a lot about accessibility that I never would have encountered otherwise.

And while I don't disagree that there are plenty of libraries, websites, apps, etc. written in React that are inaccessible, I do disagree there is something inherent in ReactJS that makes developers build inaccessible sites. In fact, I love the accessibility tooling available in the React ecosystem, so this post is really about how React can help you make more accessible websites than you've ever made before.

I'll outline how you can combine React linting tools, DOM auditing, and Storybook (a component library tool) to provide a really supportive accessibility environment for developers -- whether they are accessibility pros or just getting started. By the end of this post, you'll have the following configured for your Gatsby project (or other React project):

  • in-editor reporting of accessibility errors
  • a pre-commit hook for preventing accessibility errors from getting into the repository
  • browser console reporting of accessibility errors during development, with links to info on how to resolve the errors
  • a component library with built-in accessibility testing so all project stakeholders can hold the team accountable for accessibility issues

Want to get started right away? I created a Gatsby starter with all these accessibility tools built in. Checkout the gatsby-starter-accessibility repo that has all these features available out of the box.

Tools and Setup

eslint-plugin-jsx-a11y

If you've written JavaScript over the past few years, you've probably used or at least heard of ESLint. If not, now is a great time to get started with it!

ESLint is a linting utility for JavaScript that helps you catch formatting and syntax errors while you are writing code. Most editors have some sort of linting configuration built in, which lets you see errors in your editor while you code.

This is really helpful for keeping code consistent, especially when there's a lot of people working on a project.

ESLint also has a really healthy plugin ecosystem. You can include rules specific to the JavaScript framework you are working with (i.e., React, Angular, Vue, etc), among others. For React, I typically use the eslint-plugin-react and the really helpful eslint-plugin-jsx-a11y. This plugin lints your code for known accessibility violations, using these rules.

Having these automated tests run while you are writing code can prevent so many errors. Even though automated accessibility testing catches only about 20-30% of all accessibility errors, catching these errors before they make it into a codebase can save time, budget, and energy for doing more manual testing once the code is in the browser.

Usage

Here's how you can get started with accessibility linting in your React project.

First, we'll need to install the necessary eslint packages:

npm install eslint eslint-plugin-react eslint-plugin-jsx-a11y --save-dev

In your package.json, add the following configuration:

"eslintConfig": {
    "parserOptions": {
      "sourceType": "module"
    },
    "env": {
      "node": true,
      "browser": true,
      "es6": true
    },
    "plugins": [
      "react",
      "jsx-a11y"
    ],
    "extends": [
      "eslint:recommended",
      "plugin:react/recommended",
      "plugin:jsx-a11y/recommended"
    ]
}

With this added to your package.json, ESLint will use the rules recommended by ESLint, React, and the jsx-a11y plugin while you are working. 

You'll want to make sure your editor is set up to display linting errors in the editor for this to be really useful.

Add a pre-commit hook for preventing inaccessible code in the codebase using lint:staged

Now we've got some accessibility linting set up, and hopefully everyone working on the project has linting turned on in their editor so they can see any errors while they work.

But you can't be 100% sure that everyone will be paying attention to the linter. And even if they are, it's easy to make a quick change, switch files, and any errors will be out of sight, out of mind.

What we can do as an extra check to prevent inaccessible code from entering the codebase is to add a pre-commit hook that runs the linting we set up above every time a developer tries to commit code. If an accessibility error is found, an error message will display with the relevant linting error and location of the error, and the commit will be prevented until the developer resolves the issue.

lint-staged will run a pre-commit hook that will catch any accessibility errors raised by eslint-plugin-jsx-a11y

lint-staged will run a pre-commit hook that will catch any accessibility errors raised by eslint-plugin-jsx-a11y

Usage

The easiest way to set up pre-commit linting hooks is using the lint-staged package. After you've got all your eslint configuration set up (from our first step), run the following command in your project directory:

npx mrm lint-staged

This command will install the husky package for managing the pre-commit hooks and look in your package.json to automatically setup a pre-commit hook based on your linting configuration.

A simple configuration that lints all JS files based on the existing eslint configuration in the repo will look like this (from package.json):

"husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
},
"lint-staged": {
    "*.js": [
      "eslint"
    ]
}

You can adjust this as you see fit. For example, sometimes you want to limit linting to certain directories. To run the pre-commit hook only on JS files in the src directory, you would update the lint-staged configuration like this:

"lint-staged": {
    "src/*.js": [
      "eslint"
    ]
}

The great thing about lint-staged is that it only lints the files that are part of the current commit. If for some reason there is some pre-existing errors in another part of the codebase, the commit won't be prevented--it only prevents new errors from being introduced.

react-axe

The great thing about the linting setup we have now is that it will prevent a lot of errors from being introduced into the codebase. It won't prevent all errors, however. Some errors only exist when several components are used together, or from certain content, and can only be caught in the browser.

Luckily, we have a solution for this, too. Axe is an open source engine for automated accessibility testing, supported by Deque. I first became familiar with axe by using their really useful browser extension for testing individual pages in the browser.

The problem with browser-extension accessibility testing is that they are typically only run after development is complete. Using the react-axe library, you can have automated accessibility testing run on every page during development, so developers can get real-time feedback on accessibility issues. This helps make sure that accessibility issues never make it to production, and it also educates developers who may not be accessibility experts on potential pitfalls.

The react-axe library is an easy to use implementation of the axe engine, specifically for React.

Usage

Here's how to get started using react-axe with Gatsby (someone made a Gatsby plugin for it!):

npm install --save gatsby-plugin-react-axe

Add gatsby-plugin-react-axe to your plugins array in gatsby-config.js

module.exports = {
 siteMetadata: {
        title: 'Gatsby Default Starter',
    description:
      'Kick off your next, great Gatsby project with this default starter. This barebones starter ships with the main Gatsby configuration files you might need.',
    author: '@gatsbyjs',
  },
  plugins: [
    'gatsby-plugin-react-axe',
    // other plugins go here
  ],
};

Now, when the page renders, the plugin will print any accessibility errors to the browser console. Here's an example, where I've put an <h5> directly underneath an <h1>:

React aXe will show accessibility errors in the console while you are developing.

React aXe will show accessibility errors in the console while you are developing.

You can see that in the axe message in the console that it has identified my heading issue: "Heading issues should only increase by one" as a moderate issue. It also includes a link to learn more about why this is an issue and how to resolve it: https://dequeuniversity.com/rules/axe/3.2/heading-order. And lastly, it displays the specific element that is causing the issue for easy identification.

This kind of instant feedback is so important, whether you are an accessibility beginner or even a seasoned pro. Catching the automated issues instantaneously can give you more bandwidth to focus on other more involved tasks.

Storybook and Accessibility

The last piece of our accessibility workflow has to do with our component-driven workflow. For React projects, I have really enjoyed using Storybook to build and document our front end components. 

Storybook is an open source tool for developing UI components in isolation for React, Vue, and Angular. It makes building stunning UIs organized and efficient.

storybook.js.org

Besides having a nice workflow and UI, Storybook has an awesome accessibility add-on that adds a panel to each component in your component library highlighting accessibility issues.

Our storybook configuration has built-in axe tests for each component and a color blindness simulator, provided by the storybook accessibility add-on.

Behind the scenes, the add-on actually also uses aXe for testing. This is really nice, because it means that the testing we are using in development is the same as what we are using in the component library. Having the errors highlighted in the component library also helps everyone on our project teams catch accessibility issues as they are browsing the library, either for QA purposes or design inspiration.

Setup

The setup for Storybook is a bit more involved, so if you haven't used Storybook before, you can checkout the Storybook for React documentation for a generic React setup.

If you want to get Storybook running with Gatsby, see Visual Testing with Storybook in the Gatsby docs.

Once you have Storybook setup, adding the accessibility add-on is pretty straightforward.

First, install the add-on:

npm install @storybook/addon-a11y --save-dev

Then add this line to your addons.js file in your storybook config directory:

import '@storybook/addon-a11y/register';

And lastly, add this line in your Storybook config.js file to automatically add the accessibility panel to all components:

addDecorator(withA11y);

When you run Storybook now, you should now see the accessibility panel (see a live version here):

Our storybook configuration has built-in axe tests for each component and a color blindness simulator, provided by the storybook accessibility add-on.

Our storybook configuration has built-in axe tests for each component and a color blindness simulator, provided by the storybook accessibility add-on.

As a side note - you can control the order of the tabs in your add-ons panel based on the order that you import add-ons into your addons.js file, if you want to have the accessibility panel display by default, make sure it is the first line in your addons.js.

Wrap up

If you didn't follow along with the setup or just want to get a new project setup quickly with this workflow, checkout the gatsby-starter-accessibility Gatsby starter!

You can create a new Gatsby site with all the configuration I described above out-of-the box with this single line in your terminal:

npx gatsby new my-accessible-project https://github.com/benjamingrobertson/gatsby-starter-accessibility

Or you can checkout the specific configuration in the repo.

Whether you ran through all the steps above or use with the starter, you'll have the following features set up in your Gatsby / React project:

  • in-editor reporting of accessibility errors
  • a pre-commit hook for preventing accessibility errors from getting into the repository
  • browser console reporting of accessibility errors during development, with links to info on how to resolve the errors
  • a component library with built-in accessibility testing so all project stakeholders can hold the team accountable for accessibility issues

On a complex project with many team members and moving parts, automating accessibility testing will help save time to make sure you can pay more attention to the accessibility tasks that can't be caught by automated tests. 

Beyond that, tools like this can really help developers level up their accessibility knowledge.

I know it's helped me--I hope it helps your team too!

Jun 03 2019
Jun 03

By nature, menus are complicated. They’re not easy to work with, build or style, and yet they are probably the single most important navigation element of any website. Despite their complication, they need to be perfect to serve their purpose. A menu can make or break a website. They can make your browsing experience a pleasant one, or can drive you to leave a website frustrated and likely never to return.

When it comes to menus and forms, it is best to let Drupal dictate the direction rather than build them independently of Drupal. By adhering to Drupal’s best practices we can save a lot of time, effort and frustration. For example, rather than writing your menu’s markup before you see it being printed by Drupal, it is best to build your menu in Drupal and see what the markup looks like. Then you can use Drupal’s markup as a starting point for writing your menu’s markup. 

This is going to be a lengthy post (mostly because it includes a lot of code snippets), but this article will cover all you need to accomplish the following:

Build a multi-level menu component in Pattern Lab

Let’s start by building a pretty straight forward multi-level menu component in Pattern Lab. If you’ve used Pattern Lab or KSS Node you know most components require at least three files: 

  • .twig for the component markup and logic,
  • .yml or json for the component data or dummy content
  • .css or scss for the component styles
  • In some cases you may also need a Javascript file

For more in-depth explanation on building and integrating components read our blog series.  
Note: This series is over two years old and many things have changed since then, but the basics of building a component still apply.

Building the component

  1. In your theme’s components location create a new directory called main-menu
  2. In the main-menu directory, create the following three files:
    • main-menu.twig
    • main-menu.yml
    • main-menu.scss
  3. Inside main-menu.yml add the code below:
  4. The data above represents an array of items. Each item has 3 key/value pairs: Title, URL and menu_level.  Each item represents a link in the menu.  You may notice some of the links have nested arrays (i.e. below). These represent submenus in the menu tree. The items array above is only intended to simulate the menu’s data for our component. In Drupal the array will be provided when we add menu links to Drupal’s Main Menu.
  5. Inside main-menu.twig add the code below:
  6. If the code above does not look familiar to you it’s probably because you’ve never used a Twig Macro. I will explain the macro in detail shortly, but for now let’s move on to completing the component.
  7. Finally add the following styles in main-menu.scss

These styles are as bare as possible. They are simply to make the menu look presentable and could use a lot of improvements. This is what the multi-level menu looks like:

multi-level menu

It’s important to note that the component will simply be used for styleguide purposes. We will create a similar component for Drupal, but we will use the original component above as a base for markup styles and behavior.

Why do we need to create a duplicate component for Drupal?

Drupal provides attributes Pattern Lab does not understand. Rather than over complicating the component, we are going to keep it simple for styleguide purposes while the Drupal version is more elaborate with all the things Drupal needs. This is not required but provides more clarity to the process.

Create a Twig template suggestion for the main menu

Our ultimate goal is to update Drupal’s menu system to render with similar markup as the main-menu component. This will require several steps which we will cover next.

Follow these steps to enable Twig Debugging in your theme. Then, you can inspect your site, which will allow you to see the various template suggestions that Drupal uses to render the page; including your navigation menu. The debug information looks like this:

Under File Name Suggestions notice two template names: menu.html.twig & main-menu.html.twig. The X next to menu.html.twig indicates Drupal is using this file to render the Main Menu. The second file, main-menu.html.twig, is what Drupal is suggesting we create if we only want to alter the Main Menu and not other menus.

Under Begin Output notice the path where menu.html.twig can be found, the example above is pointing to Drupal’s stable theme.

To ensure we only affect the main menu and not other menus on our site, we are going to make a copy of Drupal’s menu.html.twig in our theme and then override it. This is recommended rather than modifying Drupal core’s template. Let’s start:

  1. Copy the menu.html.twig template from core/themes/stable/templates/navigation/ into [site_root]/themes/custom/<your-theme>/templates/navigation/menu.html.twig (if these folders do not exist yet in your theme go ahead and create them).
    Following the golden rule “Never hack core”, we want to make a copy of Drupal’s menu template in our own theme. Replace the core theme’s name with your core base theme if you are not using stable.

  2. Next, In your theme rename the newly copied template to main-menu.html.twig.
    Copying menu.html.twig into our theme will affect other menus. This is why we are renaming the template so it only affects the main menu (main-menu.html.twig). Replace ‘main’ with whatever your menu’s machine name is if you are not using Drupal’s Main Menu. This can be found in Drupal’s Menus page (admin/structure/menus).

  3. After clearing Drupal’s cache, inspect the menu again and you should see the X next to main-menu.html.twig which means Drupal is now using our custom twig template suggestion to render the menu.

Create a multi-level menu in Drupal

  • Let’s make sure we have a menu we can see in Drupal. Let’s create a multi-level menu using the Main Navigation menu (Structure | Menus | Main Navigation).

  • Add as many links as you wish. Be sure to add nested items so we end up with a multi-level menu.

  • In addition, ensure each of the submenu’s parent links are set to “show expanded”. You will see the option on the Add/Edit Link page.

  • Finally, go to Structure | Block Layout and click Configure next to Main Navigation

Customize the template suggestion

Before we look at the code inside menu.html.twig as it may look confusing or not familiar, we are going to move it into the same directory as the main-menu component. We are doing this to make some improvements to the macro.

  1. In the same directory where you created the main-menu component, create a new file called _main-menu-macro.twig (notice the leading underscore in the file name). This file is only for Drupal purposes and we don’t need it to be shown in Pattern Lab. The underscore allows Pattern Lab to ignore it.

  2. Copy all the code from main-menu.html.twig into _main-menu-macro.twig.

The above code is a Twig Macro. Macros are the Twig version of functions. Just like you would write a function in PHP to do something and return something, you can use a Twig macro to generate some output.

Rendering menu with default macro

If we were to use the macro provided by Drupal as is our menu would render at its simplest form with minimum markup and almost no semantic css classes. See example:

The markup above may look different depending on your base menu. The classy base menu may show more markup but it does not make our job easier to style the menu.

Update Drupal’s menu macro to match our component’s markup

Not having the right markup for the menu, or any other element for that matter, can really complicate things for us when it’s time to style. We are going to modify the macro so it matches the markup of the main-menu component, and as a result the styles we wrote for the component will apply to the Drupal menu.

Menu Macro explained

Let’s step through this macro line by line to understand what it does. To keep things simple we are going to ignore all the custom classes we added above and focus on the macro itself.

  • Twig macros can be called from other twig templates; and it's also possible to place the macro within the same twig template from which you call it. The context is used in this case (line 21). So, with this import statement, we imported the macro and set it as a variable called menus.
  • Using the menus variable we then assign a name to it (main_menu), (line 23), which will take the following parameters: items, attributes, and 0). This name can be anything you wish.
  • Now we declare the macro again but this time with its new name, main_menu,( line 25), and pass the slightly modified parameters items, attributes, menu_level. We've changed the menu_level to a variable. If you are wondering where these parameters come from, you can see them at the top of the file.
  • Now that we’ve updated the arguments, we self import the macro again to make use of it (line 26).
  • Before writing any markup, we first check whether there are menu items to render (line 27).
    • If there are items in our main menu we start writing the markup. However, since we may have a multi-level menu, we want to make sure we identify the top level menu from nested (submenus), menus in the tree.  
    • This is where we first check if the menu_level is 0 (zero).
    • If it is the top level menu, we print a <ul> and we pass Drupal’s attributes in addition to our custom class.
    • If menu is not top level (submenus), then we simply print a <ul> with its corresponding class.

Learn more about Macros in Twig Templates.

Looping through the menu tree

Looping through the items array allows us to intersect each item and apply classes or attributes.

  • First we loop through the items array (line 33), and for each item, we print a <li> some classes which can be helpful if we need to style the different states of the menu.
  • For each link in a list item, we pass two things:
    • The node title
    • The node url
  • Inside the list item, we check to see if that particular item has other items or submenus.
  • When submenus exist, we make use of the macro again to repeat the process of printing the menu. This is where the macro saves us from writing duplicate code.
  • For each level of submenus we are increasing the menu_level by 1 and printing it as part of the submenu class. This is handy if we want to target a specific submenu in the tree.
  • Finally, we close all previously open actions/tags (i.e. for loops, if statements, lists, and macro).

RESOURCE: I recently ran into a blog post by Tamas Hajas where he has a great way to address classes and states on a menu. Check it out Drupal 8 Twig: add custom CSS classes to menus

Looking at the rendered menu after Macro improvements

Now that we have a better understanding on how the macro works, and after making the improvements discussed above, the markup for the menu would look something like this:

Integrate the Main Menu component with Drupal’s Menu

The last part of the process is to integrate all the work we’ve done with Drupal, so our Main Menu is rendered with the markup, styles and behavior we implemented when we built the component.  

  1. >In your editor, open [site_root]/themes/custom/<your-theme>/templates/navigation/main-menu.html.twig
  2. Delete all the content in the twig template except for the comments, and then paste the code below into it
{{ attach_library('your_theme/main-menu') }}
{% import '@patterns/main-menu/_main-menu-macro.twig' as menus %}
{{ menus.main_menu(items, attributes, 0) }}
  1. Clear Drupal’s cache
  2. Reload Drupal’s page

Since we moved the macro to the component’s location, all we need to do in the main-menu.html.twig template is to import the macro and provide the parameters the macro expects. These parameters can be found in the twig template’s comments.

If we did our job right, Drupal’s menu should now look and behave the same way as our component. In addition, if you inspect the Drupal page, the menu should reflect the same markup as the main-menu component.

IMPORTANT: If you are using the Main Navigation block to position the navigation where you want it in the page, you may need to make a copy of the twig template for that block in order to assign the main-menu class the menu needs.  

Drupal Libraries

As a best practice, we should create a drupal library to attach any styles and javascript to our component. See this article for adding CSS and JS to a page or component.

In our case our library would look like this:

main-menu:
  css:
    component:
      dist/css/main-menu.css: {}

This library has already been attached above inside menu--main.html.twig

By doing this any styles we wrote for the component will apply to the main navigation when it’s rendered in Drupal. Drupal libraries have no effect in Pattern Lab.

After completing the steps above, clear your Drupal’s cache and reload your Drupal site. You should see your Drupal menu being rendered with all the styles and markup we wrote throughout this post,

What about accessibility?

You should always ensure your menus and navigations are accessible. It is the right thing to do. However don't yell at me for not following my own advise. In an effort to keeping this tutorial simple, I opted to omit anything related to accessibility. Perhaps part two can focus on that ;-)

In closing

I’d like to admit that I went about the long way to get the main menu working on both, Pattern Lab and Drupal. There are other ways to accomplish this by using contrib modules such as Simplify Menu (full disclosure, I helped create the module), and perhaps Twig Tweak among several others, however, the approach I took here gives you the most control and that can make all the difference if you are dealing with a pretty advanced or complicated menu.

Jun 03 2019
Jun 03

In the battle for insurance customer loyalty, the best customer experience wins. Equipped with a powerful content management system (CMS) like Drupal, insurance web teams are prepared for a competitive landscape crowded with fast-on-their-feet insurtech startups and looming giants of tech, Amazon and Google

The Drupal 7 Versus 8 Debate: A Team Approach 

Drupal 9 is coming. With the release just under a year away, the time is now for insurers’ teams to resolve their internal CMS debate — remain on Drupal 7 or upgrade to Drupal 8?

Bridging the customer experience gap is no small feat. However, insurance business leaders, marketers and developers are tackling the challenge head on. They comprise the team of experience builders with seats at the table for decisions like a CMS upgrade. To forward growth, their technology decisions are prioritized by data security and cost control. Also topping the list of evaluation criteria is a capacity for continuous improvement and swift speed to market of applications and functionality. Business leaders, marketers and developers bring unique approaches to achieve these common goals. In this article, we’ll evaluate Drupal 7 and Drupal 8 through the lens of these three stakeholders.

Current Drupal 7 sites have captured a glimpse of why Drupal is a fit for insurance, but the real power lies within Drupal 8. Of course, the decision to upgrade requires thoughtful consideration and planning. It’s a significant undertaking, particularly for large sites. However, factoring in the robust features of Drupal 8 with the appealing innovation forecast for Drupal 9—and the simple upgrade path connecting the two—insurers are likely to find that the advantages of upgrading far exceed the disadvantages. 

Drupal 7 Versus Drupal 8 for Business Leaders

Business leaders’ roles and responsibilities revolve around improving operating efficiency and cutting expenses. A flexible technology stack is crucial to stay competitive, perhaps even opening doors to collaborate with emerging insurtech startups. 

Focusing on the bottom line, insurance business leaders are understandably concerned with forecasting migration costs. 

Gaining a Competitive Edge 

With Drupal 8, insurers can gain a foothold to gain, and keep, a competitive edge in the market. 

  • Drupal 8 core offers many advantages, including improved performance and a better editorial and developer experience, to close the innovation loop.
  • To support the leap from Drupal 7, Drupal 8 now includes a built-in user interface to streamline migrations and offers more support for multilingual migrations.
  • More accessible web forms and other accessibility improvements in Drupal 8 serve to support legal compliance efforts and extend insurance offerings to the widest possible audience.

Benefits of Drupal 8 

business benefits of Drupal 8

Source: Mediacurrent

The many advancements in Drupal 8 core are reason enough to consider an upgrade, but contributed modules represent the best innovation in the Drupal ecosystem. The brilliant and globally spread Drupal community has shone a spotlight on Drupal 8. Drupal 7 simply hasn’t received the same level of enhancements and attention. Furthermore, passing on Drupal 8 now can also mean missing competitive advantages during the waiting time before Drupal 9. 

Looking ahead, moving to Drupal 8 now will make for an easier transition to Drupal 9. In the words of Frank Sinatra, “The best is yet to come...and won’t it be fine” (or should we say, nine?).   

Estimating Effort and Cost

Insurance business leaders are naturally concerned with total cost of ownership for their Drupal CMS. The migration roadmap is an important factor in that equation. 

Can you take your time to upgrade for Drupal 9? The answer is, technically, yes — but consider both migration and opportunity costs.  After clearing the jump from Drupal 7 to Drupal 8, expect future upgrades to Drupal 9 and onward will be significantly easier. 

Drupal 8 marked the beginning of a new continuous innovation model where advances in functionality are released rapidly on a six-month release cycle. Also, the Drupal 8 architecture is tuned so that a simplified upgrade path awaits to Drupal 9. This approach allows you to benefit from the innovation of Drupal 8 as Drupal 9 brews in the same codebase. 

Mediacurrent’s Drupal 9 Upgrade Guide can help prep your site for the move to Drupal 9. 

Drupal 7 Versus Drupal 8 for Marketers

Insurance marketers of all types, e.g., home, auto and life, view the customer experience as synonymous with digital experience. They have watched customer loyalty dwindle as the market has shifted online, where it’s never been easier to switch providers and shop online for quotes.

Earning Loyalty, Improving Customer Experience

Drupal 8’s appeal to marketers has grown significantly with major releases emphasizing ease of use and customer experience. Insurance organizations like MagMutual have embarked on the transition from Drupal 7 to Drupal 8 to better serve marketing teams:

Our Drupal platform allows our team to adapt to that very quickly to change marketing strategies as we continue to grow and evolve with our customer base.

Sallie Graves, CIO, MagMutual

Catch up on our CIO Interview with MagMutual to see how the organization is bringing new engagement strategies to life on an adaptable platform.

The key to forging deep customer loyalty lies in improving the customer experience from start to finish. In evaluating a CMS platform, marketers need a solution to tighten the reins on data so that it can be applied to the customer experience. 

For Guardian Insurance, Drupal 8 was a savvy place to land. Read Guardian’s Drupal 8 case study to see how they built a data-informed customer experience to win millennial insurance shoppers. 

Our Drupal 8 platform will serve as a foundation as we scale and enhance our web and mobile experiences for customers.

Peggy Maher, SVP, direct to consumer at Guardian Life Insurance 

Drupal 8 and Modern MarTech Stack 

Insurance marketers on Drupal 7 have most likely been with the same platform for a few years. If that rings true for you, consider the strategic doors that an upgrade can open. Think big about your website as a business tool. 

Consider questions like:

  • Does your conversion rate, bounce rate, site traffic and page load time indicate it’s time for a redesign?
  • Do you have a solution for customer journey mapping? Can you see what works, what doesn’t and, most importantly, why to engage prospective and current customers?
  • What usability improvements can help shape the customer experience?
  • Are there any areas of your digital presence lacking in personalization?

Drupal 8 is built for easy integration with your current and future marketing toolkit. Connect marketing automation, email service providers, CRM and more with Drupal 8 as the foundation for your digital experience ecosystem.

Drupal 7 Versus Drupal 8 for Developers

Security 

Developers in the insurance space are tasked with managing the security implications for mountains of personal data and sensitive information. 

We mentioned previously that the developer community has been laser focused on innovation in Drupal 8 —this also applies to security. Major security flaws are first found—and first fixed—in Drupal 8. If that’s not reason enough to contemplate a move to Drupal 8, consider also the security implications of Drupal 7’s impending end of life where core maintainers check out of security duty.  Beware— your site’s data could become vulnerable to hacking and other exploits. 

A study from 2018 found 63% of hacked sites running Drupal had outdated versions when breached.  

Ahead of the Curve 

The Internet of Things (IoT), which includes smart home devices and new telematics solutions, gives insurers a new opportunity to learn from customers to serve them better. Beyond just a website, insurers need to meet customers on their screen of choice. Whether it’s mobile, wearables or smart home devices, screen time is all the time. Drupal 8 core is built with the elasticity to accommodate customers’ devices of today and tomorrow. 

For more considerations from a site builder’s perspective, read 10 Reasons Why You Should Start Your New Project in Drupal 8 on the Acquia Developers blog. 

Conclusion

For insurance providers, digital transformation is where customer experience meets Drupal 8 technology. With a highly proactive community behind the screens, the Drupal project is paving the runway for next-generation customer experiences. 

Drupal 7 to Drupal 8 converts like the State of Georgia and Pegasystems are but two examples of large, complex sites that saw significant gains from their migration. Acquia and Mediacurrent have proudly supported these organizations on their Drupal journey. Watch their migration stories here

Master Your Drupal 8 Upgrade With a Trusted Partner

The final crucial consideration on the road to adopting Drupal 8 is choosing a migration partner. As a leader in Drupal development, strategy and design, Mediacurrent has partnered with high-profile clients ranging from large enterprise businesses to education. Together with Acquia, our talent, tools and processes ensure a smooth and successful migration. Partnering with us will help you establish the personalized digital experiences that capture customer loyalty — leveraging flexible open source technology and with the lock-tight security the industry requires.

May 31 2019
May 31

For all its benefits, working remote— as most of our Mediacurrent team does— still has its challenges. 

The one that people ask me about the most is, "how do you keep any kind of work / life balance when your work and home are inseparable?" For me, the answer to this has been what I call my "shutdown ritual." It's basically just how I try to end my workday every day, but I've found putting some thought into a routine has helped a lot to make my evenings more relaxing and my mornings more productive.

In this post, I'm going to cover:

  • what a shutdown ritual is
  • the benefits  of having a shutdown ritual
  • my specific shutdown ritual

What is a shutdown ritual?

So first, what is a shutdown ritual?

A shutdown ritual is a set routine of actions that you perform at the end of each work day to finalize your day and signify that your work day is done.

I got this concept from an excellent book called Deep Work: Rules for Focused Success in a Distracted World, by Cal Newport. 

His core argument in the book is that the most valuable skill in our economy is deep focused work and that is becoming increasingly rare. If you want to set yourself apart, cultivating a deep work ethic is the way to go. He outlines several rules and guidelines you can follow to start cultivating this habit.

One of the tools he recommends is the shutdown ritual.

The bare outline of the shutdown routine that he outlines in Deep Work is:

  1. update all todo lists
  2. read over the todo lists in their entirety (reprioritizing items as necessary)
  3. review the calendar for the next two weeks, make sure any todos required for events are on the todo list
  4. write down a plan for the next day
  5. close everything on your computer
  6. say a magic phrase, like "Shutdown complete" or "I'm outta here"

Newport also discusses the shutdown ritual briefly on his blog: Drastically Reduce Stress with a Work Shutdown Ritual.

Why do a shutdown ritual?

One of Newport's biggest criticisms of modern workers is that we're always on, and because of this, our attention and energy is too dispersed. We can get notifications or just compulsively check Slack or email, even outside of work hours. But deep work requires disciplined attention and energy. If you want to do deep work during the day, you need to make sure you are not constantly doing shallow work (even off the clock). 

Benefit 1: A defined ending

One of the main benefits of the shutdown ritual is having a well-defined end of the workday. Once the shutdown ritual is done, work is done. Don't think about it. Don't worry about it. Don't check email. Don't look at Slack. If you want to be your most productive self, you need to take a complete break until the next work day.

Now it's time to do all the relaxing evening things like feeding your kids and washing the dishes.

When I tell people I work from home, a majority of them say something like, "You must feel like you're working all the time" or "How do you separate your work life from home life?" and I have certainly found it to be a bigger challenge to turn off at the end of the day since I don't really leave "the office." The shutdown ritual helps define the end of the workday and the beginning of being fully present at home.

It has helped me be more productive during the day and helped me have more focused attention with the family after work.

Benefit 2: Confidence in the ending

The important part about the steps in the shutdown routine is giving you confidence that everything you needed to do is done. 

If you're like me, you might be washing the dishes and still be debugging code in your head. Or you might suddenly remember an important email you were supposed to respond to and didn't. Or you might start thinking about a meeting on your schedule tomorrow that you're anxious about.

But the steps of your shutdown ritual should help you capture all these thoughts before you end your workday. You want to capture them and write them down somewhere, so they aren't floating around in your brain all night. 

Sometimes, you might be in the middle of your shutdown ritual and remember something that can't wait until tomorrow. That's fine, go ahead and do it and then start your shutdown ritual over.

Because once your shutdown ritual is over, and a work worry comes into your head, you want to be confident to say to yourself: 

I went through the shutdown ritual. I know that everything important has already been accounted for. Therefore, there is no need to worry.

And move on with your night.

Benefit 3: Having an anchor for other habits

The last benefit I'll mention is that having a shutdown ritual at the end of the day can be a helpful anchor for other habits.

If you have a well-established habit like a shutdown routine, you can leverage it to help establish other habits. James Clear calls this Habit stacking. The idea is that by pairing a new habit with one that already exists, you make it more likely to stick to a new habit.

Some examples of habit stacking with the shutdown ritual:

  • after my shutdown ritual, I will take 5 deep breaths and smile
  • after my shutdown ritual, I will put on my workout clothes and go to the gym
  • after my shutdown ritual, I will call a friend

A shutdown ritual can help you end your workday productively and launch a new habit or hobby to make the rest of your life even better as well!

My Shutdown Ritual

Here's what my shutdown ritual looks like. At 5:15pm everyday, I get a friendly message from slackbot to start my shutdown ritual. 

You can set a reminder in Slack like this:

/remind me to 

Time to start your shutdown ritual!

- reconcile timesheet
- check email for anything requiring urgent response
- add new / outstanding tasks to todo list
- check JIRA
- skim task lists
- check calendar for tomorrow
- make a rough plan for the next day

Shut down complete

every weekday at 5:15pm

For me, this is actually about 45 minutes before the end of my workday. I used to have the reminder for 15 minutes before I signed off, but I could never get to a stopping point and do the shutdown in 15 minutes. 45 minutes gives me enough time to start looking for an exit in my current work and to go through the routine.

Here is what is on my shutdown ritual list:

  • reconcile timesheet
  • check email for anything requiring urgent response
  • check JIRA
  • add new / outstanding tasks to todo list
  • skim task lists
  • check calendar for tomorrow
  • make a rough plan for the next day

Reconcile Timesheets

I take a look at my time tracking software and make sure all my time is accounted for.

Check Email

I go through my email inbox, responding to anything that is really urgent, and adding tasks to Todoist for anything that is not. My goal is to delete as many as possible.

Check JIRA

I open up JIRA to see what tasks are assigned to me, and add them to Todoist, if they aren't already there. I sometimes remember things I said I was going to do but didn't (like update a ticket or assign to someone else) so if I can quickly do that I will.

Skim Todo lists

This gives me a broad view of what's going on. Sometimes I notice a glaring error or remember something that completely slipped my mind, so I add that here. I also sometimes reorder things based on how priorities changed throughout the day.

Check Calendar

Next, I check my calendar for tomorrow. Do I have any meetings tomorrow that I have a deliverable for? Did I complete the deliverable? Any conflicts?

Make a rough plan for the next day

The last item on my list is making a rough plan for the next day. This really sets me up for success in the morning, and helps prevent a slow, groggy start to the work day. Sometimes I make my plan in Todoist just by setting due dates for todos for tomorrow and putting them in the order I want. Other times I have a simple text file where I make a list. It kind of depends on what projects I'm on and the kind of work I'm doing from week to week.

Shut down

I close all applications on my computer. I put the computer to sleep or shut it down. Sometimes I say "shutdown complete"

Sometimes here I tidy up my desk.

I start singing "It's a wonderful day in the neighborhood" and change into my house sweater and house shoes.

The work day is done. I'll be back tomorrow. 

And that's how I end my days productively with the shutdown ritual.

May 31 2019
May 31

Mediacurrent's Rain Install Profile logo

Mediacurrent created the Rain Install Profile to build fast, consistent Drupal websites and improve the editorial experience. Rain expedites website creation, configuration, and deployment.

The Mediacurrent development team is pleased to announce some new updates to the Rain distribution in version 3.0. We have now made Drupal project template easier to use and maintain by splitting Rain content features (all of which are optional) from the main “base” package. This allows developers flexibility in which features they use while still pre-configuring modules that jump-start development.

There are some key changes that we will highlight here:

  1. The Rain package has now been split and renamed to mediacurrent/rain and mediacurrent/rain_features respectively. The latter repository now contains all the optional content features and their dependencies while the base package pre-configures the base installation.
  2. An UPDATE doc has been added to the Rain repository which explains in detail how to update from the 2x branch to 3x. This document will be kept up to date with any future changes that require manual changes or explanation.
  3. A few new dependencies have been added while several less frequently used dependencies have been removed. The UPDATE doc gives further details on what was added or removed and how to upgrade.

Note that the Drupal-project template is only used for provisioning new projects. Any project that currently uses the 2x version of the Rain distribution will not break or be forced to update. Updates to 2x will continue through to Drupal core 8.8 but then be sunset in favor of the 3x branch. Overall the process of updating from 2x to 3x should be relatively painless. 

If you experience any problems updating please file an issue in the official Rain project queue on Drupal.org: https://www.drupal.org/project/rain.

Installing Rain 3.0

To install the Rain distribution, we recommend you leverage our Drupal project template which includes a VM and Guardr security along with the Rain install profile and other tools.

Our recent article entitled “Drupal 8 Rain & GatsbyJS Integration” covered how to install Rain using the project template so we will recap the first step here which remains the same in version 3.0. 

First you will want to create a repository wherever you typically host your Git projects (i.e. Github, Bitbucket or Gitlab). Once you have that setup you can clone Mediacurrent’s repo and point the origin back to your Git repo.

Example:

git remote set-url origin [email protected]:mediacurrent/shortcode_project.git

Next, you will want to initialize the project. You can do that by running the following commands with your local host name and IP.

Example:

composer install

composer drupal-scaffold

./scripts/hobson project:init example.mcdev 192.168.50.4

Finally, to build the project and run the install you can simply run “./scripts/build.sh” which runs composer install as well as the Drupal install. Note that the project README has more detailed instructions but this will give you an idea how to get up and running quickly.

Video Tutorial for Installing Rain

[embedded content]

Related Resources

[Webinar Recording] Rain + GatsbyJS: Fast-Tracking to Drupal 8

May 29 2019
May 29

Gaining approval to launch a new website is a big investment — and it’s expected to achieve a big reward. Your internal team (and customers) expect it to match up to their favorite website. That could be Amazon, Apple, or any number of well-known brands relying strongly on their website.

Needless to say, the expectations for a new website are very high, regardless of your budget. Compounding the challenge is the fact that a site build remains a complex process due to technology, expectations, diverse perspectives, and competing goals within the organization.

The challenge for the business is that a new website build is not standard operating procedure. It is not something that is done regularly. It is often resisted by the internal users because as much as people want the latest and greatest site, they may also fear change. So the risk-reward can be very high for the person in charge of the project, but selecting the right digital agency and leveraging your agency-partner relationship can tip the scales in your favor. Your agency-partner, let’s say partner, can help you, because it is standard for them.

Perspective from both sides of the aisle 

My career experiences have given me a broad perspective and good understanding of the internal challenges one faces to get buy-in for a major website re-build project.

Today, as a Mediacurrent Project Manager, I primarily work with existing clients for both site builds and post launch support, and I also work on pre-sale projects.

I was previously hired by a top 20 medical device manufacturer into a new position responsible for Online Marketing Strategy and Analytics, reporting up to a reasonably new head of the department of Marketing Services. Up to that point, online marketing and the website was not a focus for the marketing team. We made the case for a new website, got management and budget approval, chose Drupal, and I managed the entire process — including vendor selection.

The RFP Process

  • If you have an existing agency partner, they can help you. It would essentially be consulting time, but often the partner sees a lot of RFPs and can identify areas that you may have missed.

  • Have a diverse group of people involved in the process. This can make the process slower, but can help significantly in the end if you have early buy-in from all the right parties.

  • Accept what you think is fair based on the request vs. resources and experience being made available to you. You may not always have the names of all the individuals assigned to your project, but the partner will ensure the resources meet the need.

Development

  • If the partner doesn’t offer, ask for regular demos of functionality throughout the development phase. This will help you see the work being done and you can make adjustments as needed. Be careful with adjustments though. You want them to be clarifications and not changes to the original scope of work.
  • Don’t go short on Quality Assurance (QA) time. Partner QA teams do nothing but QA and are well versed at finding things you may not think to look for. Allow the partner to QA each ticket you review. If you by-pass QA or do it yourself, you run a high risk that there will be issues and ultimately misses.
  • Keep your stakeholders abreast of the work being done, so they see progress. Invite them to the demos and reconfirm their approval.

Training Internal Users

  • During development, begin planning for training your internal users. Without their buy-in, you will fail. Keep them informed of the progress and if possible create a campaign that raises awareness and keeps the project top of mind.
  • Be sure to build your site with help text for each field. When demos take place, have them recorded so you have videos of both front and back end for the users to understand how what they insert is rendered.
  • Your partner can help plan training sessions to get everyone acclimated to the new system.

Post-Launch

  • Websites are evolutionary; new features and functions arise as users get acclimated to them. Most likely there will be items that didn’t make the initial launch in order to keep within time or budget, but having a support agreement will allow you to continue to improve your site. If necessary, have your partner convey the fact that these new features and functionalities are possible, but can be done post-launch to keep the project on time.
  • Reporting is critical. While this has to be established during the development phase, you need to develop a series of reports. There should be a report for the product team with specific areas for them to focus on and the senior management team, which wants to know if their investment is paying off. Your partner can help develop these as they have done them for other clients in the past, as opposed to taking time to do it yourself.
  • Your hosting and development companies need to work in unison, and sometimes this can be more than two companies. Keep them connected to ensure the entire platform is optimized.

While these are high-level considerations, I believe they are all critical to success. When you have the opportunity to build a new site or revise an existing one, following these guidelines will put you in a position to be successful and to leverage that success to a promotion.

May 17 2019
May 17

At DrupalCon Seattle this year, Mediacurrent was excited to unveil our latest distribution and Gatsby integration. Rain is a group of prepackaged, pre-configured components vetted by our development team and sourced from the open source community.

Our goal it to help web teams create, configure, and deploy websites faster. This tutorial will show you exactly how to get up and running end-to-end. You can also follow along with our tutorial videos

Step-by-step guide to get started with Rain, Gatsby, and Netlify 

  • Installing the Rain distribution
  • Enable JSON:API
  • Hosting integration
  • Setup Gatsby
  • Configure Netlify
  • Connect Drupal 8 to Netlify

Step 1 - Installing the Rain distribution

[embedded content]

There are many ways to spin up a new Drupal 8 instance. In this tutorial we will use Mediacurrent’s open source Drupal project template which is available for download on Bitbucket. This repository includes everything you will need to get up and running including VM, Guardr security integration, the Rain install profile and more.

First you will want to create a repository wherever you typically host your Git projects (i.e. Github, Bitbucket or Gitlab). Once you have that setup you can clone Mediacurrent’s repo and point the origin back to your Git repo.

Example:

git remote set-url origin [email protected]:mediacurrent/shortcode_project.git

Next you will want to initialize the project. You can do that by running the following commands with your local host name and IP.

Example:

composer install
composer drupal-scaffold
./scripts/hobson project:init example.mcdev 192.168.50.4

Finally, to build the project and run the install you can simply run “./scripts/build.sh” which runs composer install as well as the Drupal install. Note that the project README has more detailed instructions but this will give you an idea how to get up and running quickly.

Once you have completed your install you will want to push updates to your git origin.

Step 2 - Enable JSON:API

[embedded content]

In order to make our Drupal 8 site provide data to the Gatsby frontend we will enable the JSON:API module added to core in version 8.7.  The Drupal 8 source plugin for Gatsby requires JSON:API to ingest content from Drupal but eventually a GraphQL module-based source plugin will replace the need for JSON:API.

Mediacurrent has a Packagist feature module that makes this process a little bit easier because it will also add some test content we need to get Gatsby running out of the box. Otherwise, you would have to manually create any paragraph being used in our Gatsby starter.

To add the Rain Gatsby feature simply run the following command:

composer require mediacurrent/rain_gatsby

After the Rain Gatsby feature is downloaded you will enable the feature which in turn enables JSON:API and creates 1 test page with paragraphs. When you have completed this step, be sure to export your configuration and push any file updates to origin.

Step 3 - Hosting integration

[embedded content]

Most Drupal web hosts (e.g Acquia, Pantheon, etc.) have their own git repository they use for deploying artifacts to the server. This includes all  the actual Drupal files that make up core, contributed modules and libraries. We don’t want our source git repository to store artifacts or conform to the folder layout required by the web host. Instead, we execute deploy commands to build the artifacts from Composer and commit them to the appropriate destination git repository. To make that process easier we have some additional configuration to add to our config.yml file that instructs how and where code should be deployed.

The key aspects to both the Acquia and Pantheon configuration is pointing the release repo to the appropriate git URL provided by your host, the name of the host and the release drupal root directory. Our examples use Acquia and Pantheon but also support generic git artifact repositories like AWS.

Acquia config:

project_repo: [email protected]
release_repo: [email protected]:mcABCProject.git
release_drupal_root: docroot
deploy_host: Acquia

Pantheon config:

project_repo: [email protected]
release_repo: ssh://codeserver.dev.YOUR_UUID_VALUES.drush.in:2222/~/repository.git
release_drupal_root: web
deploy_host: Pantheon

Additionally for Pantheon you will need to add a pantheon.yml file to the root directory with the following values:

api_version: 1
web_docroot: true
php_version: 7.1 (or latest PHP version supported)

This command also needs to be run in order to clean up the Pantheon git repo prior to our first deployment:

rm -r README.txt autoload.php core example.gitignore index.php modules profiles robots.txt sites themes update.php vendor web.config

Now we are ready to build and deploy for the first time. We do this with two commands, one to build the artifacts and one to push files to the release git repository.

Example (using Pantheon):

./scripts/hobson release:build Pantheon develop
./scripts/hobson release:deploy Pantheon develop -y

After you have deployed code to Acquia or Pantheon you should be able to run a clean install using either the sample Rain child install profile (mis_profile) or cloned profile you have created (see Rain README for more details).

Step 4 - Setup Gatsby

[embedded content]

To connect your Drupal instance to Gatsby, at a minimum you just need the Gatsby source plugin pointed to Drupal’s JSON:API endpoint. For those new to Gatsby, it can be a lot of work to map your components to Drupal content using GraphQL.

In order to make this whole process quicker and easier, Mediacurrent created a Gatsby starter (available at https://bitbucket.org/mediacurrent/mis_gatsby_rain/src/develop/) that does a lot of the initial component development for you. Our Gatsby starter includes React components with GraphQL that maps to the Paragraphs data incoming from the Rain install profile. Any time you change a Paragraph you will need to adjust your components and GraphQL but it’s much easier than building everything from scratch. The components also include basic markup, styles and in some cases Javascript to give developers something working right out of the box.

Spinning up the Gatsby + Rain starter is very simple, and uses the same syntax as other Gatsby starters. See the example below:

gatsby new my-rain-starter https://bitbucket.org/mediacurrent/mis_gatsby_rain

In the next step, we will point Gatsby to the appropriate JSON:API feed coming from our Drupal environment. Since this value will change per environment we have already created a variable named “BASE_URL” in our gatsby-config.js file. To set this value, you simply add BASE_URL to a .env variable in your docroot. Important: remember to include the trailing slash and you do not need to add “/jsonapi” to the path. See below:

BASE_URL=http://myproject.mcdev/

To test simply run the following commands (note that this assumes you have NVM installed):

nvm use
nvm install
npm install
npm run develop

If you are able to run without error you are in good shape! Remember to commit any updates made but you will want your local “.env” file ignored.

Step 5 - Configure Netlify

[embedded content]

Now that we have Rain and Gatsby connected locally we will want to prepare our static host. There are many options available, but we like Netlify because it’s free and easy to set up.

Once you sign up for a free account you will have an option to create a new site. You should see a similar screen as below.

config netlify

Mediacurrent uses Bitbucket for our git repositories but you can connect to any of the popular Git hosts from this screen. You will want to make sure to select the git repo you set up earlier that contains all of your Gatsby files. When you get to the last step you need to add two additional configuration settings.

additional config settings

For build command you will add “npm run build” and in the next box you will add “public” as your publish directory. This tells Netlify how to build Gatsby and where your public docroot lives.

Finally, we need to set up our “BASE_URL” variable in Netlify to point to our public Drupal instance. To do this we will add a netlify.toml file to our Gatsby repo with our host name.

Example netlify.toml:

[context.production.environment]

  BASE_URL = "http://pathtodrupalsite.com/"

We need to tell Netlify to look for BASE_URL in this value so we will configure that in the “Environment” area on the project settings page. See below:

Netlify environment

To give it a whirl, go to “Deploys” and manually trigger a deployment. You will see in the console log whether it was able to read in JSON from your Drupal 8 site. Note: a good option to add some additional security is to add an htaccess password to your Drupal site and make sure that you are accessing that JSON endpoint over https.

Step 6. Connect Drupal 8 to Netlify

[embedded content]

By this point we have everything spun up connected but Netlify only builds when we manually trigger a build. In this step, we will point Drupal 8 directly to Netlify so that we can programmatically tell Netlify when to build. This is accomplished with the “Build Hooks” module.

The Build Hooks module is very flexible and can point to any environment which has a URL that triggers a Gatsby build. For Netlify we will be using the build_hooks_netlify submodule that provides direct access to Netlify using their API.

To enable API access we need to create a personal access token from your account. This is found under User Settings, Applications underneath the “Personal access tokens” area of the page. After clicking the “New access token” button you will see the following screen:

create new personal access token

All you need to do is name your token and you will be presented with the token value that the Build Hooks module needs to connect to Netlify.

Next we need to create a build hook trigger that is set up underneath the “Build & deploy” settings for your application. This is the URL that we are going to ping from Drupal in order to tell Netlify when to rebuild.

build hook trigger

Now let’s hop on over to our Drupal site and get things set up there. After adding and enabling the build hooks module (“composer require drupal/build_hooks”) and Netlify submodule you will be ready to configure the Netlify settings. This is where you will plug in the personal access token just created (see below):

build hook netlify setting

Once we do that we still need to set up the Build hooks environment. We will add a Frontend environment using the “Netlfy” environment type in the Build Hooks configuration.

From there we need to supply a few settings including the frontend URL, Build hook URL, API id and Git branch. The API ID value is found on the main “Site details” page for your Netlify app (see screenshot below).

site details

The interesting thing about the Build hooks module is that we have options for how we want to trigger Netlify’s build. We can manually trigger a build from Drupal 8 clicking a button, or we can auto-trigger builds every time content is saved or after cron runs. For our purposes we can select “When content is updated” but the beauty here is that you could set up a test environment that auto-builds while only updating production when manually triggered. That is the power of Gatsby + Drupal!

One additional step is we can prevent the auto-save setting locally by adding one line of configuration to our local settings.php. This effectively overrides that auto-save trigger. For that you will want to add the following line:

$config['build_hooks.settings']['logging']['entity_types']['node'] = 0;

Wrap-up - Final Testing

The last thing we need to test is to make sure that saving a piece of content in our Drupal host will trigger a new build in Netlify. To do that we click on any sample node on our test site with a small change such as an updated title. The first thing you should see is a message indicating that a change has been pushed to your Frontend environment. If that works we will want to check our Netlify “Deploys” tab to see if the build has been triggered successfully. If you run into any issues, you will want to double check your configuration and Drupal logs for errors.

Still having trouble? For Rain specific issues, please create a ticket in our project issue queue on Drupal.org. For Gatsby related questions or problems, we have an issue set up on our Gatsby + Rain starter repository

Apr 24 2019
Apr 24

alt=""

We’re using Drupal 7, should we migrate to Drupal 9? What are the advantages of moving to Drupal 8 now versus waiting until 9? How do we prepare for Drupal 9?

We work through these questions with our client partners and the community on a regular basis. If your organization is using Drupal 7 or Drupal 8 today, then below is useful information that will help with your migration plans to Drupal 8 and 9. 

TL;DR -- Drupal 9 is being built in Drupal 8 and is backwards compatible. If you’re on Drupal 7, don’t wait until Drupal 9 to begin your upgrade. There is no value waiting on Drupal 9 and there are plenty of advantages your organization will benefit from with a migration to Drupal 8 including; increased security, simplified upgrade path to Drupal 9, improved performance, and a better editorial, developer, and customer experience. In short, you’ll miss competitive advantages for the next 2 years if you wait for Drupal 9. If you’re already using Drupal 8, you’re well on your way to the benefits of Drupal 9. Keep Drupal 8 up to date to mitigate security risks. 

Drupal 7 End of Life

As of April 7, 2019, there were over 290K websites using Drupal 8. With our migration of Manhattan Associates, Olympus, Pegasystems, and Guardian Insurance websites (to name a few) to Drupal 8, Mediacurrent is an industry leader on understanding, planning, and executing migration projects.

“End of Life” is the date when the Drupal community officially stops supporting Drupal 7. Drupal 7’s end of life has been extended to Q4 2021, giving you time to prepare your organization for change. 

drupal8timeline
Source: Dries Buytaert, How to Prepare for Drupal 9 

How Drupal 7 End of Life Impacts My Website?

When Drupal 7 support ends, there will be no more Drupal core updates to Drupal 7 - even for critical security issues. The contributed modules that power your site will also no longer be actively tested and reviewed, patches and security evaluation will depend on your internal resources or partners.  

alt=""

Average Cost of a Security Breach

One recent study found, “The global average cost of a data breach to a business is $3.86 million, and in the U.S. the average price tag swells to $7.91 million per breach...” 

And a study from 2018 found 63% of hacked sites running Drupal, had outdated versions when hacked.  Ensuring that you manage the security implications of Drupal 7’s End of Life is vital to the health of your organization.

Migrating to Drupal 8 is More Than Security

"Drupal 8.6 is a significant upgrade because of its emphasis on ease of use. This version levels up the customer experience, making it easier and less expensive to migrate from older versions, easier to install, as well as easier for marketing teams to deliver impact, faster. With a highly engaged community focused on delivering features that make customers shine, I’m excited about this release and what is on the horizon for Drupal."

Megan Sanicki, Executive Director of the Drupal Association

Check out this Acquia and Mediacurrent webinar for more info on the benefits of Drupal 8.

benefits of Drupal 8

Learn to Love the Upgrade Path

Upgrading your website is the opportunity to revolutionize the way you think about the web as a business tool. If you have a Drupal 7 site, you’ve most likely been on it for a few years. How many little usability improvements have you considered in that time?

  • Is my design dated? 
  • Do my editors like the experience? 
  • Is my site responsive? 
  • Does my site build reflect modern practices in SEO, accessibility, and user experience?

An upgrade gives your organization the opportunity to reexamine how your implementation of Drupal, strategy, and design while reducing security vulnerabilities, costs, and improving competitive advantages. 

With Drupal 8, you can take advantage of its innovation today as well as it’s built-in upgrade path to Drupal 9, so start planning a migration path internally as well as with your partners.

Should We Wait for Drupal 9?

It’s essential to know a migration to Drupal 8 or 9 or another CMS is inevitable if you’re on Drupal 7 today. Pausing your migration until 9 (release date June 3rd 2020) doesn’t provide long-term value. Your organization will continue to miss out on the features, benefits, and expertise you’ll find with Drupal 8 as well as its simplified upgrade path to Drupal 9.

Drupal 9 is being built in Drupal 8 and is fully backwards compatible. Drupal founder Dries Buytaert wrote, “With the release of Drupal 8, we moved Drupal core to use a continuous innovation model. Rather than having to wait for years to get new features, users now get sizable advances in functionality every six months.”

A Drupal 9, 10, 11...upgrade will not be the same mountain from previous versions of Drupal given Dries agile model for Drupal development and release model. It more closely aligns today with a typical saas release plan. To take advantage of the full potential of Drupal your best option is upgrading to Drupal 8 with the help of an experienced agency partner. When Drupal 9 rolls out, you’ll be able to sit back, relax, and take immediate action on the update.

What Are My Next Steps?

Mitigating risk is simple with an experienced partner. We advise our clients to take the following steps:

  1. Ensure your website will be secure after Community Support ends. You can do this by developing an internal plan to monitor future Drupal 7 security releases, or engaging with a hosting provider like Pantheon, or agency partner, like Mediacurrent, to cover you while you plan and execute the move off of Drupal 7.
  2. It’s likely the time is now for a reassessment of how you use the web. Partnering with an expert partner like Mediacurrent will help you to reassess your website plans, determine if your Digital and Design strategies are effective, and ensure your next platform serves your needs, customer needs, and can adapt in the future. Check out 20 Things to Know Before Choosing a Digital Partner for your Site Migration for help. 
  3. Once you have identified the correct platform, plan and execute your migration. By taking care of security first, and securing the right partner, you can take the time to correctly plan and build your next Digital Platform in Drupal.

Migrating from Drupal 8 to Drupal 9

Drupal 8’s end of life is also November 2021. Updating from Drupal 8 to Drupal 9 is just that -- an update. If you’re on Drupal 8 today, keep Drupal 8 up to date, and be prepared to make the switch by including it as a part of your 12-month plan.

Final Thoughts

If you’re on Drupal 7, then you’re okay for now, but the sooner you plan for the change the more prepared your organization will be to create and show value from your Drupal investment.

However, transitioning to Drupal 8 or Drupal 9 comes down to a number of factors and is not a quick decision. Do the due diligence work of understanding the requirements and needs of your website and your customers, then consider that information with the reality of your budget, capabilities, and timeline. We work through these questions with our clients on a regular basis and the reality is the answer is unique to every organization.

To learn more about our process and how to successfully navigate these waters, feel free to contact us directly.

Mar 19 2019
Mar 19

One of the challenges with an extensible platform like Drupal is the sheer number (tens of thousands) of available modules can be a daunting task to evaluate which ones are the best fit for your application. Every year, I have posted a round-up of the top modules to help steer newcomers to a vetted list of essential contributed modules. This article will go a step further by offering guidelines to help your project team assemble modules that meet your organization’s needs.

Methodology

There are many criteria to consider when evaluating Drupal community projects. Each factor is not weighted the same and very few should be considered in isolation. Before reviewing the list below, it’s important to assess your organization’s risk profile.

For example, an agency with full-time Drupal developers is going to be able to provide upstream support for modules in the form of patching and other improvements. As a result, modules that might have otherwise been disqualified could be supported in a way that mitigates risk. Many smaller organizations, however, might want to steer more towards stable, vetted projects. Doing so will ease the maintenance burden over time.

Example Project Page

Say, for example, you are evaluating MetatagMaintained by Mediacurrent, this module provides a flexible system for customizing the meta tags used on a website.

Metatag page on Drupal.org

Evaluation criteria

1. Module Usage

The project page will show downloads and site usage. Usage can be viewed by version (ie Drupal 6, 7, 8) and is weighted higher than download counts. Low usage of a few hundred sites, or less, would likely disqualify a project.

module usage

2. Issue Queue Activity

The project issue queue will indicate the level of activity and number of bugs including critical issues and issues flagged for security. The volume of bugs is not necessarily a problem in that larger projects will have more issues reported. The severity of bugs should be considered as well as the overall activity. Projects with only a handful of open issues logged should be considered as a higher risk. Projects with frequent issue updates and patches are considered lower risk.

issue queue activity

3. Security

The Drupal community has a dedicated security team to review projects for potential security vulnerabilities. Each module maintainer has to “opt-in” to receive security coverage and must have a stable release available. Projects that have not opted into security coverage do add risk, which needs to be considered. Check out our blog for more ways to assess modules for security

Drupal.org security advisory

4. Manual Review and Testing 

If possible, have developers spot check module code. Look for red flags in terms of code styling, organization and general adherence to Drupal.org best practices. Additionally, even after a module has been preliminarily screened it should be further evaluated when installed and configured. If the module appears buggy, unstable, or does not appear to fit the project needs, it might need to be replaced with an alternative solution.

index: metatag

5. Release Status

The release status is solely managed by the project maintainers’ and does not fully indicate the stability of the module. The release version is a factor in that it indicates the project maintainers’ assessment of stability. There is no governing model for how releases are labeled. Projects could have 1.0 stable releases and have outstanding security bugs or critical issues while development or sandbox modules can sometimes be production ready. It is important to consider other factors before making a final judgment. Modules with dev releases should be further scrutinized and vetted, including a more exhaustive manual code review. Alternatives should be evaluated. It should be noted that a sandbox module in some cases will still be advantageous to a fully custom coded alternative.

Metatag module release status 8.x

6. Commit Activity

Project code updates and the frequency of stable releases are highly weighted. Projects without commits in 6+ months are considered higher risk. Frequent project updates and releases are a good indicator of stability and support.

commits for Metatag

7. Project information

The maintainer will indicate whether a project is actively maintained, minimally maintained, obsolete, or abandoned. Obsolete projects are immediately disqualified.  

project information

8. Risk Assessment

The size and scope of the module’s functionality should be very strongly weighted. A module that has very few lines of code and adds simply functionality, e.g. a block on a page, is considered relatively low risk. A module that manipulates data in any way is higher risk and problems or the remove of the module could result in data corruption or loss. A module that provides critical functionality to a project will be evaluated much more deeply than a module that provides marginal benefit.

9. Benefit

Modules should be evaluated based on their fit for the project. Every module added to a project generates some level of risk in terms of stability, security, maintenance overhead, etc. Therefore, inclusion depends on the demonstration of benefit.

Your Feedback

Have any suggestions or feedback? Talk to me at https://twitter.com/drupalninja or use the comments below. We are always looking to make improvements to our processes.

Mar 15 2019
Mar 15

A lot of effort goes into engaging your visitors to ‘Sign-up’ or ‘Contact’ you. You send them a warm and fuzzy invitation to complete the form, tell them all the great reasons why they should complete the form… but who likes to complete a form?  Guarantee a smooth sign-up process and increase the completion rate of your webforms with these six tips. 

#1 Make it Flow

Before you begin designing that web form, it is always good to create a User Flowchart. Working to establish the form completion process from start to finish, a flowchart will help you: 

  • Determine what information is needed (and when)
  • Decide what actions and interactions are appropriate
  • Determine the order of actions
  • Make considerations for new patterns to aid the completion process

A User Flowchart can begin with a simple Flow Outline, which can then be placed in a flowchart diagram and later illustrated using low fidelity paper prototypes to find the most natural set of actions. When creating the outline consider the following:

The Business Objective

  • What is the main objective of the website for achieving successful completion of the form? (ie, we want to gather as many email addresses as possible.)
  • What is the required information needed from the person completing the form? (ie, we need their name and email, and since our site is only for adults we also need their birth date.)

The User Persona

  • Take advantage of the information gained from the User Personas to focus on the user’s various needs and considerations. What problem do they want to solve and how can this form help them?

  • What devices do they access most frequently to complete webforms? It’s good to know in advance if most of the users complete forms on their mobile phones and/or if they have inferior internet connectivity.

The Entry Point

When designing a User Flowchart, keep in mind the point of entry. Perhaps they arrive after clicking the Call to Action on the homepage. Often webforms are a part of an email or social media campaign, or the user arrives at the form after an organic search. The users should be treated differently based on where they come from, and may need extra context to reiterate the goal of the form to help them get orientated when they arrive. Consider all possibilities.

#2 Keep it Short and Sweet

Don’t ask for information that’s not needed. Your subscription or contact form — or any form that gathers basic information — should only ask for the bare necessities needed in order to accomplish that goal. People will usually stick around long enough to enter their name, email address and password. Anything more than that should be the absolute minimum amount of information needed, with further data obtained in follow-up communications or by implementing a multi-step form (see tip #3). No one enjoys completing a form, so keep it as simple as possible! Neil Patel found that three form fields was the optimal number.  Pegasystems, a Mediacurrent client, leveraged third-party integrations on their Drupal 8 site to pre-fill form fields with data and improved the user experience for returning visitors. 

Reducing the number of form fields can increase conversion rates by 26 percent. 

Email Address

  • Forward thinking email form fields provide suggestions for fixes when the email address has been entered incorrectly. … Did you mean @gmail.com?
  • If you include an auto fix for mistyped email addresses you won’t need to require the user to enter it twice. Otherwise, it’s is a good approach to provide the extra guarantee that they’ve got it right.
  • When the form is for creating an account or signing up for a newsletter, a current practice is to use the email address for the account instead of providing a separate username. This will cause less frustration with creating one that is not already in use, as well as remembering it every time they login.

Name

The person’s name is really only needed in instances where account personalization or custom communication is used. A frequent approach is to provide one field for their full name. This is a bonus since some users may have more than two words that make up their full name, and one field takes less time to complete (especially on mobile devices). Check first to see if the system requires the first name to be isolated for marketing purposes.

Password

  • Enough with the 'confirm password' already! They will lower your conversion rates. Give the user the option to actually SEE the password they’re entering with a ‘show password’ toggle, and they won’t have to enter it twice.
  • Include a Password Strength Indicator. You can get creative with messaging to encourage users to try harder when creating a more secure password like Geeklist does: “Crack Time: 5 minutes”
  • Depending on the level of site security, another time-saving feature is the ability to never have to enter their password again with the ‘Remember Me’ feature.

#3 Multi-step Forms

Single step forms are the most common type of form found on a website. Sometimes, however, using the minimum amount of fields will not accomplish the goal of capturing essential user data. Instead of simply adding more fields to your one-page form you should be aware of an important point: 

Multi-step forms have been found to increase conversions by as much as 300% (without increasing website traffic). 

Multi-step forms convert well for several reasons:

Simplicity

Through the use of progressive disclosure design techniques, we can improve usability when only the minimum data required for a task is presented to the user. Multi-step forms provide the ability to break up a longer form into manageable steps so the user is not visually overwhelmed with requirements at the beginning or during the process. By including only one or two questions per step with a manageable number of steps overall will improve the user experience and significantly increase the chance they will complete it. 

Reduced Psychological Friction

Multi-steps with a simplified interface allow opportunity to use low-friction language in order to reduce psychological friction. In order to encourage the user to become immersed with an energized focus on the activity, we must always seek to minimize disruptions and use language that puts them in a positive state of mind. 

Orientation

Progress bars encourage form completion. The most common use of visual progress trackers are when conducting an online purchase since those are often broken into a multiple step process. It answers the questions the user may have during completion:

  •  How long will the form take?
  • What comes next?
  • Is anything happening?

Displaying the steps required to complete the form along with where the user currently is at in the process will help manage their expectations and keep them oriented throughout.

Investment

By using the approach of requesting general information at the beginning of the form and moving towards more sensitive information requests towards the end of the form, the user feels more invested and is therefore more likely to complete.

Conditional Logic

Longer forms will sometimes benefit by using conditional logic in order to personalize the experience. The user is provided with specific questions based on certain responses therefore eliminating irrelevant information retrieval while simultaneously obtaining more targeted data. Save them valuable time and customize their experience, and they will likely reward you by clicking the submit button.

#4 Make it Easy to Read

Including the labels and inputs, consider the context being used for all text on the page and work to ensure your font sizes are large enough to be legible on all devices. The amount of content on the page should be considered while also using best practices for accessibility. 

  • Recent trends are a 14px font size at minimum.
  • When specifying a 16px font size for mobile devices, iOS will not zoom in when the user taps the field, because it’s not needed. This approach can be less distracting especially when there are multiple form fields on the page.
  • Consider the maximum amount of characters that will be needed in all cases to ensure enough room is provided to complete each field. For example, some zip codes in other countries use a varying number of digits.

#5 Inform Everything

Label All Things

The label of the form field you want the user to complete should ALWAYS remain visible. The labels can be placed outside of the field near the top, right, or left — or even better — use the Infield Top Aligned Label. This popular approach has been found to be the quickest to scan, has the best flow, and takes up less real estate. The labels are placed inside of the field, jumping to the top left corner as the user begins typing. Either way, at no point should the user lose sight of the information that’s needed inside of the field.

Inline Form Validation

  • Inform the user as they progress if anything has been entered incorrectly or if a field is missing information. Don’t make them click the ‘Submit’ button at the end of the form only to receive a bunch of red text telling them what they have to re-do.
  • Micro interactions such as a simple green check or a red ‘X’ along with a brief message as the user completes the form will improve the workflow.
  • Tell them if their CAPS LOCK IS ON.

Required or Optional?

Inform the user which fields are required and which are optional for the form to be accepted. An asterisk is often used to designate required information, but they are ignored by screen readers so make sure the required fields include the HTML5 ‘required’ attribute or the aria-required set to true.

Field Details

Explaining the information needed for each field is another great approach. If your Registration Sign-up Form will require a password with at least 6 unique characters with 2 of them numbers, tell them! Does the phone number field require a +, or a country code, or an area code? Tell them or show them.

Progress Bar

  • A form that’s broken into logical steps is easier to complete. If there are multiple steps that require multiple screens to complete, add a progress bar so the user knows where they are in the process.
  • If possible, add a link to the completed steps in the progress bar so the user can go back if needed.

Safety

  • Make your users feel safe during sign-up by informing them about your terms, policies, or rules.
  • Ensure them you will not share their information or spam their email.
  • Provide an easy way to cancel or opt out at any time, without much effort.

#6 Must be Mobile

While optimizing your site for mobile devices, any forms on your site should also be carefully considered. Not only are the screens smaller, but often the connections are slower, and entering text can be a bit tricky, so reducing the number of required fields is especially important. Luckily, recent innovation for mobile forms have provided modern solutions and compression techniques that could actually encourage sign-up on a mobile device:

Predefined DropDowns

  • Whenever possible, avoid open input fields and provide a dropdown list instead for easier completion.
  • Dropdown selections should be written as they would normally display (ie, Credit Card expiry date: 01/20).

Collapsible Menus

This really helps when multiple offerings are available with details for each.

Predictive Search Fields

As the user begins typing the keyword, a list of possible results is provided. 

Calendar Tools

Choose a calendar that is easy to use, with big targets that help to avoid user input errors

Combine Inputs When Possible

Providing only one field for a ‘Full Name’ instead of one for ‘First Name’ and one for ‘Last Name’ will speed up the form completion process and reduce user frustration. 

Automatic Advance

The system should recognize when a date or email has been entered and take the user to the next field automatically, whenever possible.

Buttons That Engage

  • The ‘submit’ button should use a strong command verb that provokes emotion or enthusiasm, such as ‘Sign-Up Now!’
  • Use bright, engaging (and accessible) color combinations. Color changes on tap add even more visual information about the progress.
  • Ensure the tap target is large enough for users with big fingers or who have difficulty being accurate. Apple's iPhone Human Interface Guidelines recommends a minimum target size of 44 pixels wide 44 pixels tall.

Final Word

Achieving a smart form design isn't always easy, but it's well worth the effort. 

What are some great examples of forms you've seen? 

Editor’s note: This post was originally published on November 14, 2016, and has been updated for accuracy and comprehensiveness.

Jan 23 2019
Jan 23

Just over a year ago I decided to repurpose an internal contrib-focused meeting and make an open meeting to support contributing to Drupal, called the Contrib Half Hour. Along the way we moved its time a little later to avoid conflicting with another important community initiative and then restructured it to add focused meetings for certain topics. To make things even better, almost all meetings have been recorded and uploaded to our Youtube channel. 2019 is going to see some additional changes that I'm excited to start on.

Our Q&A have issues

Throughout the year it became apparent that there was a huge overlap between the Q&A meetings, where we'd focus on general questions and discussions from the community, and the issues lab, where we'd focus on specific drupal.org project issues. While there's definitely a case for both, the overlap became somewhat naturally as the Q&A days had us often look at Drupal issues.

As a result of this we're going to combine the Q&A and Issues Lab days into one that'll be more open ended, letting us focus on general discussions some days and specific issues other days.

The testing shall continue until code improves

We're also continuing our dedication to helping people learn how to write code tests for their modules and themes. While during 2018 we focused on functional testing for Drupal 7 and 8, I'm aiming to expand our coverage (ba-dum-dum) in 2019 to also include unit testing.

I'd also like to open an invitation for folks to join our testing lab who are starting to write tests to join our labs where we'll be able to help.

Upgrade Lab: Time to upgrade

It was announced late last year that Drupal 9 will be released in June 2020 and that Drupal 7 and 8 will reach their end-of-life in November 2021. The main driving factor behind these dates is that the various libraries Drupal 7 and 8 depend upon will all have reached their end-of-life in November 2021 and so will no longer receive security updates from their respective maintainers. To avoid needing to come up with a plan to provide security coverage for a huge number of out-of-date 3rd party libraries, the Drupal core maintainers are dropping support when the other libraries also stop being supported.

It was also revealed that the usual upgrade anxiety for major releases of Drupal (5 to 6, 6 to 7, etc) would not be the case for Drupal 9. The plan is two release Drupal 9.0.0 and the final minor release of Drupal 8 on the same day, with the only difference being that all deprecated D8 APIs are removed from D9. As a result it will be relatively easy to upgrade from Drupal 8 to 9, “just” update all contrib code and custom code to no longer use the deprecated APIs along the way, and in theory everything should just work.

With this in mind we think it's time for people running Drupal 6 and 7 sites to start looking to upgrade to Drupal 8. Towards that goal we're going to have a regular meeting where we look at the steps to upgrade a site to Drupal 8 using the bundled Migrate system. We'll look at what's involved, how it works, how to plan for it, and how to help contributed modules support Drupal 8's upgrade solution. I'm intending that we'll be able to collaborate on improving both core and contrib's upgrade functionality, and in so doing help all sites looking to upgrade. I'm also hoping that we might be able to provide some assistance to folks attempting custom upgrades using Migrate's APIs, but we'll see how it goes.

Schedule

Our schedule for the next few months looks like this:

  • January 3: Q&A
  • January 10: Turning custom code into OSS
  • January 17: Q & A & Issues
  • January 24: Testing Lab
  • January 31: Upgrade Lab
  • February 7: No meeting
  • February 14: Mirroring git repositories
  • February 21: Q & A & Issues
  • February 28: Testing Lab
  • March 7: Upgrade Lab
  • March 14: Presentation TBD
  • March 21: No meeting
  • March 28: No meeting
  • April 4: Q & A & Issues
  • April 11: Testing Lab
  • April 18: Upgrade Lab
  • April 25: Presentation TBD
  • May 2: Q & A & Issues
  • May 9: Testing Lab
  • May 16: Upgrade Lab
  • May 23: Presentation TBD
  • May 30: Q & A & Issues

Last updated on Feb 14.

Same Bat Time!

We're going to continue meetings at the same time each month, using the same video conferencing provider:

And remember, if you're not able to join us then you can always catch up later as all meetings are recorded, when I don't forget to hit the record button that is.

See you then!

Jan 02 2019
Jan 02

With the year winding down the month was a little quiet, but we still got some good contributions going.

Client sponsored

Thanks to our awesome clients for giving us a chance to help make open source software better for everyone.

Self-directed

Mediacurrent provides some extra time during the week for folks to scratch their own itches, and sometimes people triage issue queues instead of watching football on TV :-)

Blog posts

A little light this month, but there are still two good blog posts from our team.

Contrib Half Hour

We squeezed in four Contrib Half Hour meetings into the month, despite the company being closed for Turkey Day.

Events

Lots of folks were working on their presentation proposals for DrupalCon Seattle 2019. see Tara’s blog post for details. There are also several events coming up soon that we’ll be attending, including DrupalCamp NJ and Florida DrupalCamp in February and then NERDSummit in March.

Stay warm!

That’s it for this month. Hope everyone in the Northern Hemisphere stays warm, everyone in the Southern Hemisphere enjoys their summer, and the folks in the middle don’t brag too much!

Oct 03 2018
Oct 03

Recently, The Guardian Insurance Company made the strategic business decision to start marketing and selling their products directly to consumers. While Guardian has been around for nearly 160 years (WOW!) most consumer experiences with their products stem from employer insurance coverage offerings. As the industry landscape evolves and the US workforce moves slowly towards distributed and independent employment Guardian endeavored to differentiate their offerings not only from industry stalwarts but also from up-and-coming, startup-like products catering to the same demographics. Mediacurrent was proud to be chosen by Guardian Insurance Company as their Design and Strategy partner during product development of their new direct-to-consumer website.

Now that the site has launched, we’re happy to share some behind-the-scenes details of how this fresh, new experience came together. While our Case Study gives a broader overview of the project, this blog post will provide additional insight into our data driven design process.

Part 1 of this 2-part series covers the early planning parts of our process including Strategic Design Discovery, Style Tiles, and Wireframing. Part 2 will cover Mockups & Visual Design, Custom Illustration, and Custom Iconography. Let’s dive in!

Strategic Design Discovery

A Discovery phase begins many of our projects at Mediacurrent. This phase is led by a cross-functional group of our world-class team to help frame the challenges ahead. Throughout this phase, comprehensive knowledge of the Guardian brand, its customers, its competitors, and its business were gathered. These strategic design discovery insights allowed us to understand the types of consumers the new product is being geared towards (user personas), how success is being measured (Key Performance Indicators or KPIs), the ways in which a person becomes a customer (conversion paths) and a boatload of other data that served as our “guiding light” throughout the process.

Wireframes

Next, we moved on to really digging into the user personas and conversion paths generated in the Discovery phase by creating wireframes for the different sections of the site. One of the most exciting parts about this project was that we were not only designing the marketing section of the site but also the entire customer experience from the point where the visitor is attracted, becomes a lead, and eventually converts to a customer. This means that in addition to top-level marketing pages – like the home, about, and product pages – user journey designs were also needed for getting a quote and enrolling in one or multiple products.

Throughout the wireframing process, we broke down the different types of pages and sections of the site that users will encounter when visiting and organized the placement of content and calls-to-action (CTAs) by mapping the layout structure to the user journeys and KPIs identified in Discovery. Working from the Mobile First perspective, we made sure to consider this hierarchy not only on desktop machines but also tablets and mobile phones. In this case, we decided to take a medium fidelity approach – meaning that we avoided color or imagery in order to maintain focus on content organization and the user journey. We did include the typographic and iconography styles defined in our approved Style Tile, and we simulated actual copy since the process included quoting and checkout workflows which would not have made sense with greek copy.

In the end, these blueprints ensured that the user experience was providing the clearest path for a visitor to learn about the products, understand the cost and coverage offered, then ultimately enroll in a Guardian Insurance plan.

The goals mapped through the top-level marketing page wireframes were not only to educate the consumer about the company and the products offered but, more importantly, to serve as a hassle-free gateway to the actions the business measures – namely generating a quote and enrolling. On the homepage, Guardian wanted to make sure a newly developed brand message – Life is full of surprises. The cost of paying for them shouldn’t be. – was clearly communicated so we even started to play with some interaction suggestions. 

medium fidelity wireframe focuses on content organization and the user journeyDesktop, tablet, and mobile homepage wireframes.

The goals mapped through the quoting experience provided a simple way to understand the cost and coverage offered for a variety of different types of consumers – single person, couple, children, adult dependents, etc.

wireframe shows progression toward getting a quote

Tablet-width wireframes of the Find a Dental Plan (or quoting) process.

The goals mapped through the enrollment/checkout process were to 

a) keep the experience as simple and logical as possible for all types of visitors; 
b) allow them to enroll in one or multiple products at the same time;
c) gather all legally required information and consent – which varies between products.

wireframes show user journey to find a price quote

Desktop-width wireframes of the Enrollment (or checkout) process.

Along with these broader page-level experiences, microinteractions – such as saving and retrieving quotes – were considered and wireframed to ensure that the experience was cohesive.

Style Tiles 

With these insights in hand, we began creating Style Tiles that took the brand’s visual guidelines, placed them in an interactive digital context, and expanded on them where we saw the need and/or opportunity. This process created a high level view of the visual tone of the new website. Adding a bit of complexity, Guardian was deep in the midst of a larger corporate rebrand when our project began. In this case, we had to consider the existing brand guidelines, be flexible enough to incorporate new brand elements as they were provided, and ensure that the digital experience was coherent, unique, and accessible to all users – a critical concern identified during Discovery. 

Three concepts were presented initially:

1. New Blue Suit

– This concept expresses subtle sophistication through the use of color, typography, and whitespace. It relies heavily on the brand’s primary blue hue as a color that reinforces trust, loyalty, and integrity. An overall contemporary, minimalist approach is suggested as a means of reducing cognitive load. The icon style followed these principles as well by choosing an outline style with subtle monotone accents. Typographically, we included the fonts defined in their brand guidelines in order to maintain consistency with existing materials.

style tile includes blue and gray color palette and brandon grotesque typography

2. Happy Place

This concept is lively and pleasant using bright colors to create a friendly experience. We expanded the brand color palette to add cheerful, accessible hues able to be used in a variety of UI elements. Typographically we pushed the existing brand guidelines by incorporating a new font – Open Sans – as its wider variety of weights allows it to be used more expressively than the currently defined Arial family. Our type treatments utilized a lighter weight body font to balance the heavy use of color and maintain valuable whitespace. The icon style suggested takes a more fully-realized illustrative approach making use of the expanded color palette and adding dimension through highlights and shadows.

style tile with primary color palette

3. Gilded Skies

This concept reduces the color palette and adds trendy accents. Broader than New Blue Suit, but more restrained than Happy Place, this example’s color palette features a rich gray, trusted blue, and adds shades of gold to suggest value, elegance, and quality. Here we’ve suggested a hand-drawn icon style that personalizes the experience with a more genuine feel. We also included photography style suggestions that feature color and light effects to extend the color palette and maintain a clean and crisp look.

style tile features photography examples and a gray, blue, and gold palette

Through this exercise, we were able to understand just how far Guardian was willing to push their existing brand and create a final document that was approved by all stakeholders as the visual voice we wanted to achieve with the final product. In the end, and with a few iterations in between, we landed on what was essentially a blend New Blue Suit and Gilded Skies as the path forward. This final Style Tile was chosen in order to maintain consistency with Guardian’s larger, existing brand guidelines while introducing elements that would help create a more casual tone appropriate for the demographic of their direct-to-consumer offerings. 

final style tile includes blue, grey, gold and red tones, typography, buttons, and icons

Stay Tuned!

Our process does not end here but part 1 of this post does, unfortunately. :( Keep an eye out for part 2 where we’ll dig into the visual design details of the site! We’ll look at different visual concepts that were created, how the design was finalized with custom illustrations and iconography, and the component-driven approach we follow. For now, just direct your feet to the sunny side of the street!

Sep 24 2018
Sep 24

Culture. It's the only truly sustainable competitive advantage for a Drupal business.  But what does that look like in action? I've seen firsthand how that culture extends far beyond Mediacurrent's business and customer service approach, shaping the way we network. 

We have all been to a party, lunch, or even coffee and cookies with a vendor trying to make a connection with you or your company. You can separate all of these into two basic categories: those that you walk into and have fun and those you walk into defensively because you know the goal is to pitch a sale to you.

Hosting a networking event can be a costly endeavor for your company and there is no guarantee that you will receive a high percentage of return on your investment. Between your time investment, activities, and potentially cost of a space, expenses can begin to pile up quickly.

Hitting that optimal zone where customers or potential clients will feel relaxed and are open to conversation is key to reaching your maximum potential for ROI for your event. There are several ways you can do this, but it all starts with one word.

Passion.

Passion for what you love is the difference between just hosting an event and connecting with the community in your field of business. The goal is to show your passion for what you do, and the community you are in -- in our case, the open source and Drupal communities.  

DrupalCon 2018 conference aerial group shot

Take the Dave and Paul approach for example. Over DrupalCon 2018, they threw an amazing after party hosted by Mediacurrent. Everything down to the invites was inclusive to all (not just those with purchasing power) with the message of “Hey, we are throwing a party, come to hang out! Hope to see you there.” Every single person was treated like a friend.

karaoke at Mediacurrent's DrupalCon Nashville after party

While at the party, the sales team focused on just interacting, listening to people’s experience and thanking the community for showing up. This approach made people feel so comfortable that if they had a sales question, they would just ask.

When a person feels welcomed, unpressured and a part of the group, then it's easy for them to make the leap from conference attendee to a potential client. Remember: you and everyone who attends your function is a part of the same community. If you view them as just potential sales, then this will be translated into your body language and verbiage.

In closing, being a part of the Mediacurrent team has reaffirmed for me the value of networking with authenticity. Hosting your event with the passion you have for the community you are a part of will shine through to everyone who attends and solidify you in their mind as the right partner for their project.

Sep 20 2018
Sep 20

As we enter the month of September and start planning for 2019, it’s a good time to take stock of where Drupal is as a project and see where it’s headed next year and beyond.

Dries Buytaert, founder of Drupal, recently wrote his thoughts around the timeline for Drupal 9 and “end of life” for Drupal 7 and 8. We will look at current Drupal 8 adoption and assess where we sit in 2019 as well.

An important part of this discussion that deserves attention is the rise of Javascript as a programming language, in particular, the rise of React.js. This technology has put CMSs like Drupal in an interesting position. We will look at how React/Javascript are evolving the web and assess what that means for the future of Drupal.

Finally, we will wrap up with thoughts on what these changes mean for both developers and organizations that use Drupal today or evaluating Drupal.

Drupal 8 Adoption

As mentioned previously, Dries has offered his thoughts on the proposed timeline for Drupal 9 in a recent blog entry on his website (see below).

timeline: Drupal 9 will be released in 2020. Drupal 8 end of life is planned for 2021

In early September Drupal 8 released version 8.6.0 which included major improvements to the layout system, new media features, and better migration support. This is in addition to many other improvements that have been released since Drupal 8.0 was first unveiled in late 2015.

In terms of adoption, Drupal has picked up steam with 51% growth from April 2017 to April 2018.

Dries Keynote Drupalcon 2018

graph showing that as of April 2018, 241,000 sites run on Drupal

As encouraging is that news is, it’s still should be noted that Drupal 7’s popularity still far exceeds Drupal 8 both in current usage (800k compared to 210k+ sites) and in terms of growth year over year. 

Drupal’s weekly project usage from August, 2018

graph shows Drupal 7 adoption exceeds that of Drupal 8

Drupal 7 will reach its end of life likely around November 2021 with paid support extending the lifetime with commercial support (as was the case with Drupal 6). Will Drupal 8 reach the level of usage and popularity D7 has? Perhaps not but that is largely due to focus on more robust, “enterprise” level features.

Drupal as a CMS sits largely in between Wordpress and enterprise proprietary CMSs like Adobe CMS and Sitecore in the marketplace. With the release of Drupal 8, the project moved more into the direction of enterprise features (which could explain some of the fall-off in adoption).

Pantheon had two excellent presentations (also at Drupalcon Nashville) that dive deeper into Drupal’s position in relation to other projects, most notably Wordpress. I would recommend watching WordPress vs Drupal: How the website industry is evolving and What's possible with WordPress 5.0 for more information on this topic.

According to builtwith.com, Drupal still has a sizable chunk of Alexa’s Top Million Sites. It should also be noted that Drupal does better the higher you go up the list of those sites which underscores the project’s focus on the enterprise.

CMS market share (builtwith.com)

5% of Alexa's Top Million sites run on Drupal

Drupal usage statistics (builtwith.com)

8.5% of the top 10k websites run on Drupal

With the release of Drupal 8, Drupal’s target audience started consolidating more towards the enterprise user. In the future Drupal’s success as a project will be tied more closely to performance against platforms like Adobe CMS and Sitecore in the marketplace.

React (and Javascript) take over the world

The thing about Javascript is that it’s been around forever (in tech terms) but recently has taken off. I won’t detail all the reasons here. Seth Brown from Lullabot has one of the best write-ups I have seen from a Drupal community perspective. In short, the ability now to run Javascript both in the browser and on the server (Node.js) has led the surge in Javascript development. Github shows us that more projects are built with Javascript than any other technology and Stack Overflow’s survey tells us that Javascript is the current language of choice.

Stack Overflow 2018 survey results

Javascript is the most popular language

Github projects 2018

2.3 million Javascript Github projects

Dries recognizes the importance of Javascript and has spoken about this recently at MIT. In a bit, we will look at some of Dries’ ideas for the future in relation to the Drupal project.

A few years ago we saw several Javascript frameworks pop up. These became very popular for single page applications (SPA) but also had broader appeal because they could make any website feel more interactive. React.js & Ember.js were both released in 2015 and Angular.js is older but has started getting more attention around the same time.

A big issue that needed to be solved with these frameworks was how to address SEO. Initially, these frameworks only rendered the page in the browser which meant site content was largely hidden from search engines. For SPA’s this was not necessarily a deal breaker but this limited the broader adoption of this technology.

Only fairly recently have we seen solutions that are able to use the same framework to serve pages both in the browser and on the server. Why do I bring this up? Because this has been one of the more difficult challenges and React.js addresses it better than any other framework. There are many reasons why React.js adoption is exploding but this is why I believe React is king.

The State of Javascript report from 2017 is often referenced to illustrate React’s popularity (see below):

survey respondents indicated that they have used and would use Javascript again - more than other technologies

John Hannah also has some great graphs on javascriptreport.com that demonstrate React’s dominance in this space (see below).

Npm downloads by technology (1 month)

React downloads (1 month) exceed angular and vue

Npm downloads by technology (1 year)

React downloads (1 year) exceed angular and vue

Finally it should be noted that Facebook’s technology, GraphQL paired with React.js is also on the rise and intertwined with the growth of this technology. GraphQL will come into play when we look at how CMSs are adapting to the surge in Javascript and Frontend frameworks.

React and the CMS

Is React compatible with CMSs of ‘ole (e.g. Wordpress, Drupal, etc.)? Well, yes and no. You can integrate React.js with a Drupal or Wordpress theme like you can many other technologies. In fact, it’s very likely that Drupal’s admin interface will run on React at some point in the future. There is already an effort underway by core maintainers to do so. Whether or not the admin will be fully decoupled is an open question. 

Another example of React admin integration is none other than Wordpress’ implementation of React.js to create the much anticipated Gutenberg WYSIWYG editor.

Gutenberg editor

screenshot of empty Gutenberg editor

In terms of websites in the wild using React with Drupal, there have been solutions out there (TWC, NBA, and others) for many years that use Drupal in a “progressively decoupled” way. The “progressive” approach will still exist as an option in years to come. Dries wrote about this recently in his blog post entitled “How to decouple Drupal in 2018.”

The problem I have with this type of solution is that sometimes you get the best (and worst) of both worlds trying to bolt on a Javascript framework onto a classic templating system. The truth is that Drupal’s templating theme layer is going to have trouble adapting to the new world we now live in (addressed in detail at Drupalcon’s “Farewell to Twig”). 

The real power of React is when you can combine it with GraphQL, React router and other pieces to create a highly performant, interactive experience that users will demand in years to come. To accomplish this type of app-like experience, developers are increasingly looking to API’s to address this dilemma, which we will examine next.

CMS as an API

The last couple of years there have been many Cloud CMS-as-an-API services pop up that have been generating some attention (Contentful might be the most popular). At this time it doesn’t appear that these API’s have disrupted market share for Wordpress & Drupal but they do signify a movement towards the idea of using a CMS as a content service. 

The “Decoupled” movement in the Drupal community (previously known as “Headless”) has been a big topic of conversation for a couple of years now. Mediacurrent’s own Matt Davis has helped organize two “Decoupled Days” events to help the Drupal community consolidate ideas and approaches. Projects like Contenta CMS have helped advance solutions around a decoupled architecture. Dries has also addressed Drupal’s progress towards an “API-first” approach recently on his blog.

While cloud services like Contentful are intriguing there is still no better content modeling tool that Drupal. Additionally, Drupal 8 is already well underway to support JSON API and GraphQL, with the potential to move those modules into core in the near future.

As I look at the landscape of the modern technology stack, I believe Drupal will flourish in the enterprise space as a strong content API paired with the leading Javascript Frontend. React & GraphQL have emerged as the leading candidates to be that Frontend of record.

Next, we will look at a relatively new entrant to the family, JAM stacks, and see where they fit in with Drupal (if at all?) in the future.

JAMStacks - The Silver Bullet?

The popularity of Netlify hosting and static generators has created some buzz in the Drupal community, particularly Gatsby.js, which we will examine in a moment.

Netlify provides some great tooling for static hosted sites and even offers its own cloud CMS. Mediacurrent actually hosts our own website (Mediacurrent.com) on Netlify. Mediacurrent.com runs on Jekyll which integrates with a Drupal 8 backend so we are well aware of some of the benefits and drawbacks of running a static site.

Where Drupal fits into the JAM stack is as the ‘A’ (for API), with ‘J’ being the Javascript Frontend (i.e. React) and ‘M’ being the statically generated markup. Back in 2016 we liked this idea and settled on Jekyll as the tool of choice for our rebuild as it was the most popular and well supported project at the time.

Since then Gatsby.js has risen dramatically in popularity and has a robust source plugin system that enables it to be used as a Frontend for many platforms including Drupal and Wordpress.

The creator of Gatsby, former Drupal developer Kyle Matthews recently spoke on the subject at Decoupled Days 2018. While it’s hard to know if JAM stacks like Gatsby having staying power in the years ahead they do have a lot of appeal in that they simplify many of the decoupled “hard problems” developers commonly run into. The question of scalability is an important one yet to be answered completely but the upside is tremendous. In a nutshell, Gatsby provides an amazingly performant, React/GraphQL solution that can pull in content from practically any source (including Drupal).

Do JAM stacks like Gatsby have staying power? Will these close the complexity gap that blocks more sites (large or not) from decoupling? We will have to stay tuned but the possibilities are intriguing.

Looking Ahead

We have examined the state of Drupal as a project, future release plans and how it is adapting towards a future that is “API First” that also fits well with the React world in which we now live. 

The main takeaway I would offer here is that Drupal, while still an amazing tool for managing content, is better suited as a technology paired with a leading Frontend like React. With the web evolving from monolithic systems to more of a services-type approach, it makes sense to use a best-in-class content modeling tool like Drupal with a best-in-class FE framework like React.js. 

What does that mean for the average Drupal developer? My advice to Drupal developers is to “Learn Javascript, deeply.” There is no time like the present to get more familiar with the latest and greatest technology including GraphQL.

For organizations evaluating Drupal, I do think the “Decoupled” approach should be strongly considered when planning your next redesign or build. That being said, it’s important to have an understanding of how the pieces fit together as well as the challenges and risk to any approach. This article attempts to present a high-level overview of the technology landscape and where it’s headed but every organization’s needs are unique. At Mediacurrent we work with clients to educate them on the best solution for their organization. 

Have questions or feedback? Hit me up at https://twitter.com/drupalninja/

Sep 13 2018
Sep 13

The marketing landscape is vastly different than it was when Drupal 7 was released in 2011. Since then, there has been a shift, placing the marketing team in the driver’s seat more often and almost always involved in the CMS decision. In this post, we’ll outline some of the ways you can up your SEO game with Drupal 8.

Traditional SEO is dead.

No longer will well-placed keywords alone get you to the top of the SERP ranks. Content is still King in the world of marketing and it’s what helps you improve your SEO.

Every algorithm change Google has made has one thing in common: it aims to provide the best content based on what it "thinks" the user is trying to find. In other words, - what is the users intent. If you want your rankings to stick past the next update, don't try to cheat the system. Attract your prospects with informative, entertaining pieces that they can use to take action. And avoid no value posts that are keyword stuffed with your industry and the word "best" 100 times. Google can see through it and so can all of your users.

That said, there are a few other factors that are critical to keeping your rankings high that can’t be ignored including quick load times and mobile-friendliness. Drupal 8 is built with several of these factors in mind to help us make needed improvements quickly and effectively.

Mobile First Mentality

Drupal 8 is created with responsive design capabilities built in, so you can begin to address any problems immediately. That’s not to say all of your responsive problems will be solved. Content editors will still need to think through their content and imagery, themers will still need to do configuration to establish things like breakpoints, etc. but Drupal 8 will set you on the right path, giving you and your team many of the tools you need.

You’ll also have the option to choose different images and content for desktop and mobile versions right from the WYSIWYG editor, making it easier to see the differences for every piece of content when you add it and before you publish. This means a solid visual of both versions in real-time for faster publishing and peace of mind knowing exactly what your users experience on any device. 

The Need for Speed

Another big factor that could affect your rankings is speed on both desktop and mobile. Google places such high importance that they’ve given you a PageSpeed Insights test to show where and how your website is slowing visitors down. Drupal 8 is “smart” in that it caches all entities and doesn’t load JavaScript unless it has to. This means the same content won’t be reloaded over and over and instead can be loaded quickly from the cache.

Drupal 8 also uses industry-leading caching technology to allow updated content to be served fresh to a client, while preserving the cache on content that hasn’t changed. So, after your visitors come to your website once, they won’t have to wait for all content to load each time, making load times much faster.
Another way Drupal 8 improves speed is through feature velocity. Because so much new functionality is built into Drupal 8 core, creating and publishing new dynamic content experiences is significantly faster than in Drupal 7. A blog post that features dynamically updated data, relevant to and powered by your content can be built in the UI in Drupal 8, something that in Drupal 7 would have taken custom development and several modules.

Responsive design is a must-have in today’s digital landscape and speeding up your website on both desktop and mobile is a surprisingly effective way to contribute to your SEO efforts. In short, if you’re marketing team is focused (as you should be) on top rankings, Drupal 8 provides many of the tools to make that happen. 

Accessibility = Key for Search

The release of D8 marked a big push toward improving web accessibility, including: 

  • Overall community commitment to accessibility 
  • Technical features for improved accessibility like controlled tab order and aural alerts 
  • All features conform with the World Wide Web Consortium (W3C) guidelines

This is important because, as we know, the relationship between web accessibility and SEO is closely intertwined.

Drupal 8 SEO Modules

Here are some top Drupal 8 SEO Modules to use when optimizing your site. 

  1. Pathauto - helps save you time from manually having to create URL path/aliases.
  2. Metatag - allows you to automatically provide structured metadata, aka "meta tags", about a website.
  3. Sitemap - provides a site map that gives visitors an overview of your site. It can also display the RSS feeds for all blogs and categories.
  4. Redirect - Almost every new site needs to incorporate 301 redirects for old page URLs. This gives site admins an easy interface for creating those redirects in Drupal.
  5. Google Analytics - This simple module allows site admins the ability to easily configure Google Analytics in Drupal.
  6. Easy Breadcrumbs - uses the current URL (path alias) and the current page's title to automatically extract the breadcrumb's segments and its respective links. 
  7. SEO Checklist - uses best practices to check your website for proper search engine optimization. It eliminates guesswork by creating a functional to-do list of modules and tasks that remain. 

Conclusion

Drupal’s content management system is perfectly structured for search optimization and its core features support many of the critical SEO elements. But, SEO is only part of the story. In the next post, we’ll explore some of the do’s and don’ts and things to keep in mind once you’re on Drupal 8. 

Sep 13 2018
Sep 13

Choosing a platform on which to build your website can be a daunting task. There is an ever-growing list of content management systems (CMS) from advanced platforms like Drupal and WordPress to all-inclusive DIY website builders like Wix and Squarespace. The right choice depends on factors such as desired functionality, flexibility, available budget, and your ability to manage the site after launch.

Where you fall on the spectrum between mom-and-pop shops and enterprise businesses will also heavily influence your decision.

  Mom-and-Pop <—————————> Enterprise

Questions to consider before choosing your CMS

  • How often do you want to post or update content?
  • How many content editors will be adding to the site?  
  • Do your editors need varying degrees of access and permissions?
  • Will your site have a heavy reliance on search, interactivity, or 3rd-party integrations?
  • Do you have specific design needs that require multiple custom layouts?
  • Will you be able to support the site without developer support?
  • What is your project budget?  
  • What is your post-launch support budget?

Scalability vs Simplicity 

WordPress and Drupal have many things in common. Both are open source and freely available, are supported by their developer communities who contribute code to the projects including regular security updates, and offer extensive add-on functionality to the CMS core through plugins and modules.

Site builders or content managers who have used both systems often have a bias for WordPress over Drupal, considering WordPress the more user-friendly of the two. Before one can accurately make such an assessment, I believe the comparison must be apples to apples between comparably sized sites with similar functionality or complexity. If one compares how user-friendly WordPress is for creating and managing a personal blog or small business website that requires no customizations and has static content versus the complexities of using Drupal to build a site for the enterprise with dynamic relationships between various data points, that is not a reasonable comparison.  It is true that Drupal has a higher learning curve than WordPress largely due to the amount of available customization that is built into its core. WordPress is simple to use, especially for blogs or small sites, but not necessarily scalable or suited for larger more complex sites. If pushed to the enterprise end of the spectrum above, would WordPress still maintain its user-friendliness and be able to scale? Conversely, Drupal is best suited for enterprise level sites with custom requirements and would add unnecessary development overhead if chosen for a small site or blog.

If WordPress and Drupal were Lego types...

I’ve often thought of Wordpress and Drupal in terms of Lego whereas:

Lego Duplo set, simple with large building blocks like Wordpress

Source: Lego.com

WordPress is like Lego Duplo where you can build things easily with preformed shapes as long as those preformed shapes match your specific needs. These preformed shapes equate to plugins to add functionality and pre-designed theme templates that determine the styles and layout of your site. Duplo blocks are appropriate for ages 1-5 or, in other words, personal projects or small to medium businesses with simpler requirements. 

 

Lego Technic race car is complex like Drupal

Source: Lego.com

Drupal is like Lego Technic where you can build whatever you can imagine with little to nothing preformed. Like Technic pieces, Drupal has highly configurable plugins that provide granular control over the functionality of your site and do not impose pre-selected designs to your theme. They are appropriate for ages 7-16 or, in other words, medium to large businesses or organizations with complex requirements. 

With that analogy in mind, let's explore some of the advantages of each platform.

Advantages of WordPress

Confession: I love WordPress. It’s true! As a non-developer with several personal projects outside of work, whether it was for my consultant friend who needed a five-page site with a contact form, a guitarist wanting to promote his music, or managing several blogs, WordPress meets those needs perfectly. Below are the features that stand out in my experience from which people draw the conclusion that WordPress is so user-friendly. 

Dashboard

Upon logging into WordPress you are presented a user-friendly and intuitive admin interface from which you can figure out almost instinctively how to manage your website. You can quickly navigate to various types of content or site functionality from the left rail admin toolbar. The admin toolbar has appropriately named menu items. Hovering over each one triggers a slide out sub navigation making it easy to find the action or setting for which you are looking.

Screenshot of Wordpress user-friendly dashboard

Media Library

Adding images to your content or as a featured image above a post or page is quite simple. With a click of a button, you can add images, audio or video files, documents, and PDFs. Images are automatically given responsive image styles so that they adapt appropriately to the width of one’s browser window or mobile device.

Though not specifically part of the media library, inserting YouTube or Vimeo videos into a post is as simple as pasting the URL. WordPress will render the video as embedded on the page (also works with Twitter and Instagram posts).

Adding Content

As noted above, the Dashboard provides quick access in a few different ways to add new content. The Add New Post (or another type of content) edit page has a visual WYSIWYG editor for formatting your content with links to add media, categories, tags, and visibility of your new post. You can easily view revisions after content has been published and revised with functionality that is provided out of the box.

Screenshot of Wordpress admin interface for adding a new blog

Plugins and Themes

I’m grouping these two together because here is where we begin to add to WordPress core and its out of the box functionality. I’ve used 3rd-party plugins to add custom forms, simple e-commerce capabilities, invoicing and client management features, automated backups, and SEO enhancements to WordPress sites. The WordPress Plugin Directory boasts 56,182 available plugins to add functionality that is not included or as customizable within WordPress core. Many plugins are completely free or offer freemium versions with more advanced premium features available for a one-time charge or subscription fee.

Wordpress.org ecommerce plugins

Likewise, the WordPress Theme Directory offers many free or commercial templates searchable by layout options, features, or subject (topic matter of your site). Themes typically have some customization built-in to control layout options, widgets, background images, and the like.

Screenshot of Wordpress themes and layout options

Updates

WordPress Core, installed plugins and themes can be updated with the click of a button through the Dashboard. 

screenshot of Wordpress plugin updates

*Plugins are a double-edged sword in that they add flexibility from a non-developer standpoint while simultaneously introducing more risk from a security standpoint. The more 3rd-party plugins you use, the more dependence you will have on those 3rd-parties keeping their code secure by providing timely updates. Security issues with WordPress are introduced most often through vulnerabilities exploited in plugins.

Lower development costs 

This isn’t a feature of WordPress, but it’s worth mentioning that if the “out of the box” solutions meet your needs and you are able to build a site without the assistance of a developer, it will cost you less. If you fall on the mom-and-pop end of the spectrum, have a lower development budget, and are not picky about every detail of design or functionality, WordPress is likely a great option for you.

Advantages of Drupal

Custom content types and views 

Whereas WordPress comes with two content types (posts and pages), Drupal also comes with two content types out of the box (article and basic page). However, it not only allows you to edit the fields for those content types but also create new content types and views without custom code that meet your specific requirements. If your site needs a blog, you can create a content type for blog posts and a view that displays them the way you want. If you need a staff directory, you can create a content type for staff that has fields for name, title, profile picture, bio, etc., and then create a view to display the staff in a list, a grid, or to whatever your specs require.

This is one way in which Drupal and WordPress differ. Drupal is an application framework that allows you to build what you need the way you need it. WordPress core starts as a blog that makes you add to core in order to manipulate its built-in behavior. For example, in order to disable blogging in WordPress, you have to install a 3rd-party plugin such as Disable Blogging in WordPress.

If you compare WordPress core and Drupal core, Drupal is far more robust than WordPress.

Access control and user permissions 

Out of the box Drupal core allows you to create and define your own user roles and associated permissions for each. If your site requirements call for multiple levels of user permissions with varying degrees of access, Drupal lets you create new roles and assign them with custom permissions. And, unlike WordPress, Drupal allows granting more than one role to your users. This gives you fine-grained control over what they are allowed to do. Building on the previous example of a staff directory, you could create a role for Staff and only give that role permissions to edit one’s bio page. All of these customizations for roles and permissions can be done in the admin without adding any custom code.

Screenshot of managing roles in Drupal CMS

screenshot of permissions in Drupal

adding a new user in Drupal CMS

Taxonomy 

Whereas the tagging system in WordPress is flat, in Drupal you can have multiple types of categorization and determine how much information you want to track on each one. Drupal allows you to create more complex and custom data relationships across various types of content.

screenshot of taxonomy terms in Drupal CMS

Internationalization 

Want the Drupal admin to display in the native language of your officemate overseas? No problem! Native language handling is now built into Drupal 8’s core APIs which improve the ease of globalization management. Building a multilingual site no longer requires installing multiple contributed modules. 

Drupal 8 multilingual configuration

Security 

Drupal is known for having a volunteer security team and a standardized set of policies and procedures for dealing with security issues. Security advisories are routinely posted on https://www.drupal.org/security for Drupal core as well as contributed projects. For enterprise clients with specific security needs, the Drupal distribution Guardr is available with a combination of modules and settings to enhance the Drupal application’s security.   

Drupal.org security advisory

Customization

As a web application framework, Drupal can be adapted to meet very specific requirements. For example, the Drupal entity system allows tracking specific data points and values that are needed when building applications. At times, Content Types aren’t the best choice for these data elements, and more custom entities allow for improved performance and fit the requirements best.

If this has you scratching your head, you’re not the only one. I’m purposely skirting around the complexity of the section because it is beyond the scope of what I’m trying to speak to here. The important difference here is that Drupal allows tracking points of data without cluttering up the editorial experience. Sometimes the data needs to be seen but not heard. Drupal lets you do that. And site editors may never even realize it’s happening.

Conclusion

As a site builder who has built dozens of sites in HTML, Joomla, and WordPress and worked for five years as a project manager at Mediacurrent (almost exclusively with Drupal), I realize that the Lego analogy may be helpful but at the same time not completely accurate. After all, WordPress boasts such enterprise level sites such as Techcrunch, Sony Music, and Time, Inc. But my experience reinforces the perception that WordPress is amazing at simple sites or blogs while Drupal is the go-to for more complex sites. 

I’ve found that clients will like a template design exactly the way it comes except for “insert numerous design changes” or the plugin functionality as-is “if you change this one behavior that isn’t built into the plugin.” And at that point, the gains of using out of the box functionality and design offered by WordPress (either via core WordPress or plugins and themes) are lost to customizations and a custom Drupal implementation is preferred. If you fall on the enterprise end of the spectrum and have deeply refined technical requirements, Drupal is likely a great option for you.

It comes down to the level of complexity for which you need to plan. If you are building a large site that is essentially brochureware (static pages), WordPress will work for you. If your site requirements call for a dynamic application with a heavy reliance on custom search results, interactivity, or 3rd-party integrations, or if you have specific design needs that require multiple custom layouts, your best bet is to use Drupal 8.

Aug 22 2018
Aug 22

At Mediacurrent, we hear a lot of questions — from the open source community and from our customers — about website accessibility. What are the must-have tools, resources, and modules? How often should I test? To address those and other top FAQs, we hosted a webinar with front end developers Ben Robertson and Tobias Williams, back end developer Mark Casias, and UX designer Becky Cierpich.

The question that drives all others is this: Why should one care about web accessibility? To kick-off the webinar, Ben gave a compelling answer. He covered many of the topics you’ve read about on the Mediacurrent blog: introducing WCAG Web Content Accessibility Guidelines, some the benefits of website accessibility (including improved usability and SEO) and the threats of non-compliance.

[embedded content]

Adam Kirby: Hi everybody, this is Adam Kirby. I'm the Director of Marketing here at Mediacurrent. Thanks everyone for joining us. Today we're going to go over website accessibility frequently asked questions. 

Our first question is: 

Are there automated tools I can use to ensure my site is accessible and what are the best free tools? 

Becky Cierpich: Yes! Automated tools that I like to use —and these are actually all free tools— are WEBAIM’s WAVE tool, you can use that as a browser extension. There's also Chrome Accessibility Developer Tools and Khan Academy has a Chrome Plugin called Tota11y. So with these things, you can get a report of all the errors and warnings on a page. Automated testing catches about 30 percent of errors, but it takes a human to sort through and intellectually interpret the results and then determine the most inclusive user experience. 

What's the difference between human and automated testing? 

Becky Cierpich: Well, as I said, the automated tools can catch 30 percent of errors and we need a human on the back end of that to interpret. And then we use the manual tools, things like Chrome Vox or VoiceOver for Mac, those are some things you can turn on if you want to simulate a user experience from the auditory side, you can do keyboard only navigation to simulate that experience. Those things will really help you to kind of drive behind the wheel of what another user's experiencing and catch any errors in the flow that may have come from, you know, the code not being up to up to spec. 

Then we also have color contrast checkers. WEBAIM has a good one for that and all these are free tools and they can allow you to test one color against another. You can verify areas that have too little contrast and test adjustments that'll fix the contrast. 

What do the terms WCAG, W3C, WAI, Section 508, and ADA Title III mean? 

Mark Casias: I'll take that one - everybody loves a good acronym. WCAG, these are Web Content Accessibility Guidelines. This is the actual document that gives you the ideas of what you need to change or what you want to a base your site on. W3C stands for World Wide Web Consortium - these are the people who control the web standardization. WAI is the Web Accessibility Initiative and refers to the section of the W3C that focuses on accessibility. 

Finally, Section 508 is part of the Rehabilitation Act of 1973, well it was added to that act in 1998, to require Federal agencies to make their electronic and IT  accessible to people with disabilities. ADA Title III is part of the Americans with Disabilities Act which focuses on private businesses, it mandates that they need to be fully accessible to individuals with disabilities. 

 What are the different levels of compliance? 

Tobias Williams: Briefly, the WCAG Web Content Accessibility Guidelines tell us that there are three levels - A, AA, and AAA, with AAA being the highest level of compliance. These are internationally agreed to, voluntary standards. Level A has the minimum requirements for the page to be accessible. Level AA builds on the accessibility of level A, examples include consideration of navigation placement and contrast of colors. Level AAA again builds on the previous level - certain videos have sign language translation and improved color contrast. 

To meet the standard of each level there are 5 requirements that are detailed on the WCAG site. Every every actionable part of the site has to be 100% compliant. WCAG doesn't require that a claim to a standard be made, and these grades are not specified by the ADA but are often referenced when assessing how accessible the site is.

Should we always aim for AAA standards?

Ben Robertson: How we approach it is we think you should aim for AA compliance. That's going to make sure that you're covering all the bases. You have to do an internal audit of who are your users and what are your priorities and who you're trying to reach. And then see out of those, where do the AAA guidelines come in and where can you get the biggest bang for your buck? I think that the smart way to do it is to prioritize. Because when you get to the AAA level, it can be a very intense process, like captioning every single video on your site. So you have to prioritize. 

What Drupal modules can help with accessibility?

Mark Casias: Drupal.org has a great page that lists a good portion of these modules for accessibility.  One that they don't have on there is the AddtoAny module that allows you to share your content. We investigated this for our work on the Grey Muzzle site and found this was the most accessible option. Here are some other modules you can try:

  • Automatic Alternative Text -The module uses the Microsoft Azure Cognitive Services API to generate an Alternative Text for images when no Alternative Text has been provided by user.
  • Block ARIA Landmark Roles -Inspired by Block Class, this module adds additional elements to the block configuration forms that allow users to assign a ARIA landmark role to a block.
  • CKEditor Abbreviation - Adds a button to CKEditor for inserting and editing abbreviations. If an existing abbr tag is selected, the context menu also contains a link to edit the abbreviation.
  • CKEditor Accessibility Checker - The CKEditor Accessibility Checker module enables the Accessibility Checker plugin from CKEditor.com in your WYSIWYG.
  • High contrast - Provides a quick solution to allow the user to switch between the active theme and a high contrast version of it. (Still in beta)
  • htmLawed  - The htmLawed module uses the htmLawed PHP library to restrict and purify HTML for compliance with site administrator policy and standards and for security. Use of the htmLawed library allows for highly customizable control of HTML markup.
  • Siteimprove - The Siteimprove plugin bridges the gap between Drupal and the Siteimprove Intelligence Platform.
  • Style Switcher - The module takes the fuss out of creating themes or building sites with alternate stylesheets.
  • Text Resize - The Text Resize module provides your end-users with a block that can be used to quickly change the font size of text on your Drupal site.

At what point in a project or website development should I think about accessibility? 

Becky Cierpich: I got this one! Well, the short answer is always and forever. Always think about accessibility. I work a lot at the front end of a project doing strategy and design. So what we try to do is bake it in from the very beginning. We'll take analytics data and then wecan get to know the audience that way. That's how you can kind of plan and prioritize your features. If you want to do AAA features, you can figure out who your users are before you go ahead and plan that out. Another thing we do is look at personas. You can create personas that have limitations and that way when you go in and design. You can be sure to capture those people who might be challenged by even things like a temporary disability, slow Internet connection or colorblind - things that people don't necessarily even think of this as a disability.

I would also say don't worry if you already have a site and you know, it's definitely not compliant or you're not sure because Mediacurrent can come in and audit, using the testing tools to interpret and prioritize and slowly you can get up speed over time. It's not something that you have to necessarily do overnight. 

How often should I check for accessibility compliance? 

Tobias Williams: I’ll take this one - I also work on the front end, implementing Becky’s designs. When you're building anything new for a site, you should be accessibility testing. test work, During cross-browser testing, we should also be checking that our code meets the accessibility standards we are maintaining.

Now that's easy to do on a new cycle because you're in the process of building a product that currently exists. I would say anytime you make any kind of change or you're focused on any kind of barrier of the fight, I would run a quick accessibility check. And then even if you don't address the changes straight away or at least you're aware of that, you can document them and work on them later. As far as an in-production site where you have a lot of content creators, or where independent groups work on features it is also a good idea to run quarterly spot checks. 

I've seen these on a few sites, but what is an accessibility statement and do I need one?

Becky Cierpich: An accessibility statement is similar to something like a privacy agreement. It's a legal document and there are templates to do it. It basically states clearly what level of accessibility the website is targeting. If you have any areas that still need improvement, you can acknowledge those and outline your plan to achieve those goals and when you're targeting to have that done. It can add a measure of legal protection while you're implementing any fixes. And if your site is up to code, it's a powerful statement to the public that your organization is recognizing the importance of an inclusive approach to your web presence. 

What are the legal ramifications of not having an accessible website? 

Ben Robertson: I'll jump in here, but I just want to make a disclaimer that I'm not a lawyer. Take what I say with several grains of salt! This whole space is pretty new in terms of legal requirements. The landmark case was  Winn-Dixie, the grocery store chain — it was filed under title III of ADA Act and they lost. It was brought up by a blind customer who could not use their website. The court order is available online and it's an interesting read but basically, there were no damages sought in the case. The court ordered that

they had to have an accessibility statement that said that they would follow WCAG 2.0. That's a great refresh for site editors to make sure that they're following best practices. They also mandated quarterly automated accessibility testing. 

I really think if you have these things in place already, you're really gonna mitigate pretty much all your risk. You can get out in front of it if you have a plan. 

If I have an SEO expert, do I need an accessibility expert as well? 

Tobias Williams: I'll explain what we do at Mediacurrent. We don't have one person who is an expert. We have a group of people. We have several developers, designers and other people on the team who are just interested in the subject and we meet once a week, we have a Slack channel where you just talk about accessibility. There are people who are most familiar with different aspects of it and that allows us to be better rounded as a group. 

I can see somebody being hired to be an accessibility expert but I think that the dialogue within a company about this issue is most important. The more people who are aware of it, the better. You can prevent problems before they occur. So, if I'm aware of the accessibility requirements of an item building, I'm going to build it the right way as opposed to having to be reviewed by the expert and then making changes. The more people who are talking about it and were involved in it and I'm the general level of knowledge, it goes a long way. We don't need to have experts as much as we need to have interested people. 

As a content editor, what's my role in website accessibility?

Mark Casias: Your role is very important in website accessibility. All the planning and site building that I do [as a developer] won't mean a thing if you don't attach an image alt tag to your images or you use a bunch of H1 title tags because you want the font size to be bigger and things like that. Content editors need to be aware of what they're doing and its impact on accessibility. They need to know the requirements and they need to make sure that their information is. keeping the website rolling in the right direction. Check out Mediacurrent’s Go-To-Guide for Website Accessibility for more on how to do this. 

Some of the technical requirements for accessibility seem costly and complex. What are the options for an organization?

Ben Robertson: Yeah, I totally agree. Sometimes you will get an accessibility audit back and you just see a long list of things that are red and wrong. It can seem overwhelming. I think there's really a couple of things to keep in mind here is that one, you don't have to do everything all at once. You can create an accessibility statement and you can create a plan and start working through that plan. Two, it really helps to have someone with experience or an experienced team to help you go through this process. There can be things that are a very high priority that are very easy to fix and there can be things that may be a low priority.

You can also think about it this way: if you got a report from a contractor that something you're building was not up to code, you would want to fix that. And so this is kind of a similar thing. People aren't going to be injured from using your website if it's inaccessible but it's the right thing to do. It's how websites are supposed to be built if you're following the guidelines, and it's really good to help your business overall. 

How much does it cost to have and maintain an accessible site? Should I set aside budget just for this? 

Adam Kirby: You will want to set aside a budget to create an accessible site. It is an expense. You're going to have to do a little bit more for your website in order to make sure it's successful. You're going to have to make changes. How much does it cost? That will vary and depend on where you are with your site build; if it’s an existing site, if you're launching a new site, the amount of content on your site and the variability of content types. So, unfortunately, the answer is it just depends. 

If you need help with an accessibility audit, resolving some known issues on your site, or convincing your leadership to take action on website accessibility, we’re here for you.  

Webinar Slides and Additional Resources 

Aug 15 2018
Aug 15

As marketers, we understand the importance of having a system that promotes ease and efficiency when it comes to implementing marketing processes. You want to create content once and use it over and over in different ways to create contextual user experiences. 

Drupal provides you with a variety of powerful, integrated tools to not only help you understand who your visitors are and what they want to accomplish, but to also dig deeper into their interactions, engagements, and habits with your site. 

Here are just a few reasons why enterprise marketers adopt Drupal. 

1. Enormously scalable - you can’t outgrow Drupal!

Some of the biggest, most visible, and highest-trafficked sites in the world run on Drupal, including, The NBA, Johnson & Johnson, and The Weather Channel. Drupal has proven itself on enterprise websites with over 1M pages and over 20,000 requests per second. In short, you can’t “outgrow” Drupal but can continually add new content and features to your enterprise website.

2. Easily execute your content marketing strategy

A big part of a marketing strategy is content creation, so it is important that marketers are easily able to add new pieces to their website. Drupal allows marketers to quickly add blog posts, videos, and landing pages to their website by filling out a “form” with all of the relevant information and then publishing it. For example, if I want to add a post to the Mediacurrent blog, I can be in and out in less than 7 clicks. In-page editing with Drupal 8 makes the publishing process even faster.  

3. Integrate with Marketing Automation 

Every major marketing automation platform has a custom module created for easy integration into a Drupal website. How do I know? Mediacurrent developed most of them - including the Hubspot, Pardot & Silverpop module!

4. Establish an efficient workflow

A planned workflow is the underpinning of every efficient business process. Whether a business is processing leads, updating a web page, evaluating a capital purchase, or approving new hires, certain actions must take place in order for the function to be completed. Workflow involves the passing of content between people in a chain that abide by a predefined set of rules.  Drupal allows you to easily create a workflow that is customized to your company's processes and team.

5. Create dynamic digital experiences….easily

Drupal fully integrates content, community, and commerce in a single platform. If you’re staying competitive, you’ve likely made a significant investment in creating a dynamic website that really tells the story of your brand and what you have to offer. With Drupal as the backbone for your digital strategy, the options for creating personalized web experiences are endless. Drupal’s architecture makes it the ideal platform for creating and delivering segmented content. 

6. Don’t waste your marketing budget on licensing fees

As open source software, the Drupal package has no license fees, it’s free for you to download, modify, etc. Which means your marketing budget goes towards the things that make your site unique, not towards fees for a large software company.

7. Bridge the gap between IT And marketing

When building a Drupal site, the amount of coding required to maintain or build the site is up to you. A full-featured site can be built fulfilling many business requirements with point and click ease. For us “non-coding” marketers, Drupal allows us to go into each page and easily edit the content while still maintaining the consistency of our branding—without the need to know HTML or CSS.   

8. Benefit from the thriving development community

When a business chooses Drupal, a vast community of support becomes available. Whether it be Drupal’s extensive project issue queues, thousands of nationwide meet-ups and Drupalcamps, or IRC channels, the chances are the problem encountered has been faced before, documented, and has a community willing to help you solve it.

9. You’ll have search engine optimization nirvana 

Drupal gives you control over everything you need to optimize your website for search engines. That includes custom page titles, meta descriptions, URLs, copy, and it plays well with Google Analytics.

10. Security - it’s good enough for over 1 MILLION websites

When deciding on a software solution for your company's digital needs, security is often one of the top concerns. Open source software, like Drupal, has the added bonus of having thousands of talented individuals work on a particular problem. With entire teams and methodology devoted to ensuring its steadfast reputation as a secure CMS. Drupal also have an official “SWAT team” that is well-versed in online software best practices and serves as a resource for all custom module maintainers and code contributors to utilize when submitting custom projects. What passes today as secure code may not stay the same tomorrow when new vulnerabilities surface. There's peace of mind in knowing not only is your online software secure, but that it's also in an active state of safeguarding against security attacks, both past and present.

Because Drupal is not tied to a proprietary vendor’s roadmap, it’s advancing based on the work of thousands of developers around the world. Drupal organically evolves at the speed of the web, offers the cost savings and agility of the open source model, and gives you the ability to integrate content across a range of channels and campaigns.  

In the next blog of the series - we’ll hear from the Chief Marketing Officer at Acquia, about how she is leveraging Drupal 8 to achieve her business goals. 

Aug 08 2018
Aug 08

Alan Onnen is the Associate Director of Marketing for the Shirley Ryan AbilityLab. Recognized as #1 in rehabilitation for 27 years in a row. AbilityLab introduces its revolutionary care through 5 Innovation Centers - state-of-the-art hospital facilities and equipment for exceptional patient care provided by the best medical and nursing support.

With 15 years of experience in the marketing industry, the past 5 being with SRA and being a part of the team that helped adopt Drupal, Onnen has seen firsthand how Drupal 8 powers digital strategy. 

Mediacurrent Interview with Alan Onnen 

Mediacurrent: What does “digital transformation” mean for you? 

Alan Onnen: Digital transformation means a constant evolution. There’s no single transformation; it’s a constant state of change, staying on top of trends at once. As a digital marketer, you need to know a little bit about everything, UI, UX, nerdy stuff, best practices, changes in the digital environment, what people expect from websites in your vertical, etc. Some people think transformation is a binary term - something new - but it's not.

Mediacurrent: How does open source fit into the equation?

AO: Open source is something that’s not new but it’s getting so mainstream its part of that digital transformation. It’s about adjusting to the new worlds where open source doesn't mean unsecure - it means that it’s open and honest. We had to get buy-in from stakeholders. They dismissed it at the beginning of the RFP bc they thought you needed a Sitecore or an AEM. It took a long time and a lot of agency people to show how safe it is to help make them believe that open source isn’t a dirty word.

Mediacurrent: What current challenges are you trying to solve for?

AO: It is a constant struggle to keep up with Google - making sure our content is optimized for search algorithms. Our overall challenge is to keep our content fresh, navigating innovative best practices for our website while keeping up with legal and social constructs.

Mediacurrent: How are you using Drupal 8 to solve those problems? 

AO: One of the big reasons we chose Drupal was because of its customization ability. Our knowledge base is spread across so many people so Drupal’s ability to customize the backend experience and offer the fields and plain English way we need to talk about things is really important. Even just the simple need for content creators to be able to edit things and be able to customize that experience.

Another big reason was the fact that its open source and the community surrounding Drupal. If you have an idea you can find someone who has half baked or full-baked into that particular module or idea to help give your devs a headstart solution. With Drupal, you don’t have to start from scratch when you need something new to move the website forward. Chances are, someone has had a similar idea you can pull from.

Mediacurrent: Has this been your first experience with Drupal or have you worked with previous versions of Drupal in the past? What did Drupal 8 give you from a marketers/content editors perspective?

AO: I came to SRA on a proprietary healthcare based CMS. It was designed to serve mid to small hospital systems and we didn’t have access to the backend part of the site before. SRA put out an RFP for a replatforming and redesign of our website . We talked to different agencies, and Drupal kept coming up - there were no licensing fees with open source. The spin up on Drupal is more robust than most paid CMS experiences. The cost point of view is having it be free and open was very appetizing and Drupal had other features that appealed to us. 

Mediacurrent: Since launching on Drupal 8 have you noticed an increase in website conversions?  What would you attribute to that success (or lack of success)? By use of marketing automation strategies? Bc of easy integration?

AO: Drupal can be leveraged any which way you want it to be. We take advantage of the extensive list of modules. We have seen nice conversions off the YAML module & the webform module. It’s true of the module philosophy to be able to build how you want them too. 

With Drupal, our web traffic has been up. We have 3 very different facets of our site - rehab measures database, research educational platform, home site - and Drupal can support them all very well. It’s a testament to Drupal - with a flexible CMS, reporting, user interfaces, and a back end that can be robust enough to bring things together in an organic and seamless way. 

Mediacurrent: What are 3 factors you look at when evaluating an agency? Cost? Reputation? Their own web design? Logos they've sold? 

AO: With our RFP out, we began evaluating the superficial - books, examples, case studies, white papers, if their leadership had given talks and what they had talked about, the look and feel for brand consciousness, - exploring that space of ability. We didn’t want someone who was making cookie cutter websites and we didn’t want to stay looking just in the healthcare vertical. Our list was narrowed down to those whose work we respected and admired. 

In the RFP, the CMS wasn’t a consideration. We didn’t tell people which platform you needed to be on. We asked for the cost, their preferred CMS and why, and we never cared about where the agency was located. It’s important to know the the people are the agency - communication is critical. For instance, in their responses to those RFP’s are there timelines? Are they realistic? Do they make sense? It’s easy to see how much effort they did.

No one else did research like you guys [Mediacurrent] did before they got there for a face to face meeting. Your team said “oh, well we’ve already talked to discharge managers, nurses, planners.” They went through example personas, guessing on journeys, patients - and they were smart with how they handled it and took the initiative that early in the process. That showed us a lot about them. It wasn’t a giant new business budget and they didn’t ask for money up front. 

In all, the RFP process was about 4 months.

Mediacurrent: As a marketer using Drupal, what are some of the hot topics you'd like to know more about today? Personalization, marketing automation, etc.

AO: I’d like to know more about:

  • Integrations with personalization
  • Integrating with Google Analytics, tracking to AEM, adwords, & api that moves page data to backend sites
  • Marketing Automation capabilities

Mediacurrent: What advice would you give other CMO’s/VP’s/Director’s who are hesitant to move to Drupal 8?

AO: I would say it depends on what their hesitation is. You have to be committed to the build of your site. You need to be able to really understand your content creators, the users of your CMS, the scope of what they want to be doing, and understand what they could be doing on the front end. It’s important to know the ingredients - you can muck up Drupal and waste dev hours if you don’t know how the workflows to go and to know your taxonomy and pathing modules. 

Drupal requires a Digital Marketer to have a vision for what they want it to be before they start developing - or else they risk having to go back and retrofit into their CMS environment that they could have efficiently put in the first time.

The journey of CMS and Drupal needs to be a thoughtful one.

______________________________________________________

We want to extend a big THANK YOU to Alan for participating in this interview. In the next part of the blog series, we will dig into the top reasons for Drupal 8 and why enterprise marketers choose Drupal.

Aug 08 2018
Aug 08

Security maintenance — and the ability to apply security updates quickly — is part and parcel to open source project success. 

Updating is typically done as part of the normal software release cycle, however, there are times when a security advisory needs to be released ASAP. A strong incident response plan builds a first defense line to mitigate and patch vulnerabilities. 

But what does a successful security response look like in action?

On the heels of a recent Drupal security update on August 1, 2018, Mediacurrent’s Senior Project Manager Christine Flynn had the same question. To find out, she interviewed our Open Source Security Lead, Mark “shrop” Shropshire, to get a layperson’s perspective on the security team’s approach.

Christine and Shrop on a call

 

“An off-cycle Drupal security advisory dropped on August 1, 2018. What does that mean for folks who aren’t developers?”

Flynn: I was watching the Slack channel as our team fixed sites, and I got some idea of what was happening. I’m not going to jiggle anybody’s elbows while they’re applying a security update, but I’m really curious now that the fixes are all in. 

Shrop: The official Drupal Security Advisory came out late in the day, after Symphony published their announcement in the morning. There was also one from Zend.

Flynn: I read all of those links while the team was applying the security update, but I feel like I didn’t totally understand the implications. I’d love to get a better picture from you of what they mean.

Shrop: You bet! I hope you can hear me, I’m at a coffee shop right now.

Flynn: Are you on their unsecured WiFi?

Shrop: Nope! I’m on a hotspot and on VPN. It’s funny, the more you know about security, the more it changes what you do. Other people think you’re paranoid. But you’re not! You just understand the realities. 

Flynn: Ha! Why am I not surprised? All right, let’s dig in.

“What was the security update for?”

Shrop: Drupal Core was updated because there were some security releases for Symfony. We call those “upstream” in the biz, which means that Drupal depends on them, and they are actively worked on outside of Drupal. I understand the Symfony project worked closely with the Drupal Security Team to make sure Symfony and Drupal were both updated and ready to be announced publicly at the same time. Drupal version 8.5.6 pulls in the Symfony updates as part of the Drupal update process. 

Flynn: Was that the only update?

Shrop: No, at the same time, there was also an update to Zend Framework, but that was only an issue for users who were making use of modules or sites that used Zend Feed or Daictoros. There is a core issue to update the related Zend libraries for those who require or need the updates. 

“If not updated, what could a malicious user do to a site?”

Shrop: This is a hard one to answer this soon after the release of the security advisory. I’m going to do some checking to see if I can get more information on this for academic purposes, but the Drupal Security Team is not going to make any statements that could help someone attack a site. It is up to security teams and researchers to dig into the code and determine more about the risks involved.

Based on the Symfony project’s blog post, it appears that a specially crafted request could allow a user access to a URL they do not have access to, bypassing access control provided by web servers and caching mechanisms. That’s a fancy-pants way of saying that a website visitor could gain access to pages you don’t want them to see.

“When will we know more?”

Shrop: Within days - sometimes hours - we might start to see exploit methods posted on the Internet. Taking security seriously and responding quickly once a drupal.org security advisory is announced is a way to stay ahead of these concerns.

Mediacurrent doesn’t want to fearmonger, but it is better to be safe than sorry. That’s why I always push to update as soon as possible while weighing in on mitigating factors that may lessen the severity of the issue for a particular application. But I will keep digging. I’m curious! 

“If you had to tell a CEO or CFO the value that implementing this security update swiftly provided, what would you say? Let’s say this CEO does not have a strong background in technology or security.”

Flynn: I could see an executive with a strong public safety or physical security background being pretty understanding of why you want to apply a security update for a potential vulnerability quickly, but what if it’s someone who doesn’t have that experience, and isn’t a technologist?

Shrop: Check out this link from Acquia about the security update. This helped me so much. They published this shortly after the PSA came out, and although they’ve updated the text since then, they said at the time, “It is advised that customers set aside time for a core upgrade immediately following.” When I read, “immediately,” I knew that we had to get the update out within hours. If I was asked to get on a call with the executives from any company, at that point, I am confident. If Acquia is saying it, we need to do it. That’s enough to stand on with anybody. I’m not saying that the Acquia team has more information, but they have a very robust security team. They always dig in quickly. They have to, to know if they can mitigate the issue by adding web application firewall rules.

Flynn: Firewall rules? How does that work? 

Shrop: The last few core updates, Pantheon and Acquia put mitigations into their WAF - that’s Web Application Firewall. Pantheon confirmed the night of the security advisory release that they were blocking attempts on their platform, and Acquia did the same thing. So if someone tried to exploit a site that was hosted there before Drupal was updated, they were there, helping to prevent that site from being attacked successfully. It’s a great extra layer of protection. Now, me and Acquia and Pantheon will always still want to update Core on each site, because WAF-level mitigation might not catch everything. But I am super happy when I see it because there’s a good chance that it will catch anything that happens while a team is still implementing a security update.

Security is all risk assessment and mitigation. You want to layer defenses. And something like this, we are going to make sure we deal with this problem. That’s why Acquia, Pantheon, Platform.sh, and others in the community immediately add those extra mitigations to their firewalls. It’s to buy time so that people can get their updates in. That’s not where mitigation ends, but it helps. 

“What type of sites were affected by this? Does everyone use Symfony?”

Flynn: When I first read about the upcoming security advisory, I saw that it affected “third party libraries.” That made me think that some of our clients might not be affected because it would only affect certain modules. Can you tell me what types of sites were affected?

Shrop: Got a link for you, but basically, anything on Drupal 8 was affected. Drupal 8 uses components from the Symfony project. The Drupal community made the decision to use Symfony so that we didn’t have to maintain everything ourselves. So this is a great example of the power of open source, with the Symfony and Drupal security teams working together to release this fix. We all end up benefiting from having a larger community to fix issues. There’s no way an internal team working by themselves can write as secure applications on their own compared to open source software, in my opinion. It has nothing to do with how good you are, it’s the nature of development. With open source, you have a greater team with Drupal and then again, with Symfony, an even greater team to lean on. With each community that is included you are expanding your team and your ability to detect and prevent threats. 

“How was the security vulnerability discovered?”

Shrop: That’s generally never disclosed because you never want to tell malicious users how you found an opening. 

But we do have a few people to thank: Michael Cullum and @chaosversum were thanked by Symfony for separately reporting the two issues addressed in Symfony security releases. They also thanked Nicolas Grekas for implementing the fix. I would also give a huge thanks to Symfony and the Drupal Security Team for coming together to implement the fix and for coordinating the announcements. It’s hard work, and it shows the community at its best.

“So when we have an off-cycle security release, first the PSA comes out. Can you tell me a bit about what Mediacurrent does from the time the PSA comes out to just before the security advisory drops?”

Flynn: As someone on the team at Mediacurrent, I can see some of the things you do. But I’m wondering what else happens behind the scenes? 

Shrop: The first thing that happens is that I’m notified about the PSA coming out. I’m signed up for updates via email, Twitter, and RSS feeds from https://www.drupal.org/security, and so are a lot of other folks at Mediacurrent. Internally, we have some processes that we have standardized over time for how to deal with security updates that we follow across the company. We centralize information we have on the security PSA/advisory, recommend client communications, and talk about how to prepare as a team. We have multiple communication threads internally, as well, so no one can miss it. I send an email to the staff and I post in our Slack in a few places to get us ready.

Flynn: I know that we often clear time in advance for the team to implement the security updates.

Shrop: Yep. All of us share more information as a team as official information is released or as our own investigations reveal information. For example, early on the day the security advisory was released, our DevOps Lead, Joe Stewart, noticed that Symfony had put out a notice that they were also going to be releasing a security update that day, so that gave us a heads up that it might be related. We couldn’t know for sure until the security advisory actually came out, though. No one can do it by themselves, which is why we have a whole team working on it - it’s the only way to handle these things. ​​​​​​

Christine and Shrop on another call

“So then the security advisory drops. How did we go about fixing the issue?” 

Shrop: First, we reviewed the advisory to assess risk and for any mitigations that help determine how quickly we need to perform updates. With this advisory, it was needed pretty much immediately, so we started to update Drupal core for our clients and pushed to test environments. Our QA team performed regression testing related to the update. Once QA approved each update for each client, we worked with folks to approve the updates and release them to the live environments. 

The important points are to line everyone and everything up in advance, have the talent in-house who can work on clients of all shapes and sizes and needs, and then to work as a team to resolve the issue on every client site as quickly as possible. 

“Were there any sites that were trickier to update? Why?”

Shrop: Clients that were on older versions of Drupal Core, who had delayed upgrading, were harder to update. Every site was updated within a short time, regardless, but even though they started at the same time, those clients did not finish first, because there was more development and testing needed on each site.

Flynn: What was different about the process to update those sites? 

Shrop: If a client wasn’t on version 8.5.x, the lead technologist on the project had to work on an alternative update to secure the site or application, since there wasn’t a security update released for it. Figuring out an alternative process on the fly always introduces risk. It’s part of the value that we bring, that we have team members that have the expertise to evaluate that sort of thing. For example, we had one new client that was on an older version of Drupal 8 core. So one of our Senior Drupal Developers, Ryan Gibson, had to go in and determine what to do. He ended up updating Symfony itself to mitigate the risk. 

Flynn: I’m guessing that we are going to recommend to that client that we update Drupal core for them very soon?

Shrop: Yes. The big takeaway is you’re lowering your risk of problems by staying on the most recent, up-to-date minor version of Drupal 8. Version 8.5.x is current and stable right now, so you should be on that.

Flynn: Why would a client not update?

Shrop: There are always dynamics. I hear lots of good excuses, and I’m not exaggerating, they are good, real reasons! The client is busy, the client has multiple workstreams, it’s hard - but it is getting to a point where I want to recommend even more strongly to clients that it is more expensive to not upgrade. It is going to cost them more when there is an update because we have these additional evaluation and update tasks. The whole point of Drupal 8’s release cycle is to spread the maintenance cost over years rather than getting hit all at once. 

Flynn: And it introduces greater risk. A security breach is an order of magnitude more expensive than extra mitigation steps.

Shrop: Definitely.

“When is the next version of Drupal Core coming out?”

Shrop: Version 8.6.0 will be released in September. Our teams are already starting to test the early versions of this release on some of our projects. If a security update comes out in September, we want all of our clients to be prepared by being on the currently supported version of Drupal core. That way, they will receive security updates.

Flynn: One of the nice things about the Drupal development community is that they provide the betas of the next version of Drupal core so you can get ahead of the next release, right?

Shrop: Yes. When the community starts releasing betas or release candidates, especially release candidates, you want to start testing ahead of time. If you have a Drupal site, you can get your developers to test. If you find a problem, it may not be with your site, it might be an issue with Drupal core and this is a great opportunity to contribute your findings back to drupal.org and help the greater community. There might be a security release weeks after a version comes out and you want to be prepared to implement it.

Flynn: It goes back to risk mitigation.

Shrop: If you are on, say, an 8.2 site right now, you’re on the higher risk side, unfortunately. We advise our clients that it is in their best interest to be on the current, stable version. It costs our clients more in the long run if they don’t update on a steady basis.

Flynn: So if you’re on an older version of Drupal Core, you might not get an easy-to-implement security update when a vulnerability is discovered?

Shrop: The quotes from the Drupal Security team I really want to emphasize are, “Previous minor releases will become unsupported when a new minor release is published,” and, “Any additional security updates for officially unsupported branches are at the sole discretion of the security team.” This is important to understand. For the SA Core 2018-002 fix earlier this year they provided release updates for older versions of Drupal… but they didn’t have to. In the case of the fix last week, they did not.

“What was the best gif exchange of the Drupal core security update process?”

Flynn: I nominate this one, from mid-afternoon:

Slack Gif Example

Shrop: Definitely! 

“What story didn’t we tell yet?”

Shrop: I think we covered most of it. The last thing I’d put out there is for the technical folks reading this. You need to read the security advisories, join Drupal Slack, read what Acquia, Pantheon, and others are saying about each announcement. Then, you take all of that in and make your assessment of what actions you are going to recommend your organization take. This should lead your organization to a documented security plan that you follow. But, you know… 

Flynn: “Update all the things”?

Shrop: Exactly!

Other Resources
7 Ways to Evaluate the Security and Stability of Drupal Contrib Modules | Mediacurrent Pantheon Guest Blog 
Security by Design: An Introduction to Drupal Security | Mediacurrent Webinar

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web