Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
May 29 2020
May 29

Happy to announce we're attempting to kick off a new community initiative primarily focused on fixing and closing bugs.

We're hoping to

  • reduce the total amount of open core bugs
  • reduce the average age of open bugs
  • increase the number of closed bugs
  • mentor those looking to get move involved in contributing to core
  • give community members from countries in the Eastern Hemisphere the chance to participate in a core initiative in their local time zone.

We need you!

Resolving core bugs requires a wide range of skills - we're looking for volunteers to join us who can help with one or more of the following tasks:

  • Triaging and classifying bugs
  • Writing good bug reports, with steps to reproduce
  • Writing patches to resolve the bug
  • Writing automated test-cases to confirm the bug, and that it is resolved
  • Reviewing patches, through the lens of each of the core gates e.g. technical, accessibility, performance, backwards-compatibility, documentation, internationalization and usability.
  • Communicating with sub-system experts in order to gain sign off on non trivial changes
  • Writing documentation as required
  • Manual testing of the patch
  • Communicating any changes via blog posts, change records, release note snippets etc.
  • Coordination and management

If you are are looking to get involved - come join us on Slack in the #bugsmash channel.

We will meet asynchronously in the #bugsmash slack channel fortnightly on a Tuesday at 0400 UTC which maps to the following times:

  • 2pm AEST
  • 12 noon AWST, CST
  • 4pm NZST
  • 9.30am IST
  • 6.00am CEST
  • 5.00am BST
  • 8.00pm PST
  • 11.00pm EST
May 29 2020
May 29

In a recent Drupal training, I got a question about a replacement for the Drupal 7 Nodequeue module for Drupal 8 and other future versions. What this module allowed you to do was sort your content in whichever order you preferred.  

In Drupal, we make lists of content using Views and out of the box, and we have the ability to sort this content in different ways, such as:  

  • Date created
  • Date updated
  • Alphabetically  

But what if I want a list of content sorted in whichever order that I want? This is what Nodequeue allowed me to do: let me sort my content arbitrarily.  

Unfortunately, the Nodequeue module no longer exists for Drupal 8. But good news: there's a replacement called Entityqueue. This module does everything that Nodequeue lets us do in Drupal 7, and more.  

But content creation in Drupal has changed since Drupal 7. Many people are now using the Paragraphs module to lay out their content, so in this video tutorial, I'll be showing you two different methods of custom sorting:  

  • Entityqueue in Views
  • Paragraphs with Content Reference  

[embedded content]

Entityqueue in Views

After installing the module, we have a new option in Admin > Structure called Entityqueues. By default, there are no queues, so we create one:  

  • Name: Featured Content
  • Queue Type: Simple queue
  • Type of Items to Queue: Content
  • Content Type: Article (or whichever content you'll be sorting)  

After saving our queue, we have two different ways of adding content to the queue. We click 'Edit items' and type in the title of the content in the autocomplete field, click 'Add item', and click 'Save.'  

Another way to add items to the queue is to go to the content and click 'Edit'. Now, a new tab appears at the top of the page that says 'Entityqueue.' This will show a list of the queues this could be added to (it could be more than one). Click 'Add to queue' to add it.  

After adding it, we might want to rearrange the order of the items inside of that queue. Click the 'Edit subqueue items' and drag them around.  

For this tutorial, I've assumed you've already created a View of your content that you'd like to sort. Now, how do we get what we see in our View to match our queue?

Add Relationship to Your View  

The magic of Entityqueues comes from the relationship that we add in Views: whatever happens with our queue can be matched in our View. To add the relationship do the following:  

  • Open the 'Advanced' section of your View
  • Click 'Add' on 'Relationships'
  • Check the box next to 'Content queue' (found in the Entityqueue category)
  • Click 'Add and configure relationships'
  • Check the radio button for the queue that you made (if you've made more than one, they will all show up here)
  • Check 'Require this relationship'  

After doing this, the View will now only show content that has been added to the queue. Great!   

However, the order of our content might be incorrect. How do we get the sorting to match what's in our queue?

Add Sorting Criteria

If you've made no changes to the sorting criteria on your View, your content is likely being sorted by 'Content: Authored on (desc).' Basically, it's being sorted by the date the content was created. We need to remove this sorting criteria:  

  • Click on 'Content: Authored on (desc)'
  • Click 'Remove'  

Now, we need to add a new sort criteria that matches what is in our queue:  

  • In 'Sort Criteria' click 'Add'
  • Check the box next to 'Content Queue Position' (found in the Entityqueue category)
  • Click 'Add and configure sort criteria'
  • Click 'Apply' (you can leave the default settings)  

And now, our View content and order matches what is in our Entityqueue!

Paragraph Type with Content Reference

Although Drupal 7 did have support for the Paragraphs module, this method of laying out content has really gained popularity since Drupal 8 was released in 2016. To keep this tutorial brief, I won't go into all the details of creating new Paragraph types, but here are the basics.  

After downloading and installing the module, we have a new section in Admin > Structure called Paragraph types:  

  • Click 'Add paragraph type'
  • Label: 'Featured Content'
  • Description: 'Content that can be added and sorted arbitrarily'
  • Click 'Save'
  • Click 'Add field'

Add a new 'Content' (reference) field:  

  • Label: 'Featured Content'
  • Allowed Number of Values: unlimited
  • Restrict to Content: 'Article'
  • Click 'Save'  

On your Paragraphs-enabled content type, you now have the option to add a 'Featured Content' paragraph. This will display an auto-complete field (similar to Entityqueue) where you can type the Title of the content you want to feature. You can add multiple items, and rearrange them how you'd like.  

By default, what's shown is a simple link to the content, but this can be modified at the theme layer to display however you'd like, such as a slideshow of the featured content (but that's beyond the scope of this tutorial).

Comparing the Two Methods

From an Editor's perspective, it seems like there's less steps involved going with the Paragraphs approach, so why use that over Entityqueue? There's advantages to both methods and you have to choose which is right for your scenario.

If you have a Paragraphs-enabled content type, going down the Paragraphs route may be the simplest option. Editors just add the Paragraph to the page and begin typing and re-ordering the content. However, this features content in only one location on the site.  

With Entityqueue, though there's a few more steps from the Editor's perspective (and you may want to create a menu item so they can get to the queues quicker), if you need content to be sorted and featured in multiple places on your site, this is the route to go. In the video, I created a Views Page which has a relationship with my queue, but I quickly created a Block, which inherits all the settings I had from my page) and I can now place this in a region and have the two show the same content in the same order.

Wrapping Up

Nodequeue was a great Drupal 7 module, and luckily its spirit lives on (okay, that sentence might be a bit puffed up). But Entityqueue offers a great alternative and even includes some features that Nodequeue didn't, like being able to sort other entities like users and taxonomy terms.  

And content entry in Drupal 8 has evolved with the Paragraphs module, which also offers us a nice, easy-to-use method of sorting content in whichever order we'd like. To get more in-depth web development training, check out our training page or sign-up for a tutorial.

May 29 2020
May 29

I organized Drupal 9 Porting Day for April 28 as part of my #DrupalCares funding sub-campaign to help the Drupal Association bounce back from their financial losses due to the ongoing pandemic. It was a lot of fun with Lee Rowlands, Vladimir Roudakov, Adam Bergstein and Mike Lutz helping lead the contribution before and after my time of availability. 126 issues were worked on and 43 newly Drupal 9 compatible releases were made then.

Given how fun it was, with Drupal 9 coming out next week it was logical to do another event. Last Friday would have been a great opportunity in person at DrupalCon Minneapolis if not for the pandemic (again). So I decided to schedule the event for that weekend. Surabhi Gokte and Gabriele Maira helped a lot in getting the event off the ground and we announced Drupal 9 Porting Weekend for May 22-23 to accommodate people available on the workday as well as the weekend.

With more time to prepare, a lot more interested folks signed up to help lead the event in their respective timezones. 14 leads signed up and helped contributors for 52 hours, while the event lasted. Thanks Vladimir Roudakov (VladimirAus), Janna Malikova (JannaKha), Vaibhav Jain (vaibhavjain), Tsegaselassie Tadesse (tsega), Gabriele Maira (gambry), João Ventura (jcnventura), Oleh Vehera (voleger), Matthew Radcliffe (mradcliffe), Michael Lutz (mikelutz), Adam Bergstein (nerdstein), Kristen Pol, Qiangjun Ran (jungle), Jaideep Singh Kandari (JayKandari) and Digant Jagtap (digantdj), you were fantastic!

Kristen Pol and Tsegaselassie Tadesse were also very active in the planning stage, Kristen published a very detailed guide to the weekend, Tsega wrote up and posted developer tips. The Bassam Ismail posted this video based on those guides of an actual Drupal 9 project update running with Upgrade Status and Rector, ending in submitting the patch:

So with everything well prepared, Vladimir and Janna started the weekend and the leads were handing off responsibilities to each other throughout the whole event. This is how time coverage looked like for the whole 52 hours. There was not a single time when someone was not there to help:

We had a lot of fun and learned a ton from each other. While numbers will not explain the event, that is all we have after the fact to look at, so here they are:

When looking at project releases, the weekend also supported a major increase in daily newly Drupal 9 compatible releases also with several days of after-effects (I am counting these with my own script):

New releases at the weekend and shortly after included fun modules like Pirate but also seriously cool modules like the Tome static site generator, Quicklink and top 200 most used modules like Views Accordion and Schema.org Metatag.

As luck would have it Drupal 9.0.0 RC1 was also released on this weekend, which meant that people testing their updated projects also gave the Drupal 9 release candidate a test drive right away.

For me this event was amazing to organize. The results in new Drupal 9 compatible projects before the stable core release and the additional testing of the release candidate are all good material outcomes. The raised awareness around the porting process and tools as well as the know-how shared will last even longer as people use what they learned and teach others as well. Also the concentrated increased use of the tools resulted in more improvement suggestions, so we can make them even better for the next wave of porters to come.

Thanks all for your involvement, you made a lasting difference. Keep spreading your know-how and all the good things about Drupal 9!

Ps. Next up is celebrating the release on June 3rd, 2020! Post your artwork, selfies, videos and events at https://celebratedrupal.org/ and let's have some fun together.

May 29 2020
May 29

Universal design of ICT is about designing websites, apps and self-service machines so that as many people as possible can use it regardless of disability. Those who use your website may be visually impaired or blind and therefore dependent on screen readers, or people with disabilities who use keyboard only or other tools to navigate the website, or users with cognitive disabilities.

We've put together five tips on how to make the site accessible to as many users as possible.

01 Typography - make your website easy to read

Your website should be easy to read. Those who use the website may be visually impaired, may have cognitive impairment, or may simply want to scour the content of the page. Simple design concepts such as using the right size of the text, length of lines and subheadings help here.

In documents and on print it is common to use 12 dots on text, while on screen this text becomes very small. It is recommended to use 14 or 16 points instead. The text should also stand out above the background. Avoid long texts on images and, if necessary, use a  semi-transparent background color.

Long lines are harder to read, and the long distance from end to start of the next line can also interfere with the flow of reading. For a single-column page, 45 to 75 characters are considered satisfactory lengths. It also helps with the read flow that the start of each line is equal. Body should therefore be aligned to the left, not centered.

Divide the text into paragraphs and use headings and subheadings. This makes it easier to understand the structure of the text. Make sure the headings are bigger so that they are different from the body text. 

02. Contrast for the visually impaired and color blind, but also those who are out in the sun.

obile phone held up towards the sun, with reflection on the screen.

It is of little help that the text is large enough if you have light gray text on a white background. Good contrast on texts, buttons and icons is very important. This is not only for the visually impaired, but also for users who have low brightness and contrast on their screen, such as when out in the sun.

For at innholdet skal komme godt nok frem skal kontrasten være 7:1 på liten tekst (f.eks brødtekst) og 3:1 på overskrifter og større illustrasjoner, ikoner o.l. 

For the content to appear clearly enough, the contrast should be 7: 1 on small text (eg body text) and 3: 1 on headings and larger illustrations and icons.

03. Proper use of alt text

"Man with a white Guy Fawkes mask is facing camera in front of a graffiti wall.

Alt text is a texts that can be read by screen readers so that those who cannot see the image won't miss any important information on the page.

A typical mistake is to start the alt text with "Picture of ..". or "icon for ...".  The screen readers knows that the content is an image, but it needs a text to describe it to the user. Therefore, use the alt text to describing the image rather than explaining that it is an image.

It is also important to be detailed if it is important to the context. The alt text should not consist of keywords, but be a complete sentence. Examples of bad alt text for the image above would be "Person with mask, graffiti wall". A better alt text is "Man with a white Guy Fawkes mask is facing camera in front of a graffiti wall." Also, make sure the text is not too long. The maximum length of the alt text is 125 characters.

04. Make the links stand out from the text

Links in the body text can sometimes be difficult to detect, especially for the visually impaired and color blind. The links should therefore be clearly distinguished from the text around, both in color and underline. But it is not just in the design that one can make a difference, it also matters what text you use. We often see links at the end of a sentence that are named "here". For example, “Read about our services here”. Instead, you want to tell the user what the link does or what content it links to in the link text itself. A better link text would be "Read about our services".

05. Make the texts easily understandable

This tip is very much related to the first, but this is more about language and content production than design and layout. Keep in mind that some users might have some cognitive disabilities. A simpler language and shorter sentences might make it easier for these users.

  • Make your texts short and precise. Avoid writing long paragraphs that cover several topics.
  • Use bullet points if possible.
  • Simplify the language. If you use abbreviations or subject terms, it is wise to explain these the first time they are used.
  • Use images and illustrations to divide the content and to illustrate the main points.
May 28 2020
May 28

The launch of Drupal 9 is less than a week away, and that is cause for celebration. In the past, the Drupal community and the Drupal Association have organized a variety of celebrations across the globe. For Drupal 8's launch we saw more than 200 release parties happen on six continents. 2015 Drupal 8 Celebrations

Celebrations in the time of COVID-19 are a much different affair; the world looks different than it did for Drupal 8's launch in 2015.

But that doesn't mean we aren't going to celebrate!

For Drupal 9, the community has built CelebrateDrupal.org - a central hub for all of the virtual celebrations the community will undertake this year for the release of Drupal 9.

We encourage you to join in the fun!

You can post your virtual events for others to join, upload photos of your Drupal 9 cupcakes, or selfies of your celebration, or add video. We've also provided a complete brand kit with the updated Drupal brand, which you are welcome to use as part of your celebrations.

We encourage you to post about your celebrations on social media using the hashtags #CelebrateDrupal, #Drupal9, and #D9LaunchDay (on June 3rd). 

Finally, we'd love to have you join us for DrupalCon Global, from July 14-17, where we'll be reflecting on the Drupal 9 launch as a community.

While we're sad we can't celebrate in person, we're thrilled to celebrate with the whole Drupal community virtually following Drupal 9's release on June 3rd. We'll see you online!

May 28 2020
May 28

This month’s SC DUG meeting featured Will Jackson from Kanopi Studios talking about his virtual background and office.

Before everyone was learning to use Zoom virtual backgrounds, Will had built out a full 3D room for his background, including family pictures and other fun details. He talked about what he built and may inspire you to try some more personalized than swaying palm tree and night skies.

[embedded content]

If you would like to join us please check out our up coming events on MeetUp for meeting times, locations, and remote connection information.

We frequently use these presentations to practice new presentations, try out heavily revised versions, and test out new ideas with a friendly audience. So if some of the content of these videos seems a bit rough please understand we are all learning all the time and we are open to constructive feedback. If you want to see a polished version checkout our group members’ talks at camps and cons.

If you are interested in giving a practice talk, leave me a comment here, contact me through Drupal.org, or find me on Drupal Slack. We’re excited to hear new voices and ideas. We want to support the community, and that means you.

May 28 2020
May 28

It’s been a long few months for many of us and we’re all ready for some good news!! Luckily, as a part of the Drupal open source community, we have some. Our group continues to be full of strong, resilient, and uplifting individuals who truly understand that we're all in this together. 

You Have Resources

We cannot recommend strongly enough to please, stay connected and in-touch with your local community. Now more than ever, this can help maintain momentum and provide the companionship that many of us miss during this time of social and physical distancing. Many local and regional meetups provide time at the beginning of their events for networking, including dedicated time for those looking for work and those who are hiring. We encourage virtual event organizers to continue to provide (or even expand) this aspect of online events.

Beyond the power of word-of-mouth, there are other online resources available to you in these unusual times. There are Drupal Camps that have year-round job boards posted on their websites. Drupal.org has a whole section of their website dedicated to those looking for work. The organizations that are posting here are invested in Drupal, just as you are. This common spark could start you on a new path. 

What You Can Do for Yourself

In spite of the global state, there are many things you can do - you are empowered! We suggest you start with the following:

  • Add your profile on Drupal.org
  • If you already have one, give your Drupal profile an overhaul and be sure it’s up to date. 
    • Update your bio: Ask yourself if that is really how you see yourself
    • Past companies: Don’t forget to show your growth
    • Bio Picture: Just make sure that if you look like it’s your prom picture, that you intended it that way.
    • Ask a fellow community member to review and provide suggestions for improving it. Many of us have difficulty in promoting ourselves, so ask for help to ensure that potential clients/employers see you for all that you are!
  • Update your resume
  • How to prepare for an interview
  • Don’t get shy. We repeat: Don’t Get Shy! Even when feeling the “aloneness” of it all, get out there virtually. Attend local meetups and camps to network and grow the community
  • Keep learning. In the face of everything, stay curious! It’s probably how you started down this road, to begin with

How Employers Can Help

Great leaders know that communication is the key to success. Now more than ever, your leadership skills and community contributions are needed to help pull us through this global crisis. Please, 

  • Be transparent with employees and contractors. We are all in this together.
  • Sponsor DrupalCamps at the job board level to get connected.
  • List any open positions on Drupal.org.
  • And remember the gift of presence; network at local and regional meetups and mentor those you can.

We Never Stop Growing

Even in challenging times, we as individuals and as groups cannot stop growing. Take time, get talking, and get excited. There are many more roads to be traveled, together.


We welcome additional resources in the comment section, thanks!

May 28 2020
May 28

Vardoc, a Drupal distribution, is a knowledge base system, a wiki system, and a document management system designed to host a massive amount of content in a structured and easy-to-find format. With Vardoc, your content can be easily structured, and scheduled. It allows you to personalize your content easily and contribute your expertise in the knowledge base.

You can build a connected organization, product, or knowledge area to allow everyone involved to find the answers they seek and contribute their expertise in the knowledge base with the help of Vardoc. Think of it as a wiki site of your product, user manuals, or organizational processes with an easy structure, collaborative tools, and a friendly design.

Vardoc page open on the screenAn insight into Vardoc's elements 

Who can benefit from Vardoc? 

Let’s get to the part where we understand who this system is for. The agencies who want to document their software, product documentation sites and website based interactive user manuals can benefit from Vardoc. It also works a great deal for documentation of Open Source projects and inter-organisational processes. Vardoc is cost friendly and saves the usual development time.

What makes Vardoc wonderful?


A by default powerful search which searches through the vast repository of the documents and provides the relevant results. The search mechanism is already set and tailored for the knowledge base system by prioritizing headings and titles more than the content's body.

Editorial features

The distribution supports editorial features which help keep the documents up to date. The editing mode is also tailored for quick review and vetting of information. Vardoc’s media library is full of interesting features that provide an appealing way to display media libraries. Vardoc also allows one image to have many previews with the help of image cropping and settings present within the CMS. And, it provides simple and easy ways to create and manage new and existing pages respectively.


Being a knowledge base, the website at its core provides powerful features to structure the framework in which the documents are to be stored. This gives the user the power to tailor the structure and present the data in a hierarchy which best suits the organization.

User Management

To control and regulate the engagement of the website the admin will have full control of their roles and permission. You don’t need to worry about losing the important experience that is needed when a team member retires or leaves. Vardoc helps you to engage users from various departments to use the information that is needed in one space.

Customisable themes

It is essential to have proper theming on your website. You can brand your website by modifying the starter theme with some easy-to-make and quick CSS changes.


When potential users are searching the web, make sure your website is there to be found. On Vardoc you are immediately optimized for search engines when you update your sitemap.xml, create and set customized URL paths and custom page titles, and include specific keywords.

Accessibility compliance

The Vardoc based website already complies with the accessibility requirements (WCAG 2.0) for various user groups.

Social media Integration

Out-of-the-box social media integration which enables governments to link their social handles to the website.


Vardoc provides a front-end design to work with all the latest versions of all the commonly used web browsers. Vardoc makes sure that you are able to reach your audience across all devices and web browsers. It is completely optimized for mobile and other devices to access whenever and wherever you want to.

Multilingual options

Vardoc provides access to several languages with localized and translated content, date formats, country flags, modern fonts etc.


Vardoc’s real-time analytics feature allows users to measure and monitor the site activity in real-time through google analytics professional integration. 

Summing Up

It is much cost friendly and saves the industry-standard development time. It has everything under one roof. Organisations may find it easy to decide but depending on their current website’s dynamics, our resource involvement depends. 

Vardoc is currently available for download for Drupal 8 and has stable releases that are covered by security advisory policy. For more information on its Drupal 9 readiness, check here.

OpenSense Labs has always been keen towards finding the appropriate solution for clients and prospects in general. Feel free to reach us out at [email protected] for help.​

May 27 2020
May 27

Is a design revolution on the way? History says yes.

A new decade tends to usher in new design trends, but 2020 is turning out to be much more than just a new decade. As we look forward to finally breathing a sigh of relief, once Covid-19 heads for the history books, now is the time to prepare for what’s next. 
Seismic shifts and societal aftershocks stemming from the global pandemic stand to reframe how we view and interact with the world, and that includes websites. Design is inextricably linked to world events and there is no doubt that the economic, emotional, and political impact of Covid-19 has rocked “business-as-usual” to the very core.
During stay-at-home lockdowns, websites were catapulted into the primary means of connection. Chances are, the strengthened online attachments made over the past few months aren’t going away. Moving forward, “normal” will look a lot different than how we remember it. 
What does this mean for your website? How can you ensure that your site aligns with emerging expectations, current concerns, and new preferences for staying connected and conducting business?

Looking Back to Look Forward

For perspective on the design approach that will resonate with your audience, let’s take a quick look back to the design revolutions that followed major global upheavals from past decades -- starting with the last time that world was gripped by a pandemic that rivaled Covid-19. Of course, web experiences were not a factor for much of the previous century, but many of the same principles apply. Whether we are talking about color choice, fonts, building facades, or refrigerators, design has a powerful impact, even when -- often especially when -- it registers on a subtle or unconscious level. 

From Pandemic to Prosperity

Immediately following the devastation of World War I, which killed 40 million people worldwide and more than 5 million Americans, one-third of the world’s population became infected with the Spanish Flu. More than 20 million people died as a result, including 675,000 Americans. 

It’s hard to imagine a series of events that sparked a more desperate need for optimism and a determination to reshape a vision for the future that was driven by positive energy. 
Enter the Roaring Twenties: Modernist designs, marked by innovation and experimentation vs. realism and the rules of the past were the primary influences during this era. It was a time of fun, flashy and opulent design with gold as a dominant color and art deco as the signature style. 

an representative Roaring 20s illustration of a woman1920s design depicted opulence, sophistication, art deco designs and women stepping out of traditional roles.


Then: The Crash

The Great Depression of the 1930s marked a sudden and sweeping turn in economic realities. It sparked another design revolution that reflected efforts to lift up a population who was dealing with tremendous loss and uncertainty. Bright colors and positive messaging were intended to spark optimism and hope.
Streamline moderne emerged as a new architectural style that emphasized industrial materials such as concrete and glass, along with smooth curves. A lack of ornamentation and sharp angles aligned with the economic austerity of the times, while unexpected colors injected bright spots into the dreary realities of the day. 

The Blytheville Ark Bus station built in 1937The former Blytheville, Ark., Greyhound Station. Built in 1937 and listed in t he National Register of Historic Places. Public domain Photo by Nyttead, Wikimedia Commons.

A signature Depression-era design achievement was the Sears, Roebuck & Company’s decision to hire industrial designer Raymond Loewy to redesign its Coldspot refrigerator in 1934, in an effort to create excitement about the appliance and encourage consumers to shop. Touted as a “single, smooth, gleaming unit of functional simplicity,” the redesigned Coldspot sparked a fivefold increase in sales for Sears between 1934 and 1936, due to both the redesigned appliance and the effective advertising campaign.

Impact on a far greater scale accompanied the graphic design campaigns created to spark excitement about the National Recovery Administration (NRA). Posters with the Blue Eagle were splashed in major cities all over the United States, and Blue Eagle became a widely recognized symbol of the government’s commitment to helping with jobs that would offer much needed food, shelter, and economic security.

NRA Blue Eagle PosterDepression-era poster widely displayed by retailers to show support for the National Recovery Act.

Onward and Upward

During World War II, iconic propaganda posters fueled the war effort with messages that urged specific actions, while conveying unity, strength and the ultimate triumph of good over evil. 
As the war ended, the United States was quickly catapulted into the “atomic age,” which encompassed the years of 1945 through 1963. Atomic Age design trends reflected a determination to redirect the world away from one of history’s darkest chapters, while harnessing the war’s massive destructive capabilities for scientific achievements that would have a positive impact on humanity. Abstract designs, bright colors (turquoise was huge) and graphic elements inspired by science and space emerged as dominant design devices that represented a bright future of boundless possibilities.
The “boomerang” emerged as a signature motif of the 1950s, as well as designs that suggested galaxies, planets, stars and space travel. 

1950s boomerang pattern1950s "Atomic Age" designs references galaxies, space and the iconic boomerang motif.


Radical and Rebellious

Post-war optimism took a nosedive in the late 1960s and 1970s, as the Civil Rights movement, along with opposition to the draft and the war in Vietnam, fueled widespread unrest and antagonism toward authority. 

Psychedelic designs that featured bright and unexpected colors, kaleidoscopic patterns, and groovy typography reflected an emerging youth culture noted for rebellion and a determination to be seen and heard. 

A 1960s era graphic design"Psychedelic Dingbats," by Hendrike. Wikipedia Commons.


The Next Big Downturn

Throughout the 20th century, graphic design served as an essential tool for shifting societal gears following crises and setbacks. As we entered the age of digital communications, rapid change and heightened competition called for far more rapid response to evolving user needs and expectations. 
Let’s fast forward to 2008 and the Great Recession that followed the sub-prime mortgage crisis and the near collapse of global financial markets. At this point, the web had long since entered into the mainstream as a critical component of consumers’ connection to the world. The rise of “Web 2.0” was allowing for widespread sharing, interaction, and connection via social media and commenting capabilities.
As the Great Recession sparked distrust in mega-corporations and complicated, behind-the-scenes financial dealings, it fueled the rise of simple, web capabilities that offered transparency, no-nonsense, and value. Digital natives for whom online interactions were second nature, drove the growth of direct-to-consumer brands such as Warby Parker. Casper®, and Blue Apron. 

Successful web designs trended toward unintimidating colors, most notably “millennial pink,” along with minimalism and simple, clean graphics. The elegant simplicity of Apple’s design sensibility is emblematic of this era. 

What Now? Post Covid-19 Design

At Promet Source, we are in no way suggesting that Covid-19 is behind us, but as we proceed with hope and caution toward that point, we are devoting a depth and breath of empathy and insight into the types of redesigned web experiences that will effectively resonate with audiences. 
While the pandemic had and is having a distinctly different impact on every household and every individual, it’s fair to assume that varying degrees of post-traumatic stress will accompany adjustment to the new normal.  
It seems no surprise that the Pantone 2020 color of the year appears closely aligned with the reassurance that post-pandemic audiences will be seeking. Classic blue is described on the Pantone website as, “a reassuring presence, instilling calm, confidence, and connection. This enduring blue hue highlights our desire for a dependable and stable foundation on which to build as we cross the threshold into a new era.”

Pantone Color of the year 2020. Classic blueClassic Blue: Pantone 2020 Color of the Year

Calm and confidence is certainly not limited to a single color, but the concept is essential. Successful web experiences will not be looking to further rock anyone’s world. 
Confined to their homes, audiences have spent more time on the web than ever before. Chances are, they’ve experienced sites that offered excellent, streamlined navigation, sites that were frustrating to find what they needed, and everything in between. Moving forward, the bar is high, and like never before, audiences will appreciate impeccably designed web experiences. 

As people are confined to their homes and finding online experiences to be their primary connection to the outside world, websites are being called upon to do more heavy lifting than ever before.

Historically, economic downturns, and large-scale disasters of every kind have presented an opportunity for renewal and reinvention. This renewal is reflected in the design of the world around us, from fashion to websites. Our expectation for the post-pandemic era is design trends that evolve towards brighter colors, whimsical styles, and simplicity. For your website, this might mean a fresh, new color palette, bolder fonts with smoother edges, brighter images, and a renewed organization of previously complex menus and data.

At Promet Source, we’re committed and uniquely qualified to work closely with clients to ensure that their websites exceed the expectations of their audiences. Looking to start a conversation on aligning your site with new and emerging realities? Contact us today.



May 27 2020
May 27

Drupal 7 to 9 Upgrade

Drupal 7, our much-loved CMS that was released in 2011, is nearing the end of its life. No, that's not hyperbole; Drupal 7 is scheduled to reach end-of-life in November 2021. Drupal 8 has been out for a few years, but at the time of this writing, Drupal core usage statistics indicate that only about 350,000 of the more than 1.1 million reporting Drupal core sites are using Drupal 8.x. Over 730,000 of those sites are still using Drupal 7. If your site is one of those 730,000 still on Drupal 7, should you upgrade to Drupal 9? 

Drupal 7 is coming to an end

Whether or not you choose to upgrade to Drupal 9, it's time to acknowledge one very important truth: Drupal 7 is coming to an end. After a decade in service, Drupal 7 will stop receiving official community support in November 2021, and the Drupal Association will stop supporting Drupal 7 on Drupal.org. Automated testing for Drupal 7 will stop being supported via Drupal.org, and Drupal 7 will no longer receive official security support.

Beyond the loss of support for Drupal 7 core, there is less focus on the Drupal 7 version of many contributed modules. Some of them are quite stable and may work well into the future, but others are more neglected. The reality is that once module maintainers have moved their own sites to Drupal 8 or Drupal 9, they may lose interest in spending the time it takes to keep a Drupal 7 version of their code up to date.

Upgrading from Drupal 7 is harder than from Drupal 8

Drupal 8 was released in November 2015. When the Drupal Association announced Drupal 9, they discussed a big change coming to the Drupal ecosystem: Major Drupal version changes would no longer be a substantial replatforming effort, but would instead be a continuation of an iterative development process. In practice, this means that Drupal 9 is built in Drupal 8, using deprecations and optional updated dependencies. The result is that upgrading from Drupal 8 to Drupal 9 is just an iterative change from the final Drupal 8 version. Drupal 9.0 involves the removal of some deprecated code, but introduces no new features; it's a continuation of the fully-tested, stable codebase that is Drupal 8. Basically, Drupal 9.0 is just another release of Drupal 8. 

On the other hand, Drupal 7 has significant differences from Drupal 8 and 9. The jump from Drupal 7 to Drupal 9 can be an enormous undertaking. Third-party libraries replaced huge swaths of custom Drupal code. The procedural code was reworked into object-oriented code. The code changes were massive. Upgrading a Drupal 7 site to Drupal 9 will bring it into the new upgrade paradigm, but there's quite a bit of work to do to get there.  So the question of whether, and how, to make the jump to Drupal 9 is more complicated.

That leaves Drupal 7 sites with a handful of options:

We’ll focus on the first option in this article, and the others later.

Benefits of Drupal 8 and 9

While Drupal 8 is a big change from Drupal 7, it features many developmental and editorial improvements that pay dividends for users who are willing to take the time to learn how to use them.

Lots of contributed module functionality now in core

One of the biggest upsides of Drupal 8 and Drupal 9 versus Drupal 7 is the fact that many of the things that require contributed modules in Drupal 7 are just baked into core now. This includes things like:

  • Layout Builder provides the ability to create customized page layouts that Panels or Display Suite provide in Drupal 7.
  • Blocks have been re-imagined to be fieldable and re-usable, things that require contributed modules like Bean in Drupal 7.
  • You don’t need to install a contributed module and third-party libraries to get a WYSIWYG editor; it’s built into core.
  • Views is in core, and most of the custom lists in core are now fully customizable views.
  • Media handling is not an add-on. It’s an integral feature. To get similar functionality in Drupal 7, you need a half dozen or more complicated contributed Media framework modules, each of which might require quite a bit of additional configuration. You can get a pretty decent media handling experience in Drupal 9 by doing nothing more than enabling the Media and Media Library modules and using the default configuration.
  • Web services are built in, like JSON:API.
  • Customized editorial workflows are now available in core, providing functionality that would have required contributed modules like Workbench Moderation or Workflow.

That’s just to mention a few features; there are many things in core that would require contributed modules in Drupal 7.

Maintaining this functionality is simplified by having more of it in core. Managing fewer contributed modules simplifies the process of keeping them in sync as you update versions and dependencies, and trying to decide what to do when you get a conflict or something breaks. As Drupal 7 development falls by the wayside, this is even more important, as it could take months - or longer - to get updates to Drupal 7 contributed modules, until they’re no longer supported at all after end-of-life.

Having these solutions in core means everyone is using the same solution, instead of splintering developer focus in different directions. And having them in core means they’re well-tested and maintained.

Composer gets us off the island

One of the changes to Drupal since the Drupal 7 release is that Drupal 8 and 9 extensively use third party libraries like Symfony for important functionality, instead of relying on custom Drupal-specific code for everything. That move “off the island” has introduced a need to manage Drupal’s dependencies on those libraries. This is handled with yet another tool, a package called Composer.

You need to manage the dependencies of these new top-level third-party libraries, but each of these libraries has dependencies on other libraries, which have dependencies on more libraries, creating a confusing spiderweb of dependencies and requirements and potential conflicts. Dependency management quickly becomes a maintenance nightmare. It’s a new tool to learn, but Composer is a great dependency manager. Taking the time to learn Composer gives developers a powerful new tool to deal with dependency management.

Composer can do other things. If you add cweagans/composer-patches, it’s also a very useful tool for managing patches from Drupal.org. You can add a patches section to composer.json with links to the patches you want to watch. Composer will automatically apply the patches, and your composer.json file becomes a self-documenting record of the patches in use.

You can read more about Composer in another Lullabot article: Drupal 8 Composer Best Practices.

No more Features for configuration management

In Drupal 7, many sites deploy configuration using the Features module. Depending on who you ask, using Features for configuration management could be regarded as a good thing or a bad thing. Many developers maintain that Drupal 8 (and therefore Drupal 9’s) Configuration Management system, which allows database configuration to be exported to YML files, is much easier than the Drupal 7 Features system. As with Composer, it takes time to learn, but it enables developers who understand the system to accomplish more with less effort. 

Secure PHP support

Drupal 7 sites could be running on deprecated versions of PHP, even as old as 5.3. Drupal 7 sites should already have moved to PHP 7, but could still be running on older, very outdated and insecure, versions of PHP. Drupal 7 currently works with PHP 7.3 but has problems with PHP 7.4. As PHP continues to progress and deprecate older versions, you may find that you can no longer keep your Drupal 7 site running on a secure version of PHP. Drupal 8 runs on PHP 7.0+, and Drupal 9 runs on and requires a minimum of PHP 7.3, so both provide a better window of compatibility with secure PHP versions.

Resistance to migrating to Drupal 8 and 9

There are some reasons why sites delay making this move:

Lack of Drupal 8 versions of Drupal 7 contributed modules

Early in Drupal 8’s release cycle, one of the big complaints about Drupal 8 was that many Drupal 7 contributed modules no longer worked in D8. It did take time for some contributed modules to be updated to Drupal 8. However, many Drupal 7 contributed modules were no longer needed in Drupal 8, because the functionality they provided is now a part of Drupal 8 core.

If you haven’t checked the state of Drupal contributed modules in the last few years, take a look at what’s now available for Drupal 8. You can check the Drupal 8 Contrib Porting Tracker to find the status of popular Drupal 7 modules and see whether they’ve gotten a Drupal 8 stable release. You may find that modules that were missing early on are now available, or that you no longer need some contributed modules because that functionality is now managed in another way.

More importantly, you don’t have to worry about lack of parity in Drupal 8 contributed modules when Drupal 9 is released; as long as the Drupal 8 module in question isn’t built on deprecated code, everything that works in 8.x should continue to work in Drupal 9. And if a D8 module is built on deprecated code, the maintainer should be aware of it. All the code that is being removed in Drupal 9 has already been deprecated in Drupal 8.8, so there won’t be any surprises for module or site maintainers.

Maintenance overhead for small teams

With the introduction of Drupal 8 and Drupal 9, the new paradigm in Drupal development is more frequent, smaller releases. This mirrors a larger trend in software development, where iterative development means frameworks make more frequent releases, and consequently, those releases aren’t supported as long. 

This means you need to commit to keeping your site current with the latest releases. If you’re part of a small team managing a large Drupal site, you may simply not have the bandwidth or expertise to keep up with updates. 

There are some tools to make it easier to keep a site current. There is an Automatic Updates module that might be helpful for small sites. That module is a work in progress, and it does not yet support contributed module updates or composer based site installs. These are planned for Phase 2. But this is a project to keep an eye on. 

You can manage updates yourself using Composer and Drush. Sites of any size can also use  DependaBot, a service that creates automatic pull requests with updates. 

And of course, some web hosts and most Drupal vendors will provide update services for a fee and just take care of this for you.

The new way of doing things is harder

The final complaint that has prevented many Drupal 7 sites from upgrading to Drupal 8 and Drupal 9 is that the new way of doing things is harder. Or, if not harder, different. There’s a lot to unpack here. In some cases, this reflects resistance to learning and using new tools. In other cases, it may be that long-time Drupal developers have a hard time learning new paradigms. Another option may be that developers are simply not interested in learning a new stack, and may no longer want to develop in new versions of Drupal. 

Drupal 6 and 7 have a lot of “Drupalisms,” Drupal-specific, custom ways of doing things, so developers who have been deep into Drupal for a long time may feel the number of things to re-learn is overwhelming. Fortunately, the “new” things, such as Composer, Twig, and PHPUnit are used by other PHP projects, so there is a lot that Drupal 7 developers can learn that will be useful if they work on a Symfony or Laravel project, for example.

Developing for Drupal 8 and Drupal 9 is certainly different compared to Drupal 7 and older versions. Some developers may choose this as a turning point to shift gears into other career paths, developing for a different stack, or making a more substantial change. But with the Drupal 7 end-of-life approaching, developers who don’t want to move to Drupal 8 and Drupal 9 must make some move, just as Drupal 7 sites must move to a modern platform.

Security considerations

In today's world, enterprises have a responsibility to protect their website users' personal data - and they face costly liability considerations if they don't. For many organizations, this means website security is a looming and ongoing concern. It's common for enterprise security policies to require that organizations only use services with ongoing security support. Relative to the Drupal 9 upgrade, this means that many enterprises can't continue to maintain Drupal 7 websites after they stop receiving security support.

But what does “no more security support” actually mean?

When Drupal 7 reaches end-of-life, the Drupal community at large will no longer provide “official” security updates or bug fixes. The Drupal Security Team will no longer provide support or Security Advisories for Drupal 7 sites. Automated or manual processes that you currently use to update your sites may no longer work.

There is a bit of nuance to the lack of security support, however. The Drupal 7 ES program involves partnering with a Drupal Association-vetted vendor and assuring that the vendor is coordinating responsible disclosure of security issues and fixes while publicly sharing the work toward those fixes.

Practically speaking, this means that even if you’re not partnered with an ES vendor, you can still get security patches for your site. However, websites using modules that aren’t actively supported by ES vendors won’t have the benefit of a partner to hunt down and fix issues with those modules, security, or otherwise. If you have modules or other dependencies that age out of security updates, such as the end-of-life of the PHP version you’re hosting, you may be left with a website with an increasing number of security holes.

Additionally, after November 2021, Drupal 7 core and Drupal 7 releases on all project pages will be flagged as not supported. As a result, third-party scans may flag sites using Drupal 7 as insecure since they’ll no longer get official security support.

No more bug fixes or active development

Alongside security considerations, a lesser concern of the Drupal 7 end-of-life timeline is an official end to community-at-large bug fixes and active development. Drupal 7 development has already shifted to focus on Drupal 8 over the past several years, with Drupal 7 bugs lingering. For example, take a look at the Drupal.org issue queue for Drupal 7 core bugs; you’ll see issues that haven’t been updated for weeks or months, versus hours or days for Drupal 8/9 development issues.

Questions to ask when migrating from Drupal 7

So how do you decide which path is right for your organization? Here are some questions to ask.

What are the skills and size of your development team?

The shift from Drupal 7 to Drupal 8 and Drupal 9 involved a shift from Drupal-specific paradigms to incorporating more general object-oriented programming concepts. If your team consists of long-time Drupal developers who haven't done a lot of object-oriented programming, this paradigm shift involves a learning curve that does have an associated cost. For some budget-conscious organizations, this may mean it's more economical to remain on Drupal 7 while developers work on skilling up for Drupal 8/Drupal 9 paradigms.

Another consideration is the size of your development team. If your team is small, you may need to engage an agency for help or explore the other alternatives mentioned above.

What are the plans for the site?

How much active development is being done on the site? Are you planning to add new features, or is the site in maintenance mode? What is your budget and plan to maintain the site; do you have developers devoted to ongoing maintenance, or is it one small priority among many competing priorities? 

If you're planning to add new features, the best option is to migrate to Drupal 8 and Drupal 9. Drupal 9 is under active development, and these modern systems may already include the new features you want to add. If not, working in an ecosystem that's under active development generally reduces development overhead. 

What is the life expectancy of the site?

How many years do you expect the current iteration of the site to continue? Are you planning to use the site for three more years before a major redesign and upgrade? Eight more years? Sites with a shorter lifespan may be good candidates for Drupal 7 ES, while sites with longer life expectancies would benefit from upgrading to a modern platform with a longer lifespan.

What code is the site using?

Do an inventory of your site's code. What contributed modules are you using? What do you have that's custom? Drupal 8 upgrade evaluation is a good place to start. 

Some Drupal 7 contributed modules have Drupal 8 and Drupal 9 versions available, while others no longer apply in a world with different programming paradigms. Still, others may now be a part of Drupal 9 core. 

If you're using a lot of custom modules and code, migrating to Drupal 8 and Drupal 9 is a bigger project.  You might be able to mitigate some of that by altering the scope of your new site to take more advantage of the new capabilities of core and the available Drupal 8 contributed modules.

What features do you want?

Make a list of the features that are important to your organization. This should include features that your site currently has that you couldn't live without, and features you'd like to have but currently don't. Then, do a feature comparison between Drupal 8 and Drupal 9, and any other options you're considering. This may drive your decision to migrate, or you may decide that you can live without "must-have" features based on availability.

Where to go from here

Bottom line: with the Drupal 7 end-of-life date coming next year, now is the time to scope your site changes. But where do you go from here? The next few articles in this series explore how and when to upgrade from Drupal 7 to Drupal 9 and alternate solutions if upgrading isn’t a good choice for your organization. Stay tuned!

May 27 2020
May 27

Drupal is one of the most popular CMS-es in the world. Currently, over a million websites use Drupal. The larger the website, the more likely it is that it was built on Drupal. Why should you choose it for your project? Take a look at what programmers are saying about this topic. 


Robert developer

Robert develops web applications on a daily basis. He has been doing this for over seven years. 

Why did he decide to work using such a technology?

"Drupal has a ready-made system with clear documentation. It is also a safe tool for building websites. We can be sure that it will work properly and will not be hacked. Confidential data is therefore secure. 
Drupal provides many ready-made modules at drupal.org, making it is easy to organise a website like from building blocks."


Grzegorz developer

Grzegorz has been working with Droptica for almost three years. Every day he further develops Droopler – thus he offers a real contribution to Open Source. Why does he use Drupal?

"Drupal is different from other CMS-es with which it is often compared. Its characteristic feature is open architecture. As website creators, we can choose what data we want to present on the web and how it should be edited. We are not limited to the article/category/static page model – we can freely model the content, responding to even the most specific needs. Building a basic, functional website is extremely fast when compared to other solutions."


Bartek developer

Bartek is not only a PHP developer, but he also has set up his online Drupal-based store.

"I have built a simple platform for selling electronic products that will be easily accessible to those who have paid for the order – everything is automatic, without any additional admin work.

It required installing and configuring several modules and adding a dozen or so lines of my own PHP code. It took several hours of work. The question is: what will help you do it faster?"

Why should you consider Drupal for your next project?

This is a more complicated issue, so: 

1. Immediately after the installation, I have a working page with the most important functionalities for many types of pages:

  • logging in,
  • skins,
  • creating various types of content (fully extensible forms),
  • simple interface for building queries in order to present data in various ways.

 2. Unlimited expansion options:

  • There are many additional modules that add even such complicated functionalities as a store with just a click of a button.
  • Drupal has extensive documentation and a well-described API. If like me, you are not a programmer, you can always use the help of a professional.
  • Drupal uses Symfony components and has a similar structure. If you are familiar with this framework, you will find your way around it quickly.

3. Security

Drupal's security team operates on a very high level. Security updates are being released immediately after finding and fixing any problem with the system.

4. Drupal is Open Source What does it mean exactly?

  • It is free,
  • you can modify it according to your own needs,
  • you are independent of other service providers, so you can develop it yourself or it can be done by any team associated with Drupal.


Mariusz developer

"Drupal 8 is the best CMS written in PHP with programmers in mind. It is also an Open Source platform – accessible by everyone. It is built on Symfony components. It is a very rich API, with a very good and – most importantly – reliable documentation. Why am I a Drupal supporter? It has a huge community that is active and participates in contrib projects. By choosing Drupal as a technology for your website, you get the support of a huge community with members from around the whole world."


These are just a few examples of the programmers' opinions about Drupal. The longer someone works with Drupal, the more clearly, they see its huge number of advantages. Clients also notice this and intentionally choose Drupal as a technology for building their websites, e.g. Bossa or Here.com

If you are thinking about choosing a technology for your company website or web application, consider Drupal. You can find the complete information on Drupal at "Why Drupal".


May 27 2020
May 27
Four people holding a rainbow like flag with clouds and sky in the background

Usually, the restrooms are marked as ‘men/male’ or ‘ladies/female/women at offices, restaurants and other public places. Have you ever imagined yourself being in a state of utter confusion while deciding which restroom to use? No? Well, this is an everyday issue in the life of trans genders and gender-nonconforming people. The sad truth is that they fear harassment and keep running into such unnecessary barriers which makes their life harder. No wonder a report on gender and sexuality by J. Walter Thompson Innovation Group had some staggering revelations to make.

Graph showing the views of Gen Z on trans and diversity

With the world gone digital, web designs are one of the barriers in the life of these people. While filling a form or signing up for something, the options for genders are most likely to be male and female. Rarely, we find websites with either no gender options (when not required) or other preferable options to choose from.

In order to provide the best user experience, you need to understand how the facet of their lives intersects with your website. For that, it becomes important to educate ourselves about the LGBTQ terminologies and issues so that you develop a sense of when and what is appropriate to say or ask. If you want to increase the lifetime value of your customers, you need to make your website more trans-inclusive which will enhance the user experience for everyone.

Getting things right

Using gender inclusive language and designs means writing or speaking in a way that does not discriminate against a particular sex or gender role. Moreover, it promotes gender equality and stands against gender bias.

Designers should not limit the gender options to male and female, and definitely not make it mandatory! In fact, gender should not be asked where it is not needed. And wherever required, the gender options should not be limited.

Key Considerations for gender-inclusive design

Key considerations for gender-inclusive design

Before asking for the gender of a person, make sure you have a good reason behind why you need that information. And when you are sure that it is needed, make sure you give more diverse options to choose from. ‘Prefer to self identify’ or ‘add your own’ are great additional options. 

When people are not identified as male or female, they do not like being referred to as ‘he’ or ‘she’. Hence, you can ask for pronouns, so they can be referred to correctly during their experience with your website or app.

Images representing different body sizes, genders on the websites and ads allow room for representation. You can hire models for photoshoots. If you cannot have your own photoshoot, you can use the trans-inclusive stock photo collection launched by Broadly which is free for wide use.

If you ask needless questions or limit the options for the users to select, you lose value in the eyes of the users. Designers should make sure that they put in options that do not perpetuate gender stereotypes. 

There should also not be any sort of restrictions to make changes. Once, someone creates a web address, username or complete profile, they should be allowed to make changes if required. The users should be made aware that their information will not be shared with anyone. And if there is some kind of information that needs to be shared, let the users know. This will make them feel safe and build trust.

It is important to have a name change process. It is likely that you have one for marriage related name changes already. Create a process that allows anyone to change their names without any legal documents.

Many websites and applications incorporate gender in their designs and products even though the product is gender neutral. Like, clothing, wine or toys etc. Brands should evaluate an alternative and see what else can be done. Several OTT platforms ask for gender while signing up which is not really needed.

 A purple background with Two gender options written on it: Male and Female
Zee 5, an Indian OTT app, while signing up had male and female as the only two options while asking for gender. Snapchat settings pageSnapchat profile setting menu does not ask for gender.

There are a lot of gender options and so it is not possible to use all of them. And even if you want to, you will have to change the control you use. For example, consider this screenshot.

A personal details page of a form with multiple gender optionsSource: keepitusable


We all want to be treated with dignity and respect regardless of our gender, religion, or where we come from. So, make sure that these diverse groups feel at home when they visit your website. Eliminating gender inequality is the future of design. 

So tell us, are you ready to ‘trans-form’ your website?

May 27 2020
May 27

Greg HarveyContinuing our short series of articles highlighting ways that the Drupal software and its community are building solutions to help combat the effect of COVID-19, today we hear from Greg Harvey of Code Enigma. Here, he describes their project at the the National STEM Centre in York, England

STEM stands for Science, Technology, Engineering and Mathematics. STEM Learning is the company that built and operates the National STEM Centre in York, England. They provide specialist training in STEM subjects to teachers from across the UK. As well as classroom training opportunities in state of the art facilities, they provide free, high-quality online education resources via their website. They have been using Drupal to deliver this important content since 2015.

Supported by their principle Drupal services supplier, Code Enigma, STEM Learning increased their server capacity when it became clear the COVID-19 pandemic was going to hit and many children in the UK would soon be homeschooling. 

STEM anticipated increased demand (having seen how online education resources in France were beginning to feel the strain of school closures (one of Code Enigma’s directors is a parent in France) and decided to react before it became an issue. 

Code Enigma is also an AWS Select Tier partner. The website is hosted at AWS, so it was possible to quickly scale the solution using AWS’s public cloud products and services. The fact that Drupal is ready to Enterprise-scale right out of the box, with the right support, was also extremely helpful.

Consequently, when the UK Department for Education contacted STEM Learning to inform them they wanted to sign-post teachers and parents to the website from the main UK government website, everything was already in place. Code Enigma’s developers and designers worked quickly with STEM Learning to adapt the front page to help people find homeschooling resources efficiently. They also designed and created some new landing pages, such as this one for parents, to help people get straight to the relevant content.

In short, thanks to Drupal, STEM Learning is actively supporting homeschooling in the UK during this global pandemic, by providing high-quality teaching resources online and for free.

Screenshot of STEM website

May 27 2020
May 27

We live in the age of the digital, with digital experiences an intrinsic part of our everyday lives. This means that now more than ever there’s a need for incredible amounts of people who have the skills to craft compelling experiences in the digital. A large portion of them is represented by software developers.

However, one of the main characteristics of the digital is its unbelievably fast pace. There are new trends and technologies emerging constantly, and it’s very difficult to keep up, especially for larger businesses whose digital endeavors are broader and encompass multiple different channels. 

What this means is that all these highly skilled developers need to at once be familiar and experienced enough with existing technologies and prepared for any future trends that might emerge further on. It’s definitely no easy task finding and retaining this perfect blend, especially with the unprecedentedly high demand for developers today. 

In this post, we’ll dive deeper into the importance of a development team that’s future-ready, explain what future readiness even means, and look at some tried and tested methods for acquiring a team of future-ready developers. 

What does it mean to be future-ready?

Future readiness means different things for developers and businesses, so we’ll define each separately. Still, both of them ultimately tie together: due to the need for digital experiences, business future-readiness depends majorly upon developer future-readiness.


If a developer is future-ready, it means they are familiar with and follow best practices, know and effectively implement accessibility guidelines, and are up-to-date with a range of technologies as well as trends (e.g. web components, lazy loading, etc).

They don’t necessarily have to be experts at obscure emerging frameworks, but they do know enough about the state of the software development landscape that they’re able to adopt a new technology if it turns out to offer a significant business advantage, or a greatly improved developer experience.

When it comes to a future-ready development team, one of the most important characteristics is the developers’ ability to cooperate internally. They are able to complement each other’s potential skill gaps to deliver a cohesive final product. 


A business that’s future-ready is not locked into a system that doesn’t allow integrations, or that’s dependent on a lot of other technologies that are outdated. 

It’s built on a platform that can scale and that is owned by the business, not a third party. It has the capability of integrating new technologies, and is optimized for mobile and multichannel digital experiences.

By investing in their employees’ growth, as well as by following industry standards and agile methodologies for swift iteration, it is resistant to disruption and always able to use its familiarity with the digital to its advantage.

Why do you need a future-ready development team?

This is more or less a no-brainer; if you want your digital business to be future ready, the baseline of that business has to be future ready. 

Plus, the future is uncertain - that means, while you can never be fully prepared for it, you have to do what you can to at least be somewhat prepared. There are new technology trends emerging all the time, and if you want to be on the cutting edge, you need to be able to leverage them when you or your clients need them. 

Also, considering the current disruption, the nature and importance of digital experiences are themselves changing - right now, for example, we’re seeing a major rise in e-commerce and video conferencing solutions. Those that respond quickly without having to change course have an obvious advantage in navigating such crises. 

This is where a future-ready development team comes into play. It’s even more convenient if you leverage the expertise of a skilled development agency, as you don’t have to invest a lot of resources into vetting and re-/up-skilling your in-house employees, but rather get a readymade team of developers possessing the exact skill-sets that you need.

If you are, for example, a startup building your groundbreaking tech product, you’ll definitely want to make use of the most innovative technology available to you, as well as make sure you’re working with vetted experts who follow best industry practices. Read here how proven Agiledrop engineers can help you build high-end digital products. 

What’s the best way to secure a team of future-ready developers?

As with any developer, there are several ways, e.g. outsourcing (to an agency or a freelancer) or in-house. For a future-ready team, however, it’s even more important that you’re able to get exactly what you need without too much additional overhead. 

With everything going on recently, it’s become incredibly difficult to attract in-house talent that fits your needs, let alone vet them and/or invest into up-skilling your existing talent. As stated, your best bet right now would be to partner with a company that’s focused exclusively on development, as you can be sure they’ll invest their energies into being up-to-date. 

For complex projects that require various technologies all functioning together, you’d typically need a full team, not just a single developer. Cherry-picking the team with the exact needed skill-sets from a pool of available freelancers would likely be a very time consuming and costly process - plus, you get no guarantee that these individual developers will work well together.

A development company such as Agiledrop can provide a full team that is used to working together and collaborating on complex problems to deliver smooth and efficient solutions. Our engineers are encouraged to learn about any new technologies that interest them, and to share what they’ve learned with the whole team during monthly AgileTalks. 

As is also obvious from our name, we follow agile methodologies in all our projects, but we ultimately always adapt to our clients’ workflow, adopting their tools and processes. This ensures that, while our clients benefit from our expertise in the latest trends, this benefit never comes at the expense of internal consistency. 

So, if you’re currently in the process of searching for a future-ready development team, you’re in luck - get in touch with us and find out how our skilled engineers can help you deliver just the product you need. 


The faster the pace of the digital, the more important it is to be future-ready. And, as drivers of digital experiences, developers and engineers are key in guaranteeing digital-based future readiness. 

Future-ready businesses have an obvious competitive edge, but it is not always possible to invest in an in-house team of future-ready developers. In those cases, finding and partnering with a development company that’s able to provide the right skills for your needs is definitely the best bet. 

Ideally, you’d also want that partnership to be long-lasting, so that you don’t have to search for the right partner again during every big project. If you’re able to secure a partner that can accommodate your digital requirements when you need them, you’ll never again have to worry about future disruption - you’ll be future-ready.

May 27 2020
May 27

In this series about building multilingual sites, we will use Drupal as our central content management system. In this blog, we will dive into how we can implement translation for different features based on defined user stories with Drupal core and contributed modules.

Getting started: elaborate on a process

Having a good translation strategy starts at the early beginning of a project. Here are a few topics that could help to elaborate a process.

The translation strategy could be approached in several ways depending on the project:

With a minimum viable product (MVP) or a new project build

  • Fully translated, with several languages, for the first release

  • A proof of concept in a single initial language

  • A subset of languages first, then add more languages at a later phase

  •  ...

With upcycling an existing project or doing a project migration

  • The source and destination content model might not be the same

  • Some translations could be partial or outdated

  • ...

For both content creation and update, we should be able to answer the following questions:

  • Who are the personas? They could be represented by Drupal roles: content editor, translator, reviewer, publisher, …

  • What are their relations with the translation system, which features can help their work?
  • How will the content and features access be handled?

  • How will the content flow between personas, is there a publication workflow? Example: when the source is ready for translation is a simple workflow enough (translation review then publication) or do we need a more elaborate process that allows back and forth between reviews?

  • Are revisions required? Would it be possible to roll back a previous revision and how does it affect translations? Also what happens when the source is updated?

  • What are the relations between languages? Are we able to translate from another language than the source?

  • For locale, how can I make use of a first contributed version then override it, handle change and provide flexibility when more context is needed?

  • What are the available resources? In house translators, one or several specific translation agencies that might be business-specific, automated translation services? How do we want to deal with deadlines and scheduled publications?

  • How does it integrate with third parties (if any)? Translators could be part of a CRM or translation jobs might need to be reported in an accounting system.

  • What is the translation scope? It could be frontend and/or backend, do we want URL aliases to be translated?

  • Do we have to deal with external entities (e.g. content being imported and updated from an external service)?

  • Do we need a different structure between the source and the translation?

  • How does the translation fallback behave? Do we want to display the source, display a message, redirect, …?

Drupal multilingual concepts

Let’s see what Drupal brings out of the box. Here is a quick recap of the Drupal translation concepts.

  • Interface translation: also known as “locale”, it can be handled via Gettext / .po files. It includes strings passed through the t() function or trans Twig tag, these strings are also contained in Yaml files (module name in the info file, schema label, title in routing and annotations. They are not synced between environments by default, but their import can be automated.
Example: the label of a button in a Twig template

  • Configuration entities: core, contributed and custom modules are providing them via their schema. They can be synced via the configuration export/import between environments.
Example: strings set for Views, Blocks, settings, …

  • Content entities: their blueprints are made from configuration. They are specific to each environment by default.
Examples: Nodes, Terms, Users, Media, ...


With the Drupal capabilities in mind, we could continue by refining some parts of our process as common user stories, by project stakeholders. Then see how it can be covered with the core or contributed ecosystem. Here are some examples of possible expectations.

As a Product Owner, I can

  • have an overview of all the translations and their status

  • access each node translation without having the admin UI translated

  • edit translations that are defined by code

As a Translator, I can

  • be notified of new translation requests without having to access a Drupal site

  • receive structured files like .xlf or .po that I can use with other translation solutions than Drupal

As a Translation Reviewer, I can

  • let know the Publisher that a translation is ready for publication

As a Site Builder, I can

  • limit the edit / view access to several languages to translate content before publishing it, as a whole for a language

  • limit the access to translation languages, by user

As a Developer, I can

  • add metadata to locale by specifying context related strings

  • have support for plural

  • update locales between environments

  • extract translations from custom code

  • make sure that every string is translatable

  • migrate content with translations and map them to a new content model

Translations in the wild

Content translation will be developed in the second part of this series, so let’s see first how some of these user stories can be covered by the contributed ecosystem and which tools are available for developers.

Drupal core (>= 8, 9)

Each core concept is basically covered by its own module with the Language module as the common requirement: Configuration Translation, Content Translation, Interface Translation.

Make the source language editable

Since 8.5.0, the Interface translation module provides an easy way to enable interface translation for the site default language. Given that English is the default language: edit the English language and check “Enable interface translation to English”. In a sense, it can be regarded as a successor of String Overrides.


Multilingual migrations are stable (8.9.0, 9.0.0). Migrate Drupal Multilingual module is no longer required.

Translation context

Context can be used to provide or identify variations of the same string.
So it can also be used to group translations for business-specific translations (e.g. custom code) that might not fall in the scope of contributed translations by adding metadata.

This issue aims to provide context filtering in core (> 9.x) so it will replace modules like Locale Translation Context.

Examples of context definition

  • PHP $this->t('May', [], ['context' => 'Long month name']);

  • Twig <span>{% trans 'May' with {'context': 'Long month name'} %}</span>

  • Javascript Drupal.t('May', {}, {context: 'Long month name'});

  • PHP annotation label = @Translation("Month", context="Date"),

POEdit with context

The core API

The core provides great services to deal with translations, like 

Contributed solutions

Translation Management Tool (TMGMT)

TMGMT facilitates the translation process and really shines if you need to export the data structure with the content while outsourcing a translation Job.
It supports a large variety of translation service providers (Lionbridge, DeepL, Google, ...) and provides support for content, configuration and interface translation. These 3 sources are displayed as an overview, so it replaces solutions like Translation Overview.

The beauty of this unified solution is that you can outsource translations with any of the provider (like DeepL), and e.g. create a Job that groups each locale string as Job items.

Translation Extractor (POTX)

The Drupal core interface translation export (admin/config/regional/translate/export) will export basically everything that is available in the interface translation UI. This module provides

  • string extraction from code, instead of strings that have previously been registered

  • filtered extractions as .pot (template) or .po files by language with optional inclusion of the translations.

The Drupal 8 version is still a working in progress, make sure to review these issues:
String context not taken into account when retrieving a translation and Plural translation values are not exported.

TMGMT Source

Disable Language
Filters out disabled languages from the language switcher and sitemap redirects users that don’t have the permission to view disabled languages and much more.

Allowed Languages
Set restrictions on which content a user can edit by language.

Administration Language Negotiation
Its main use case is to allow displaying the frontend of the site in one language and still keep most of the backend in English (or another language of your choice).

Since 8.6.4, this behaviour can still be partially achieved for the backend, with core configuration, by using the Account administration pages as a detection method for interface text.

Paragraphs Asymmetric Translation Widgets
While using Paragraphs, it could be required to have a different structure between the source and the translations. Make sure to carefully test it if you switch from Paragraphs default widgets as data loss might occur if you already have translations. Also, there might be some limitations while using TMGMT.

Drush supports locale check, update and import (see https://localize.drupal.org/translate/drupal8)

Quick tips

Having an overview of the content model (entities and relations) can help to answer accurately some site-building questions:

  • which entities are the subject of a content moderation

  • which ones are translatable (entity and field level)

  • which tools might answer the requirements (Paragraphs, Blocks, …)

  • how does it integrate with site search (e.g. while using Search API)

Troubleshooting common errors:

  • Interface: Check if the string is wrapped in a t() function or trans tag. Reduce duplicates early (interface translation strings are case sensitive).

  • Content: check the translatability of your entities and fields, the Content language UI is a great tool for this (/admin/config/regional/content-language)

  • Configuration: the schema or the .config_translation.yml files might be missing.

Making use of context early for business-specific translations might help later to include translation metadata to export or filter.


More to come on this topic

In the next blog, we'll adapt our content translation flow and delegate this to the Translation Management Tool (TMGMT), where we will tackle different approaches to solving complex issues such as using content moderation for symmetric and asymmetric translation.
Finally, we'll finish off the series with a third instalment to look into how we've approached and solved a complex Gatsby multilingual integration with Drupal 7, and how this can be applied to a decoupled Drupal 8 site. 

Questions? Comments? Want to learn more? Get in touch with us today!

May 27 2020
May 27

In the era of Information overload, data can talk and communicate powerful stories. Here is  what we did while building an Aid Transparency portal for a large Non Profit, communicating using data made the portal “Come Alive” and  present to the users the impact of the work done by the organization.The approaches implemented include:

  1. Use of Data Highlights
  2. Intuitive Search Interface
  3. Data Visualization
  4. Use of Animation in Design

Aid Transparency is about presenting data around donors, funds received, fund utilization/expenses, areas of impact in  a transparent manner. The first step was a study of the customer’s domain and the work carried forward by the customer organization. Understanding the donors, the impact areas, the funds received, funds utilized, regions in which they work. Mapping all the key parameters of the underlying data, their meta information and their inter-relationships.

A sitemap was defined to communicate the different perspectives of the data like: pages on fund utilization, pages that were contribution/donor specific, pages that detailed the resource utilization, etc. The best graphical visualization was identified for these pages. Yet some of this graphical information could be overwhelming for  visitors who do not relate to the representation and numbers.  To further simplify this, a layer of Data Highlights was introduced.  The Data Highlights  represented a one line story around the data that was presented and was much easier for a lay user to understand. These Data highlights were presented on the homepage and across the site.


Above is a sample Data Highlight that leads to a page that allows you to see the utilization of funds, based on the area of impact, region and year.

Intuitive Search Index 

A very important feature on a data-intensive site are the Search Interfaces. To make them intuitive, Narrative based Search Interfaces were implemented.

On the homepage a Natural Language form was used to identify the type of the audience and understand the area of interest of the user to direct the user to the exact section in the site that would meet his needs.


In scenarios where distribution of data needs to be presented across locations or location is one of the key attributes, using Maps to present the data helps the user to drill down to the location of choice. 

Data Visualization

Effective use of Bar-charts, Doughnut charts, Sankey Flow diagrams, Maps were used to present data. The Visualization of data makes it easier for the user to understand the data and each of them represents a particular Data Story.


  • Bar charts are used to compare categorical data. They are oriented vertically instead of horizontally. The main advantage of bar charts is that it is better with many categories, especially on a small screen, as the height can be adjusted to show all categories. 
  • Donut charts are the same as a pie chart, but by only displaying an area along the outer edge of the pie, it becomes easier to compare the elements to each other. These are used to present the data as a percentage of sum total as 100%. In Donut charts, the space in the middle could also be used to communicate additional information.. 
  • A Sankey diagram is a type of flow diagram, in which the width of the link between two nodes is shown proportionally to the flow quantity. Here this is used to depict the flow of Funds from Donors to area utilization or to type of supplies used.
  • Map Charts are used when we need to show distribution across geographies. In this case both impact and fund utilization across geographies is presented using maps.  Additionally Map also serves as a navigation tool to zoom in to identify the destination the user is looking for to get more specific information.

Use of Animation in Design

The home page used a video in the background to tell the story about the organization. Simple Animations on the page helps to bring the page alive. In the Data Visualization some of the popular Animations used were timeline animations, growing bar charts, rotating pie charts. These animations helped amplify the Data Story put forth by the visualizations.


This Site has been built using Drupal Solr and Highcharts.

May 27 2020
May 27

The systems and subsystems related to Drupal’s migration API are certainly exciting. In the previous articles in this series, I wanted to draw as complete a map as possible (part one) of the vast amount of resources, possibilities and referenced experts. In the second part I wanted to expose some basic mechanics of the migration processes in Drupal and knowing that this opens the door to thousands of options, possibilities and techniques&mldr;.I didn’t want to let a third article go by without sharing some experiences migrating data from a common format as a Google Spreadsheet, just an usual way in wich sometimes the data are sent.

Picture from Unsplash, user Pan Xiaozhen, @zhenhappy

Table of Contents

1- Introduction and remember ETL processes
2- Exposing data through Google Spreadsheet
3- Special Properties from the JSON transformation
4- Characteristics of the Migration
5- Custom Module for Migration
6- :wq!

This article is part of a series of posts about Drupal Migrations

1- Drupal Migrations (I): Basic Resources

2- Drupal Migrations (II): Examples

3- Drupal Migrations (III): Migrating from Google Spreadsheet

1- Introduction (and remember ETL processes)

Well, I would like to start by posing a scenario: imagine that we must migrate a list of taxonomy terms to our Drupal Installation. The source of the data is important, since it defines what type of Plugins we will have to use (source Plugins for the extract, but it can also have influence for the processing and for the final load in destination).

The imagined scenario of this article will be the following: we have “inherited” a migration task already initiated by a previous partner. This migration consists of populating an existing vocabulary in our Drupal installation with taxonomy terms.
To practice with other Plugins and other migration models, I thought we can take a Google spreadsheet as a source of data. Let’s not forget the frame we’re in:

ETL Scheme and Drupal Migrate API overview

Today our goal will be to fill the fields of a taxonomy term using the data contained in a external Google Spreadsheet. So we have to complete these fields:

Taxonomy term basic fields

And we’re going to do this describing a Migrate Process and executing it as Configuration. Do you know the differences between migrations as code and as configuration? You can learn some keys about this topic here, in the previous article about Migrations.

2- Exposing data through Google Spreadsheet

So now, to perform source data extraction, we’ll need a spreadsheet with exposed values. I’ve created a Google spreadsheet here at this address. This Google Spreadsheet contains some columns with values related with fields of a taxonomy term, ready for migration.

In order to processing the data source we’ll use the Migrate Google Sheets contrib module from Drupal.org, so you can run your Composer to download the resource. Just launch:

composer require drupal/migrate_plus #If applicable
composer require drupal/migrate_google_sheets
drush en migrate_plus migrate_google_sheet -y

This contrib module will treat the resource as a JSON file, though for that we have to do some tasks previously. For example, we have to expose the Google Spreadsheet like a JSON datasource, using the tools provided by Google.

  • First, we need extracting the workbook-id of our Spreadsheet: docs.google.com/spreadsheets/d/1bKGbPbgeuXaBfcKetaDqoDimmYcerQY_hT1rqzw4TbM/ -> workbook-id: 1bKGbPbgeuXaBfcKetaDqoDimmYcerQY_hT1rqzw4TbM.

  • Second, we need the worksheet-index too. This is only the index of the tab with data from the Spreadsheet. In this case -> worksheet-index: 1.

  • Third, Building the JSON exposed URL using the pattern: spreadsheets.google.com/feeds/list/[workbook-id]/[worksheet-index]/public/values?alt=json, for us: http://spreadsheets.google.com/feeds/list/1bKGbPbgeuXaBfcKetaDqoDimmYcerQY_hT1rqzw4TbM/1/public/values?alt=json.

That’s all! now we got an exposed Google Spreadsheet as a JSON file and now we can get the values from the selected Source Plugins of the Drupal Migrate API.

Google Spreadsheet JSON dataformat

3- Special Properties from the JSON transformation

Now we’re seeing our Json datasource from our browser (maybe better you use some kind of extension for your browser in order to get a well-formed view of the Json data, like Firefox is doing by default):

        "gsx$id": {
          "$t": "1"
        "gsx$name": {
          "$t": "Term 1"
        "gsx$description": {
          "$t": "Descrip 1"
        "gsx$url": {
          "$t": "/t1"
        "gsx$published": {
          "$t": "1"

As we can see, some items has been changed from the original format. Look there:

Comparing data formats

An important observation about this transformation is that the move to JSON format includes some changes over the original spreadsheet. For example, the field identification is modified by Google by adding certain prefixes to the name:

  • gsx$ for field names.
  • $t for values stored in fields.

And the headers has been changed:

  1. ‘Id’ is now ‘gsx$id’
  2. ‘Name’ is now ‘gsx$name’
  3. ‘Description’ is now ‘gsx$description’
  4. ‘Url’ is now ‘gsx$url’
  5. ‘Published’ is now ‘gsx$published’

But since these changes are stable, the Plugin takes care of their processing:

// Class GoogleSheets.php
// Module migrate_google_sheets
// @see https://git.drupalcode.org/project/migrate_google_sheets/

// Actual values are stored in gsx$<field>['$t'].
$this->currentItem[$field_name] = $current['gsx$' . $selector]['$t'];

This allows us use simply the names of the data in their exposed ‘flat’ transformations: all will be in lowercase and with spaces or special characters removed. In addition, the values are stored in an XPath feed/entry path, which the module will also take over:

// For Google Sheets, the actual row data lives under feed->entry.
if (isset($array['feed']) && isset($array['feed']['entry'])) {
 $array = $array['feed']['entry'];

4- Characteristics of the Migration

The first observation we will make is that the Google Spreadsheet Plugin is actually an extension of the Json Processing Plugin, as we can see in the class:

use Drupal\Core\Plugin\ContainerFactoryPluginInterface;
use Drupal\migrate\MigrateException;
use Drupal\migrate_plus\Plugin\migrate_plus\data_parser\Json;
use GuzzleHttp\Exception\RequestException;

 * Obtain Google Sheet data for migration.
 * @DataParser(
 *   id = "google_sheets",
 *   title = @Translation("Google Sheets")
 * )
class GoogleSheets extends Json implements ContainerFactoryPluginInterface {

Also we can see that the GoogleSheet Plugins is marked as a Data Parser in its block annotations, sowe’ll need some more resources: a base source Plugin and a Data Fetcher (then the Google Spreadsheet Plugin will be the third part in the process).

Ok, What Source Plugins are available in my Drupal installation? Let’s see. Launching:

drupal debug:plugin migrate.source

We’ll get by prompt:

[email protected]:/var/www/html$ drupal debug:plugin migrate.source  
 --------------- --------------------------------------------------------- 
  Plugin ID       Plugin class                                             
 --------------- --------------------------------------------------------- 
  embedded_data   Drupal\migrate\Plugin\migrate\source\EmbeddedDataSource  
  empty           Drupal\migrate\Plugin\migrate\source\EmptySource         
  url             Drupal\migrate_plus\Plugin\migrate\source\Url            
 --------------- --------------------------------------------------------- 

[email protected]:/var/www/html$ 

Ok, as a Source Plugin we can use the class Url.php (our file is exposed by URL). In the Url.php class, we see that we need some king of data parser (The Google Spread Sheet class).

   * The data parser plugin.
   * @var \Drupal\migrate_plus\DataParserPluginInterface
  protected $dataParserPlugin;

And looking for a fetcher / handler, we can find out a data fetcher for http processing, the class Http.php ready to work with a Url Plugin as source:

 * Retrieve data over an HTTP connection for migration.
 * Example:
 * @code
 * source:
 *   plugin: url
 *   data_fetcher_plugin: http
 *   headers:
 *     Accept: application/json
 *     User-Agent: Internet Explorer 6
 *     Authorization-Key: secret
 *     Arbitrary-Header: foobarbaz
 * @endcode
 * @DataFetcher(
 *   id = "http",
 *   title = @Translation("HTTP")
 * )
class Http extends DataFetcherPluginBase implements ContainerFactoryPluginInterface {

From another side, seems that the Url.php class requires url directions from its constructor method. We can use single URL directions or a set:

   * {@inheritdoc}
  public function __construct(array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration) {
    if (!is_array($configuration['urls'])) {
      $configuration['urls'] = [$configuration['urls']];
    parent::__construct($configuration, $plugin_id, $plugin_definition, $migration);

    $this->sourceUrls = $configuration['urls'];

So by putting together the different parts we’re looking at, it looks like we’ll have to give a structured form to the elements, according to their order and position. In short, our first section for the Source would look like this:

  plugin: url
  data_fetcher_plugin: http
  data_parser_plugin: google_sheets
  urls: 'http://spreadsheets.google.com/feeds/list/1bKGbPbgeuXaBfcKetaDqoDimmYcerQY_hT1rqzw4TbM/1/public/values?alt=json'

5- Custom Module for Migration

We’ll create a new custom module called migration_google_sheet and with structure:


Migration Description File: migrate_plus.migration.taxonomy_google_sheet.yml

langcode: en
status: true
      - migration_google_sheet
id: taxonomy_google_sheet
label: 'Migrating Taxonomy'
  plugin: url
  data_fetcher_plugin: http
  data_parser_plugin: google_sheets
  urls: 'http://spreadsheets.google.com/feeds/list/1bKGbPbgeuXaBfcKetaDqoDimmYcerQY_hT1rqzw4TbM/1/public/values?alt=json'
    - name: id
      label: 'Id'
      selector: id
    - name: name
      label: 'Name'
      selector: name
    - name: description
      label: 'Description'
      selector: description
    - name: url
      label: 'Url'
      selector: url
    - name: published
      label: 'Published'
      selector: published
      type: integer
  name: name
  description: description
  path: url
  status: published
  plugin: 'entity:taxonomy_term'
  default_bundle: tags

So now, executing the migration from prompt:

drush en migration_google_sheet -y 
drush migrate:import taxonomy_google_sheet

[notice] Processed 30 items (30 created, 0 updated, 0 failed, 0 ignored) - done with 'taxonomy_google_sheet'

Well done! We just migrated thirty taxonomy terms from a Google spreadsheet:

Taxonomy Terms Just migrated

You can download or clone the custom Migration module from my gitlab repository.

[embedded content]

May 26 2020
May 26

Now that decoupled Drupal has permeated the Drupal community, even to the furthest extremes, articles (including my own) introducing concepts and how-to tutorials describing how you can build your first decoupled Drupal architecture are ubiquitous. As a matter of fact, decoupled Drupal now also has a book on the subject as well as an annual conference dedicated to the topic. Particularly with the JSON:API module in Drupal core as of 8.7.0, decoupled Drupal out of the box has never been easier.

But despite the brilliant spotlight shining on decoupled Drupal from all corners of the CMS industry, there are lesser-known secrets and hidden treasures that reflect not only the innovative character of the Drupal community but also some true gems that can accelerate your decoupled Drupal implementation. Whether in the area of web services or the category of Drupal modules that extend those same web services, there are myriad components of the decoupled Drupal experience that you may not have heard of before.

In this multi-part blog series, we’ll delve into a few of these concepts in this companion piece to the recent session I (Preston So, Editor in Chief at Tag1 Consulting and author of Decoupled Drupal in Practice) gave entitled “Secrets of the decoupled Drupal practitioner” at DrupalCon Seattle in April. We’ll first venture through a rapid reintroduction to decoupled Drupal before moving progressively up the stack, starting with web services and ending with some of the consumer tooling available to help you maintain high velocity.

A quick introduction to decoupled Drupal

In short, monolithic Drupal consists of a contiguous Drupal architecture that cannot be separated into distinct services. In other words, the default Drupal front end is inextricable from the larger Drupal monolith because of all the linkages that require the front end to remain coupled to the back end, including data references in the theme layer and other tools like the Form API, which allows for the rendering of forms in the Drupal presentation layer according to certain back-end logic.

Defining decoupled Drupal

The simplest definition of decoupled Drupal is also one that adheres to the larger definition of decoupled CMS (and an exhaustive definition is also available in my book Decoupled Drupal in Practice). In short, a decoupled CMS is a content or data service that exposes data for consumption by other applications, whatever these applications are built in, including native mobile, native desktop, and single-page applications. Whereas a single Drupal site could serve a single consumer, in today’s landscape, many practitioners are implementing a single Drupal site that simultaneously acts as a repository for a wide variety of consumers.

The original iteration of decoupled Drupal came in the mid-2010s with the advent of progressively decoupled Drupal. In this paradigm, rather than separating out the front end into a separate implementation, a JavaScript framework could be interpolated into the existing Drupal front end and have access not only to ES2015 capabilities but also certain data Drupal makes available to its presentation layer.

Universal JavaScript

With the proliferation of Node.js and the enablement of server-side JavaScript, Drupal began to be relegated more to concerns surrounding API provisioning and structured content management, while JavaScript application libraries and frameworks like React and Vue.js could take over for all rendering concerns, not only on the client side but also on the server (for both progressive enhancement and search engine optimization purposes).

A typical architecture that implements decoupled Drupal in conjunction with a universal JavaScript application (shared JavaScript code for rendering across both client and server) would facilitate the following interactions: During the initial server-side render executed by Node.js, the application fetches all data synchronously from Drupal to flesh out the render that will be flushed to the browser. Then, when the client-side bundle of the application initializes, the initial render is rehydrated with further asynchronous client-side renders that retrieve updated data from Drupal as needed.

There are many risks and rewards involved in implementing a decoupled architecture of this nature, especially in terms of architecture, developer experience, security and performance, and project management. For more information about these advantages and disadvantages as well as more detailed background on decoupled Drupal, consult my new book Decoupled Drupal in Practice (Apress, 2018).

An alternative API: RELAXed Web Services

While JSON:API and GraphQL have seemingly received all the airtime when it comes to web services available in Drupal, there is another web service implementation that not only adheres to a commonly understood specification, like JSON:API and GraphQL, but also enables a variety of new functionality related to content staging and offline-enabled website features. RELAXed Web Services, a module maintained by Tim Millwood and Andrei Jechiu, implements the Apache CouchDB specification and is part of the Drupal Deploy ecosystem, which provides modules that allow for rich content staging.

An implementation of CouchDB stores data within JSON documents (or resources) exposed through a RESTful API. And unlike Drupal’s own core REST API, now mostly superseded by the availability of JSON:API in core as of Drupal 8.7, CouchDB implementations accept not only the typical HTTP methods of GET, POST, and DELETE, but also PUT and COPY.


RELAXed Web Services occupies a relatively unique place in the Drupal web services ecosystem. The diagram above, which is not exhaustive, illustrates some of the ways in which Drupal’s major web services modules interact. Some depend on only the Serialization module, such as Drupal’s JSON:API implementation (prior to its entry into Drupal core), while others such as GraphQL rely on nothing at all. RELAXed Web Services relies on both REST and Serialization in order to provide its responses.

Thus, we can consider RELAXed Web Services part of the RESTful API segment of Drupal’s web services. The above Euler diagram illustrates how GraphQL, because it does not adhere to REST principles, remains uniquely distinct from other modules such as core REST, JSON:API, and RELAXed Web Services. While all RESTful APIs are web services, not all web services are RESTful APIs.

Installing and configuring RELAXed Web Services

To install RELAXed Web Services, you’ll need to use Composer to install both the relaxedws/replicator dependency and the module itself:

    $ composer require relaxedws/replicator:dev-master
    $ composer require drupal/relaxed
    $ drush en -y relaxed

Fortunately, RELAXed Web Services does not require you to use its content staging capabilities if you do not wish to, but you will need to configure the Replicator user and install the separate Workspaces module if you wish to do so. Without the Workspaces module enabled, the default workspace that is available by default in RELAXed Web Services is live, and we will see in the next installment of this blog series why that name is so important.

The screenshot below displays the RELAXed Web Services settings page, where you can configure information such as the Replicator user and customize an API root if you wish to prefix references to your resources with something different.


While covering the full range of RELAXed Web Services' capabilities is beyond the scope of this first installment, I strongly encourage you to take a look at what is available with the help of the Apache CouchDB specification, as some of the use cases that this approach can enable are unprecedented when it comes to the future of user experiences leveraging decoupled Drupal.


In this blog post, we embarked on a rapid-fire reintroduction to decoupled Drupal for those unfamiliar with the topic as well as a deep dive into one of the most fascinating and seldom discovered modules utilized in the decoupled Drupal space, RELAXed Web Services, which implements the Apache CouchDB specification. In the process, we covered how to install the module before turning to how to use RELAXed Web Services to implement a variety of data requirements in decoupled Drupal architectures in the next installment.

In the next installment in this multi-part blog series, we'll cover how to employ RELAXed Web Services for common needs in decoupled Drupal architectures and some of the intriguing ways in which the module and its surrounding ecosystem enable not only content staging use cases but also offline-enabled features that satisfy the widening demands that many clients working with decoupled Drupal today have on a regular basis.

Special thanks to Michael Meyers for his feedback during the writing process.

Photo by Michael Dziedzic on Unsplash

May 26 2020
May 26

Many costs are associated with developing a new ecommerce site or migrating from an antiquated setup to an upgraded version. And unless you work in the thick of ecommerce development every day, you likely don't know what questions to ask to ensure you’re getting the full picture.

This article explains what your typical expenses will look like and makes a few suggestions about how to approach budgeting for this undertaking.

Open Source vs. SaaS: A Comparison of Costs

You need to decide whether you will go with open source or a Software-as-a-Service (SaaS) platform to power your site. The cost of doing business is very different with each model.

An open source ecommerce framework has the expenses front-loaded. You pay for development time and configuration costs, and then the final product is yours to own and manage—license-free. 

A SaaS approach is quicker to get live and has lower costs up front. But then you pay an annual license fee and give a percentage of your revenue to the platform with each transaction made. 

Start by doing some easy math. Calculate three percent of your average annual sales. With an SaaS approach, if you sell $50 million online each year, you'll pay $1.5 million in revenue share (on top of licensing fees). If that is an acceptable cost of doing business and allows you to “set it and forget it," then SaaS is likely the right way to go for you.

But if you're a business that needs or wants more control of the front- and back-end experiences, you can use that three percent as a starting point to decide how to shape and invest in your online architecture. With open source software, you’d invest this money up front in year one. In years two and beyond, expenses taper down to about 15 percent of this initial investment annually to keep operational. 

Complete this exercise in relation to your own revenue and figure out what your working budget would be to get started. If three percent leaves you with peanuts, I’d suggest searching out a DIY platform-first ecommerce tool and seeking the help of an independent contractor to start generating revenue online. Your year-one investment may look closer to 50 percent of your annual online revenue to get where you need to be. 

Try to avoid thinking of this as an expense. Instead, think of how much money you’re going to spend to get a return on investment. How long will it take you to earn that ROI? Are these expectations realistic?

How to Budget for an Open Source eCommerce Architecture

Moving from an existing platform (typically SaaS or home-brew) over to a fully open source, headless ecommerce architecture setup incurs costs like:


Planning is the backbone of a successful ecommerce development project. If you don’t spend the time and money to work out that foundational blueprint, you will get a half-assed outcome that will likely cost more than you were initially promised.

On average, the planning processes for building a substantial ecommerce site for businesses that generate $50 million or more in revenue take 10 weeks of work and cost about $50,000. 

Planning is the absolute MUST-DO on your list. If you skip it, you may save $50,000, but your project will spend it on the other end trying to figure out who meant what because you flew cheap and blind. 

Ask if your proposed agency completes the following activities in their planning phase: 

  • Visualization / live prototyping 
  • Conversion planning, persona development, user journeys 
  • API integration planning, platform and integration reviews and selections 
  • ERP / product mapping 
  • Server and dev ops planning, security, performance and scalability planning

If you’re being pitched the above list, and you can see working past examples of blueprints such as these, then you’re spending your money wisely and you have a shot at getting this project right the first time. 

TIP: This plan should be detailed enough that you can either take it and build out your new site in its entirety with your on-staff tech team, or take it to ANY agency and have a crystal-clear spec for execution. 

Planning is not conceptual. It is a fully operational blueprint that the engineers have stamped and approved. This is a one time cost and the most essential ingredient in your budget. 

If you can only afford to get through planning in year one, make it a priority and wait for the next round of capital expenditure funding to implement it.  

Creative Design

Designing a new eComm site is the fun part. This phase of the project should be done after planning is fully signed off on. That’s because planning allows ideas to flow and evolve. And changes in functionality dictate front-end experiences. 

Your design phase will vary in price depending on what you want to see mocked up versus just built by the team without your input. Set aside $25,000 to $45,000 to make sure your creative phase reflects the quality of your business accurately. This is a one-time cost.

Here are a few tips to ensure that you’re spending your money wisely:

  • Beware of agencies that propose mockups for 30 pages within your new ecommerce site. This is a waste, a cash grab, and a sign of an inexperienced development team.  
  • Limit mockups to the home page, catalog landing page, product details page, and a general content page. However, if you have some funky options in your cart and/or checkout process, design them, too. 
  • Don’t bother fully mocking up creative designs for responsive options. If you’re dead set on seeing the mobile experience, start with the homepage on phone only and evaluate from there. 
  • Don’t waste time or money creating full mockups for each page. You can always add more designs as you go, if needed, or designers can provide elements to improve designs on single pages.
  • Complete and approve the home page design fully first before moving onto any “internal” templates. You don’t want rework across multiple designs. 
  • Use a web design agency, not a design agency. There are specifics for designing to web standards that don’t apply to companies that deal in logos, brands, and print work.

Sprinting / Development

Your project team should work with you to break your planning into stories, block these stories into epics, and group these epics into sprints. You’ll then have an idea of how many sprints you’ll need to get live.

Typical costs for sprinting range from $20,000 to $60,000 a month for the lifetime of the build cycle, which is usually six to 12 months. After this investment, you have a feature-rich ecommerce setup to push live. (Remember: These expenses are front-loaded. After this one-time cost, you own the site and don’t have to pay licensing fees or share your revenue).

Sprinting costs depend on velocity. That is, how many bodies can we afford to put on this development until the sprints are done? If you have $20,000 a month to spend for six months, you’ll get through $120,000 worth of programming or about 600 hours (give or take per agency).

That’s a decent amount of programming time for a version one go-live. You can alter the velocity, or speed with which you move, by altering your spend. After you get to that first launch, you may have the option to taper down resourcing (i.e., output) and slow spending over the following months.

Additional Features or Ongoing Support

Your site is not a static business channel. You’ll need to budget for continued rollout of new ideas, features, integrations, and changes. We often work with companies to train an in-house developer and take the agency expense out. With an open architecture and open source ecommerce setup, the ongoing costs are fully in your control.

Plan out your monthly spend over 12 months to figure out what’s realistic to your ROI, and if you should start right away or take a break.

TIP: Budget for  at least a year of ongoing expenses at whatever rate you deem suitable if you want to get a little consulting, training, advice, or coding from some experts. Just be sure to align your expectations of output with your willingness to spend.

Third-Party Expenses

Look past your site to see the full picture. What else does it need or plug into that has an annual contract? Account for these costs, too. A few typical additional expenses include:

  • Hosting
  • Server maintenance, security, updates and monitoring
  • Accounting software
  • ERP software / PIM 
  • CRM software
  • 3PL software (shipping, warehousing, labeling)
  • Programmers on staff
  • CSRs on staff 
  • Training and documentation


Your website is not an expense; it's a revenue channel that needs to be flexible and well architected. A substantial investment will be needed to compete online, so make sure you understand the costs involved. 

If you don’t know where to start, chat with a consultant to see if your math lines up with your goals, and then take this information to your internal team. You have options, and they should be clearly laid out for you up front, not presented to you with an invoice when you’re well into development with an agency’s team. 

Inform yourself on the process, not on the programming, and you’ll be in a better position to evaluate the best path forward.  

Click to contact one of our ecommerce consultants

May 26 2020
May 26

The power of Drupal lies with its modules. With thousands of core and contributed Drupal modules to choose from, Drupal developers can easily implement ones that meet their needs. But what if the requirements are very specific and you don’t have a module available for it? How can you customize a Drupal website for a client who has unique needs that just cannot be accomplished with core or contributed modules? Enter Custom modules.

Custom modules in Drupal 8 give you the flexibility to create new features and/or tweak existing features to accommodate a business’ unique and growing aspirations. Drupal 8 custom modules propels innovation and enhancements to help enterprises expand their horizons. This article should help you get started with creating your very own Drupal 8 module 

drupal module development

Getting started with Module development in Drupal 8

Let’s now get started with creating a custom module in Drupal 8 in a few easy steps:

Step 1: Name the Drupal 8 Module

First, we need to create a custom module under ‘web/modules/custom’ folder. We will name the folder as welcome_module.

module development

Some things that you should keep in mind before giving a machine name to your module are:

  • It should not start with uppercase letters.
  • There should not be any spaces between the words.

Step 2: Get noticed with the info.yml file

We have to create a yaml file with the machine name of our module for Drupal to be able recognize the module. I’ll create a yaml file like this welcome_module.info.yml.
Here is our welcome_module.info.yml file created under "welcome" directory we created in Step 1.

name: Welcome Module
type: module
description: 'First Custom Drupal 8 Module.'
package: Custom
version: 1.0
core: 8.x

name: Welcome Module (The name displayed on the modules list in Drupal) 
type: module - (Declaring that this is a module or theme) 
description: Custom Example Drupal 8 Module (Description of the module) 
package: Custom - (Mentioning that this is a custom module) 
version: 1.0 - (Module version) 
core: 8.x - (Drupal version)

Step 3: Creating the routing file with routing.yml

Next step is to add a welcome_module.routing.yml file under the "welcome" directory:

  path: '/welcome/page'
    _controller: '\Drupal\welcome_module\Controller
    _title: 'Welcome to My Module in Drupal 8'
    _permission: 'access content'

The first line is the route name [welcome_module.my_welcome].
Under path, we specify the URL path we want this route to register. This is the URL to the route.
Under defaults, we have two things: the _controller which references a method on the WelcomeController class and the default page title (_title).
Under requirements, we specify the permission of the accessing. User needs to have to be able to view the page.

Step 4: Adding a Controller 

Create a folder "modules/custom/welcome_module/src/Controller". In this folder, create a file named "WelcomeController.php" with the following content:

namespace Drupal\welcome_module\Controller;
class WelcomeController {
  public function welcome() {
    return array(
      '#markup' => 'Welcome to our Website.'

Now Login to your Drupal site and enable your module. To check if it functions properly, visit the path you specified in your routing file, that is /welcome/page. If you get the ‘Page Not Found’ error, then clear the cache by navigating to admin->configuration->performance. Check again and it should function properly this time.

drupal module

That’s it! You’ve successfully created your very first custom module in Drupal 8.
Finally, when you go to /welcome/page URL, you'll see Title “Welcome to My Module in Drupal 8" and markup “Welcome to our Website." text printed from our module.

May 25 2020
May 25

Last weekend all of our employees were encouraged to take part in the Drupal 9 porting weekend and it turned out to be a great experience for all of us. Feeling the team spirit both within the team and the Drupal community, deeply affected us as a group and on a personal level as well. Our day on Friday started with a kickoff meeting, where we went over the days ahead and how we would proceed in updating all of our projects, supporting each other and anyone that needed help within Drupal. Our goal, which we achieved, was to ensure that all modules maintained by our colleagues had a stable release. Also, our goal was that the modules we use most often, would also have the Drupal 9 readiness patch become ‘Reviewed and Tested by the Community’.

Everyone can be Makers

In our kick-off meeting, we provided some mentoring to make sure that all our colleagues had the necessary knowledge to fully participate in this initiative. This included how to use the drupal.org issue queues, how to create patches, and how to efficiently start an environment capable of performing the necessary testing. Some of our colleagues opted to collaborate with their skills in other areas, helping to prepare for the upcoming launch of Drupal 9 in little more than a week.

We have a mix of people at 1xINTERNET, some of us were contributing for the first time and others are experienced experts, simply a great mix! 

The weekend highlights: 

  • We worked on 46 different projects 
  • We released Drupal 9-ready stable versions for 15 Drupal projects
  • We enabled a couple of new contributors that contributed for the first time to Drupal
  • Our non-coder employees worked on Celebrate Drupal 9 launch and content issues on drupal.org

João Ventura had previously agreed to help with the global contribution in Drupal’s #d9readiness Slack channel, so that issues could be better worked on by the Drupal community. His job was made a lot easier by the extensive documentation prepared in advance by Gábor and Kristen Pol.

We had a lot of fun and our team members loved it. Therefore we have decided to do this more often. We want to plan regular Contribution events at 1xINTERNET and also make sure that all employees participate in making Drupal better.

So, how was your weekend? 

May 25 2020
May 25

Due to current conditions with COVID-19, DrupalCon was forced to cancel all trainings. Because of how popular our trainings were, we are pleased to offer them fully online. 

Our DrupalCon trainings are back!

With our newfound time and our ongoing commitment to accessibility & remote-availability, the Debug Academy team is proud to announce that we are offering our DrupalCon courses directly! We plan to donate a portion of the proceeds to the Drupal Association.

Elevate your Drupal 8 application with ReactJS

Advanced ReactJS development for Drupal 8

Advanced module development with OOP

How has COVID-19 impacted training courses in general?

We are aware that a number of us are running on empty, many of us simply do not have the stamina for attending full-time training programs, and that's OK. Debug Academy has created a handful of new course offerings with our present reality in mind.

When creating new course offerings, we have elected to divide them into multiple, shorter sessions when practical. In addition, our courses come equipped with presentations, written material, live instruction, experienced instructors who can answer your questions, and, most importantly, detailed exercises paired with their solutions.

To see our other course offerings, please click here to visit the "upcoming events" page on DebugAcademy.com:


All upcoming training courses

May 25 2020
May 25

One can't utter the words web accessibility without mentioning the WCAG guidelines. They are a great resource, but trying to interpret them to make your website accessible can be intimidating. Fortunately, there are some great accessibility testing tools, such as WAVE, that can point out the problems. Great! Except when you try to use it and turn on an accessibility testing tool in your browser, you instantly find a sea of red and yellow warnings. If you're as new to this as I am, you may sit there wondering, well what now? What do these all mean and where do I even begin to fix the problems? Fortunately, it can be easier than you think to solve the biggest problems.   

Here's a list of 10 ways to increase web accessibility across the board, before you start wading through all the nitty gritty details:  

1. Logical Headings and Page Structure

Example of how a page looks without CSS or JS

Well-structured and organized content will make it easier for everyone to navigate your page and take in your content. Both humans and search engines appreciate clear and consistent content. Taking the time to structure your user-interface properly can really pay off, and will be especially appreciated by readers who use assistive technology like a screen reader to access your page. No one wants to sit there guessing what the difference is between your three "Main Menus." The W3 page has some good tips on how to properly structure your page.

If you turn off CSS and Javascript, you can get an idea of how your webpage is read for someone using a screen reader. CSS allows you to position elements wherever you want on the page, regardless of where they are in the code. However, to users using a screen reader, the page won't appear as it does visually but how it is ordered in the code. The same goes for JavaScript. It allows you to manipulate elements by hiding them, removing them or showing them, but the webpage won't appear the same way it does visually to a screen reader.   

2. HTML Semantic Markup and Use of Landmarks plus ARIA  

Semantic structure and navigation with green checkboxes

Always use native HTML elements to make the website more accessible when available. You should use HTML5 tags to mark up the main sections of a page (footer, header, navigation, main, etc.), as well as sections, paragraphs and lists. HTML tags can be used to tell a computer about the content of a website and can make navigating using a screen reader much more accessible. This page has a good checklist on HTML elements and attributes for accessibility. When HTML markup is not sufficient, use ARIA markup. ARIA (Accessible Rich Internet Applications) is a set of attributes you can add to HTML elements to make them more accessible for users who use assistive technologies. The first rule of ARIA is don't use ARIA. If there's a way to do it with semantic HTML, that's always a safer bet but if you're not sure how or when to use it, this page does a good job of explaining that.   

3. Headings

h1, h2, h3 headings on a page

The proper use of headers is another element that goes a long way in helping to structure your page and making it easier to navigate. Headers allow users with screen readers to skip to the section they want. The <h1> element denotes a main heading and there should only be one per page: your page title. <h2> indicates subsections beneath it, and further embedded subsections of that are labelled with <h3>, with <h4> imbedding your content even further, and so on. For more details on how to structure headers, try this blog. Just don't be tempted to skip a layer and add a <h4> beneath an <h1> because users will end up confused. That's like skipping arithmetic and trying to learn algebra after just learning how to count. What happened to <h2> and <h3> and why are there letters in math class all of a sudden?! 

4. Forms

Form fields

It is essential that forms can be accessed by the keyboard alone for users that cannot use a mouse. Provide overall instructions about filling out the form before the <form> element since screen readers usually switch to 'Forms' mode when they encounter a form. Each field in the form needs to be properly labelled and the label needs to be in close proximity to the input box for that field. Also make sure any additional instructions are outside the box and not placeholder text inside. For more details on forms, the University of Guelph accessibility page has a good explanation on forms. Basically, when you're building a form, it's one place where you don't want to think outside the box.  

5. Images

Image sample with alt text

Users who rely on a screen reader to access your site need images with alternative (alt) text and there are different types of alt text to use depending on the type of image. If the image is descriptive, such as a young child riding a bike in downtown Boston, the alt text should describe something to the effect of "A young child riding a bike on the streets of downtown Boston." If the image is a functional image which denotes an action, such as magnifying glass to represent a search action, it should indicate the action in the alt text, saying "search." The exception to all this is purely decorative images, which should have an empty alt text. Keep your alt texts snappy. A picture is worth a thousand words, but in this case, 140 characters is usually enough. If you need more clarification on what to write for alt text or how to make them more accessible, then here is a handy guide.   

6. Tables

Table example with HTML tags

Only use tables when absolutely necessary. Do not use tables as part of the layout or to display lists. Misusing tables can make them confusing for screen readers. Use tables to display data with a logical relationship that is best represented in a grid. To make tables more accessible, mark headers with <th> and cells with <td>. Here's more info on accessible tables.  

7. Keyboard Navigation

Person clicking on the tab button

It is important that the site be navigable with a keyboard. Some users cannot use a mouse, and certain assistive technologies do not allow for precise clicking or hovering. Or maybe the user's track-pad just stopped working. To make sure that your website can be navigated using a keyboard, tab through the site using your keyboard. As you tab through the site, check that there is a focus ring  (usually a light blue outline by default) around focusable elements (buttons, links, form inputs, etc.) and that the keyboard focus order matches the visible focus order. Remove any off-screen focusable elements. If you're still not sure how to make your site more keyboard navigation friendly, here is an excellent checklist.   

8. Add a 'Skip to Content' Link

Page with 'skip to main content' button

Another great way to improve site accessibility is to add a 'skip to content' link. When tabbing through a screen to access content, it can quickly become tedious if you have to go through a ton of repeated elements in the header of each page before getting to the main content. A 'skip to content' link provides a keyboard-supported means of bypassing these repeated elements to access the main content, making navigating your page with a keyboard or while using a screen reader much easier. Trust me, if you've ever heard a screen reader reading your mega-menu items every time you land on a page, you'll jump at the chance to let users skip to the good stuff. You can find a bit more about skip-to-content links here

9. Appearance

Page with good spacing between images and text

Certain design elements can also help improve accessibility. Ensure there is enough contrast between the text and the background. Also, choose a sans-serif font for increased legibility, ensure the font is large enough, and enable resizable text. Never underestimate the value of space. Ensure adequate spacing between each line of text and between paragraphs. We've written a more detailed explanation on how to keep the design elements of your website accessible.   

10. Media

Video with text description

It is always best to have alternative ways for users to access essential media and consider removing most non-essential media. Avoid any flashing media since this can trigger seizures in some users.  Always caption all audio or video content. Some video platforms such as YouTube have auto-captioning that uses speech recognition to caption videos. It is less than perfect though, so while it can be a good start, it is best to manually review the auto-captions. Captions can benefit everyone, and sometimes users would prefer reading captions to a video than hearing audio when visiting your page in a library, at work or on a busy subway.  

Another way to make media more accessible is to include an audio description of the key visuals in video content. Another important thing to do is to disable automatic playback of all media. There is nothing more annoying than trying to figure which open tab that noise is coming from. Imagine how much more annoying it can be for those who rely on screen readers and keyboards to navigate. If you need more tips on how to make media accessible, this page does a good job of explaining alternative media types and requirements.   

In Conclusion

With this list in hand, you're not an accessibility expert, but you could just make your site more accessible than most of your competitors. And you're well on your way to adopting more inclusive practices into your work. If you need a hand figuring all this out, contact us or join our Web Accessibility training, which guides you through this step-by-step.

May 25 2020
May 25

Over the past month, I have been working on a large scale Drupal 8 build that is leveraging the Layout Builder module for much of the site's displays. If you are not familiar with Layout Builder, it's a fairly new initiative that hit Drupal 8 core as an experimental module in 8.5 and then gained full status in 8.7.

So far, I am really enjoying using Layout Builder, my point of view being very much form a theming perspective. In my option, Layout Builder is almost like a hybrid between Panels and Paragraphs. It's ideal for content-centric sites where you'd like to hand over more control of content display to editors while keeping to a structured modular content model. This paradigm should sound vaguely familiar for those folks who have been building with Paragraphs.

"Drupal 8's Layout Builder allows content editors and site builders to easily and quickly create visual layouts for displaying content. Users can customize how content is arranged on a single page, or across types of content, or even create custom landing pages with an easy to use drag-and-drop interface."


Here are some highlights that I think are worth noting.

  • Works on all different kinds of entities, media, nodes, blocks, Paragraphs, and more
  • Drag and drop goodness in the Admin UI, similar to Panels
  • Pulls in all kinds of entities from fields, blocks, custom modules, views, user information, system, and more
  • Limit entities that can be selected on a per content type basis (or allow all!)
  • UI option to Override a layout on a per node basis per content type
  • Large ecosystem via contrib. modules
  • Extensible via custom code, for example defining a new layout in a theme or module
  • One-off Layout Builder custom blocks created in the UI.
  • Excels at the creation of structured modular content for content editors.
  • Layouts export to config (drush cex) with the exception of those that have been overridden on an entity.

While the Paragraphs module has been all the rage for the past several years, Layout Builder has gained more prominence recently, though I suspect Paragraphs will be around for some time to come. I have not tried it, but I am guessing you could even bring in Paragraphs to Layout builder so you would have a joining of the two. On the site I am working on now, we are using standard fields and blocks as our main Layout Builder content.

The Drupal 8 Layout Builder drag and drop admin UI showing how blocks and sections are laid out The Drupal 8 Layout Builder drag and drop admin UI showing how blocks and sections are laid out

Kicking the tires

If you have not used Layout Builder yet for a project and have been wanting to jump in, I hope this article will serve as a good overview. So far, I have learned a lot by just playing around with it. The basic setup happens on a an entity's manage display admin UI where you can check a box to have Layout Builder take over and manage the display of a given view mode.

Speaking of view modes

I've found view modes to come in quite handy with Layout Builder. There are a few different ways we are using view modes here. One is to set other view modes that Layout builder blocks can reference. For example, if you are in a Default view mode for your main layout, you could also setup another view mode, say "Related" for your main blocks to use for their displays on Default.

Another method is to setup an entirely different view mode as a Layout Builder layout and then give content editors an option to switch view modes per node. I figured out how to use hook_entity_view_mode_alter to switch our Layout Builder display based on a field value, I'll probably write up a dedicated post for that. I did see mention of a contrib. module called Layout Builder Library which allows content editors to switch layouts from a predefined list so that might be a good way to go as well. I have not tried that module so I can not speak to how it works.

Layout Builder Styles

One contrib. module I have found to be invaluable is Layout Builder Styles. This allows for setting pre-defined HTML classes for use in the Layout Builder UI for both sections and blocks. You can choose to allow for multiple classes per element or just one. Since I write my Sass using BEM, I tend to add some of the section classes as BEM modifiers so as to fit these classes into my existing Sass workflow seamlessly.

Another advantage of using Layout Builder Styles is that once you assign a class to an element, it then creates custom theme hooks based on your class. Imagine if you will, a number of blocks with the same class that you want themed in a specific manner, you could use the same template for all of these based on a class that has been set. Note, there is an open issue with an RTBC patch that fixes cases where these theme hooks do not work. I tested the patch here installing via composer and it does fix the issue.

Layout Builder Modal

This is another very useful contrib. module in the Layout Builder ecosystem. This module takes some of the configuration out of the very narrow native off-canvas dialog and turns it into a configurable modal which to me if much more editor friendly. It also gives you the option to switch to the admin theme while in the modal which I like very much.

Mind the admin UI

One thing that I noticed is, since the Layout Builder UI uses your front-end theme, there may be some cases where your theme CSS might do some unexpected things on the admin side. For these instances, I created a _layout-builder.scss file where I use a class that only renders within the admin UI, for example, layout-builder__section and make a few updates straighten things out.


If you have an entity type that allows per entity override with Layout Builder, keep in mind that once you override that entity, the layout will no longer be kept track on in config. That's expected behavior but does allow for more flexibility for content editors. For those cases, you might limit what entities can be selected in the main entity settings. For example, we see these three radio button options available on the entity config display settings for "Content Fields."

  1. Allow all existing & new Content fields blocks.
  2. Allow specific Content fields blocks (whitelist):
  3. Restrict specific Content fields blocks (blacklist):


One thing that caught me out in the Layout Builder blocks UI was that I was expecting to be able to put an HTML wrapper around certain blocks within a section but that functionality does not exist yet. There are a few open issues for that feature request. Think Field groups within the blocks layout UI.

Overall, I think Layout Builder in Drupal 8 core is an amazing and very useful tool that will be around for some time to come including the upcoming release of Drupal 9, June 2020.

Key Resources, Issues, and APIs


May 24 2020
May 24

Jitsi video conference

Best video conferences are built on Jitsi. Jitsi is a set of open-source projects that allows you to easily build and deploy secure video conferencing solutions. At the heart of Jitsi are Jitsi Videobridge and Jitsi Meet, which let you have conferences on the internet, while other projects in the community enable other features such as audio, dial-in, recording, and simulcasting.

We have integrated Jitsi service with Drupal to access video conference directly from a Drupal site. You can create random or custom conference rooms or join existing conference. By default, the Jitsi meet server is used to establish connections, but you can specify your own server in settings.

Please check and try the module project which is in development version.

May 23 2020
May 23

My last blog post was about my journey towards "getting rid" of Disqus as a comment provider, and moving over to hosting my comments on Github. The blog post was rather light on technical details, so here is the full technical walkthrough with code examples and all.

Since I already explained most of the reasoning and architectural choices in that post I will just go ahead with a step by step of the technical parts I think is interesting. If that means I end up skipping over something important, please let me know in the (Github) comments!

Step 0: Have a Gatsby.js site that pulls it's content from a Drupal site

This tutorial does not cover that, since many people have written such tutorials. As mentioned in my article "Geography in web page performance", I really like this tutorial from Lullabot, and Gatsby.js even has an official page about using Drupal with Gatsby.js.

Step 1: Create a repo to use for comments

The first step was to create an actual repository to act as a placeholder for the comments to be. It should be public, since we want anyone to be able to comment. I opted for the repo https://github.com/eiriksm/eiriksm.dev-comments. To create a repository on GitHub, you need an account, and then just visit https://github.com/new

Step 2: Associate blog posts with issues

The second step is to have a way to indicate which issue is connected to which blog post. Luckily I am still using Drupal, so I can just go ahead and create a field called "Issue id". Then, for each post I write, I create an issue on said repo, and take a note of the issue id. For example, this blog post has a corresponding issue at https://github.com/eiriksm/eiriksm.dev-comments/issues/6, so I just go ahead and write "6" in my issue id field.

Step 3: Fetch all the issues and their comments to Gatsby.js

This is an important part. To be able to render the comments at build time, the most robust approach is to actually "download" the comments and have them available in graphql. To do that you can try to use the source plugin for GitHub, but I opted for getting the relevant issues and comments and creating the source myself. Why, you may ask? Well the main reason is because then I can more easily control how the issue comments are stored, and by extension also store the drupal ID of the node along with the comments.

To achieve this, I went ahead and used the same JSONAPI source as Gatsby will use under the hood, and then I am fetching the issue comment contents of each of the nodes that has an issue ID reference. This will then go into the gatsby-node.js file, to make the data we fetch available to the static rendering. Something along these lines:

exports.sourceNodes = async({ actions, createNodeId, createContentDigest }) => {
  const { createNode } = actions
  try {
    // My build steps knows the basic auth for my API endpoint.
    const login = process.env.BASIC_AUTH_USERNAME
    const password = process.env.BASIC_AUTH_PASSWORD
    // API_URL holds the base URL of my Drupal site. Like so:
    // API_URL=https://example.com/
    let data = await fetch(process.env.API_URL + 'jsonapi/node/article', {
      headers: new fetch.Headers({
        "Authorization": `Basic ${new Buffer(`${login}:${password}`).toString('base64')}`
    let json = await data.json()
    // Create a job to download each of the corresponding issues and their comments.
    let jobs = json.data.map(async (drupalNode) => {
      // Here you can see the name of my field. Change this to whatever your field name is.
      if (!drupalNode.attributes.field_issue_comment_id) {
      let issueId = drupalNode.attributes.field_issue_comment_id
      // Initialize the data we want to store.
      let myData = {
        drupalId: drupalNode.id,
        comments: []
      // As you can see, this is hardcoded to the repo in question. You might want to change this.
      let url = `https://api.github.com/repos/eiriksm/eiriksm.dev-comments/issues/${issueId}/comments`
      // We need a Github token to make sure we do not hit any rate limiting for anonymous API
      // usage.
      const githubToken = process.env.GITHUB_TOKEN
      let githubData = await fetch(url, {
        headers: new fetch.Headers({
          // Hardcoded to my own username. This probably will not work for you.
          "Authorization": `Basic ${new Buffer(`eiriksm:${githubToken}`).toString('base64')}`
      let githubJson = await githubData.json()
      myData.comments = githubJson
      // This last part is more or less taken from the API docs for Gatsby.js:
      // https://www.gatsbyjs.org/docs/node-apis/#sourceNodes
      let nodeMeta = {
        id: createNodeId(`github-comments-${myData.drupalId}`),
        parent: null,
        mediaType: "application/json",
        children: [],
        internal: {
          type: `github__comment`,
          content: JSON.stringify(myData)
      let node = Object.assign({}, myData, nodeMeta)
      node.internal.contentDigest = createContentDigest(node)
    // Run all of the jobs async.
    await Promise.all(jobs)
  catch (err) {
    // Make sure we crash if something goes wrong.
    throw err

After we have set this up, we can build the site and start exploring the data in graphql. For example by running npm run develop, and visiting the graphql endpoint in the browser, in my case http://localhost:8000/___graphql:

$ npm run develop

> [email protected] develop /home/eirik/github/eiriksm.dev
> gatsby develop
# ...
# Bunch of output
# ...
You can now view eiriksm.dev in the browser.
View GraphiQL, an in-browser IDE, to explore your site's data and schema

This way we can now find Github comments with graphql queries, and filter by their Drupal ID. See example animation below, where I find the comments belonging to my blog post "Reflections on my migration journey from Disqus comments".

Graphql browsing

In the end I ended up with the following graphql query, which I then can use in the blogpost component:

allGithubComment(filter: { drupalId: { eq: $drupal_id } }) {
  nodes {
    comments {
      user {

This gives me all Github comments that are associated with the Drupal ID of the current page. Convenient.

After this it's only a matter of using this inside of the blog post component. Since this site mix and match comment types a bit (I have a mix of Disqus exported comments and Github comments), it looks something like this:

let data = this.props.data
if (
  data.allGithubComment &&
  data.allGithubComment.nodes &&
  data.allGithubComment.nodes[0] &&
) {
  // Do something with the comments.

Step 4: Make it possible to fetch the comments client side

This is the part that makes it feel real-time. Since the above code with the graphql storing of comments only runs when I deploy this blog, comments can get quickly outdated. And from a UX perspective, you would want to see your own comment instantly after posting it. This means that even if we could rebuild and deploy every time someone posted a comment, this would not be instant enough to make sure a person actually sees their own comment. Enter client side fetching.

In the blog post component, I also make sure to do another check to github when you are viewing the page in a browser. This is because it is not necessary for the build step to fetch it once again, but I want the user to see the latest updates to the comments. So in the componentDidMount function I have something like this:

componentDidMount() {
  if (
    typeof window !== `undefined` &&
    // Again, only doing this if the article references a github comment id. And again, this
    // references the field name, and the field name for me is field_issue_comment_id.
  ) {
    // Fetch the latest comments using Githubs open API. This means the person using it will 
    // use from their own API limit, and I do not have to expose any API keys client side.
        "https://api.github.com/repos/eiriksm/eiriksm.dev-comments/issues/" +
          this.props.data.nodeArticle.field_issue_comment_id +
      .then(async response => {
        let json = await response.json()
        // Now we have the comments, do some more work mixing them with the stored ones, 
        // and render.

Step 5 (bonus): Substitute with Gitlab

Ressa asked in a (Github) comment on my last blogpost about doing this comment setup with Gitlab:

Do you know if something like this is possible with Gitlab?

Fair question. Gitlab is an alternative to Github, but differs in that the software it uses is itself Open Source, and you can self-host your own version of Gitlab. So let's see if we can substitute the moving parts with Gitlab somehow? Well, turns out we can!

The first parts of the project is the same: Create a field, have an account on Gitlab, create a repo for the comments. Then, to source the comment nodes, all I had to change was this:

--- a/gatsby-node.js
+++ b/gatsby-node.js
@@ -125,15 +125,25 @@ exports.sourceNodes = async({ actions, createNodeId, createContentDigest }) => {
           comments: []
-        let url = `https://api.github.com/repos/eiriksm/eiriksm.dev-comments/issues/${issueId}/comments`
-        const githubToken = process.env.GITHUB_TOKEN
+        let url = `https://gitlab.com/api/v4/projects/eiriksm%2Feiriksm.dev-comments/issues/${issueId}/notes`
+        const githubToken = process.env.GITLAB_TOKEN
         let githubData = await fetch(url, {
           headers: new fetch.Headers({
-            "Authorization": `Basic ${new Buffer(`eiriksm:${githubToken}`).toString('base64')}`
+            "PRIVATE-TOKEN": githubToken
         let githubJson = await githubData.json()
+        if (!githubJson[0]) {
+          return
+        }
         myData.comments = githubJson
+        // Normalize it slightly.
+        myData.comments = myData.comments.map(comment => {
+          comment.user = {
+            login: comment.author.username
+          }
+          return comment
+        })
         let nodeMeta = {
           id: createNodeId(`github-comments-${myData.drupalId}`),
           parent: null,

As you might see, I took a shortcut and re-used some variables, meaning the graphql is querying against GithubComment. Which is a bad name for a bunch of Gitlab comments. But I think cleaning those things up would be an exercise for the reader. The last part with client side updates was not possible to do in a similar way. The API for that requires authenticating the request. Much like the above code from sourcing the comments. But while the sourcing happens at build time, client side updates happens in the browser. Which would mean that for this to work, there would be a secret token in your JavaScript for everyone to see. So that is not a good option. But it is indeed theoretically possible, and could for example be achieved with a small proxy server, or serverless function.

The even cooler part is that the exact same code also works for a self-hosted Gitlab instance. So you can indeed run open source software and own your own data with this approach. That being said, not using a server was one of the requirements for me, so that would defeat the purpose. In such a way, one might as well use Drupal as a headless comment storage.

I would still like to finish with it all working in Gitlab too though. In an animated gif, as I always end my posts. Even though you are not allowed to test it yourself (since, you know, the token is exposed in the JavaScript), I think it serves as an illustration. And feel free to (Github) comment if you have any questions or feel I left something out.

May 23 2020
May 23

In a new Drupal 8 build that I am working on, there is a use case for some menu items to have an abbreviation underneath. I wanted to create a content editor friendly way of achieving this in the Drupal menu admin UI. Since I have already implemented the Drupal 8 Link Attributes widget module, I got to thinking that perhaps I could extend the module to handle these abbreviations.

Extending the Link Attributes widget

I was happy to discover that Link Attributes can be extended to any kind of additional HTML attribute you might need for your menu. I came up with the idea that if I could add a new field for the abbreviation, I could turn it into an HTML data attribute for a menu item and then output it with a little jQuery.

There are two pieces to extending the widget within a custom module, my_module.

  1. Leverage function my_module_entity_base_field_info_alter to add the new attribute desired.
  2. Create a custommy_module.link_attributes.ymlfile and add your attribute in there.


Our function looks like this:

function my_module_entity_base_field_info_alter(&$fields, \Drupal\Core\Entity\EntityTypeInterface $entity_type) {
  if ($entity_type->id() === 'menu_link_content') {
    $fields['link']->setDisplayOptions('form', [
      'type' => 'link_attributes',
      'settings' => [
        'enabled_attributes' => [
          'id' => FALSE,
          'name' => FALSE,
          'target' => TRUE,
          'rel' => FALSE,
          'class' => TRUE,
          'accesskey' => FALSE,
          'data-menu-abbreviation' => TRUE,


The key from the above code is 'data-menu-abbreviation' => TRUE, to let Drupal know, we want a field with that name. Once that is done, we can write a little code in our my_module.link_attributes.yml file as to how this will look in the menu UI. Note that we match the attribute name from entity_base_field_info_alter.

  title: Menu Abbreviation

Once you clear cache, the menu UI will now show the new field we created.

The Drupal 8 menu admin UI showing the new field for an abbreviation attribute The Drupal 8 menu admin UI showing the new field for an abbreviation attribute

Because we use data- here, this attribute will render as an HTML5 data attribute which is ideal to leverage with jQuery. Inspecting on the front end, we see the menu item render as:

Rendered HTML

<a href="https://www.dannyenglander.com/blog/drupal-8-architecture-how-to-add-custom-html-data-attributes-to-menus//" class="custom-menu__link" data-menu-abbreviation="DRPL">
  A menu link with an abbreviation

This is a great, we now have our abbreviation within the menu link. The next step is to read the data in jQuery and render that as a span tag within the menu item.

Pull the data in via jQuery

Now in our custom theme JS file, we can loop through the menu items and output each data attribute like so:

     // Get the menu data attribute and render as a span tag.
      $(context).find(".custom-menu__item--level-1 > a").once('menu-abbreviation').each(function () {
      // If there is a data attribute, "menu-abbreviation".
        if ($(this).data('menu-abbreviation')) {
        // Set a variable.
          var menu_abbreviation = $(this).data('menu-abbreviation');
          // Output the tag from the data.
          $(this).append('<span>' + menu_abbreviation + '</span>');

After this code, we now see the output look like this:

<a href="https://www.dannyenglander.com/blog/drupal-8-architecture-how-to-add-custom-html-data-attributes-to-menus//" class="custom-menu__link" data-menu-abbreviation="DRPL">
  A menu link with an abbreviation

This works great and solves a very specific use case but as you can imagine, this type of customization could come in handy for a lot of menu needs.


There are a few gotchas here, it sounds like hook_entity_base_field_info_alter may be changed or deprecated in Drupal 9 so be aware of that when upgrading. (see the issue listed below in resources). You also might need to use hook_module_implements_alter to adjust the weight of your custom code to be sure it fires after link_attributes if your module is named with a letter starting before the letter "L".



May 22 2020
May 22

Today we participated with our full team in the  Drupal 9 porting weekend. You can read about our commitment to Drupal 9 here.

During this efforts we updated the contributed module Image Edit. The module allows to edit images in place on Drupal 8 and Drupal 9 websites. The module was originally developed for a client. Initial development was by our colleague Melinda, who is currently on a maternity leave.

While making the module ready for Drupal 9, we fixed some issues and released the first stable version.

When I tested the patches provided by different colleagues, I realized how useful this module is.

Therefore I created some examples and a short screen cast about it.

With this module you can transform an image like the two images below.

May 21 2020
May 21

Whether you're a developer or a designer, everyone has a role to play in making websites more accessible and usable for site visitors. Our design and development teams got together to create this checklist of high-priority tasks you can execute to make your site more accessible. These are some of the issues that affect users of assistive technologies the most, so they should be first on your list when you're forming a plan to improve website accessibility.

Accessibility Checklist

Color Choice - Choose a well-balanced set of complementary colors that meet color contrast standards.

Color Contrast - When combining colors, verify that they have at least the minimum required color contrast.

Link Style - Add at least two differentiators to links for users with visual disabilities

Buttons - Remember color contrast requirements, states (i.e., hover, focus, etc.), and readability when designing and developing buttons for your site.

Forms - Set up your forms for success by including accessible labels, fields, instructions, errors, and alerts.

Color Choice

  • Create a visual design for your site using a balance of colors that isn't too distracting, while also not being too timid. This helps organize the site for all users, especially for those with disabilities. The effective use of color combinations in your website can establish a visual hierarchy, organize content, and draw distinctions between things such as foreground and background, or static areas and areas that are interactive. 
  • Use the primary color palette for things like CTA's, icons, and any place where highlighting areas visually is important.
  • Save secondary colors to highlight less critical information, such as secondary CTA's or backgrounds.
  • Finally, apply neutral colors to things like text and backgrounds, or to tone things down when there are large areas of color.

Color Contrast

One of the designer's most important tasks is to check color contrasts. Once you learn how to do this, you can easily integrate this task into your design workflow. When you are checking color contrasts, you should:


  • Pull the hex value(s) and go to the WebAIM Contrast Checker tool
  • Enter your hex value(s) into the Foreground Color or Background Color field(s)
  • Using the sliders below the Foreground Color or Background Color, change the color values until the Contrast Ratio is at or above these minimum values:
    • For text that's at or over 18.66px and bold, look for a color contrast of at least 3:1
    • For text under 18.66px, look for a color contrast of at least 4.5:1
  • Pull the new hex value(s) and place them into your page


  • Download the Colour Contrast Analyser tool from The Paciello Group for Windows/macOS
  • Enter your hex value(s) into the Foreground Color or Background Color field(s)
  • Using the sliders below the Foreground Color or Background Color, change the color values until the Contrast Ratio is at or above these minimums:
    • For text that's at or over 18.66px and bold, look for a color contrast of at least 3:1
    • For text under 18.66px, look for a color contrast of at least 4.5:1
  • Pull the new hex value(s) and place them into your design

Other useful tools

  • Colorblinding: This extension simulates what your website looks like to a visitor with a color vision impairment.
  • ColorZilla: Advanced Eyedropper, Color Picker, Gradient Generator and other colorful goodies

Link Style

Make sure links can be distinguished from regular text. When you use links in body content, they should be visually distinct in two different ways. One of these should be color, but the other differentiator should be independent of color to provide a distinction for colorblind users. When links are placed in the header, footer, or sidebar navigation, this differentiation is not required, although it is recommended. Having links underlined by default and removed on hover/focus is the best option, because most users expect that behavior, and it is also the default behavior of browsers. Other options include highlighting, dots, dashes, an outline, or bolded text.

A focus state is required on all links, so be sure to include it when setting the hover state. This adds a solid border to a link when a user tabs to it using their keyboard, which helps keyboard-only users who use the keyboard to navigate instead of a mouse. 

Make sure horizontal and vertical link groups have enough space to enable users to access them easily. Iconography can also help users, giving them another way to distinguish between links and plain text. Users understand content more quickly when paired with a visual cue, such as an icon. Finally, use descriptive text for links instead of general text like "More" or "Click here." Links should have some context to the content they're related to; however, make sure they are kept short and understandable.

When designing links, think about the following states:

  • Default (unvisited)
  • Visited (already visited)
  • Hover (moused over)
  • Focus (focusable elements via the keyboard tab key, i.e., links, buttons, etc.)
  • Active (clicked on, i.e., tabs or navigation)
  • Disabled (not able to be activated by the user)

 Further reading on link style:


When we talk about buttons, we're referring to regular form buttons and links that are styled as buttons. When developing for accessibility, form buttons should always be used in forms, and links should be used when you need to redirect the user to another page, site, or an anchor within the page.

Buttons should have a clear and solid border color that meets color contrast against the background color and a background color that meets color contrast against the text. When you hover over a button, there should be a very noticeable differentiation in the background and text color. Inverting the colors is a good option; alternately, darken the background color, and invert the text color.

When designing buttons, think about button sizing for both desktop and touch screen. Minimum touch targets should be comfortable for an adult finger to navigate successfully. The Web Content Accessibility Guidelines (WCAG) specify a minimum size of 44x44 pixels, or larger for users such as children or people with motor difficulties. 

Create button labels that are easy to read. Choose sentence case or title case over uppercase, and make sure the font is big enough for easy readability. Make labels action-oriented, i.e., "Next step," or "Save recipe." Including iconography within your buttons can help users understand actions more quickly. Include button states in all designs. These states provide users with feedback that an action is about to happen. When designing buttons, think about the following states:

  • Default (what a button looks like without any interaction)
  • Hover (on desktop, when a user's cursor is hovering over a button)
  • Active (a user has clicked on, and it is selected)
  • Focus (when a user clicks on or uses a keyboard tab key)
  • Disabled (not active)

Think about the overall button hierarchy within the system regarding primary, secondary, and tertiary buttons. This hierarchy lets users understand what the primary and secondary calls to action are on a page. 

 Further reading on buttons:


When designing forms, these tips can make them more readable and usable:

Group related fields 

  • Group logical sections with clear headings, i.e., Personal information, Contact information, Billing information. 
  • Groups of fields (i.e. checkboxes, radio buttons, etc.) should be contained within a <fieldset> that includes a <legend> element. The <legend> element holds the title for the grouped fields, which will be displayed on the page.
  • Include ample white space between sections to provide a visual distinction across sections. 

Single column forms

  • Forms are easiest to scan when form titles and fields are stacked in one column and aligned. This allows the eye to quickly scan down a single column instead of zig-zagging across multiple columns.

Form labels

  • For text fields, it is best practice to place labels above corresponding form fields in a form. Place checkboxes and radio buttons to the right of each field.
  • Use a bolded font to help form labels stand out. A flag on whether the form field is required should be placed right after the label as well. This can be a red asterisk, red "REQUIRED" text, or something similar. Form labels can also contain brief instructions for the particular field; for example, Date (mm/dd/yyyy)
  • In addition to a label, each form field should have descriptive helper text and placeholder text. Left-aligning and stacking form labels over their respective fields improve scannability. Keep the labels short and sweet.
  • Don't use placeholder text as a label, as this text isn't available to screen readers. Placeholder text disappears when the user interacts with the field. This can be annoying for users who forget what the placeholder text said. For sighted users, placeholder text offers an excellent opportunity to give users brief instructions, or show them how to format their information.

Form fields

  • Form fields should have a clear, solid border color that meets color contrast against the background color and a background color that meets color contrast against the text within the field.
  • The width of the form field should match the content it will contain. For instance, a date field would have a much shorter width than a name field that must accommodate long names.

Form field states

  • When designing your form fields, include the various field states. These field states give the user visual cues about where they are within the form, and where they're going next.
  • Field states to include are default, focus, feedback, and disabled.

Form instructions

  • Provide a brief list of form instructions directly above all input forms. A note about required fields is recommended, as well as required formats (i.e., dates).

Form alerts and errors

  • Use form errors and alerts to concisely explain to users how to fix issues that prevent them from completing the form. Follow color contrast requirements with these alerts and errors.
  • Display alerts as a summary at the top of the form, including brief steps on how the user can fix the issues. You can also include links directly to the fields containing errors within the form. Display errors with each problematic form field to make it easier for a user to find specific error details. This may be inline, above, or under the field. 
  • When a field has an error, change the form field's border to another color. Red is recommended because it's universally understandable as an error in a form. In addition to a color change, another differentiator should be added to form fields when they receive errors. This could include an error icon within the field or to the left of the error message.
  • Try to keep the form lengths short. If fields aren't required, consider whether those form fields are truly necessary on the form. If you don't need them, leave them out altogether. The shorter the form, the fewer opportunities for errors.

Further reading on forms:

As designers and developers, we can help make the world more accessible to our users. Half the battle is knowing what needs you should be designing for, and the other half is applying the design during development with the best practices and requirements we've discussed. Let's start today by taking a closer look at our work and finding opportunities to make it more accessible, more usable, and more inclusive for everyone. 

If you would like to ask us any questions about this article, please join us on Slack in the #accessibility channel. We look forward to seeing you there!

Kat Shaw

Kat Shaw

Kat is passionate about digital accessibility, and happy to continue her work as an advocate with her new colleagues at Lullabot.

Ana Barcelona

Ana Barcelona

Ana is a Senior UX Designer at Lullabot whose creative vision stems from user needs, a sensitivity towards concept, typography, color, and kinetics. 

May 21 2020
May 21

Drupal 9 release is more than just round the corner — the 9th version is already knocking at our doors.

If you plan for Drupal 9 (and you should), the good news is that the upgrade should be easy. However, your website will need to fulfill a few Drupal 9 requirements in order to move to the new version seamlessly. Today, let’s discover how to prepare your website for the Drupal 9 upgrade with the help of the latest tools.

The new Drupal 9 logo symbolizing the fluidity and modularity of Drupal, and the value of the community of creating a greater whole together:

New Drupal 9 logo

When will Drupal 9 be released?

The planned Drupal 9 release date is June 3, 2020. It will come on the same day with D8.9 and will be just a cleaned up version of it with deprecated code removed and third-party dependencies updated. If they are almost identical, why update a website to the new version then? The answer comes next.

Why upgrade: the expected Drupal 9 benefits

  • Cool Drupal 9 features coming. Starting from Drupal 9.1, new cool features will be added for better website user-friendliness, accessibility, performance, security, privacy, openness for integration with new devices and channels, and much more.
  • Latest libraries for better performance. The latest libraries and components, including Symfony and Twig, make your website faster, cleaner, safer, and easier to maintain and extend.
  • Beautiful and accessible front-end theme. The new front-end theme Olivero gives websites a professional look, makes them attractive and highly accessible to all audiences according to the standards.
  • Long-term support. D9 will be supported for years ahead, while D8 reaches its end-of-life in November 2021. Moreover, this support will only work for D8.9, while older versions will stop being supported in 2020.
  • Incredibly easy upgrades. Thanks to full backward compatibility in Drupal 9, your Drupal 8 to 9 upgrade should be a snap of a finger. All is needed is to meet a couple of requirements that we are sharing next.

Getting ready for Drupal 9: what is needed

Here are the major Drupal 9 readiness requirements websites should meet in order to be instantly Drupal 9 ready. For implementing them you can always rely on our Drupal support and maintenance team:

  • Using the newest minor version of Drupal 8
  • Keeping your modules and themes up-to-date
  • Making sure your hosting environment is up-to-date
  • Checking and cleaning your site from deprecated code

NB: The deprecated code part needs a special explanation. Deprecated code means functions and APIs that have been marked as deprecated because they have more modern alternatives and need to be cleaned up to achieve Drupal 9 compatibility.

Many of these pieces of code are really easy to find and replace. This is especially true thanks to useful upgrade preparation tools that help discover and clean up deprecated code that we are describing next.

How to prepare for Drupal 9? Useful tools in review

Here are a few great Drupal 9 checkers that will help you update your website to a newer version. They have earned the best feedback in the developers’ circles, including our Drupal development & support team’s devs that use them extensively.

Let’s begin with the Drupal Check and the Drupal Rector that are developer-oriented tools, but each of which also has a contributed Drupal module based on it. The modules offer user-friendly admin interfaces, which makes them a better option for non-tech-savvy audiences. Here are these two “couples”:

The Drupal Check command-line tool and the Upgrade Status contributed module based on it

The Drupal Check analyses the D9 upgrade status of your website — what is ready, what is not, and how to fix this. It checks the core, contributed, and custom modules, as well as your system requirements, and gives you the improvement suggestions.

The Drupal Upgrade Status module adds a UI and a bunch of helpful features for an easier Drupal 9 upgrade check. We have shared a blog post on how to prepare for Drupal 9 with the Upgrade Status module.

Upgrade Status contributed module to prepare for Drupal 9

The Drupal-rector tool and the Upgrade Rector contributed module based on it

The Drupal Rector is one of the latest and greatest Drupal 9 upgrade tools. It automatically updates deprecated code for D9. Rector offers automated fix suggestions for contributed and custom modules and makes it easy to generate patches. Its contributed module version with a user interface is fresh and new, released in May 2020.

The deprecated code coverage of Drupal Rectore is not complete, so it works best together with the Upgrade Status module. Although their UIs are not yet integrated, they complement each other in the Drupal 9 upgrade preparation.

Upgrade Rector contributed module to prepare for Drupal 9

The Drupal 9 Deprecation Status page based on the data from the PHPStan

Here is another very useful quick Drupal 9 upgrade status checker. On the above mentioned page, you can look up the Drupal 9 compatibility of contributed modules. The page is user-friendly and equipped with charts. You can also filter the results to quickly find the necessary module.

Drupal 9 Deprecation Status page to prepare for Drupal 9

Let us help you prepare for your Drupal 9 upgrade

Despite the availability of the user-friendly versions of Drupal 9 upgrade status checking tools as contributed modules, you may need help using them. So if you wish, never hesitate to entrust the Drupal 9 upgrade preparation to our Drupal maintenance team.

Our developers have experience with both the Drupal Rector and the Drupal Check in Drupal 9 preparations, both for the contributed modules they maintain and for our Drupal team’s customers’ websites.

We strive to make their sites more innovative and efficient, for which one of the ways is updating it to new versions. Our support services are very cost-effective, and our experience allows us to resolve tasks quickly. Let’s start with a consultation, which is totally free.

May 21 2020
May 21

Designing an attractive and highly functional website has a lot of important considerations, like whether users would intuitively connect more with turquoise or cyan, and whether it works with the branding. However, one often overlooked but important consideration is accessible design, and since it's always easier to fix things that you uncover in the design process, it is best to consider accessible design upfront in the design process.

Here are seven design elements to keep in mind when designing your website so it'll not only look great, but be easy to use for everyone.   

1. Colour Contrast

Contrast checker with green checkmarks

Colour contrast is important for both low-sighted and color blind users. I also appreciate good contrast when I'm trying to read my phone by the pool in the bright sun at noon after three margaritas. Furthermore, according to WebAIM, poor text contrast is the number one accessibility error in the top 1 million visited sites. For AAA standards, text and background need to be black and white. For AA standards, there is a 4.5:1 ratio to background for text and 3:1 for headings, as well as a 3:1 ratio for non-text contrast. 

The following tools can help you analyze your colour contrast: my preferred contrast checker, aptly named Contrast Checker and the Webaim one, and a browser extension for Firefox and Chrome.  

2. Hierarchy and Layout

Layout with image and text visible at a glance

Keep the hierarchy and layout of your page logical and organized and everyone will thank you. Make sure key information is visible at a glance and follows a logical hierarchy. There is nothing more frustrating than to have to scroll through an entire page or click a ton of links to get to the important information. It can be even more annoying on a screen reader. If you're not sure on how to proceed, here are some tips on layout on creating accessible layout. And remember, a good general rule is less is more. Cut the clutter and find your inner Marie Kondo.   

3. Fonts

Checkmarks beside accessible fonts

Use a sans-serif font. Sans-serif fonts are clearer and legible at any size, not to mention they scream bold and modern design. Sans-serif fonts are so cool that I once watched an hour-long documentary on Helvetica titled the same. Or maybe that just shows how cool I am? Either way, sans-serif fonts are where it's at because they're simply easier to read. Also, make sure your text is large enough to read; have a text size of at last 16 px. If you need to emphasize information, bold is easier to read than italic or uppercase. Lastly, don't use stylized fonts outside of your logo. This page from Penn State provides a nice list of accessible fonts.   

4. Enable Text Resizing

Magnifying glass over lorem ipsum

Ensure your text is resizable so users who have just had their glasses trampled by their obese Saint Bernard can zoom in on your content while looking up opticians. Most modern day browsers support scalability, however be sure not to inadvertently turn off user scalability as a function. Check to make sure your site scales properly. You can easily achieve scalability by using relative sizes such as percent or ems rather than absolute sizes like pixels or points. The Yale accessibility site has a nice guide on how to ensure text is resizable.   

5. Text Spacing

Lorem ipsum showing letter spacing, line spacing and baseline

Serifs are out, space is in. Think lovely Scandinavian minimalism. Leaving enough space between lines of text and images helps the user focus more on what is important. Ensure that the line height is at least 1.5 times the font size and that the spacing following paragraphs is two times the font size. Letter spacing (tracking) should be at least 0.12 times the font size and word spacing at least 0.16 times the font size. If I still haven't convinced you of the importance of text spacing, this page might, along with providing more tips.   

6. Links

'Click here' link and a more descriptive 'Read full story' link

Ensure links are distinguishable by something other than colour. An underline is standard and does the job. Also, name them something useful, short and descriptive. And definitely not 'Click Here.' All links linking to the same page should have the same description. Be sure to mention if the link opens a new tab or triggers a download, in which case indicate the file type and size, too. Again, the Yale accessibility site has a nice guide on how to make links accessible.   

7. Style Focus

Buttons with and without a focus ring

Browsers display a focus ring around currently focused elements. Often, this is turned off because designers find it visually unappealing but it can be essential to those using a keyboard to navigate your site. If you are going to remove the default style focus, then be sure to replace it with something else to denote the focus. Or alternatively, have a style focus which is activated only when using the keyboard to navigate and not the mouse. Here are some more tips on how to implement style focus.   

Need More Accessibility Guidance?

If you follow these seven tips, you'll be well on your way to having a site that is accessible and enjoyable for everyone. And if you need a hand figuring all this out, take our Web Accessibility training, which guides you through this step-by-step. Also, I hear retro is in. Just think how cool your site can be with a sleek retro aesthetic and accessible design.

May 21 2020
May 21

"Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.”
        - Margaret Mead


Global Accessibility Awareness Day was inspired by a blog post written in November 2011 by Joe Devon, a Los Angeles based web developer who was frustrated about an overall lack of awareness about accessibility. He posted a blog calling for a day devoted to building a more inclusive digital world. Shortly afterwards, Jennison Asuncion, an accessibility professional from Toronto discovered Joe's blog post, via a Tweet. Together, Joe and Jennison cofounded Global Accessibility Awareness Day and six months later, on May 9, 2012, the first Global Accessibility Awareness Day occurred with about a dozen virtual and in-person events. 

Today,  there are, hundreds of GAAD 2020 events scheduled in every corner of the world, and never before has the imperative of an accessible web been more profoundly apparent. Covid-19 related lockdowns and stay-at-home orders led to an environment in which online resources were the primary connection to the the outside world. Moving forward, it’s anticipated that all users will demand web experiences that align with their varying expectations and abilities.

Enlightened Access

It’s wonderful that digital accessibility is inching it’s way into mainstream thinking, but too often, the time and resources associated with making sites and apps accessible is viewed as a burden -- a legal requirement that would gladly be avoided, if possible. The fact is, expanding digital accessibility represents a profound opportunity to take a more expansive, empathetic, and inclusive view of our world and that always leads to good.

We are living in a digital world that shuts out or limits the ability to engage for an estimated 15 percent of the population -- customers, constituents, audiences. 

This translate into business. Worldwide, the disabled represent $490 billion in buying power. And millennials, who value inclusivity and social responsibility more than any generation that preceded them represent $3.28 trillion in buying power. 

Once we get it, that ensuring digital accessibility is not only a legal requirement, it’s the smart thing to do and the right thing to do, our passion for accessibility moves up several notches. And just as accessible ramps at entrances to public buildings serve far more than the wheelchair bound, it’s helpful to understand that accessibility is not just for the “disabled.” 

At Promet Source, we are passionate about web accessibility as an opportunity -- not a “have to.” 

Big-Picture Benefits

Let’s consider some ways that accessibility modifications make digital experiences more engaging and flexible for people of all abilities.

  • Logical layouts and engaging designs are not just pleasant to look at. Any user can get annoyed when needed information is difficult to find and interactions are complicated, but users who have cognitive difficulties or limited computer skills can be frustrated beyond all measure. Be sure to evaluate the user experience from multiple perspectives and angles. 
  • Adequate color contrast is essential for enabling users with a wide range of visual impairments, such as color blindness, to read, navigate, or interact with a site. Low-contrast sensitivity becomes more common with age, but good contrast also ensures accessibility in low-lighting conditions and for users who could be experiencing any number of temporary visual challenges. 
  • Video captions are, of course, essential to enable the hearing impaired to understand the meaning of a video. They also enable videos to be accessible to viewers who are in particularly loud environments, or in settings where silence is required. 
  • Alternate text for images makes a site more accessible for the visually impaired. It can also bring additional context and clarity to digital experiences, while boosting search engine optimization.
  • Technology that converts text to speech is viewed as a requirement for the visually impaired. It’s also helpful for dyslexic users, people who prefer not to read, as well as people who want to multi-task. Coding websites and apps to convert text to speech has the added benefit of helping search engines to detect content.
  • Customizable text capabilities enable users to adjust the size spacing and color or text without loss of function or clarity. There are a wide range of visual impairments that make small text unreadable, and difficulties in reading small type inevitable accompany the aging process for everyone. 
  • Clear language is key to accessibility. Industry jargon and acronyms always need to be explained. Run-on sentences and paragraphs can frustrate users of all abilities and in particular those who have cognitive impairments or learning disabilities. In the current environment, there is no patience or inclination for unraveling complicated text. 

At Promet Source, we believe that the internet is for everyone, and we are thrilled for the opportunity to acknowledge and participate in Global Accessibility Awareness Day 2020. We're passionate about helping organizations to understanding what web accessibility is all about and to bring their websites into accessibility compliance.

Here's one of the ways that we are recommending GAAD be acknowledged: Select one page of your website and test it for accessibility using an accessibility testing tool. And urge others to do the same! Need help finding the right tools or fixing accessibility issues. Contact us today!

May 20 2020
May 20

Read our roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community. You can also review the Drupal project roadmap.

Project NewsDrupal 9.0

Drupal 9 will be released on June 3rd, 2020

Despite the disruption of a global pandemic, the Drupal community has beaten the odds and Drupal 9.0 is on time for it's scheduled release window on June 3rd, 2020.

Drupal 9 represents the culmination of all of the features developed over the course of the Drupal 8 lifecycle, as well as the realization of the project's commitment to easy upgrades.

Drupal 9 beta 3 is available now, and the first release candidate will be available soon. We encourage you to participate in the Drupal beta test program, to help us ensure a smooth release.

Drupal 9 porting weekend from May 22-23

With the release of Drupal 9 only a couple weeks away, the community is coming together to support the effort to get modules ready for Drupal 9. After a successful Drupal 9 porting on April 28th, nearly 75% of the top 200 most used modules are already Drupal 9 compatible. Never before has so much of the contributed module ecosystem been ready even before the new release.

If you'd like to join in on the Drupal 9 module porting weekend, community member @kristen_pol has written a guide to the event.

New Drupal Brand assets available

The Drupal Association was very pleased to announce a new evergreen Drupal brand in time for the release of Drupal 9.

What does 'evergreen' mean?

The new branding is evergreen in the sense that it is no longer tied to a specific major version of Drupal. Whether for Drupal 9, Drupal 10, and beyond this new brand can remain the consistent identity for Drupal. This parallels the Drupal project's own development philosophy, where major version upgrades should no longer be a difficult process for end users.

With these new brand materials we hope to be able to unify the presentation of Drupal throughout the ecosystem, and help reintroduce Drupal to the world when the project inevitably gains more attention during Drupal 9's release.

We encourage you to begin using the new brand within your own materials as well - to support this effort.

Automated Deprecation Patches to port your module to Drupal 9

The Drupal Association is working together with the Drupal Rector team from Palantir and contributor Tedbow from Acquia to provide automatically generated Drupal Rector patches for all the projects on Drupal.org.

As of April, these patches are already available through DrupalCI. In May we hope to begin having a bot automatically post these fix patches to Drupal.org issues

More Drupal 9 Readiness tools

Drupal.org Updates

Events listing feature on Drupal.org

As we spoke about in last month's update, we've been working on a Event Listing Content Type on Drupal.org to help replace the aging Groups.Drupal.org subsite, and to support our global community by providing a central repository of events.

EDITED: The new event listings are being beta tested by the Event Organizers Working Group before a roll-out to initial community users.

Respectful Advertising

The COVID pandemic and its impact on DrupalCon has only emphasized the need for the Drupal Association to further diversify its revenue sources. We've made significant strides over the last several years, but as we've heard from many of you, that work must accelerate.

We've made a few changes over the course of April to start accelerating this revenue diversification:

In the most noticeable change, we've partnered with CarbonAds, a network that focuses on advertising to technical audiences, to create placements on Drupal.org.

These placements are hidden for Drupal Association members, so this program also helps promote DA membership as well, and does not put advertising in the workspace of our committed supporters.

Enhanced Membership Options

Speaking of membership - we also made some major overhauls to the Drupal Association membership program during the #DrupalCares campaign. Many members of the community reached out to us asking for more options for supporting the Drupal Association through membership, and we were happy to accommodate those requests.

There are now new membership levels for annual renewal, and we've also added a monthly membership option, which is now the default. We hope to continue to expand the membership program and its benefits to further support our fiscal stability in the future. 


A special thanks


As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who make it possible for us to work on these projects. In particular, we want to thank:

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.

Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

May 20 2020
May 20

Recently, someone asked me: "What's special about Drupal? And why do you contribute?" It didn't take me long to respond, "Drupal empowers people." Drupal has changed lives, allowing a global and diverse group of people to build websites, but also the products, communities, businesses, and organizations that rely on those websites.

There's Never Been a Better Time to Learn Drupal

When I see the spark of someone grasping what Drupal empowers them to do, it makes excited for them and proud to be part of an open source community where we get to work together to make these experiences happen. That's why I love giving back to the Drupal community. Almost every month, Evolving Web gives newcomers a taste of what Drupal can do at our free What is Drupal? intro course. It's one of the most important things we do to give back.

Over the last nine years, our team has trained thousands of Drupal users. We provide in-depth week-long courses and have trained everyone from students and freelancers with a curiosity for Drupal, to web agencies, universities, and corporations who are shifting thousands of websites to Drupal and onboarding their entire staff.

In recent months, we've seen that the desire to learn Drupal is stronger than ever. It's a great time for open source, and digital independence is really important when you don't know what the next year, or the next month, will look like.

Evolving Web's Scholarship Program  

A few weeks ago, we launched our Scholarship program to give organizations in need due to the COVID-19 crisis access to free training. Our goal is to help scholarship recipients build a solid technical foundation and the skills they need to build a solid future. Our training clients include the Canadian and US governments, Ivy League universities, and big corporations like Western Digital and Sabre. We want to offer the same level of quality and hands-on instruction to as many individuals and organizations as possible.   

So far, we've had a tremendous response and have been able to give away dozens of scholarships to our upcoming courses. Our Web Fundamentals course, which covers the building blocks of web development, is popular among those looking to switch to a more technical role within their organization, and for individuals who want to leap into a career in web development.

Suzanne Dergacheva giving a live online training Suzanne, a member of the Drupal Association board, is always looking to grow the Drupal community.

We've also had great interest in our in-depth Drupal trainings. With the imminent release of Drupal 9, content editors, project managers, and web services teams need to upgrade their skills to better manage their projects, increase productivity, and improve communication. One of our most popular courses is our in-depth 5-day Drupal Training, which includes Site-Building and Architecture, Theming, and Module Development courses. This training teaches you how to build a Drupal website from top to bottom. We're excited to teach Drupal to our government, higher ed, and scholarship trainees this June 1-5.  

As more people learn about the importance of digital inclusivity, our Web Accessibility training helps them build accessibility standards into their Drupal design and development practices. This topic has never been more important as new web accessibility regulations that enforce these standards get rolled out.   

Free Resources

We're also supplementing these scholarships with free video tutorials on a wide range of web development topics, so people can learn on their own time. These tutorials include tips and tricks about web fundamentals and Drupal.   

Trevor Kjorlien giving a live online Drupal training Trevor, a developer and trainer, also teaches astronomy and makes Halloween costumes.

And for those who have little to no coding experience, we continue to offer our free What is Drupal? and HTML & CSS Basics trainings on a regular basis. These courses are designed to introduce newcomers to web development and get them started on their first projects in a welcoming and non-intimidating learning environment.

You can also subscribe to our Learn Drupal newsletter, which delivers actionable insights and tips from our trainers right into your inbox every month.  

Evolving Web is Here for You 

Our Scholarship program is here to help your organization with financial cut-backs due to COVID-19. And through our scholarships, we'll continue to build Drupal and web development expertise in the world. By sharing our knowledge, we want to prepare organizations and individuals for the future. 

And if you know of an organization that could benefit from a training scholarship, please invite them to apply!

May 20 2020
May 20

by David Snopek on May 20, 2020 - 11:17am

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for Drupal core to fix a vulnerability in jQuery. You can learn more in the security advisory:

Drupal core - Moderately Critical - Cross Site Scripting - SA-CORE-2020-002

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

FYI, there was another Drupal core security release made today (SA-CORE-2020-003) but that one doesn't affect Drupal 6.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

May 20 2020
May 20

More likely, you have a content management system (CMS), which is specifically configured and customized to manage your content. In some cases, this same software will deliver your content to your audience. In more complex cases, the CMS exposes your content over an API to a front-end application and other channels, which present this content to your audience.


echo("It's software all the way down.");

When it comes to the software supporting your website or application, there will always be a tension between building something new and innovative and getting the most out of what you have already built. Twenty years ago, Joel Spolsky wrote about Netscape making the "worst strategic mistake... they decided to rewrite the code from scratch."


While I love this quote (I probably reference this thinking at least a few times a month) perhaps the more important point is made at the end of Joel's article:

"It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time."

Now, this isn't to say that I am anti-innovation or that I am a technology conservative. In fact, I believe that iterations are the best way to make pieces of software more effective, elegant, or efficient. But, far more than this, I hate to see the waste created by under-investment in existing production software.

Talking about something new is way easier than executing maintenance plans on what you already have. And, as it turns out, executing a new development project is often far more difficult and way riskier than you can possibly imagine while you're dreaming up the new idea.

I believe that adopting a maintenance mindset is one of the best ways to delay the risky undertaking of a full web site or web application rebuild. I come across a lot of engineers, communications professionals, and digital marketers who think that web maintenance is something that starts after a development cycle and ends just before a rebuild.

Web Maintenance Graph

When talking to customers and teams, I try to encourage us to give the software being created the upper hand by employing what I refer to as "Engineering for Maintenance". You can think of this as "building it right". Once the software has been built and launched in a way that it can be maintained, you can execute a systematic maintenance plan, which I refer to as "Maintenance Engineering".

Engineering for maintenance

ALGM Web Maintenance

In the best case, "building it right" should be the first step taken towards adopting a maintenance mindset. Building and launching web software in a way that it can be maintained covers multiple interrelated disciplines. Starting from the user experience (UX) and design process, where we uncover the best way to communicate with your audience, through to the content modelling, where we plan a logical structure for your content, to picking the technology stack and developing the custom features required to present the specifics of your brand, organization, or mission.

By building something in a maintainable way, we lay the groundwork for getting the return on our investment for the longest possible time.

We frequently come across maintenance cases where "Engineering for Maintenance" was not considered. There are multiple reasons why this could be the case, running the range from inexperience to unexpected success, to pivot pressure, through to simply negligent practices. In these cases, the "Engineering for Maintenance" often takes the shape of an audit and change implementation plan to lay the foundation of what we need to take the project into an appropriate maintenance plan.

Maintenance engineering

ALGM Web Maintenance Engineering
In the web development context, "Maintenance Engineering" covers all the disciplines of keeping the website delivering the specific value it was created to deliver. This could be from simply communicating a concise brand message, through to an enterprise brand presentation, collecting donations, or selling products.

Maintenance Engineering is not just keeping the software secure and up to date - it is also about keeping features working well, iterating on features that can be changed, and building out new features which can launch on the same software. So Maintenance Engineering also covers the creation of new features to deliver new value as you iterate and grow to further understand your audience.

Consequently, this phase doesn't only involve engineers. It equally involves UX specialists, designers, content specialists, analytics consultants, and project managers.

As you may notice, there is a significant overlap in the activities that are undertaken during a new development stage and those undertaken in a maintenance stage. However, I've found that "Maintenance Engineering" has a somewhat different flavour to that of the engineering undertaken when building new software. This is due to the fact that maintenance engineering looks after a production site - it necessarily takes a more conservative approach, and moves at a different pace.

I don't mean to suggest that things move more slowly in a maintenance phase - in fact, this is often quite the opposite. I rather mean to underline the point that there are often more things to consider with a site that is in production. This is the reason that, at Amazee Labs, we split our team into a new build team and a maintenance & extension team.

Get more from what you have already built

Adopting a maintenance mindset can be a challenge. It sometimes requires a shift in thinking and taking a longer view than what you may have intended. But I believe it can be valuable, and that you can often get more out of what you have already built.

Find a partner that gets it

If you have an internal team looking after your web software, find a product owner, manager, or member of the engineering team that also believes there is merit in maintenance as a mindset, rather than a milestone.

If you outsource your web development, have a chat with your project manager or customer liaison and check that they share your view on maintenance as a mindset. At Amazee Labs, this happens by default in the regular alignment calls between the Project Manager and client Product Owner.

Take inventory

Spend some time with your chosen partner taking an inventory of where you are at with your current site or application. How aligned is your website look and feel with your brand? How well is it telling your story? Is it still effectively selling your products, or collecting your donations? Essentially ask yourself, from a functionality and communication perspective, how far off are you?

Next, take inventory of the software and infrastructure. Is the software out of date, and can it be brought up to date easily? How performant is the site? Does it feel snappy or sluggish?

Take action

Remember, the goal is to get more out of what you already have. There is no getting without doing, so the most important part of trying it out is to take action! The sooner you try to adopt the maintenance mindset, the sooner you'll really know how much more you can get out of what you have already built. In some cases, you may find that the relative cost of maintenance is so high that new software should be considered. In this case, you have learned something, so you're already better off than you were.

But in my experience at Amazee Labs, 9 times out of 10, with some planning and some creativity, we have been able to extend the lifetime of our customers' sites significantly.

Reach out

The team and I at Amazee Labs are passionate about helping you get more out of what you have already built. If you are interested to find out what we do, and how we do it, get in touch. Looking forward to hearing from you.

May 20 2020
May 20
Project: Drupal coreDate: 2020-May-20Security risk: Moderately critical 10∕25 AC:Basic/A:None/CI:None/II:None/E:Theoretical/TD:AllVulnerability: Open RedirectCVE IDs: CVE-2020-13662 Description: 

Drupal 7 has an Open Redirect vulnerability. For example, a user could be tricked into visiting a specially crafted link which would redirect them to an arbitrary external URL.

The vulnerability is caused by insufficient validation of the destination query parameter in the drupal_goto() function.

Other versions of Drupal core are not vulnerable.


Install the latest version:

Reported By: Fixed By: 
May 20 2020
May 20
Project: Drupal coreDate: 2020-May-20Security risk: Moderately critical 10∕25 AC:Complex/A:Admin/CI:Some/II:Some/E:Theoretical/TD:UncommonVulnerability: Cross Site ScriptingDescription: 

The jQuery project released version 3.5.0, and as part of that, disclosed two security vulnerabilities that affect all prior versions. As mentioned in the jQuery blog, both are

[...] security issues in jQuery’s DOM manipulation methods, as in .html(), .append(), and the others. Security advisories for both of these issues have been published on GitHub.

Those advisories are:

These vulnerabilities may be exploitable on some Drupal sites. This Drupal security release backports the fixes to the relevant jQuery functions, without making any other changes to the jQuery version that is included in Drupal core or running on the site via some other module such as jQuery Update. It is not necessary to update jquery_update on Drupal 7 sites that have the module installed.

Backwards-compatibility code has also been added to minimize regressions to Drupal sites that might rely on jQuery's prior behavior. With jQuery 3.5, incorrect self-closing HTML tags in JavaScript for elements where end tags are normally required will encounter a change in what jQuery returns or inserts. To minimize that disruption in 8.8.x and earlier, this security release retains jQuery's prior behavior for most safe tags. There may still be regressions for edge cases, including invalidly self-closed custom elements on Internet Explorer.

(Note: the backwards compatibility layer will not be included in the upcoming Drupal 8.9 and 9.0 releases, so Drupal 8 and 9 modules, themes, and sites should correct tags in JavaScript to properly use closing tags.)

If you find a regression caused by the jQuery changes, please report it in Drupal core's issue queue (or that of the relevant contrib project). However, if you believe you have found a security issue, please report it privately to the Drupal Security Team.


Install the latest version:

Versions of Drupal 8 prior to 8.7 are end-of-life and do not receive security coverage. Sites on 8.6 or earlier should update to 8.7.14.

The pre-release Drupal versions (8.9 and 9.0) have been updated jQuery to version 3.5.1 as of 8.9.0-beta3 and 9.0.0-beta3.

Reported By: Fixed By: 
May 20 2020
May 20

For every website, irrespective of the industry, a blog is a powerful magnet that attracts both visitors and search engines. In order to keep your website fresh, you need to regularly treat your audience to new and tasty content.

Among the ways to increase blog engagement is to notify users about new posts. Let’s see how to set up content email notifications on a Drupal website.

Of course, you can always rely on our Drupal development team for setting up notifications on your website according to your requirements at very affordable prices.

A few tips about how to engage readers on a blog

So you have a blog that helps you bring your message across to your prospective customers. Their interest transforms into your conversions. But how to increase content engagement? How do you connect with readers better? The tips include (but are not limited to) the following:

  • Regularly share your blog on social media and add sharing buttons for your readers to do the same.
  • Make sure your website has a comment section so your readers can share their thoughts or ask questions (and get your answers!)
  • Insert encouraging questions into your blog content that directly ask your readers’ opinion.
  • Never underestimate the power of interesting video content.
  • Share your blog on forums, communities, and specialized platforms in various engaging formats like polls, podcasts, contests, slideshows, and so on.
  • Don’t forget to increase your website loading speed so your users don’t lose their patience while waiting to read your content.
  • Be sure to improve your website’s mobile UX so it’s easy and enjoyable to read your blog from any device.
  • Email users when a new post is published, or an old one is updated or commented on. This is exactly what we are moving on to.

The role of email notifications in your user engagement

Let’s see more details about the benefits of the idea to notify users about new posts on a website. This increases the chance that they:

  • come and read your content
  • share it on social media
  • register on your website
  • subscribe to your newsletter
  • become your loyal readers
  • get involved in a discussion in the comments
  • or, most desirably, click your important CTA button

That’s why email notifications, as an important engagement technique, are beneficial for your blog views, popularity, SEO, and conversions. Considering the high open rates of emails, the impact can be very significant.

Opportunities to notify users about new posts on a Drupal website

If your website is built with Drupal, your options for through email notifications are very extensive:

  • Recipients. You can send new post notifications to subscribers,users, authors, admins, etc. These can be users of specific roles, users from a specific list, or users who have performed specific actions (e.g. commented on a blog post).
  • Events. Send emails when content is created, updated, someone posted a comment or replied to it, there are new posts to moderate, etc.
  • Form. Send notification messages, full content items, content teasers, full comment threads or just personal replies.
  • Time. Send your emails immediately, schedule them to be sent in the future, or unquee them to be processed by Drupal Cron (time-based task scheduler).
  • Amount. Notify users about every single event or collect the events into regular newsletters.

Drupal modules for email notifications

Let’s now see how to notify users about a new Drupal blog and other events described above. As usual with Drupal, this can be implemented through a wide array of contributed Drupal modules.

Which is the best Drupal module to send new post notifications to subscribers? Each of them is great in its own way and performs particular functions. Of course, anything that is not covered by them, can be added as custom functionality by Drupal development experts.

Comment Notify

Comment Notify is a lightweight module that notifies users by email about replies to their comments and other comment-related events. It is available both in Drupal 7 and Drupal 8. The module has been freshly updated.

One of its important features is the ability to send emails both to authenticated and anonymous users. Anonymous users are a very promising audience in building a blog community. Its other features include the option for users to unsubscribe, notifications for admins that they need to moderate a comment, emails for authors about new comments to their blog posts, and much more.

Comment Notify Drupal module

Admin Content Notification

The Admin Content Notification module allows you to notify users by email when new content has been created or updated. It is also available in Drupal 7 and 8.

You can notify website administrators or users of any other roles, as well as users of a specific list. It’s possible to select specific content types, events (whether the content is created or updated), send content nodes via tokens, and much more. 

Admin Content Notification Drupal module

Workbench Email

The Workbench Email module enables you to send email notifications based on content status changes. You can send emails from the admin dashboard about the transitions of content from state to state, for example, when the content moves from “draft” to “needs review.” Its work is based on configurable email templates. The module supports tokens and allows you to select users and content types.

Workbench Email Drupal module

Message Stack

The Message Stack is a complex but very powerful and flexible module that consists of the Message, Message Notify, Message Subscribe, Message Digest, and Message UI submodules. The package has capabilities that will impress any developer because there is literally anything can do with an expert approach. For example:

  • defining message types and generating messages
  • export of message types
  • subscription to events related to content
  • plugins for email and SMS notifications
  • multilingual support
  • Token support
  • Rules support
  • example modules included

Message Stack Drupal module

Let us help you notify your users about new posts on your site!

If you are still asking yourself “How can I increase my blog traffic?”, try the effective email notification techniques and boost user engagement with the help of our Drupal development company.

We understand the situation is difficult today for many businesses. So have accepted a cost-effective development approach and do the work twice as fast. A wealth of contributed modules in Drupal, for email notifications and other purposes, allows us to use minimum customization where it is possible in order to meet the customer requirements. Give it a try!

Contact us to discuss how we can use our development expertise to help your website and business.

May 20 2020
May 20

Your browser does not support the audio element. TEN7-Podcast-Ep-090-Heaher-Rocker-and-Tim-Lehnen-Drupal-Association_0.mp3


Heather Rocker and Tim Lehnen discuss the multiple missions of the Drupal Association, turning DrupalCon Global 2020, and the upcoming Drupal 9 release.


Heather Rocker and Tim Lehnen of the Drupal Association


  • Drupal Association (DA) covers three areas, drupal.org (open source projects), DrupalCon, the Drupal community
  • The DA doesn’t build Drupal directly, they build and enhance the tools that enable the community to build Drupal
  • It was a tough decision to make DrupalCon 2020 virtual, but Minneapolis community was supportive and forgiving
  • With loss of DrupalCon, DA lost 60% of its total funding, but with emergency #Drupal Cares fundraiser, the Drupal community made up the $500K shortfall
  • Drupal 9 is coming June 3, focused on empowering less-technical users
  • Drupal 8 to Drupal 9 upgrade will be as easy as minor upgrade, and that sentiment carries forward to all future releases
  • Drupal 9 has a new evergreen logo, and will help with brand recognition



IVAN: Hey everyone! You’re listening to The TEN7 Podcast, where we get together every fortnight, and sometimes more often, to talk about technology, business and the humans in it. I’m your host Ivan Stegic. As most of you know, TEN7 is squarely focused on Drupal as a technology. We live it, we breathe it, we create and we care for Drupal power websites, and we do what we can to support the community by donating our time and money by contributing to camps across the nation and of course, to Twin Cities Drupal Camp here in our backyard. Even though we’re a fully distributed firm with team members in Portland, Austin, Boise and Chicago, our roots are here in Minneapolis.

So, we’ve been giddy for almost two years now with the anticipation that DrupalCon 2020 was scheduled for Minneapolis. DrupalCon was finally going to be in our hometown, and we have been really looking forward to that. But as the Coronavirus pandemic has raged it’s not only devastated families, but it’s affected the global economy and has certainly left an indelible mark on the conference and events industry as well. DrupalCon Minneapolis has been transformed into DrupalCon Global with a new date and virtual presence online. Mark your calendars, July 14 to 17, 2020.

Today’s episode is publishing on what would’ve been the Wednesday of DrupalCon Minneapolis 2020. Trainings and summits behind us, we’d be listening to the Dries Notes and looking forward to sessions, BOFs and of course a sprint day, DrupalCon. And what better way to celebrate what would’ve been than to have two members of the Drupal Association with me today on the podcast.

My guests today are Heather Rocker, Global Executive Director of the Drupal Association, and Tim Lehnen, Chief Technology Officer of the Drupal Association. Heather is a champion for the global ecosystem of Drupal and has been Global Executive Director of the Drupal Association for just over a year. What a time to have come aboard. She has been the Executive Director of Women in Technology and the CEO of Girls, Incorporated of Greater Atlanta in the past. Tim has been involved with Drupal for over 14 years, has been the Director of Engineering in the past, the interim Executive Director, and now serves as the Chief Technology Officer of the Drupal Association.

Hello, and welcome to you both. I’m just so honored to have you on the show.

HEATHER ROCKER: Thank you. It’s lovely to be here. We’d rather be with you in person in Minneapolis though, if we had our way

TIM LEHNEN: Yeah, it would be wonderful if we could’ve been there together, but it’s great to be here and great to talk about how we’re pivoting to DrupalCon Global and making all that happen.

IVAN: I’m just honored,  and it’s nice to be speaking with you both. I want to ask the first question by saying, how are you guys doing? How are your families? Where are you joining me from on the podcast today? And also, who else is using your wi-fi?

HEATHER: [laughing] I’ll let Tim go first.

TIM: Yeah, so, doing fairly well. I’m here in Portland, Oregon and the city has been doing a decent job with our Shelter In Place and quarantine rules. So for the most part we’re doing okay here. Fortunately, my family has been not too disrupted. I, of course, have been working remotely since before all this happened. My wife, who’s a reading tutor, is now working from home and doing that virtually. And so, we just got a few folks in the home, my wife and my brother, all using our wi-fi, but otherwise we’ve been very fortunate and doing very well.

IVAN: I’m so glad to hear that. How about you Heather?

HEATHER: So, we’re doing well. So, I’m in Atlanta, just north of Atlanta, Georgia. We are handling Shelter In Place slightly differently. If you’ve seen the news lately, but my husband and son and I are staying home and staying healthy. It’s an interesting situation. So, I got married in January of this year.

IVAN: Congratulations. Wow.

HEATHER: This is a very interesting way to start a marriage. [laughing] It’s a lot of togetherness that nobody planned, so we’re getting to know each other really well from a living together perspective.

IVAN: Well done. Wow.

HEATHER: Thank you. And my son is in fourth grade, so we’re also trying to be teachers or at least teaching assistance, at the same time as working full-time from home. So, it’s an interesting situation and last week we decided to bring two fairly newborn kittens into the situation just to make things interesting.

IVAN: Wow.

HEATHER: So we’ve got a house full of excitement now.

IVAN: Oh my gosh. I’m sure your son loves having kittens around.

HEATHER: It’s a nice distraction. It’s a lot of upheaval I think for children, and it’s hard to know how it’s affecting them. So, having something fun running around the house that’s not mom and bonus dad is good stuff.

IVAN: I hear you. My kids are [laughing] giving our dog a lot of attention and have been for the last eight weeks, [laughing] and I think the dog loves it. Daphne’s a big fan of us being all around, she loves the attention.

HEATHER: Exactly. Yeah, they say dogs are winning. [laughing]

IVAN: [laughing] I agree. Well, we have a lot to talk about today. I want to make sure we cover not only DrupalCon and what was supposed to be and what it is now and what it might be in the future, but that we also talk about Drupal 9 and that beautiful new logo and brand standards that came out and the thought process behind all of that.

Before we get to that, and all that, I want to kind of go back to first principles, because we do have listeners who sometimes haven’t used Drupal in the past and don’t know what it is. I want to go back and talk a bit about the Drupal Association. Let me thank you both for serving the community as officers on the Association, and I want to go to a basic level. What is the Association? Why does it exist? What role does it play? How did it come about?

HEATHER: So, I’ll hit this at a high level and then Tim, who’s been here much longer than me, can give a great deep dive. So, the Drupal Association is a non-profit organization who exists primarily to accelerate the Drupal project. We do that through three basic program areas. One is drupal.org, which if you are familiar with Drupal Open Source Project that’s what you’re most familiar with. The second is DrupalCon which you mentioned earlier, and we’ll talk about more. And the third is the Drupal community. So, there’s some great programs that we do outside of DrupalCon, although DrupalCon’s probably the most recognized. But for drupal.org, I’ll let Tim speak to that because that’s a key area that he brings to the table.

TIM: Frankly there’s a lot to talk about. We can go on all day just about this, but the Drupal Association evolved organically about the need to support the infrastructure that the community was building. Originally, if we go back more than 10 years, drupal.org and DrupalCon were effectively volunteer-organized. People in project leadership, like Dries Buytaert and some of the key early contributors, started ad hoc, creating tools to manage the contribution system on drupal.org and gathering people together for events. And as that grew and grew it became clear that that needed to professionalize and have an organization behind it, and that was the origin in founding the association.

So now drupal.org is not only the home of the code, the home of the project, it’s also really the home of the community. It’s where we organize all of the initiatives. It’s where you can find information about local events, things like Drupal Camps. It is where we recruit new contributors into the ecosystem, and finally it’s where we promote Drupal itself to the world.

As one of the perhaps the most powerful content management system, particularly for as we like to say the most ambitious kinds of digital experiences, there’s really a lot to say about what the Drupal CMS can do. And it’s part of our role to get that word out, not just to the people who already know, but to people who might be evaluating Drupal for their needs. So, there’s a lot that we do there. And in addition to that, from an engineering perspective, there’s a lot of infrastructure that goes into supporting the project; all the testing, all the code hosting, all the management of the contribution tools. So, a lot to do there, and a lot to support the community and make sure that Drupal keeps moving forward.

IVAN: So, I think you’ve outlined good reasons and areas why someone should care about the Drupal Association. What are your roles in the Association? Heather, you’re the Executive Director. Tim, you’re the Chief Technology Officer. What are your responsibilities? Heather, why don’t you go first.

HEATHER: So we laugh, lately it depends on the day. But I would say in general, it’s a small team at the Drupal Association, and we all take on a lot of responsibility in different roles depending on the day. But if I do my role correctly at the end of the day, I’m an ultimate advocate for Drupal specifically, and open source in general. So, what I try to do on a daily basis is take the vision and strategy from the Board of Directors, from input we get from the community, from working closely with Dries himself, and translate that into operational perspective from the Drupal Association. So, how do we take that long-term strategy and put that into action in both supporting the open source community as a whole, our Drupal community specifically, and then how do we move the project forward?

So, it’s a very interesting role, made not less interesting by the timing, as you mentioned, of mine coming on and a lot of events. But what I think is interesting is we constantly have the opportunity to innovate, and I know we’ll talk about that in a few minutes. But we have to look at what’s the upside from an innovation standpoint. So, that’s what we’re trying to do right now.

TIM: Yeah, and for myself acting as the Chief Technology Officer for the Association, I do a combination of very concrete work to manage the engineering team here. So, there are only four of us the engineering team on the Association side, and we do the support, the care and feeding for drupal.org itself, maintaining that site, making sure it’s up. We ensure that the Drupal CI testing system is there to provide test coverage for all the contributions that come into the project.

And we build all of the kinds of features and support for other program areas within the Association. So, for example, the engineering side of the DA is involved in figuring out our platform to do DrupalCon Global and to enable us to have a virtual version of DrupalCon. So, there’s a lot of different areas there.

I think one of the things that’s often not well understood about the Drupal Association, especially for people who are new to the community, is the DA isn’t a top down leader of the development of Drupal itself. Drupal is built by the community. It’s built by a group of initiative leads and core maintainers and community contributors. So, what we say about our work is, rather than building Drupal directly, We build the tools that enable the community to build Drupal. And that’s really my role and our role.

IVAN: That’s a really nice description of the fact that the community is actually building Drupal, and that you’re almost just facilitating it right with the tools?

TIM: Yeah, in many ways that’s our focus. Every time we can make an improvement to the tools that we provide, that can accelerate what the community does. It can enable them to do that work faster to ensure those contributions are performance and compatible with the rest of the existing code base, and to increase the pace of innovation in Drupal.

IVAN: And there’s so much work to be done there. It’s just amazing that a team of four can be doing that on such a global scale. I commend you. It’s just so wonderful to see. Jeff Robbins has often referred to the role of leading a small company or a big company and the role of CEO, as the Chief Paranoia Officer, and [laughing] I find myself in that position a lot, even more so lately. Do we have a particular person who’s the paranoia officer, the CPO right now, or is it kind of everyone at the DA?

HEATHER: If I’m doing it correctly I’m absorbing some of the paranoia on behalf of the team. The way I’ve tried to navigate is I try to take on a lot of the worry and look at all the worst case scenarios and then figure out what we can do, and then come back to the team and put plans together. So, Tim [laughing] may have another version of that, but I hope that I’m absorbing some so the team doesn’t feel quite as impacted.

TIM:  I think it’s absolutely true. And the truth is the Association, for better or worse, is not necessarily a stranger to crisis. Way, way back in the very beginning, the first shared host that drupal.org used kind of melted down, and there was a call by Dries to get donations for a server. We had a financial entrenchment about three and a half, four years ago. It’s not that there aren’t ups and downs. One thing I really appreciate about having Heather onboard for this last year though is she does exactly as she says. She’s done a very good job of focusing on how to execute to ensure that regardless of the completely unpredictable world of circumstances, we’re still able to move forward and deliver what we can for the community.

IVAN: Let’s talk about DrupalCon Minneapolis a little bit. You guys actually announced this two years ago. It was kind of the first time that the Association announced not only next year’s, like the following year's location of the North America conference, but also two years in advance. You guys have been planning this DrupalCon for awhile. So, making the pivot to online is not a minor feat. Let’s talk about the different scenarios that you were considering early on when this first came to light that there was going to have to be a change here. And how did you come to the decision that you did?

HEATHER: I can tell you we’ve run just about every scenario possible, but both from an execution and financial standpoint. We looked at what was the path early on of moving forward and what would that look and feel like and it became clear that was not an option. So, then we looked at that cancellation. There’s a theory that contracts have force majeure and everything’s okay in a pandemic, and legally that doesn’t always work out. So, we had contracts we were still locked into.

From an economic perspective, of course everybody involved wanted things to move forward because there’s so much economic impact from a conference in a city like Minneapolis. And so it has a much broader reach than just us and our attendees. So, there was some good faith efforts. Cancellation early on was not a choice, and even long-term not even a choice, because it would’ve left such a void between money that had already been spent and the lack of net revenue that we needed to move the Association forward.

We looked at cancelling and moving tickets to honoring them in 2021, but that ended up having a short-term positive effect and a long-term negative effect, where we would’ve landed in an emergency funding situation next year instead of this year. So, what we decided we needed to do was to pivot to online, and that was because two reasons. We knew that we needed a mechanism from a funding perspective. We looked at the gap and we said, Okay, we can’t raise all this through sheer fundraising, or we don’t think we can raise it also through just a virtual conference, so we’re going to need a combination there. So, we decided to move to the online virtual conference.

The other piece is, we remain dedicated to pulling the community together. I think it’s not just a financial issue for us, it’s a community issue. And we were highly disappointed that we couldn’t be together and execute on DrupalCon which, while it’s a fundraiser, is every bit as much if not more mission-centric program for us. So, it was important for us to develop an alternative that not only helped from a financial situation, but that met the community need. And I think while it is going to be a journey for us between now and July to make that happen, we feel good about the fact that we have a mechanism to bring the community together and excited about the idea that we have global.

IVAN: Any thoughts Tim?

TIM: Yeah. I would certainly agree with that. There were some more elements. As you mentioned earlier, I was briefly the interim Executive Director while we were in the search process in finding Heather to bring her on board. And, during that period is when we were making some decisions about announcing DrupalCon Minneapolis and the next events early, doing some contracting in advance with other events. It’s a little unfortunate in retrospect. We were so pleased with ourselves, patting ourselves on the back for securing these contracts in advance, getting some discounts for multi-year advance agreements, all these sorts of things we thought were going to make the next four years of DrupalCon a total shoe in, a really, really successful sort of thing.

And now we’ve had to think about how that changes. And, it’s not clear that even after this COVID crisis resolves, if we can say that it’ll even do that. But even after things return to some semblance of normal, it’s not clear that events will be the same, that they may change moving forward. So, it’ll be interesting to see how this pivot to virtual for this first DrupalCon affects what we do in the following years as well.

IVAN: How is it working with local governments and counties and companies in the Twin Cities region?

HEATHER: Minneapolis has definitely done everything they can to help us. I think where everybody met some challenges is, in lieu of governmental dictation, some of the contracts are hard to negate. And so, everybody was really good about working with each other, but we all had very similar constraints in trying to make things work.

The nice thing is we all landed in a place where we were able to significantly reduce our liability, and in a perfect world we would’ve been able to keep those contracts intact and bring money into the Minneapolis area. But it just wasn’t going to be safe to have attendees there. I think everybody was as nice as they could be. Everyone was very stressed out. It’s a tough time for the event industry on the other side of this as well, and it definitely has an economic impact when you don’t have big events coming to your local cities. And so, we’re very aware that this has an extenuating impact beyond just our circumstances as well. So, we appreciate everybody that worked with us to get here, even though it was really stressful for everybody involved. But we ended up where we needed to be.

TIM: I would add that the community itself, of course for those that don’t know, whenever we’re looking to put on a DrupalCon, we’re always looking for champions of the local region right, the local Drupal community of that city to come together with us and help us. First of all find the parts of the city that we want to highlight to the community, the usually international community that we’re bringing to that place, and also just to help us in organizing the event and selecting the program and finding speakers and all those sorts of things.

And from that point of view, I think the local Minneapolis crowd was one of the most engaged and dedicated and helpful that we’ve worked with for many years going back to all sorts of these DrupalCon events. The excitement was really high, and at the same time I know that they must’ve been, and are, hugely disappointed that we weren’t able to make it happen, they’ve been very graceful about understanding the change we needed to make, so that’s been helpful. It makes it easier for us to make the hard decisions and do the things we need to do in the community and the local region is so understanding and so helpful.

HEATHER: Absolutely.

IVAN: And I think we’re eternal optimists, so hopefully one day we’ll see DrupalCon back in Minneapolis for the conference that we were hoping it would be.

TIM: I would love that.

HEATHER: I hope so. I was very excited about coming to Minneapolis. I’ve never been. So, I would like to visit and I would like to go to Paisley Park. That was on my list of to dos. So, I’ll be back regardless. [laughing]

IVAN: [laughing] Yeah, the biggest joke and concern we had in Minneapolis was, [laughing] what happens if it snows? Because we’ve been known to have a snowstorm or two in the middle of May. I recall two conferences ago, I think we were coming back from Nashville, and I was stuck at the airport, because there was a snowstorm in Minneapolis, and we couldn’t leave Nashville [laughing] to come back home, so it’s definitely possible.

TIM: Oh my gosh.

IVAN: Yeah. Okay, let’s talk about DrupalCon Global. It’s not like all the planning’s done and you flip a switch and all of a sudden, Yeah, let’s go online. Tell me about the event, when it is. And then what about it is the same? What’s different? What are your thoughts going into it? What are you planning? Besides the people, what's new?

HEATHER: So, you’re exactly right. There was no playbook we were hiding for in the event of a pandemic. This is the DrupalCon Global event playbook. So we definitely had to pivot quickly. And I’ll give huge kudos to our Drupal Association team and our Board of Directors for huddling quickly and figuring out what we could do and what we could do well. Tim can speak to the technology pieces of it that we have to nail down, but I think we really sat down as a team and said, Okay, how can we bring the spirit of DrupalCon through a virtual experience, and how can we make this really impactful for people?

Where I think we have some exciting innovation opportunity is it is virtual. So, what are things that we can add to the mix? What are ways that exist now where people can connect virtually? There’s a lot of interesting platforms out there. Some that existed before, a lot that are springing up now, since we are definitely not the only virtual conference pivot that’s happening in 2020. We can’t be together physically, but how do we create a hallway tract? How do we facilitate networking? How do we highlight sponsors? How do we shift so that we’ve got this really great content library of knowledge and speaking engagements, and how do we use the best of peoples’ time so that it’s really interactive?

So, we’re looking at how do we let people have Q&A’s and interaction with the speakers and not just listening to a speaker do their presentation. So, I think we’re going to learn a lot through this, but quite frankly, we may translate to an in-person event in the future, and then my gut tells me that there will be some aspect of online DrupalCon in some form or fashion from this point forward. So, I think we’re going to learn a lot as we go.

IVAN: How do you do BOFs online? Come on.

TIM: No, it’s so tricky. Oh my gosh, it’s really interesting. That’s one of the things that I think has been interesting about this whole process, because obviously your first reaction to, Oh, the whole world is in crisis. Things are falling apart. You kind of clench up in a state of fear, and start thinking conservatively about, How do we just lift and shift an in-person event to a virtual event?

But I think very quickly we realized that that’s not the right approach. We have to understand that human interaction in a virtual context is fundamentally different. So, in order to create the same kind of connections between people, we need to make sure that we’re providing new sorts of tools and opportunities to make that happen. I think, I don’t know, I’ve been to something like 10 DrupalCons or something like that, and for me, one of the most powerful moments of any DrupalCon is not just the incredible information that comes from the formal program, from the actual speakers and the different events within the conference, but it’s the fact that you can find yourself sitting next to someone at the end of a session and get into this conversation about the topic. Develop this new connection to another person and then maintain that connection when you go back offline, whether it’s on drupal.org, through Drupal Slack, or just the next time you see each other at a DrupalCon. And we really wanted that to be possible, to be the case for this global event.

Plus, we’ve been saying the word over and over, we’re calling it DrupalCon Global for a reason. The opportunity of being virtual is that we can bring in people from all over the world. And there’s time zone considerations of course, but it’s a chance to have a group of people together that maybe couldn’t go to DrupalCon before. And so there’s an opportunity here really for some fresh interaction and fresh connections and new types of connections to be forged between people who attend.

Once we really started thinking about those opportunities on a conceptual level, we started asking ourselves, How do we execute that? What’s the difference between what happens at DrupalCon and just watching the sessions on YouTube after the event? What makes the difference? So, we’re looking at platforms that let you have that kind of round table experience of being in a BOF, but have these breakout session tools.

We’re looking at platforms that can simulate what it’s like to be in the contribution room, where you can select a virtual table to join for whatever kind of initiative you’re working on on contribution day. There’s some creative things that we’re looking at there. And in particular we’re trying to find ways to encourage people to be active participants in the event, and not just passively receiving. This shouldn’t be just an extension of the quarantine Netflix binging [laughing] that we’re all doing these days. It should be a conference.

HEATHER: It’s not distance learning, right?

TIM: Exactly. I think it’s going to be really cool. We’re still narrowing down all the technical details. We’re running demos of all sorts of platforms and tools, but we’re really going to try and focus on that, and I think people will find that it’s going to be a kind of unique experience. Hopefully we’re going to move that idea of passive consumption into active participation.

IVAN: I love that idea of actually flipping it on its head and making the audience more involved and be more active as opposed to passive. I think that’s definitely where the value of networking and the value of being in person is so high. And just for the record, for our listeners who have heard us refer to BOFs, birds of a feather, they’re interactive, not like a session, but group discussion almost, where there’s a topic that’s picked and everyone who is interested in that topic gets together in a room and talks about what problems they have, what successes they have, and so on and so forth. So, for those of you listening and heard us refer to BOFs, that’s what they are.

DrupalCon’s a significant milestone for the Drupal Association from a financial perspective, isn’t it? We talked about some of the numbers earlier. Can you guys give me an idea of what the budgets are that we’re looking at, and what kind of a shortfall are we talking about that we’re trying to fill in?

HEATHER: So, when we looked at the initial shortfall, both from a traditional DrupalCon plus some other economic impact on the Association because of COVID-19, we were looking at almost a million dollars of net revenue impact. Sixty percent of our total funding comes from DrupalCon, not because it’s a best practice, we’d like for it to be more of a third of our budget, and that’s where we’re headed strategically. We just haven’t had time to get there. So, it used to be 100 percent, so kudos to everyone that came before me.

IVAN: Yeah, making progress.

HEATHER: Yeah, [laughing] so everyone that came before me has done a lot of work to get us where we are, and we continue to do work. And so, we’re trying to develop obviously some revenue diversification, but you can’t do that in just a matter of months with this kind of impact. So, we looked at that net revenue impact and we said, Okay, there’s kind of two buckets to it. One is that emergency funding piece where we spawned the DrupalCares Campaign, and then the other piece is revenue that we can bring in through this virtual conference, DrupalCon Global.

So, between those two things, the Drupal Cares Campaign has gone exceedingly well, and so we’re hoping that the virtual conference has a similar level of success, so that we can pivot and move forward from a secure perspective. `We’re not naive enough to think that events will always be the same moving forward, so we are being very strategic internally about how can we be smart about what might be around the bend that we don’t know.

It’s hard to replace 60 percent of your income overnight. But we continue to do that through programs and services offered by the DA. And quite frankly, what we’ve seen through the DrupalCares fundraising program is when more people become members, when current members upgrade their membership, and when those that use drupal.org donate to the Drupal Association, that’s the kind of sustainable funding that makes this revenue diversification less of an issue moving forward. So there are ways that we can do this over time, and we’ve seen it be successful over the past month.

TIM: I would add to that, there’s another key area that I think frankly folks like you at TEN7 and others throughout the ecosystem can help us with. Just because of the scope and scale of the COVID situation even Drupal end users, who are not particularly connected to our community, are beginning to become aware of the importance of the Association, and how it feeds and sustains the Drupal project and how that could be important. We didn’t really mention this earlier, but not only is the Drupal Association being affected by the COVID pandemic, Drupal’s also being used in the fight against COVID and to try and manage it. So, it’s used by the National Institutes of Health and the CDC and Oxfam and Doctors without Borders. It’s being used all over the world to support that people's efforts. And the DrupalCares fundraiser, among those things, has given us an opportunity to try and reach out to those end user organizations, because for my money that’s I think where we’re going to find a lot of opportunity for future sustainability. And so, for folks out there listening, helping us get the word out to those users of Drupal about the importance of supporting the DA and becoming part of our community is going to be really impactful.

IVAN: Yeah, you forget that there are users of Drupal who are actually fighting against COVID, and that’s so important to bring to the surface and to remind people. So I’m glad to hear that that’s something that’s been a focus for you as well. In a nutshell, can you guys describe exactly what DrupalCares is? I think the three of us know what it is. For those who are listening who maybe don’t have an idea, what’s the elevator pitch on what DrupalCares is?

HEATHER: So, DrupalCares is the name that we gave our emergency fundraising campaign that launched toward the end of March. And the goal was, as it sounds like from an emergency funding perspective. What became clear to me though I’ve only been here just around a year, is that this was not a crisis we would solve internally. This is a crisis that the community would help us join together and solve. And so, this was the way for us to reach out to the community to say, Here’s where we are. Here’s what we need to accomplish. Now let’s do this together!

And the community rallied and answered that call in a way that proves out everything I’ve heard about the Drupal community and my time here, and even quite frankly, during the recruitment process about how wonderful this community was. It’s true, no one lied to me. It’s exciting. [laughing] Yay!

IVAN: And what was the goal for DrupalCares?

HEATHER: The goal was to raise $500,000 which seemed doable, so really ways that people could participate in that. There was something for everyone as they say. So, new memberships and upgraded memberships counted toward that goal. Cash donations, which we had over 1,000 individuals just donate cash toward DrupalCares. We had DrupalCon existing sponsors that agreed to leave their dollars intact as we figured out what was coming next. We have organizations that donated cash. We had large individual donors. So, all of those things came together to actually help us meet that $500,000 goal, and we met it almost a month in advance of the original deadline, which was the end of May. So, this has been amazing to witness. It proves the strength of not only Drupal as an ecosystem, but the strength of our community, how quickly the businesses came together to make this work.

Dries (Buytaert), our project founder, and his wife, did an initial $100K matching campaign, so that every dollar that came in was matched. And then we had a group of Drupal businesses that came together and did the same, so that all of the impact was tripled. We met the goal! We have a great story to tell! And now we can really focus on DrupalCon Global and all the other things we do at the Association. So, the campaign was a huge success and very heartwarming for all of us involved. We’re glad to ring the bell on that one.

IVAN: How exciting. How terribly exciting that we’re able to reach the goal like that. That’s just wonderful. What else are we excited about besides DrupalCon Global? What are you looking forward to? Is it Drupal 9? Is it something else? I know I’m excited about Drupal 9. I’m excited to tell clients that it’s not going to be a big deal to upgrade, that they’re not even going to notice in most cases. That’s exciting for me in addition to the new features and the new things that it brings. But tell us about what you guys are excited about.

TIM: I can nerd out about this topic for hours, so [laughing] I’m going to jump into this one a little bit. So, of course we’re excited about the release of Drupal 9, just as a milestone for the community. So, that’s a really big deal. But as you say, and what folks out there maybe don’t quite understand yet, is Drupal 9 is the culmination of a huge amount of work over the course of about the last five years, over the entire Drupal 8 cycle, to realize a vision of a Drupal 8 software that receives continuous innovation, six-month feature releases on a regular basis, and that has an easy upgrade between major versions. The days of having to basically do a replatforming, a complete migration to go from one major version of Drupal to another are over, and we’re close enough now to the release to realize that, Yes, we’ve achieved that. We’ve actually reached that point. And that’s phenomenally exciting.

IVAN: [applause] That’s awesome.

TIM: Yeah, it’s just so cool. It’s wonderful to be at that point. I was here for Drupal 8. I was working at the Association during the Drupal 8 release cycle. And there’s just a night-and-day difference between what the struggle was to try and make that upgrade happen, and even just to hit the deadline for our release date back in the Drupal 8 cycle.

And so, every change that was made over the course of Drupal 8 has just brought us to a fantastic place on that front to make these updates easier and to make these initiatives and regular feature releases more impactful. There are a few things I’m particularly excited about over the horizon of what’s upcoming after 9 comes out, the 9.1, 9.2, the feature releases that are going to be coming next.

I think what I would say about what’s going to happen over the course of the lifecycle of Drupal 9 is Drupal 8’s initial development and much of its early feature releases, maybe up through 8.5 or so, were very, very heavily focused on fundamental and powerful architectural features of the software platform itself. There were a lot of the API first work, a lot of the entity management work, revisioning work, APIs for various components in Drupal, a lot of that work was a key focus in the Drupal 8 cycle, And it’s what’s made Drupal the incredibly powerful platform that it is.

I think a lot of work in Drupal 9 is actually going to be focused on empowering users who are not the most technical engineering users, to actually be able to fully take advantage of those sorts of features. So that’s going to come in several different forms, but by empowering those regular users to be able to take advantage of all those great architectural changes, is going to be, I think, the next phase both in adoption for Drupal and in really showcasing everything that it can do.

So, a few of those things include focus on automatic update initiatives for Drupal. There was some good work on the first phase last year, and the second phase work going on now and continuing into next year that will just help reduce the cost of ownership, to make it easier to keep sites secure and up to date, and there’s tremendous work going on there. There’s also work to make both the administrative interface of Drupal and the default theme for Drupal more modern, more robust with modern JavaScript workloads and things like that, but with all the same accessibility tools and everything that have always been a priority for Drupal.

I think what you’ll see is that these first several feature releases of Drupal are going to be about that layer where the regular Drupal user, the person who spends their day job in the admin interface becomes empowered to do more and more with each of those kinds of features.

IVAN: So, when are we expecting the actual release to come out? I think we were scheduled for the beginning of June. With the pandemic going on, are we still going to hit that? Let’s talk about when it’s actually coming out.

TIM: That’s also super exciting. So, I’m going to bury the lead for a moment just to build up the story, [laughing] ‘cause I’m excited about it.

IVAN: [laughing] Good. Good. Yeah, do that.

TIM: Okay, so back in Drupal 8, I don’t know, you probably remember that the Drupal 8 release cycle, I almost measured in terms of DrupalCons. I think there were probably four different DrupalCons where the community thought, Oh, this’ll be the DrupalCon where Drupal 8 comes out. And then it was like, Oh, no, we missed that one. It’s going to be the next one. And we missed that one. It’s going to be the next one. It was an angsty difficult time, and we eventually got there which is wonderful, and I think we’ve realized tremendous work since then. But that was pain we didn’t want to repeat, right?

IVAN: Right.

TIM: So, for Drupal 9, the core maintainer team established three official release windows. The idea was if we hit any of these three it would be an on-time release. So, the three candidates for release were going to be the beginning of June, August or December of this year. So, those were the three windows, and the whole idea was that we’d be very happy if we hit really any of those.

The June date was going to be the most aggressive date for sure. What I’m thrilled and slightly shocked by is, we’re going to hit the June 3rd release, so less than a month away! Drupal 9 is going to be out, and despite the pandemic and everything else, we’re going to be on time with our most aggressive and ambitious release date. So, it’s very, very exciting.

IVAN: That’s amazing. That’s just testament to the organization and all of the volunteers that have done all of the work to go into that and all the planning. And frankly the setup that’s been done in Drupal 8 to go to six-month release cycles to get into that habit and to set ourselves up for a release of Drupal 9. That’s, I would say, early not late or on time, but early.

TIM: Pretty much, yeah. Absolutely the earliest we could’ve conceived it happening. So, it’s really exciting.

IVAN: And what does the launch actually look like?

HEATHER: So, we’re working on that. [laughing] That’s part of the, Will it be on time? Surely not with everything going on. Oh, it is. Pivot again. So, part of what the Drupal Association is responsible for is, orchestrating the Drupal 9 launch. What we mean by that is putting together some of the marketing and PR planning around it as well as a toolkit that we can give to organizations. In particular Drupal businesses, so that they can promote it amongst their current and potential clients. And so, we’re putting that toolkit together now.

We have a draft press release that we’re going to get out to all the stakeholders very soon, so they have time to do translations and to build their press list, so that we can make this truly a global effort. But, we normally would’ve had a big splash in Minneapolis going into this, so we’ve got to find ways virtually to do it, which the community’s helping us organize some of those celebrations. But, we’ve got a lot of the marketing/PR effort on our side that we’re working on right now and should have some things coming out shortly. And Tim, I know you’ve got some more information from the community as well.

TIM: Yeah. Back during the Drupal 8 cycle again. We did this celebrate D8#endcampaign, and a lot of the people in the community who were involved in organizing that effort, are working together through the Drupal community Slack to set up a celebration for Drupal 9. And that’s going to be a way, so that on the release day global communities can have virtual celebrations about the release, and that’s going to be really exciting. I think that handles a lot of the internal side, but I think a lot of the efforts that Heather is talking about are really critical for the external perception of this release, and what it’s going to mean to the larger open source community and the technology community in general.

Major releases of Drupal are typically our opportunity to reintroduce Drupal to a wider audience. Our minor feature releases, even though they often have some really powerful new tools, don’t necessarily get the press coverage in the broader technology media that the major releases do, and we really want to make sure to capitalize on that. And so, that’s why this international translated press effort is underway, new landing pages with all the highlights about Drupal 9 are being built, all of those sorts of things. So, I think we’re really excited about that. And then, at the same time, we want to build that into momentum. I think it’s going to be a story that’s not about, Oh, we build up, we build up. June 3 is a big hooray, rah, rah, rah. And then we’re done. I think we’re going to need to be telling that story over the course of really a year or more about what it means, because we’ll have a lot of people who are then beginning their upgrade process.

We’ll have the feature releases starting to come out. We’re really going to need to share and tell that story. So, that’s going to be really important. And, we’re going to need to continue to innovate. So, Dries just published The Drupal Product Survey for 2020.

IVAN: I was just about to ask you about that.

TIM: Yeah, so that just went live. You can find it in the announcement banner on drupal.org or you can find it on Dries’ blog which is very easy to find dri.es, probably one of the shortest domain names on the web today.

IVAN: That’s wonderful.

TIM: So, I’m kind of jealous [laughing] but anyway, that product survey is something that’s been done annually, but especially around the time of a new major release. It’s a really powerful tool for end users, Drupal businesses, anybody in the community to actually have an influence on what comes next. So, I said earlier that I think one of the primary focuses is probably going to be on empowering users to use those low level tools that have been built in recent versions, to create better user experience to access all of those tools. But I think there’s other opportunities, and the survey is a great way to get that word out to the Drupal project leadership about what’s coming next.

IVAN: So, the Drupal Product Survey is currently listed on Dries'  website. We will link to it from the show notes. Go ahead and take that survey. It gives the community an opportunity to weigh in on the strategic direction of the project, and I think that’s just so valuable to do. Thank you for mentioning all of those things.

I want to say something about the new logo for Drupal 9. It’s so cool. [laughing] I love it. I love that it’s being unified across the brand. That work that SIX ELEVEN has done has just been so refreshing and evolutionary. It’s just lovely to see this is happening. Tell me about the new logo. Why do we need to unify across the brand and are we going to see a new logo for Drupal 10? What’s the thought process behind this?

HEATHER: So it’s interesting. There is not an intent to have a new logo for Drupal 10. Tim and I have been closely involved in this. There was a conversation both from key members of the community and internally at the Drupal Association that we wanted to establish what we call an evergreen logo. So, instead of being tied to versions, which if you’re thinking about most of the software and technology that you use, you’re not even aware of what version you’re using, you just know you’re using it. So, we want people to know they’re using Drupal and be less concerned about the version. So we think an evergreen logo is going to help us with that.

It’s going to help us from a marketing and PR perspective as well. A lot of the input that I get from community leaders in our business community is that we need more brand recognition. We need stronger branding in the technology community in general. And so when you have people spinning up different versions of logo, and you’ve got those all over the world, it’s hard to create that brand consistency. So, we’re hoping this evergreen logo will do that. And then it was important to us to really look at it and say, Given that Drupal the product and project, the Drupal Association and DrupalCon are all really tied together, it’s part of the same ecosystem. And so I really wanted to make sure and luckily the team agreed, and SIX ELEVEN did a great job pulling this together, about let’s make sure that that tie in is obvious.

I think we learned a lot through this DrupalCares campaign, that we can do a better job telling the Drupal Association story, and our tie to the Drupal project–that we’re not at arms length from what happens with Drupal from a technical perspective–that we’re more a part of that ecosystem in a big important way. And so we wanted to make sure that it was obvious that all those three things were together. And so, I like the logo, I’m glad you like it too.

SIX ELEVEN did great work. They stepped in as a really strategic partner at a time where we not only needed creativity in what they produced, but creativity in what they would expect from an expense perspective. So, knowing that we were having a bit of a financial crisis, they really stepped up and stepped in in a major way and created something that I’m really proud of, and to your point about will there be a new D10, the idea is no.

Tim’s been really involved in this too from the very beginning and has some thoughts on it. But I’m really excited that it’s out there. I think it’s yet another thing that I’m proud of the team and the community for coming together and getting done where we could’ve easily said, You know, there’s too much going on. Let’s put this off. But I really wanted to make a push to have these major products move forward.

TIM: Yeah, I would just add a few small things to that, which is just that the evergreen sense of the logo, that notion that we don’t need to change the brand identity for Drupal with major versions, ties exactly into what we’ve been saying about Drupal 9 and it’s upgrade path. The upgrade from Drupal 8 to Drupal 9 is going to be as easy as a minor version update. There’s huge progress in the contribution ecosystem already to make the modules that everybody uses compatible with Drupal 9. Even before Drupal 9’s release, something like 40 percent of the top 200 modules are already compatible, huge amounts of other modules are compatible, we’ve got new automated tools. It’s just much easier to make this transition, and that’s going to be true from 9 to 10 as well.

My understanding from the core maintainers is that this commitment to this upgrade cycle is not a one off from Drupal 8 to Drupal 9. This is going to be true moving forward. So the Drupal 9 to 10 release should be just as easy, if not easier, since we’ll have more time to even further refine these tools and the strategy of doing things. And so, if that’s really our goal, if that’s what we’re saying is important in part of the Drupal development process, that should be reflected by our brand and reflected by our logo. And I think that’s where we landed. I’m really proud of that work as well.

IVAN: I’m proud of it as well. You guys have done a wonderful job of rolling it out as well and showing off the brand and using it, and I think it’s only going to get better from here on in. And I love the word evergreen. It’s just so true that that’s what the logo is intended to be. I wonder if we’ll ever stop using version numbers and just refer to Drupal as the product?

Just like you mentioned, Heather, I don’t think some clients in the business world really care about the version number. In most cases I think it brings angst and concern about the cost of an upgrade for example. So, if we make that upgrade easy, do we consider not even using version numbers?

TIM: You know, I think we’re moving in that direction. I think that the current set of brand tools offers both a version with a much smaller and de-emphasized version number and a version without it at all. And I think increasingly we’ll start to see that non-versioned identity come to the floor. I think right now the lead up to this change and the sense of Drupal 9 being a milestone is still important to people, because it is the culmination of that promise, it is the realization of, Oh yes, we said it was going to be easy, and it actually is. So, I think there’s this sense that we still need to acknowledge that 9 represents that milestone, but going beyond that I think that becomes less important, and hopefully we can realize that with this change.

IVAN: Wonderful. It’s been really awesome talking to you both. I can’t believe it’s been almost an hour. [laughing]. It’s been great having you on the show. Anything you guys want to say in closing before we wrap it up here?

HEATHER: I want to take this opportunity to thank everybody in the Drupal community, whether you’re an individual or an organization or a camp or a local association. Everybody really came together in this time of need and made it possible for us to not only execute on the DrupalCares campaign, but the support around pivoting to DrupalCon Global, the Drupal 9 launch, the new logo. All these things are happening, and we’re committed as a team to pushing forwarding and to doing good things with your investment. And we’re developing strategic plans right now at the Board of Directors level where we’re looking to do even more.

So, I think folks from DrupalCon Amsterdam heard us launch that we’re working on ways to continue removing barriers to make contribution easier. I’m looking at how we increase brand awareness and adoption of Drupal so that we can satisfy the needs of our Drupal business community. We’re looking at further development of security products around Drupal and enhancing our member and volunteer programs, and also looking at diversity, equity and inclusion programming. So, those are all things we’re committed to. COVID or not, that we’re going to create and push out to the community, and not only for the community itself, but to make Drupal an even stronger product.

IVAN: Rock on.

TIM: Anybody out there who’s listening who represents an end-user organization of Drupal, understand that you’re part of our community, come join us. Come participate with us. Find ways to get involved. You can reach out to us at the Association, or you can simply go to drupal.org and find the community where they are. But we’d love to bring you in closer and have you be part of the future of Drupal. So, we hope you’ll join us.

IVAN: Wonderful. Thank you so much, both of you, for spending your time with me today. It’s been a great pleasure talking with you.

HEATHER: Thank you for the opportunity. This was fun.

TIM: Yeah, thanks for having us. This was really great.

IVAN: Heather Rocker is the Global Executive Director of the Drupal Association, and Tim Lehnen is the Chief Technology Officer of the Drupal Association. You can find Heather on Twitter as @hsrocker and Tim is @hestenet. And I’m not sure that i said that right, but it’ll be in the show notes. [laughing] For more information about the Drupal Association, visit drupal.org/association, and don’t forget that you can make a contribution to the DA to sustain it through this pandemic and the devastating effects that COVID-19 is having. Just visit drupal.org/cares.

You’ve been listening to the TEN7 Podcast. Find us online at ten7.com/podcast. And if you have a second, do send us a message. We love hearing from you. Our email address is [email protected]. Until next time, this is Ivan Stegic. Thank you for listening.


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