Dec 06 2019
Dec 06

Mark brings a fifteen year programming background and six years of Drupal experience to his role as Senior Drupal Developer at Mediacurrent. Highly involved in his local web community, Mark runs the ABQ Webgeeks Group and started the Albuquerque Drupal Users group.

A former radio personality, Mark switched careers to become a programmer when he realized he could have a fun job and eat. (No seriously, kids, radio pays horribly). But as a nod to his days as in radio, Mark hosts the bi-weekly Mediacurrent Dropcast show and the Friday 5 video seriesPrior to Mediacurrent, Mark first dove into Drupal to convert dreamincode.net to a better CMS than it had. Through that he was sent to Do It With Drupal in New Orleans, where he met the great people of the community. From that point, he was hooked. 

Mark resides in Albuquerque, New Mexico. When not in front of the computer, he enjoys playing hockey, tennis, and a good craft beer- not necessarily in that order.

Nov 08 2019
Nov 08

If you are a frontend web developer you have probably heard of GraphQL or maybe you have even used it, but what is it? GraphQL is a query language for APIs that allows you to write queries that define the data you receive. No more emailing the backend team to update an endpoint for your application. The client developer defines the data returned in the request.

What is a GraphQL Server/API?

A GraphQL server is a server-side implementation of the GraphQL spec. In other words, a GraphQL server exposes your data as a GraphQL API that your client applications can query for data. These clients could be a single page application, a CMS like Drupal, a mobile app, or almost anything. For example, say you have a MySQL database and you want to expose the content to a React application. You could create a GraphQL server that will allow our React application to query the database indirectly through the GraphQL server.

Why would you consider a GraphQL API?

1. You need an API for your applications

At Mediacurrent, we have been building decoupled static web sites using GatsbyJS. But sometimes we also need some components with dynamic data. You need an API for that and our front-end team was already using GraphQL in Gatsby. Or maybe you might develop a mobile app and need a reliable and fast way to get data from your legacy database. You can use GraphQL to expose only the data you need for your new app but at the same time give your client app developers the ability to control what data they get back from the API.

2. You need data normalization

For our purposes as developers data normalization is simply the process of structuring our data to remove redundancy and create relationships between our data. Data normalization is something database designers think about but developers and software architects should consider as well.

One of the biggest mistakes I’ve seen in my years building web applications is the pattern of including too much business logic in application components. These days, it is not unusual to require data from multiple applications, public REST APIs as well as databases. There is often duplication across these systems and the relationships are rarely clear to the development team. Creating components that require data from multiple systems can be a challenging task. Not only do you have to make multiple queries to retrieve the data, but you also need to combine it in your component. It’s a good pattern to normalize the data outside of your components so that your client application’s components can be as simple and easy to maintain as possible. This is an area where GraphQL shines. You define your data’s types and the relationships between your data in a schema. This is what allows your client applications to query data from multiple data sources in a single request.

3. You love your client application developers

A well-built GraphQL server will avoid these issues that are common with REST APIs.

  • Over-fetching - receiving more data than you need.
  • Under-fetching - not receiving all the data you need.
  • Dependent requests - requiring a series of requests to get the data you need.
  • Multiple round trips - needing to wait for multiple requests to resolve before you can continue.

Over-fetching

In a perfect would we would only fetch the data we need. If you have ever worked with a REST API you will likely know what I mean here. Your client application developers may only need a user’s name but it is likely that when they request the name using the REST endpoint they will get much more data back from the API. GraphQL allows the client to specify the data returned in the request. This means a smaller payload delivered over the web which will only help your app be more performant.

Under-fetching, dependent requests, and multiple round trips

Multiple requests with GraphQL

Another scenario is under-fetching. If you need a user’s name and the last three projects they were active on, you probably need to make two HTTP requests to your REST API. With GraphQL relationships, you can get this data back in a single request. No more callbacks and waiting on multiple endpoints to resolve. Get all your data in one request. Now you are avoiding multiple requests, dependent requests, and multiple round trips to get the data for your app’s components.

GraphQL single request to multiple data sources.

Self documenting

The type based schema that GraphQL provides creates the structure to build powerful tools like Graphiql, an in-browser IDE for exploring GraphQL.

Graphiql example

This schema also allows for what I would call a self documenting API. GraphQL playground is an example of the power of the GraphQL schema. It takes this schema and creates documentation as well as an IDE like Graphiql. When you update your schema, your documentation is automatically updated as well as the IDE. That’s a huge win!

GraphQL Playground example
GraphQL Playground example docs

You can try out a demo of the GraphQL Playground on graphqlbin.com.

4. GraphQL can replace your legacy REST API

It can be challenging to maintain versions of a REST API. Requirements change. You need to add new fields or maybe you want to delete fields from your database. Due to the requirements for backward compatibility your API has to continue supporting these old requirements. Maybe you have an old Android mobile app that relies on your REST endpoints. Maybe you have a Salesforce integration that you don’t have time to update. Most organizations can’t update all their applications at once so you can’t just turn off your old REST API. A GraphQL server can act as a middleware between your old REST API and your new applications. Then as you update your other client apps that use the REST API’s you can update them to work with your new GraphQL API. Once all of your clients are no longer using the REST endpoints you can replace the REST API fully with the GraphQL API.

5. You’re tired of maintaining old versions of your REST API

GraphQL has the @deprecated annotation that you can add to your schema to let clients know that a field should no longer be used. This is much easier to maintain than multiple versions of a REST API.

Which server should you use?

Check out GraphQL.org’s list of servers. There are projects in C# / .NET, Clojure, Elixir, Erlang, Go, Groovy, Java, JavaScript, PHP, Python, Scala, and even Ruby. My choice is the Apollo Server project. It has great documentation and provides a self documenting API for your team that is enjoyable to use. If you use Drupal there is the Graphql module that adds a GraphQL API to your site.

I hope I’ve sparked your interest in GraphQL and building a GraphQL server API. At Mediacurrent, we have seen how powerful this tool can be for solving complex application and data problems and we’d love to talk with you about it. Hit us up in the comments.

Oct 24 2019
Oct 24

Acquia Engage banner with image of New Orleans street

This year’s annual Acquia Engage US conference is coming to New Orleans in November. The event brings together hundreds of business and technology leaders across the Acquia community to tackle today’s top digital challenges.

Engage is a mainstay on our calendar—we’ve returned to participate and sponsor every year since 2015, and can’t wait to be back.

Acquia Engage is a unique conference opportunity to connect with digital leaders. It has always been a must-attend...It's a fun, informative, and collaborative forum to share ideas and best practices...

Press release quote from Mediacurrent co-founder Dave Terry

 Here are a few upcomig highlights for this year’s event:

Our Team of Drupal Rockstars Are Attending

We have a diverse team of Mediacurrent team members attending, so drop by our booth with your most pressing digital strategy and Drupal questions. This team has launched dozens of enterprise Drupal 8 projects using the most advanced Drupal 8 architecture and distributions (Lift, Site Factory, decoupled, and more). 

Lately, we’ve been focused on gearing up for Drupal 9 with our Rain install profile, increasing conversion rates with Lift as a personalization tool, and decoupling Drupal with Gatsby.

headshots of Mediacurrent team attending Acquia Engage 2019

Dave Terry - Partner, Client Services
Josh Linard - VP of Sales
Jay Callicott - VP of Technical Operations
Kevin Basarab - VP of Delivery 

Acquia Engage Award Winners 

We’re honored to have won in two categories for the 2019 Acquia Engage Awards.  These awards recognize the amazing sites and digital experiences that leading digital agencies are building with the Acquia Platform. Winners will be announced during the event.

  • Best Return on Investment: CAS, a Division of the American Chemical Society and Mediacurrent partnered to launch a new Drupal 8 platform with responsive design and significant improvements to site speed and layout—all within a tight launch timeline.  
  • Open Source Giants: The Rain install profile was created by Mediacurrent to add out-of-the-box editorial, administrative and media enhancements to the core Drupal 8 installation. Modeled after distributions 'Acquia Lightning' and 'Thunder', the Rain profile packages and pre-configures many core and contributed modules to make building Drupal websites faster and easier. Best of all, it’s free and open source.

Lift Personalization Partners

We’ve expanded our long-time partnership with Acquia by becoming an official Lift implementation partner. Our team and clients are loving the latest release of Acquia Lift that puts website personalization directly into the hands of marketers (no coding needed). If you’re evaluating Lift for your business or looking to ramp up your personalization strategy in 2020, we can help.  

Connect with Us 

Stop by our booth and pick up a t-shirt and tell us what you love about Acquia Engage. 

Will you be at Engage 2019? Book a meeting with our team or message us on the Acquia Engage app!

Oct 22 2019
Oct 22

This episode, we welcome AmyJune Hineline from Kanopi Studios to talk about the importance of open source to the community and organizations. AmyJune is the Open Source community ambassador for Kanopi. She helps keep her team connected to open source communities.  Along with working in the WordPress and Drupal communities, AmyJune also co-organizes A11yTalks, a monthly online meetup where they promote community discussions on a variety of accessibility issues. You can find her at just about every Drupal camp or con, where she will coax you into buying a beer-like drink. 

Audio Download Link

Project Pick:

Interview

  1. Tell us about yourself and about your role as an Open Source Community Ambassador?
  2. How did you get started with the Open Source Community?
  3. What would you say is the biggest benefit for an agency to contribute back to the community?
  4. Why should an organization/company using Drupal invest in giving back to the community?
  5. A lot of people think contributing back means creating a new module or a new theme.  Although those are certainly ways to contribute back, what are other ways in which an organization using Drupal or Wordpress can contribute back?
  6. What would be your advice to an organization who is interested in contributing back to the community?  What is the process like or what steps should they take?
  7. How can an agency like yours or ours motivate or encourage clients to contribute back?
  8. What kind of resources are available for an organization to get started with contributing back?
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 git@bitbucket.org: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.