Aug 12 2019
Aug 12
Image of the Rossetta Stone

In Mastering Drupal 8 Multilingual: Part 1 of 3, we focused on planning for Drupal 8 multilingual and its impact on a project's timeline and budget.

In Part 2 (below), we cover everything you need to know to have a functioning multilingual site with no custom code. Part 3 of the series covers more advanced techniques for site builders and front-end developers.

Aug 08 2019
Aug 08
Text on the Rosetta Stone

The web is constantly growing, evolving and—thankfully—growing more accessible and inclusive.

It is becoming expected that a user can interact with a website solely via keyboard or have the option to browse in their native language. There are many ways to serve the needs of non-native-language users, but one of the more robust is Drupal Multilingual.

Unlike 3rd party translation plugins like Google Translate or browser translation tools, Drupal's suite of core Multilingual tools allows you to write accurate and accessible translated content in the same manner as you write in your default language content. With no limit on the number languages, settings for right-to-left content, and the ability to translate any and all of your content, Drupal 8 can create a true multi-language experience like never before.

There is, however, a bit of planning and work involved.

Hopefully, this blog series will help smooth the path to truly inclusive content by highlighting some project management, design, site building, and development gotchas, as well as providing some tips and tricks to make the multilingual experience better for everyone. Part one will help you decide if you need multilingual as well as provide some tips on how to plan and budget for it.

Jun 18 2019
Jun 18

While many things stayed the same as previous years, such as the camp location and month it is held, this year was a first for many small changes.

Programming
The first big change was programming. Unlike previous years, where there was 1 day of training, and two full days of sessions and tracks (like you would have at a DrupalCon), this year’s schedule had one day of training, and only one day of traditional sessions.

The third day of the conference was dedicated to “unconferencing,” where those attending decided as a group what topics to discuss, and everyone participated in round table discussions for the day. The feedback was extremely positive for the new schedule, so it seems likely to stick.

The @TCDrupal unconference is underway! pic.twitter.com/WqaQsNL2rk

— Twin Cities Drupal (@TCDrupal) June 8, 2019

Welcome Party
The second big change was adding a new social event, the Welcoming Party. While the first night of camp has traditionally included a party for sponsors and speakers, this year it was opened up to ALL camp attendees. One of the core values of TCDC has always been inclusiveness, and this small change just made a lot of sense.

Community Sponsors
The third big change related to sponsors. There were still a number of great organizations who stepped up to help sponsor the conference, but this year included a dedicated push to encourage more “community sponsors.” The conference was still a very affordable $50/person, but during registration, there was ask to those who used Drupal professionally to give more, if they could afford to.

And people really came through! While there had been some individual sponsors in the past, 2019 had more community sponsors than ever before. 34 people joined in, and helped keep the conference both affordable to all, and in the black.

Jun 18 2019
Jun 18
table with a number of registration badges for Twin Cities Drupal Camp

The 9th annual TC Drupal Camp (“TCDC”) took place earlier this month (June 6-8th), and I was once again “on the scene” for this great regional conference.

Around 200 people convened in downtown Minneapolis in June for great sessions, keynote, training, networking and socializing during a beautiful and sunny week in Minnesota.

As one of the core volunteer organizers, I got to work alongside some great community members and really get a close up view of all that took place. So for those who missed it, let’s recap the conference!

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 Drupal.org, 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.

May 13 2019
May 13
tips of gold shoes on woman's feet, standing before a sidewalk art of two arrows, a decision to be made

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.

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 30 2019
Apr 30
hands at a computer keyboard, overcast by a blue hue

For many of us in the U.S., the GDPR is still a mystery. Although it had been in the works for a long while, it seemed to appear out of nowhere, cause a sudden rush of panic as the deadline to comply arrived, and then disappear without a trace.

At first blush, it seems like the kind of thing we could ignore. That’s Europe’s law, and not America’s. But a closer look suggested it would apply to any site doing business with Europeans, even if it was simply receiving site visitors from Europe. Here at Electric Citizen, that seemed to be a fairly small part of our client base, but something we took seriously nevertheless.

Apr 03 2019
Apr 03
members of Electric Citizen, all wearing team hats

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.

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!

Mar 28 2019
Mar 28
shot underneath the Chicago El subway system, with metal girders photo by Wilbur Ince

The 2019 edition of MidCamp is over, but our team left Chicago with a lot of great advice, fresh perspectives, new connections and good vibes. In what is now the 6th year of its existence, this annual spring conference heralds the coming of spring and the national DrupalCon in April.

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!

Jan 29 2019
Jan 29
new plant sprouting from the soil

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.

Jun 13 2018
Jun 13
Adam Fuchs presents on Drupal search

Twin Cities Drupal Camp 2018 just happened and Electric Citizen were able to present no less than four sessions on subjects ranging from Drupal search, configuration management, local development environments and dealing with emerging tech.

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.

Apr 17 2018
Apr 17
Nashville Skyline music city center Nashville Music City Center, a world-class venue

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 23 2018
Mar 23
drupalcon logo image

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!

Adam and Dan at the Electric Citizen booth Find us at DrupalCon booth #715
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 ralphlauren.com, mint.com, 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:

Mar 08 2018
Mar 08
upgrade keyboard image

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 ralphlauren.com, mint.com, 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:

Jan 10 2018
Jan 10
Blue path through a white maze

Setting up a robust Drupal internal site search that searches all of the content that you add to a complex site can be a bit like finding your way through a maze. 

Drupal 8 core Search has been revamped and is much more powerful and accurate than in D7, but it still concentrates on text in nodes and not other entities those nodes might contain—like Paragraphs, Views, or custom blocks. Core Search also does not allow you to choose which fields you want to index, how important those fields are, or use any preprocessors to tailor your search. Search API gives you all this and more.

Search API is a Drupal contributed module that allows you create searches on any entity known to Drupal. You can use Views to create a custom search results page with specific filters. You can create different indexes tied to specific sections or content on your site. You can do just about anything to architect your search experience other than use the core Search block—which is really the only thing that makes core Search worth using. This post however, will show you how to take advantage of the power of Search API, and keep your site search box.

Dec 22 2017
Dec 22
seo circuit board image

Drupal is well known for being a Search Engine Optimization (SEO) friendly Content Management System (CMS) and Drupal 8, the latest version, is the best by far. Many of the essential requirements for SEO best practices are already baked into the core software architecture, and with a little knowledge and some basic configuration anyone can tune up their website to become faster, drive more traffic, and perform better in the search engine rankings.

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 Schema.org 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
Green twig closeup

In the recent post Twig for Drupal 8 Development: Twig Templating Part 1, we covered some Drupal Twig templating basics like debugging, custom templates, inheritance, variables, filters, attributes, and macros. This post will cover more advanced topics. You will learn about preprocessing variables, expanding the available templates with theme suggestion, Drupal 8 Views and Twig, and the Twig Tweak module.

Dec 13 2017
Dec 13
Branch in dark forest

Twig is a PHP templating engine and the default templating engine for Drupal 8. Part of the Symfony Framework, Twig syntax compiles templates down to plain PHP when rendered in the browser.

Twig offers advanced features like template inheritance, automatic escaping, variable filters and macros to improve development workflow. Drupal 8's Twig templates are "html.twig" templates, which means that you can mix Twig into HTML easier than you could mix PHP and HTML in Drupal 7’s PHP templates.

Syntax in Twig is somewhat different than PHP, with three main kinds of delimiters:

  • {{ }} prints the content of variables or expressions. This is the equivalent of PHP’s print or echo.
  • {% %} executes "if" statements, variable definitions or for loops.
  • {# #} adds template comments that are not rendered in the page.

A very basic Twig structure to print a message using a variable might look like:
{%  set message = ‘Welcome to  my great website‘ %}
{{ message }}

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 https://driven.carlsonschool.umn.edu

Nov 21 2017
Nov 21
screenshot of success story, carlson alumni

Electric Citizen is proud to highlight another website launched this year. In October 2017, the new capital campaign website for the Carlson School of Management went live as part of a major donations drive. This was a significant part of the overall capital campaign for the University of Minnesota for "the largest philanthropic initiative in the University's history." The site was designed to highlight what's been raised thus far, and tell the story of why your gift matters.

Nov 15 2017
Nov 15
drupal-devops-image

How the DevOps movement is pointing the way forward to higher quality Drupal projects, faster delivery, happier team members, and satisfied clients for projects of any scale

Over the past several years, the best practices surrounding Drupal DevOps have expanded and improved, including continuous integration, continuous delivery, continuous deployment, and automated testing. In turn more organizations are discovering the benefits of these automated tools and deployment methods:

  • Faster development – developers can deliver more work in less time and reduce project costs (or deliver more work for the same budget)
  • Higher quality – with repeatable builds and automated tests against live production content for every change we reduces stress and uncertainty surrounding deployments of new features and bug fixes
  • Transparent development cycles – frequent builds mean any team member can check on the progress of any task at any time
  • Better collaboration – team members and stakeholders can focus on the features that matter instead of collaborating over the mundane details of builds and deploys

Whether a site is under active development or already in production, these benefits result in less stress, higher quality projects, happier developers, and satisfied stakeholders.

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 Platform.sh (Platform.sh 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.

Debugging

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 18 2017
Oct 18
Toolbox top shelf filled with used tools.

Front-end development in 2017 is a complicated and constantly shifting landscape of frameworks, trends, libraries and strategies. It seems like there is a new ‘must use’ tool every few months. It can feel as though you’re drowning in quicksand trying to keep your head above the latest trends. 

When you look at your front-end tool box, do you feel more like Bob Vila or Bob Saget? 

Bob Vila in front of drywall with arms crossed Bob Saget with arms crossed

 

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.

Oct 06 2017
Oct 06
hand holding marker, sketching out a rough wireframe of page layout on paper

Layout in Drupal 8 is a broad topic. For these articles, “layout” means anything that affects an overall web page’s appearance – elements such as page structure, columns and rows, regions, etc.

In Layout Part 1, I looked at how page layout can be done using Drupal’s core features – the default theme of Bartik, the core module of Blocks, the Twig template system.

For part 2, I'll cover what contributed (contrib) modules we can use for layout, as well as other themes and grid systems.

Why Contributed Modules?

Drupal has long allowed site owners to define content types and fields in a UI. And using Manage Display, editors can rearrange the order of how fields are rendered. What hasn’t been allowed, outside of manually editing page template files, is the ability to add or alter page regions, and move fields into different regions on a page (e.g. header, footer, main, aside). What the following modules do is allow users to customize their page layouts in powerful ways, all without getting into code.

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.

Jul 19 2017
Jul 19
scene from work, where several peoples hands come together across a table where a page layout is being discussed

What's the best approach for building out web pages in Drupal? If you’re a designer, site builder, themer or editor in charge of producing a functioning website, layout is an important consideration.

Of course we’re talking about content, but also functionality and design – you likely have custom designs you need to turn into functioning webpages, complete with different regions, different media, different callouts and multiple columns.

If you're new to Drupal 8, or just Drupal in general, there are many options and approaches you could take. Let’s take a look at what’s available, what’s changed in Drupal 8, and how you can make the right decision for building your custom website.

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.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web