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.

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!

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

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.

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!

Sponsoring

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!

Speaking

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 http://2016.tcdrupal.org 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