May 13 2019
May 13

Drupal 7 was officially released in 2011, making it quite old in web years, though it still powers hundreds of thousands of websites worldwide.

Drupal 8 was released in 2015, but the path to upgrading has never been an easy one for Drupal websites (prior to 8). So our recommendation for most Drupal 7 site owners has been to wait– wait until you have the time, budget and other resources needed to do a full redesign and migration to Drupal 8.

But Drupal 7 isn’t going to last forever.

It’s official end of life has already been decided–November, 2021. A full ten years after its original release, Drupal 7 will no longer be officially supported. What this means is no more security patches or bug fixes.

It won’t just stop working, but without official support, Drupal 7 sites will become vulnerable to crashes, hacks and other vulnerabilities. There are private companies who will continue to support Drupal 7 sites after 2021 in exchange for a support contract. But officially, it will be unsupported and after 10 years of service, most sites could benefit greatly from a more modern CMS.

But when is the best time to upgrade? What will it take? What are potential problems, or gains? And why should you continue using Drupal in the future? Let’s break down these questions one by one.

When is the best time to upgrade?

In our opinion, the best time to upgrade is the next time you fully redesign your website. While smaller, ongoing updates and improvement are critical to maintaining a vital and effective website, at some point site owners should look at conducting a full redesign.

The general recommendation is for organizations to conduct a full redesign every 2-5 years, depending on your resources, audience, content, and budget. While there’s no one-size-fits-all, anyone still running the same website after 5 years is risking their ability to stay relevant.

So much may have changed since you last redesigned–user expectations, the way people access the web, how you reach your audience. It is worth revisiting your overall strategy. Certainly the way a site is produced in Drupal 8 is also different than Drupal 7. Only focusing on a version upgrade may be a lost opportunity to take advantage of all the new features Drupal 8 has to offer.

What if I just redesigned, or don’t have the budget for a full redesign?

If you aren’t interested in a full redesign, or unable to consider that option, you have a few options. The first, as stated earlier, is to wait. Start budgeting for a redesign and version upgrade today, knowing you still have at least 2 years before you have to make your move.

The second option is to keep your current site as close to the same as possible, but upgrade to Drupal 8. I would love to tell you exactly what this will take. But like many things in life, it just depends.

The lowest cost scenario for an upgrade is a very simple Drupal 7 website, one that relies on minimal content types with few fields, very few contributed (non-core) modules, and nothing in the way of custom modules or templates. It our experience, however, this isn’t a very common scenario for all but the most basic of websites. The more complex sites depend on an array of custom and contributed modules and custom templates which make upgrading a more… nuanced experience.

Drupal 8 does have a great suite of Migrate modules in core that an experienced developer can use for when updating a site from Drupal 7 to 8 (or migrating from other content management systems). There are, unfortunately, quite a few areas where a versions upgrade runs into trouble, however.

Why can’t I just easily upgrade from Drupal 7 to 8?

As great as Drupal is, its Achilles heel has been version upgrades. They've been historically difficult and time consuming. The good news is, from Drupal 8 to 9 and beyond, this has been addressed and fixed! But if you’re in Drupal 7,  the upgrade path is still a hard one.

There is a good reason for this, of course. With Drupal 8, the entire system was rearchitected. Unlike an upgrade from WordPress 4 to 5, for example, where the overall system remained the same, Drupal 8 changed everything. It introduced the use of Symphony, Composer, Twig templating and a greater reliance on object-oriented programming (OOP).

Extremely popular modules like Views became part of Core, which is great moving forward, but (as of now) requires users to completely rebuild any Views used on their Drupal 7 sites for Drupal 8. Themes in Drupal 7 relied on PHP Template Engine but now use the more modern Twig language for templating.

Popular methods of staging sites via the Features module were replaced by new techniques such as Configuration Management. Photos and videos are now "entities" managed by the Media module, which itself is part of the core install. These were all extremely valuable improvements, but at the cost of making version upgrades difficult.

So what does it cost?

If you’re able to follow our original recommendation, and upgrade to Drupal 8 as part of an overall redesign, the cost is wide-open and not really dependent on the software upgrade. While some or all of your content might be migrated, and modules replaced with the latest versions, often times it’s faster and easier to recreate the entire site from scratch.

This approach, however, means budgeting a lot more than you might have planned for a ‘simple software update.’ Instead you budget for a full redesign and all the work that entails.

Whether you are pursuing a full redesign, or “simply” a version upgrade, the first step in estimating the cost is to conduct a site audit. Using spreadsheets or documents, start collecting data on all of your site content, asking questions such as:

  • How many content types do you have? What fields are in use?
  • How many users and user roles do you have?
  • How many Views are in use? These will need to be recreated by hand
  • How are you going to map existing URLs to content on Drupal 8? What redirects are in place?
  • How many site menus do you use? Menus will need to be recreated
  • What theme are you using? Whether it’s custom or not, it will have to be rebuilt
  • How many blocks do you have, and where are they used?
  • Are you using Field Collections? These will need to be replaced
  • How much Media do you use (images, video, etc.)? These will need to be mapped to entities
  • What contributed modules do you use? Is there a corresponding Drupal 8 version, and if so, does it offer an upgrade path?

Planning for a version upgrade requires a close look at everything your site does, all the users and content, and identifying all the series of steps required to not lose functionality, content, or search engine placement.

TLDR; the cost depends on the size and complexity of your existing site. Plan on 70-100 hours of work at the low end, to well over 200 hours for more elaborate sites.

Why should I bother with Drupal 8?

Considering all the complications and expense with upgrading to Drupal 8, a natural reaction might be to not bother at all. Why not move your site to WordPress, for example? There are, however, more than a few important reasons to consider staying with Drupal.

Drupal 8 is so much better

We’ve talked about how the rearchitected Drupal 8 made version upgrades difficult. But you can’t do that without also talking about much was gained in Drupal 8.

  • More in Core – Views, Media, WYSIWYG, Layout Builder and more
  • Improved Editorial Experience – CKEditor, drag and drop, inline editing
  • Improved Media Management – including new Media library tools
  • Accessibility improvements
  • HTML 5
  • Mobile first and responsive
  • Data integrations – API-first platform with RESTful services and JSON:API in core
  • Configuration Management – easier and faster for developers
  • Improved multilingual support for over 100 languages
  • Security and performance improvements

Future updates are so much easier

Even though the Drupal 7 to 8 process can be long and cumbersome, the future is bright! Drupal 8 was designed for ease of version upgrades. It relies on a new release cycle and semantic versioning for more predictable update schedule. Minor releases come out every 6 months (e.g. 8.6 to 8.7) allowing every site owner to keep their site up to date.

Even better, each minor release contains new and sought-after features, meaning you don't have to wait years between release cycles. Patches and bug fixes get released as needed, until the next stable release of Drupal comes out. Updating to Drupal 9.0 won’t be any different than updating from 8.6 to 8.7!

Even now, every Drupal 8 module is being tested for compatibility with Drupal 9, and the great news is that many of them are already there. As long as you’re keeping your Drupal 8 site up to date, the next full version upgrade should be a piece of cake.

Drupal is ready for the future

Thanks to Drupal’s API first initiative, Drupal 8 (and beyond) is positioned as a powerful platform that makes it easy to integrate with other systems. This includes the increasingly common need for tight integration with existing applications and tools, plus the ability to use and display your content any where you like.

Drupal can now be easily used to power mobile applications, digital signage, voice controlled skills, the Internet of Things (IoT) or as an API that other applications can communicate with directly. The world is quickly moving in this direction, and Drupal 8 is ready for it now.

Familiar with the software

In addition to gaining all the features mentioned prior, it’s worth putting in a plug for the advantage of familiarity. As much as things have changed, there is still a core experience that you will find the same. Content types still power how your content gets entered, Views still drive your database queries, Users can still be managed through powerful Roles and Permissions. Blocks are still a key element of building out your pages.

If you’ve built up years of experience and know-how working with Drupal 7, why throw that all away? Get to know the new features which will improve your site experience, while taking advantage of all that historical knowledge.

And most importantly, the community that makes Drupal so great is still here. That means all the help and knowledge sharing you found on, the online tutorials and articles throughout the web, the agencies and developers who worked with you before, and conferences and meet-ups dedicated to Drupal–we’re all here to help you move to Drupal 8!

Worried about the future of your Drupal 7 site? Thinking about an upgrade? We can help you audit your current build and identify what’s possible. Contact us for a conversation about your upgrade.

Apr 30 2019
Apr 30

In 2018, the state of California passed the California Consumer Privacy Act, or CCPA, as a consumer-rights focused bill to protect user privacy. Similar to the GDPR, the new law would require businesses to be upfront about what data they are collecting, who they are sharing it with, and allow consumers to request their data be deleted.

This changes the equation significantly for US-based organizations. You may be fairly certain your site’s visitors are US-based, but what about the state they live in? What if they are from California? Similar to other laws originating in California, the mere presence of a law like this begins to affect how all the states treat issues of privacy.

As recent as April 2019, lawmakers were pushing several news bills to reign in some of those protections, on behalf of employers and businesses who found the new law too broad. The tech industry is somewhat discouragingly behind a lot of the lobbying as well. The original law was set to take effect by 2020, but some of the details are still being debated.

It seems certain, however, that some form of the law will be implemented soon. And much like the EU and GDPR, the first step as site owners will be more transparency on data collection, and making it easy for users to opt-out, or request their personal information be deleted. Listing your privacy policy is also a requirement.

The CCPA doesn’t appear to apply to everyone, however. It is targeted towards businesses with annual gross revenues over $25 million, and/or companies whose annual revenue primarily comes from selling users personal information. And unlike the GDPR, it is more of an “opt-out” law than “opt-in.” Websites don’t have to ask before applying a cookie, and businesses don’t have to ask before selling personal information. They do, however, need to offer an easy method to opt-out.

Apr 03 2019
Apr 03

Electric Citizen is heading to DrupalCon Seattle next week! We're pleased to sponsor again this year, and send several members of the team to represent.

Look for us in the exhibit hall in booth #209, where we'll be sharing some cool EC swag, and looking to make new friends and connections in the Drupal community. This year we'll have some awesome knit hats, handmade in Minnesota, as well as some other goodies.

Keep an eye out for Citizen Dan, Citizen Tim, Citizen Aundrea (DrupalCon newbie!) and Citizen Adam, as we make our way through another DrupalCon.

What We're Looking Forward To

The sessions schedule seems especially dense this year, with one less day available than previous years. But we've got a handful of items already flagged. 

Citizen Dan
I'll be running out, trying to catch as much as possible while also helping out at the booth, but some items on my list:

Citizen Aundrea
When I'm not working the booth, I'd like to catch a few sessions.

Citizen Adam
I always look forward to learning about how others are approaching the challenges the we all face when building beautiful, accessible and performant Drupal sites. This year I'm especially looking forward to:

Citizen Tim
As with most DrupalCon visits I try to focus on where Drupal is going, and not necessarily where it has been. Here are few forward looking sessions I'm anticipating:

Mar 28 2019
Mar 28

Thursday began with a keynote from Fatima Sarah Khalid, sharing her personal experiences as a Muslim in a post-9/11 world, and offering insight on how we all might improve our understanding of diversity and inclusion.

As a member of the Drupal Diversity & Inclusion working group, it was warm and insightful personal story that had implications on how we interact with each other and what privileges some of us might take for granted.

From there, things divided up into several tracks of sessions, starting Thursday and continuing to end-of-day Friday. Content from all of these sessions is available online, simply by visiting each session page, or the Midcamp YouTube channel.

The evenings were filled with some great socializing at neighborhood bars, one fantastic game night on campus, and of course, several nights of Drupal Karaoke!

Jan 29 2019
Jan 29

We're in the deep of winter in Minneapolis, but thinking about spring and the upcoming conferences we'll be attending. Or at least later this winter.

Here's a short list of what we've got scheduled so far, and where we could meet up. Hope to see you out there!

Jun 13 2018
Jun 13

In the Twin Cities of Minneapolis and St.Paul, we are proud of our Drupal camp and this past weekend we hosted the ninth annual.  This established and well-attended event attracts the majority of local Drupalistas, some out-of-towners, and the odd Drupal luminary or two.

For many, it is the most anticipated Drupal event of the year, and like any Drupal camp it is a joint effort of dedicated individuals coming together to deliver something useful for the wider community.  If you have ever helped organize such an event you’ll know that it takes a great deal of time, coordination and old-fashioned hard graft to make it happen.  Kudos to everyone who organized, volunteered, attended, sponsored, shared knowledge, BOFed, socialized, networked or participated in any way. Thank you all!

There are many components of a successful camp, but having good sessions is essential.  Nearly 40 sessions were offered this year with true diversity of topics and delivery styles; ranging from introductory talks to more technical, and from entertaining and fun to inspiring and thought-provoking.  At Electric Citizen we were very pleased to have four sessions approved, and these were recorded for anyone to watch.  See below.

Apr 17 2018
Apr 17

DrupalCon Nashville is in the history books and it was a doozy. The whole team was able to attend a stellar week of learning, sharing our hard-earned knowledge, and networking–interspersed with plenty of fun social events.

Seasoned Drupalers know that DrupalCon is a lot more than a tech conference. It is the community event of the year; a place to meet old friends and new, a celebration, and a barometer of the health of the Drupal platform itself–something we are collectively invested in. Attendees converged from far and wide to be part of it, to contribute, to engage, to learn and share, and to support our chosen technology.

As attendees, sponsors and presenters, Electric Citizen was fully in the mix this year. Read more in this blog post, or on our Twitter, LinkedIn and Facebook channels.

Apr 17 2018
Apr 17

DrupalCon Nashville is in the history books and it was a doozy. The whole team was able to attend a stellar week of learning, sharing our hard-earned knowledge, and networking–interspersed with plenty of fun social events.

Seasoned Drupalers know that DrupalCon is a lot more than a tech conference. It is the community event of the year; a place to meet old friends and new, a celebration, and a barometer of the health of the Drupal platform itself–something we are collectively invested in. Attendees converged from far and wide to be part of it, to contribute, to engage, to learn and share, and to support our chosen technology.

As attendees, sponsors and presenters, Electric Citizen was fully in the mix this year. Read more in this blog post, or on our Twitter, LinkedIn and Facebook channels.

Mar 23 2018
Mar 23

If you have never been to a DrupalCon, make this year the one! This is a year of firsts for Electric Citizen.

  • First year as a Supporting Partner of the Drupal Association
  • First year as a sponsor and exhibitor at DrupalCon North America
  • First year to be featuring 2 speakers at DrupalCon!

DrupalCon is the premier Drupal conference of the year in North America and the most widely attended Drupal event in the world. Six of our Citizens will be there, and we encourage you, colleagues, friends and client partners to join us. Look for us in our green EC workshirts!

Mar 08 2018
Mar 08

Drupal 8 is the latest and greatest version of the popular content management system (CMS), powering everything from hobbyist websites of every stripe to Fashion, Finance, Sports and University sites like,, donor site for the University of Colorado and Sevilla Football Club

There are many reasons to upgrade to Drupal 8, both from earlier versions and sometimes from different content management systems altogether. The upgrade offers lots of benefits across the stakeholder universe. It’s quicker to set up for developers and site builders, vastly better for content editors for authoring, editing and management, and all improvements ultimately benefit site visitors who get a better user experience. 

Here is a short list of improvements and reasons why you might consider using Drupal 8 for your next web project, and you will discover many more as you delve deeper into this significant update:

Dec 22 2017
Dec 22

The core Drupal 8 software contains some SEO-friendly features ready to go, and some that require enabling and configuration. Additionally, there are other contributed modules that can be downloaded. The SEO Checklist module has a list of modules that it recommends. Together, these modules will address on-page SEO requirements involving data that search engines track on websites, including:

  • Title Tags
  • Meta-descriptions
  • Paths
  • proper use of subheads
  • keyword use
  • XML sitemaps

Sign up for Google Analytics, together with Google Search Console, and follow directions to connect them to your website. These are free tools provided by Google and work together to provide invaluable data on your website traffic, content, keyword usage, sales and conversion data, and much more; all with the ability to generate useful reports that you can share and use to make business decisions. Webmaster Tools are also available for BingYandex (Russia) and Baidu (China) depending on your need. Certain Drupal 8 modules will require you to have at least Google Analytics installed. This is a good primary step before installing modules.

The Metatag module is very important as it helps search engines find key info they are looking for on a page like the title tag and meta description for the page itself. By filling out meta tags as you go through your content creation workflow you allow the module to place this info in the header of the web page where it is expected to be.

One of the Drupal 8 modules that automates a very cumbersome task is the Redirect module, which create 301 redirects--essentially telling Google that your content has moved if you take existing content and place it in a new URL. That way you still retain any SEO juice that the content had already earned.

The Pathauto module also add convenience, as it automatically creates SEO-friendly URLs when you create content. However, in my experience, you should take a look at each URL and, sometimes, you'll need to fine-tune them by hand to make them look better on search results, and make them more click-worthy.

Because websites typically evolve over time with changes to content, new pages, deletion of old pages and so on, it means that search engines are playing a constant game of catch-up, so in order to keep things current, the Simple XML Sitemap module ( This module aims to be a replacement for the XML Sitemap module for Drupal 8) updates itself as changes are made, so that search engines can always get the latest version of your website to index.

Additional Tips to Elevate Your SEO

Run some diagnostics to understand what visitors are searching for internally on your site This is a great tactic to discover what your users are searching for and give you an indication if there is a content gap between what they want and what they find. This can be a real opportunity to develop fresh content, optimized for those searchers. And, amazingly, you can use this principle to constantly revise and refine your content to climb up the search rankings. The take-a-way here is that once content is created on your website do not let it stagnate. Search engines will revisit and catalog your site periodically. You can speed up this process by making changes and then re-submitting the page individually to Google or Bing to re-index.

For those of you who wish to operate on the cutting edge, look to tools like the Google AMP module to convert pages to the AMP standard, which optimizes for mobile. Also, explore what Resource Description Framework RDF UI module does to integrate and the effort to provide richer search results.

Finally, be aware that SEO is achieved by degrees, and that there is always room for improvement. If, as they claim, the underlying goal of search engines to find the best information and the best user experiences, we all need to look at our websites holistically, which also means looking at every factor that could impact the visitor, including the speed and performance of the site, security and how well the site plays for mobile devices.

Dec 14 2017
Dec 14

Drupal 7 views were about the best thing ever and, thankfully, they’ve been included in Drupal 8 core. Strangely though, we find ourselves using less and less of them in Drupal 8 because of the ease and power of Twig.

We did notice that views are by far the most difficult thing to customize through Twig that we’ve found in D8. It's difficult to bring in content from one views field into another in a views field twig template—although it can be done with Twig in the Views UI rewrite. If we need to customize multiple fields on a view, we usually find ourselves rewriting the views display views-views-unformatted--myview--mydisplay.html.twig template—which can be an overkill if we are only customizing a couple of fields on the view.

We recently found that Views UI rewriting and the global custom text field stripped the audio formatting of a field we needed to group into a custom HTML structure with a couple of other fields. Our only choice was to render the field with the audio formatter and write the HTML needed around it and the other fields in the view display template itself. 

We looped through the rows and found the row.content[‘#view’].style_plugin.render_tokens[ loop.index0 ] to get the field output. That gave the custom display template the rendered output of each field in the view—basically creating exactly what the view outputs without the views-field div wrappers. We could then print the rendered fields in the template in any order and with any HTML structure needed and the necessary rendered formatting.

If empty with views custom templates and Twig debugging

In the example above, we have some fields that we know are going to be constantly populated and some that aren’t. Since we’re writing custom HTML around the view fields, we need to use Twig’s {% if %} functionality to make sure that HTML is printed only when there is content to fill it.  Normally it is very easy in Twig to write an if statement to include things if there is content to fill them. With views templates however, things we're not quite so easy. We tried hiding the rewriting on the field in Views UI. We tried hide if empty in the Views UI. We tried creating a views field template for that field and using a Twig if statement there to see if a lower level hierarchy or more specificity than just the rendered field in the display template would work.  

Finally, we realized that Twig debug adds content to the view.  All of that green ← THEME DEBUG → code you see in your browser inspector when debug is enabled counts as content to views. You can beat that by using Twig's |striptags|trim filters on your rendered views field output. For some fields though, you need to preserve some tags and Twig's autoescape function likes to print the tag as content in the views display template.

In the example above, we're printing the rendered body field of the podcast episode which can have HTML added by an editor. We could probably have set up some sort of Twig {{ autoescape false }} in the views field template for the body (by the time its rendered in the display template, its too late) and done it that way, but since debugging should only be used on local development sites, why bother? Turning debugging off in the services.yml file makes the if statements work as intended so we know that they will function properly when they get to production.

Dec 13 2017
Dec 13

After setting up aD8 site and going into the theme folders for Bartik and Classy you'll notice that there are lot of templates in D8. This is because Drupal 8 really takes advantage of Twig’s template inheritance capabilities. Twig allows templates to be extended, included and embedded into other templates which allows for a very atomic approach to site building. Extends, Include, and Embed are quite similar, but there are some key points to be aware of.

Use Extends to inherit a parent twig template

Extends brings in the parent template (the one being extended) into the child template. No content outside of blocks defined in the parent template will be allowed in the child template. In a parent paragraphs template (paragraph.html.twig) there are some default classes and html structure you'll want to set that will be used in every paragraph bundle you create:

In a child text paragraph bundle (paragraph--text.html.twig) you would extend the parent template (paragraph.html.twig) and switch out the block content so the child gets the classes you want from the parent but uses its own content.

Since the parent template is being inherited with extends, all content in the child template must be inside a block defined in the parent. Content outside of parent blocks (as shown below) will not be allowed and will throw a Twig error on your site.

Use include to insert one template into another

Include also inherits content of a file, but also allows variables from the current template to replace those from the parent template. Include also differs from extends in that template you are including is included directly where the call is placed in the child. Think of it this way—extends is like bringing a parent template into a child template and changing some of the content of the parent in the child. Include brings a child template into a parent by inserting the entire child template into the parent a specific point. You could also insert an entire parent into a child and replace variables but not content.

The biggest advantage of this in my opinion is including templates from outside a Drupal site into a Drupal site or from one entity type to another. We use Pattern Lab as part of our approach to theming but while our Pattern Lab instance lives inside our Drupal theme it is technically outside of the Drupal site structure so it cannot use variables like {{ content.field_long_text }}. It even has a different suffix for files: paragraph.twig instead of paragraph.html.twig.

To get around that we use include instead of extends and use the ‘with’ function to replace variables from Pattern Lab in Drupal. The parent template paragraph--text.twig in Pattern Lab extends the Pattern Lab paragraphs.twig template to get the html structure then adds example {{ text }} variable content defined in a yml file. To get the final Pattern Lab example output.

Then in Drupal, the paragraph--text.html.twig file uses include to bring in the entire content of the Pattern Lab paragraph-text.twig file and replaces the {{ text }} variable with the Drupal output of the long text field in my text paragraph bundle {{ content.field_long_text }}.

The Drupal template uses the Component Libraries module to find the Pattern Lab Twig template and includes all the Pattern Lab structure but uses the Drupal text field for content.

Embed a twig template to replace variables and override parent blocks

Embed combines include and extends. You can embed a template in another template and replace the variables using 'with' and switch out block content from the child template you are embedding into the parent (or vice versa).

An example of this would be creating paragraphs demo content in Pattern Lab and bringing it into Drupal. Since Pattern lLb doesn’t have modules, we have to hand build the paragraph's HTML structure then exclude it in Drupal (since we don’t want the hand-built paragraphs html structure and Drupal’s).

In Pattern Lab the text.twig template gives basically the same HTML structure that the final Drupal paragraph bundle does but uses some dummy text from a yml file.

The Drupal template paragraph--text.html.twig both extends and embeds templates. It extends the Drupal paragraph.html.twig to add bring global classes and html structure into the text bundle template and it embeds the Pattern Lab text.twig template in place of the parent paragraph.html.twig content block while replacing the {{ text }} variable with the Drupal {{ content.field_long_text }} variable. Adding comments to the plwidgetopen and plwidgetclose blocks prevents them from printing the paragraph structure created in Pattern Lab.

With the setup above, you can theme the Drupal text bundle directly in Pattern Lab and have whatever structure is built around the text variable be reflected both there and around the Drupal long text field as well.

Pro Tips:

  1. It is often common to get ‘template not defined’ errors when using include, extends, or embed. You need to make sure that either the template you are inheriting is defined in the theme registry through a theme suggestion hook or that you define the correct path in your inheritance delimiter so drupal knows where to look {% include directory ~ '/templates/widgets/text/text.twig' %}.

  2. Blocks are your friend. Block structure can be switched out or added to at will with any of the inheritance methods and placeholder blocks can be used in parent templates to allow for later customization. You can use placeholder header and footer blocks in page.html.twig file to allow for custom scripts, libraries and other code to be added to different content types as needed.

Nov 21 2017
Nov 21

Our team completed the site over 2 months, including consulting on the sitemap and UX, site appearance, site build and custom Drupal development. The design follows brand guidelines established under the University campaign, while translating print guidelines into an online experience.

The campaign itself had a soft launch several years prior to the current push to a much wider audience, which included press releases, print materials and the new site. Carlson's goal is to raise $150 million. The site features up-to-date campaign statistics and uses stories to deliver a powerful and compelling message.

The site can be viewed at

Nov 15 2017
Nov 15

Your own approach will differ depending on your hosting platform, your budget, and previous experience of your team members but there are several key pieces to address as you embark on the DevOps journey. The basic setup below outlines the key pieces to a reasonable, DevOps-based workflow, regardless of your hosting platform or the various tools you decide to use.

Drupal install profile

We maintain a pre-configured Drupal 8 install profile that lives on Github and is mirrored on Packagist. This allows us to begin all new projects at "high altitude," with a working theme, preconfigured content types, Paragraphs bundles, Media bundles, and other elements that are common to almost all of our site builds. Note: This step is not a requirement, but it lets us hit the ground running with a continuous integration server, configured right out of the gate. There is nothing stopping you from spinning up a vanilla, Composer-based Drupal 8 install instead.

Local development setup

Having a solid local development workflow is a key piece of any continuous workflow environment. Developers create new features or fix bugs on their local machines, and push changes to Github in order to trigger various actions. At Electric Citizen, we have been experimenting with Drupal VM and more recently with Lando. Both of these tools provide easily repeatable processes that allow developers and contractors to easily spin up a local environment that is a close (or even exact) match to the production environment. 

Git repository and Git-based workflow

Most modern Drupal hosting platforms these days come with a bare minimum, Git-based workflow and multiple server environments. Sometimes that is enough. But a more common technique involves using Github or a similar service to manage your canonical codebase in order to take advantage of their tools and their ability to easily interact with a continuous integration server.

In our case, the build code for each project (e.g. composer.json and any custom modules or theme work) resides on Github. On every single pull request, our code is automatically deployed both to a continuous integration server and ultimately back to one of our live web environments.

Modern hosting platform

In order to truly leverage modern DevOps techniques you will need a “programmable” hosting platform that allows your developers and other systems (such as a continuous integration server) to automate and interact with your platform. Pantheon (Terminus/Quicksilver), Acquia (Acquia Cloud Hooks), and ( CLI) all provide powerful tools that allow you automate tasks within your hosting environment.

Electric Citizen has worked extensively with both Acquia and Pantheon hosting. While their tools are different, the same basic approach can be implemented on either platform (or even your own setup, though a completely custom solution will certainly entail more heavy lifting.)

Continuous Integration server

You will also need some type of continuous integration server to complete the puzzle. Essentially a continuous integration server allows you to automatically spin up and test a new version of the site each time a developer pushes a new feature or a bug fix to the git repository. In our case we are using Circle CI for this but there a variety of other popular options such as Travis CI or Jenkins

Automated functionality tests

Automated testing is another key component to any solid DevOps strategy. Each time we push a new commit, a complete version of the site spins up on CircleCI and runs through a series of automated Behat tests to verify key functionality. If the tests pass, CircleCI automatically notifies our hosting environment, and spins up a new branch and a new copy of the site ready for any final QA or additional client feedback. When we submit a Github pull request on that branch, a final CircleCI build is triggered. If the tests succeed, the code is automatically merged into the production site. 

Visual regression and load tests

We have also introduced visual regression testing to our builds using Backstop JS. Similar to our process for Behat testing, the CircleCI server automatically runs a series of predefined visual regression tests. These notify our team if even a single pixel has changed between one deployment and another. Our team has yet to integrate load or performance testing into this process but the opportunities are endless in terms of what and how you want to test.

Oct 18 2017
Oct 18

We’ve covered writing fun and fancy CSS through a preprocessor, using a framework or library to take the pain out of JavaScript, and putting a task runner to work bring it all together. Lastly, we need a proof reader. Some way to know that what we built is working or tell us what’s wrong.

Think back over all the time you’ve spent trying to find a missing semicolon or unclosed bracket that brought a project to its knees, while you manually scanned 1000s of lines of code to figure out what you did wrong. Wish you had that month or so of your life back? Tools like Stylelint, ESLint, and your browser’s built in development tools will not get that time back for you, but they will help prevent that pain from happening again.

Stylelint and ESLint are command line lint programs that comb your code and compare it against a set of specified rules. You can write your own rules, use an existing library, or a combination of both. Your linting can be targeted to follow a set of best practices, just the rules you most care about, or help you overcome bad coding habits.

For instance, you can lint your Sass with Stylelint to show an error when you use spaces instead of tabs, leave too many blank lines after a block, or miss a semi-colon. ESLint can lint your javascript to detect if you are missing a bracket somewhere or have a comparison in which both sides are the same. For more in-depth information on Sass linting with Stylelint read my recent blog post Sass Lint: or How I Learned to Love the Lint.


Another critical front-end tool is web browser developer tools. Firebug was an early version of these tools, available in Firefox, but now all browsers come with a set of developer tools. These developer tools allow you to inspect your CSS and HTML, test and debug style rules directly in the browser, and look for errors in the JavaScript console. A browser like Chrome even allows you to slow and stop animations, set the color scheme of the inspector, view print styles, and expand minified CSS and JS source files.

Oct 06 2017
Oct 06

Panels has long been one of the more popular contrib modules for layout in Drupal. At Electric Citizen, we’ve been using Panels and its large suite of associated modules (Page Manager, Panelizer, MiniPanels, Panels IPE, Fieldable Panel Panes) for years. Virtually every Drupal project we’ve worked on involved these modules in some capacity.

So what does Panels do? The full answer would take more than we’ll cover here. But at the base level, Panels offers a visual UI, where site builders can make custom page layouts through:

  • Custom page layouts (e.g. three columns, two columns with header and footer, 2x2 grid, etc.)
  • Moving and rearranging content fields into different regions of a layout
  • Inserting custom blocks and views into custom page regions (e.g. - add a sidebar menu to every basic page)

Note that Panels traditionally has been used for the “middle” content of a page – the part where the Body content goes. Headers and Footer (e.g. site name, logo, main menu) are global content areas unaffected by Panels. The exception is if you used Panels Everywhere, which takes the Panels concept to every content regions of your site (like the Blocks UI).

Panels in Action

Our client at the University of Minnesota Law School is a great example of Panels in action. Every page on the site is constructed of panels layouts.

The most common layout has a sidebar left and wider column for main content. The 2-column "sandwich" layout has site menus and various calls to action in the sidebar, while the main column contains the body copy. The header region contains a featured image (if available) and page title.

Panels IPE lets site editors change the layout of an individual page, if desired, without code. They simply choose a different page layout–three-column, for example– and then rearrange the various components using a drag-and-drop interface. They can also insert new or existing content to various page regions, such as a button to "Apply Now."

Changes from Drupal 7 to Drupal 8

Panels did so many things in the past that I think it scared people away, starting with a complex looking user interface. Panelizer also had a complex looking UI. These have been tamed somewhat in Drupal 8, and hopefully easier to understand for new users, by reducing the number of visual options, and simplifying the path to follow when applying your settings.  The basic concepts of page layout and field layout, however, have carried over between versions.

In Drupal 7, Panels had a UI, while Page Manager ran behind the scenes. In Drupal 8, there isn’t a stand-alone “Panels” interface anymore, and Page Manager is optional. You’ll need to rely on a Panels-related module like Panelizer, however, for the user interface and making edits. Panelizer was created for extending Panel-like changes on a page-by-page basis (vs global changes), but can be used in managing global settings as well.

Other changes include integration with the new Layout plugin, which lets users share layout templates between different modules, and not require developers to create separate 2-column or 3-column layouts (for example) for every module that might need it.

The in-place editor (IPE), which allows editors to add or rearrange Panels content on the page you are editing–as opposed to a backend configuration screen–has been ported to Drupal 8 but with a new, cleaner looking UI.

Fieldable Panel Panes, a useful Drupal 7 module for customized min-content-types (aka “widgets”) that can be placed within your content won’t be ported to Drupal 8. Thanks to the new-and-improved Block module, which allows for custom fields and block types, there’s no need for another module that can do this.

How to Use Panels in Drupal 8

After installing both Panels and Panelizer, you can get started customizing the layout (Display) for each content type. For each content type, under “manage display” you’ll find the option to “Panelize” your content. Once checked, you can start making your changes. The two areas you’ll want to pay most attention to are “Layout” and “Content.”

With Layout, you can assign a new page template to each content type. You can start by choosing 1-column, 2-column or 3-column layouts, and extend it from there to include dozens of variations in layout. Each page layout has its own set of style rules and regions for content.

Using “Content,” you can start rearranging the fields of your content type into different regions, as well as adding existing or custom block content to the page. Some settings can be made to fields here as well, such as the size of image. Note that In Drupal 8, everything you add to Panelizer is a Block, and not a Panel pane, as in Drupal 7.

Using Panelizer and IPE allows you to change the appearance of any content type without going into code and altering the page template files. Fields can be dragged and dropped into different regions, or rearranged in different orders. By changing the page layout, existing fields can be moved into different configurations and regions. So much power at your fingertips!

Debuting in Drupal 7, Paragraphs opened a new world of options for page layout, in a powerful and (somewhat) easy-to-grasp concept that held great power to non-technical site editors. Similar to using Panels and Fieldable Panel Panes, Paragraphs allows editor to:

  1. Create custom content types (paragraph types) with their own set of data fields (like custom block types in Drupal 8), that can then be used to
  2. Create unlimited blocks of content right on the node edit screen, and
  3. Rearrange their sort order with a simple, drag-and-drop interface.

Unlike Panels, Paragraphs doesn’t have extensive context and layout options. Instead, you can create Paragraph types, and offer them as an option for site editors to create on a page after the Body field. We like to call these Paragraph types “widgets.” Think of these widgets as similar to custom Block types. For each widget, you can define fields, define the layout, and define the style.

An easy example is an Image widget. While a site editor could add an image to a page via the WYSIWYG controls, using a Paragraph widget offers many more options. We can define the way the image renders, offer a select list of sizes for the editor choose from, and attach additional fields such as caption, source, date taken, etc. With a map widget, a site editor can simply type in an address, and a fully-embedded Google map gets rendered.

But wait, there’s more

Thanks for the ability to embed Paragraph widgets inside other widgets, we can create layout-style widgets, such as 3-column group, and then embed additional paragraph content inside of them. While this sounds complex and perhaps a bit strange, what it means is you have a container for your layout rules, and then inside the container, your custom content. For example, an editor could add a 3-column list of callouts to a page without code. Each callout could be a paragraph widget with fields for title, image, summary and link.

All Paragraph content is typically placed following the Body field. This allows editors to break up their page content with images, videos, maps, etc., without having to manage these elements inside their Body field. The ability to both “chunk out” and rearrange content on a page lends itself perfectly to the storytelling style of modern web design. Some have gone so far as to eliminate the Body field entirely from their content types, but I think it still has some use as the summary or introductory area of your page.

Sample Use Case

We first used Paragraphs extensively on the Century College website. Site editors construct and maintain rich content through a set of Paragraph widgets, all without touching code.

In the example shown here, the page is comprised of a series of widgets – text blocks, featured images, image slideshows, embedded map, horizontal rules between content. 

Trying to lay out this page content within a single Body field would get really messy. Editors would have to embed a map generated elsewhere, embed a slideshow generated somewhere else, resize and place images in the place they wanted – all within a tiny WYSIWYG editor. CSS styles and classes would likely be part of the layout, requiring editors to go into code. And should changes be required at a later date, it could get even messier.

Using a series of preconfigured Paragraph widgets we've provided, editors can:

  1. Select a widget (e.g. Map)
  2. Fill out the field for that widget (e.g. street address)
  3. Save and refresh

In this example, a map would be appear on the page, already styled and formatted for you. Should an editor wish to move the map to a different place, they simply edit the page, find the widget they created, and drag it to a new position. 

Do you need this module?

Since we have ability to create custom Block types, with their own set of fields in Drupal 8, what is the advantage to using Paragraphs? It’s debatable, but I find of the main advantages is the ability to associate these widgets of content directly with the node. Unlike Blocks, each Paragraph you create won’t appear in a giant list of content in the Blocks UI. They are only visible when editing a specific node. The disadvantage is that you can’t reuse Paragraph content on multiple pages, like you can with Blocks.

Paragraphs is very similar from Drupal 7 to Drupal 8, but some improvements to UI are coming soon (available now in experimental form). It’s already one of the more popular modules in Drupal 8, and hopefully will continue to evolve over time.

Display Suite has long been an alternative to the complexities of Panels, with some of the same key features. At its core, Display Suite allows editors to choose different page layouts for each content type, and then drag-and-drop fields into new regions (e.g. - moving an image to a sidebar, or a text field to the footer).

Another advantage of Display Suite in Drupal 7 was the ability to create custom Display Modes. As you may recall from the previous article, Drupal comes with default Display Modes for content types, such as Teaser and Full Content. But if you wanted to have a special Display Mode for a list of News articles (for example), you would have to use a module like Display Suite to create them. Since Drupal 8 now has custom Display Modes in core, this feature is no longer required in Display Suite.

The Drupal 8 version of Display Suite also handles page layouts from the Layout plugin, and are not specific to Display Suite. Like Panels, Display Suite is only for the main (middle) content and not the overall site header or footer.

An experimental Drupal Core module, Field Layout, has been introduced that duplicates the features of Display Suite. I’m not certain if this will eventually replace Display Suite entirely, but it does seem likely.

In addition to contrib modules, you can also check out contributed themes and grid frameworks for additional layout control through a grid-system.

What are grid-systems?

Grid systems are used to define a consistent structure and placement of regions for your content, following a consistent pattern (grid) of widths and heights. Grid systems have been a part of web design for several years, and much longer a part of print design.

Grid systems can come in endless variations of grids. They aren’t specific to any version of Drupal or any other CMS. But I don’t want to focus on the grid itself. Instead, I want to talk about grid frameworks (aka “grid engines”).

Grid frameworks

Grid frameworks are libraries of code, created to generate a series of grids of your choosing. These libraries do all the math in the background, calculating the width of each grid column across a range of screen sizes. Rather than build a grid system from scratch, these frameworks provide you with all the tools you need. You simply install a grid framework, and then start defining the type of grid you would like. For example, give me a 1-column grid for mobile, an 8-column grid for tablets, and a 16-column grid for desktops.

Some of the more popular frameworks I have used are SingularityGS, Susy, and Neat. One of the advantages in using a grid framework is the ability to apply grid layouts to your site, regardless of what Drupal theme you are using. The grid gets defined in your CSS, and applied to your Drupal layout.

It does require some learning, a tiny bit of math and knowledge of CSS, but it isn’t terribly hard. If you hate learning another system, and just need something simple and predefined, consider a Drupal theme with a grid-framework built in.

Themes with Grid Frameworks

The most popular option here has to be the Bootstrap theme. Installing Bootstrap gives your content access to a well-defined and responsive grid framework, plus additional theme settings for your controlling your breadcrumbs, navigation, tooltips, and more — all preset layout options.

With Bootstrap, you can apply a predefined CSS class to a block, region, or other container, and it will follow a grid such as 12-column or 16-column. Drupal templates have to be altered to include Bootstrap-specific classes, but the Bootstrap theme has done all that work for you. This theme is available for both Drupal 7 and Drupal 8. A similar but lesser-known theme, Foundation, is another option that does similar things.

Jul 19 2017
Jul 19

Blocks got a major overhaul in Drupal 8. A staple of Drupal for as long as I can remember, blocks have always functioned as little chunks of content that editors could create and move around to different regions of their theme, via the Block UI. 

The problems with blocks were (1) you only had a title and body field (2) once you had a number of them, it was difficult to use the core Block UI to manage. Many users relied on the Context module or switched to a module like Panels instead. In Drupal 8, however, Blocks begin to address these issues. 

Changes to Blocks

First change, blocks are now fieldable! This means you can create custom block types and add your own fields to each type, just like Content Types. This began in Drupal 7 with the BEANS module, but now it’s part of core. Because of this change, the Drupal 7 module Fieldable Panel Panes is also no longer needed.

Second change, everything is a block. While items such as the site navigation were exposed as blocks in Drupal 7, others were hidden from editors, such as the site name and logo. Editors can now ‘see’ these elements as blocks (site branding), edit them and move them as needed.

Third change, blocks are now reusable. In Drupal 7, blocks could be placed in one region at a time. If you wanted to use the same block in different regions, you had to duplicate its content. 

New modules for Blocks

The Blocks UI Admin is, by default, still not the best. Some older modules for managing blocks, such as Context, have made the jump to Drupal 8 (in Alpha at the time of this writing). A few new modules have a lot of promise for managing blocks as well.

The Place Block module, now in core, will let editors place blocks on the page they are currently editing, eliminating the need to go to the Blocks UI Admin, and remember the URLs or node IDs of the content they wish to alter. 

The Block Visibility Groups module improves the Blocks UI by allowing for filtering. This means editors can make the list of regions and blocks more manageable while editing and placing particular groups or types of blocks. 

Settings Tray is currently an experimental core module (formerly known as Outside-In module) that allows for the editing of all page elements, while viewing a particular page. For example, while viewing an About Us page, an editor could expose all the related blocks on a page (site name, search block, etc.) and edit each of them individually via a slide-out editor (settings tray). Being able to edit all the blocks and global elements of a site on any given page is powerful, and part of the “outside-in” initiative of Drupal for better editing experiences.

Jun 24 2017
Jun 24

The 7th annual Twin Cities Drupal conference is in full swing the weekend of June 22-25th, 2017. If you're an organization who uses or will be using a Drupal-powered website, or a web developer who wants to learn more about Drupal, this is a great, low-cost opportunity. 

Electric Citizen has been a lead sponsor since 2012, and our Citizens have been very active in organizing, volunteering, and speaking. This year is no exception, as we designed the conference website, stickers, tshirts, and signage, as well as offered up our speaking time.

Here's a list of the 5 sessions presented by our team. If you missed them, you can always go back and watch video later, it's all free and brought to you by the TC Drupal volunteers.

May 11 2017
May 11

Step 8: Set up a Custom Button in the WSIWYG Editor

In order to embed media, there needs to be a new CKEditor embed button to reference it (/admin/config/content/embed). Let's do this choosing "add embed button."

Once the button's embed type is changed to 'entity', more options become available–you can select "media" as the entity type, choose the types of media to display, and select the allowed display plugins. Display plugins are the display modes you enabled on the media bundle earlier. 

I recommend leaving all the media types blank so all types are allowed, but limiting the allowed display plugins to help keep the look of embedded media consistent. Notice that "default" is not a display option—that's why you need a "Full" display mode if you're planning on displaying images at their original size.

After creating the embed button, it can be added to the CKEditor formats. The new media embed button will be in the row of available buttons and can be dragged anywhere you prefer within the toolbar. I recommend removing the default CKEditor media button once your custom entity button is in place to prevent confusion.

Make sure to check display embedded entities, align images and track images for enabled filters and uncheck caption images if using a custom caption field. The filter processing order should have the three image filters at the top in the same order as their checkboxes appear.


If you are limiting allowed html, you will need to add the following tags into the allowed html tags field in order to allow media:

<figcaption> <picture srcset media type> <iframe src class title frameborder aria-describedby tabindex allowtransparency style> <drupal-entity data-entity-type data-entity-uuid data-view-mode data-entity-embed-display data-entity-embed-display-settings data-align data-caption data-embed-button>

Mar 20 2017
Mar 20

Once again, the whole Electric Citizen team is going on a trip to DrupalCon North America.

The annual pilgrimage for Drupal users, designers, project managers, developers and open-source enthusiasts lands in Baltimore this year – April 24th-28th. We’ll be taking in loads of sessions, keynote talks, trainings, and summits. And of course, lots of team-building fun.

Expect to see an uptick on Twitter and Facebook, as well as some new photos and blog posts when we get back. We usually come back from DrupalCon with lots of new ideas and energy to put them into action, especially around Drupal 8.

If you’re planning to be in Baltimore, let us know at @elecitizen on Twitter. We’d love to connect with new friends, or reconnect with old ones.

Jun 03 2016
Jun 03

DrupalCamp is coming to the Twin Cities again this summer!

For those who don’t know, DrupalCamp is the name for a regional conference– a smaller version of the national DrupalCons. TwinCities DrupalCamp (aka TCDC) is a great opportunity for anyone who works with Drupal to learn, network and grow professionally. We encourage all our regional clients to attend!


As we have every year since the initial 2011 TwinCities DrupaCamp, we are proud sponsors of the conference. Electric Citizen has been a Platinum sponsor for the past 5 years, and always happy to help this great local conference through sponsorships, design and volunteering.

Organizing and Volunteering

Our wonderful project manager Keri is once again cat-herding the conference organizers, helping keep us on track, on time, and on-budget. While many great people help out every year to make TCDC a success, we couldn’t do it without Keri’s guiding hand. Big shout-out to all the volunteers and organizers!


3 of us will be giving sessions at this year’s conference, so another good reason to attend. I will be giving a session on “How Long Do Websites Last”, examining the lifespan of a website, how sites can die, and ways to keep your site alive.

Our technical director Tim will be speaking on “Drupal vs Wordpress,” an age-old debate if you were to Google it, but from the perspective of how similar they’ve become, where the differ, and how to choose. No hate, just love for 2 well-known open source projects.

Finally, Keri will be teaming up with a colleague from another firm to discuss "Putting content at the center of your project." We’d like to help clients have a better plan at the beginning of a project for content planning, content strategy, content creation. Let’s not make content a secondary concern!

Are you coming?

Make sure you visit today to register. There’s another day of FREE training sessions, 2 days of sessions, and fantastic social events. It’s a great time, you should be there. Save the date, June 23rd-26th. Coming up soon!

May 27 2016
May 27

In what has become an annual tradition, the Electric Citizen team traveled cross country for a Drupal-related conference.

DrupalCon North America is an yearly conference of the Drupal community, where over 3,000 designers, developers, project managers, marketers, and more gather to network, give presentations, learn, and have fun.

For myself and Tim, it was our 6th consecutive DrupalCon and Keri wasn’t far behind (Adam was the newbie). We each went to the conference to learn, learn, learn. Also to improve what we offer at Electric Citizen and grow as a business, for ourselves and for our clients. We all had our own highlights from the conference which we’d like to share:

Dan’s Highlights

Accessibility: We’re on a mission to continually improve our understand of accessibility and the web, and several talks at DrupalCon helped us out.

Content Strategy: as we as an agency increase our work in strategic planning, learning all we can about how others are carrying out content strategy, content audits and other best practices.

Managing Support: continually improving the support services we offer our clients is another high priority this year, and I got several tips on how to keep getting better (including ramping up our support team!)

Tim’ Highlights

Progressive decoupling: learning new techniques for bringing the latest in front-end development scripting over to Drupal, such as Angular.js.

Next Level Git: picking up tips and reminders of how much more we could do as a team with version control

Drupal 8: getting up to speed with everything that's new and improved with Drupal 8. The latest version of Drupal is slowly becoming part of our new builds.

Adam’s Highlights

Component-based design: how to better utilize “atomic design” and PatternLab in our design and theming process, so we are designing around reusable components and systems instead of simply “web pages”

Keri’s Highlights

Wireframes to Widgets: we would like to continue improving our design and theming process and making it easier for a clients and developers to visualize and interact with websites as they are being designed. She picked up some ideas and techniques for better prototyping alongside Drupal. 

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