Upgrade Your Drupal Skills

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

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

Ryan Price talks with Michael Meyers about Yjs (an open-source project that enables real-time, collaborative editing similar to Google Docs) and Goose (a load testing tool), after that, Mike Anello talks with Dane Powell about Acquia BLT.

URLs mentioned

DrupalEasy News


Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

May 29 2020
May 29

As the world navigates through a public health crisis, and we are all responding to unprecedented conditions, it is a good time to evaluate how well your website is working to communicate urgent information, and how it might be improved going forward. 

The team at Kalamuna has helped many organizations prepare and respond to emergencies, and in this series of posts, we are sharing research and lessons from our previous projects and the best practices we are now recommending to our clients.

Web Design for Disaster:
Part 1 - Alert Banner Best Practices 
Part 2 - Emergency Landing Page Best Practices 

Why create an emergency landing page? 

When a natural disaster or other crisis arises, many organizations suddenly need to use their website to convey urgent new information to their stakeholders. Sometimes, posting a brief message in a well-designed alert banner may suffice, but often an emergency situation is complex, rapidly evolving, and requires robust crisis response communications.

While you might try to publish urgent information using the existing features on your website, you may soon find that components and layouts designed for marketing, fundraising, or other day-to-day activities are ill-suited for use in a crisis.

Implementing a dedicated emergency landing page may be the best way to ensure that visitors will find the crucial information they need, while keeping them from being obstructed, distracted, or confused by content that isn't relevant to the current situation.

Before starting any design or development project, Kalamuna recommends conducting a thoughtful discovery process to research the specific needs of your users and to select an appropriate strategy for your organization. Solutions that have worked well for others might not be the best choice for your particular circumstances. If you’re not sure where to start, we can help!

What types of emergency landing pages are there?

There are three common types of emergency landing pages that we have designed and implemented for our clients, each having advantages and drawbacks. The choice of which to use for your website will depend on the situation, the amount of information that you are looking to present, and the resources available for design and implementation.

The simplest and most common design is the internal landing page, which is a page or section of pages within your site dedicated to providing information about an emergency. While this is the easiest to implement, and may even be created using an existing template, your ability to customize the structure and design of the page may be limited, and you will need to figure out how to reliably direct users to it from your homepage.

screenshot of FEMA's landing pageThe Federal Emergency Management Agency has created a coronavirus landing page within their website, providing information and resources to help both the general public and several specific audiences.

If you want to display urgent information as quickly and prominently as possible, we recommend creating a homepage takeover, where your existing homepage is unpublished and replaced by content that strictly focuses on the emergency. This is the most reliable way to get important information in front of your audience while minimizing distractions, but it is more complicated to implement and may interfere with users not affected by the crisis who are looking for unrelated information.

The Australian government has replaced its main government homepage with a landing page of resources about the coronavirus epidemic.

The Australian government has replaced its main government homepage with a landing page of resources about the coronavirus epidemic.

If you want to provide an experience that can be highly customized and can deliver a lot of information over multiple pages or sections, you might create an independent emergency site, located at a separate domain or subdomain. This option gives you the most flexibility in terms of design and structure, but it could be the most expensive to implement and maintain, and might be difficult for your stakeholders to find.             

California utility companies created a stand-alone emergency site to inform the public about power shutoffs during the 2019 wildfire season.California utility companies created a stand-alone emergency site to inform the public about power shutoffs during the 2019 wildfire season.

Our friends at Pantheon have created a free pre-built response communications site for organizations on the COVID-19 response front-line to use built on WordPress. Find out more about how to use the project template and its feature set.

What should be included on an emergency landing page?

One of the most useful things for visitors to see when they arrive is a brief summary of the situation. Quickly state that there is a crisis in progress, specify who may be impacted, and list any urgent actions that need to be taken. Determine what is most important to communicate to someone who is just learning about the situation and only has time to read a few sentences. 

The Australian Department of Health provides a concise summary of the content on each page of their coronavirus alert section.The Australian Department of Health provides a concise summary of the content on each page of their coronavirus alert section.

If a situation is out-of-the-ordinary, or if the problem is technical, you may need to provide background information to help people understand what is happening and why the situation should be given the appropriate level of concern. The danger may not be immediately apparent, or popular perception may be wildly different than how things unfold in real life. Try to keep your explanation to one or two paragraphs, consider showing a video or diagram, and then provide a link to additional details.

[embedded content]

The coronavirus landing page for the government of Barbados highlights a WHO video to provide background information to their citizens.

Many visitors may return to your site to see the latest announcements during a crisis. Displaying that content prominently can allow your audience to quickly see what has changed, but be careful not to overshadow the summary or important links that you want visitors to see as soon as they arrive.

The update section on the New Zealand coronavirus site is designed to stand out and be easily found but follows after other sections of basic information and important links.The update section on the New Zealand coronavirus site is designed to stand out and be easily found but follows after other sections of basic information and important links.

To keep people informed without needing to revisit your website, you may provide ways for them to subscribe to updates. That might entail a signup form for email or SMS notifications, or links to social media accounts where you plan to post additional information as it becomes available. 

The CDC Covid-19 landing page lets you subscribe to a situation-specific email list, and displays contact information and links to a myriad of social networks where they have accountsThe CDC Covid-19 landing page lets you subscribe to a situation-specific email list, and displays contact information and links to a myriad of social networks where they have accounts.

Some visitors may need help beyond the information provided on your website, so consider displaying contact information for your organization. If you are unable to provide urgent assistance, provide the contact details for emergency services that can help. Make sure to place telephone numbers in a tel: link and email addresses in a mailto: link, so users can easily reach out with a single click.

If there are specific tasks that your stakeholders must take in response to the emergency, provide a clear list of action items. If the items aren’t immediately applicable to everyone, clarify who your audience may be and the relevant instructions.

The California State coronavirus site not only lists the actions that the public should do but also ones that they shouldn't.The California State coronavirus site not only lists the actions that the public should do but also ones that they shouldn't.

If the effects of a crisis vary based on geographic location, make sure to include an overview map of the situation. Clearly mark areas where residents may need to evacuate or be prepared to take action. For detailed instructions, you may also need to provide an interactive map, high-resolution download, or address lookup tool, but try to start with a static graphic that can be quickly and reliably loaded on all devices, and is potentially printer-friendly as cell service can become unreliable in disaster scenarios.

The Bay Area News Group made a helpful map showing which areas would have needed to be evacuated if the Anderson Dam had started failing.The Bay Area News Group made a helpful map showing which areas would have needed to be evacuated if the Anderson Dam had started failing.

If there are common concerns that you anticipate your audience to have, or if they have contacted you for clarification after the landing page was first published, consider adding a section that answers their frequently asked questions.

The federal coronavirus website not only lists the most frequently asked questions but also provides a search form to find answers to additional concerns that visitors may have.The federal coronavirus website not only lists the most frequently asked questions but also provides a search form to find answers to additional concerns that visitors may have.

There may be additional resources that can provide details or updates about the crisis, including expert sources, news outlets, and government authorities. Compile a list of links to helpful information, and try to clearly mark any external destinations with an accessible icon so users know they will be leaving your site.

The San Francisco Unified School District provides a list of resources with links clearly-marked as external, both visually and for screen readers.The San Francisco Unified School District provides a list of resources with links clearly-marked as external, both visually and for screen readers.

If the amount of content you need to provide is substantial, you will need to create supplementary pages on your site. Additional navigational elements will be required, such as a special menu to travel between relevant pages, and a return link to help users return to the main landing page. 

The California Coronavirus response site provides a sidebar menu to navigate between the different sections and prominently displays the date and time that each page has been updated.The California Coronavirus response site provides a sidebar menu to navigate between the different sections and prominently displays the date and time that each page has been updated.

Since the content on your emergency pages will certainly change as the situation progresses, display the updated date and time for each resource, so people know they are receiving the most recent and accurate information. Also indicate when planned updates will happen (e.g. 6:00 p.m. every day) so people know when they can expect new information.

Not everyone coming to your site will be able to read English fluently, so it is important to provide ways to read the urgent information in alternate languages. If you don’t have the resources to manually translate the content, tools such as Google Translate are available to provide an automatic translation.

The New Zealand coronavirus site not only provides translation options but additional resources to make their content more accessible to different audiences. The New Zealand coronavirus site not only provides translation options but additional resources to make their content more accessible to different audiences. 

How should you prepare in advance?

Since emergency landing pages look and function differently than other pages on your site, and will have a different structure and components, it is important to prepare a system to deploy them well in advance of a crisis. And in addition to the design and technical details, we recommend considering the content itself that will be contained within your landing pages.

Before you start implementation, research best practices for emergency communication strategies. Collaborate with stakeholders who were trained and are responsible for emergency procedures as well as communications for your organization.

Consider a process of contingency planning in response to a scenario plan. You can start drafting messages, compiling helpful resources, and generating graphics and maps that would be needed. 

Kalamuna designed and implemented an emergency homepage takeover for San Jose Water, which includes a template that can be adapted when an emergency occurs.Kalamuna designed and implemented an emergency homepage takeover for San Jose Water, which includes a template that can be adapted when an emergency occurs.

Ideally, you can create the landing page itself as an unpublished draft within your CMS, so that your staff can collaborate on content and see how things will look and function before it is deployed. You may even create several different draft landing pages for various potential situations, so when a crisis occurs, you will be able to add the situation-specific details to one template, and quickly publish it.

Kalamuna designed this custom interface using Drupal workflows to allow a client to quickly switch between different home pages in the event of a special promotion or emergency while making sure draft content is not deployed before it has been reviewed and approved. Kalamuna designed this custom interface using Drupal workflows to allow a client to quickly switch between different home pages in the event of a special promotion or emergency while making sure draft content is not deployed before it has been reviewed and approved. 

Just like with alert banners, make sure you have tested components in advance, made clear who is responsible for deploying the page, and created an interface that minimized the risk of accidental activation. We will provide additional tips on ensuring accessibility in an emergency and organizational planning with future posts in this series.

Hopefully, this post has helped you determine whether an emergency landing page might be a good solution for your organization, and what information your stakeholders might find most useful in a crisis. Stay tuned for additional posts in this series, and please contact us if you would like help refining your website and communication strategy.

Web Design for Disaster:
Part 1 - Alert Banner Best Practices 
Part 2 - Emergency Landing Page Best Practices 

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 more 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 29 2020
May 29

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

Universell utforming av IKT handler om å utforme nettsider, apper og automater slik at flest mulig kan bruke det uavhengig av funksjonsevne. De som bruker nettsiden din kan være svaksynte eller blinde og avhengig av skjermlesere.  Du kan også ha brukere på nettsiden som har nedsatt motorikk og som bruker hjelpemidler for å navigere nettsiden, eller brukere med kognitiv svikt. 

Vi har samlet fem tips for hvordan du kan gjøre nettsiden tilgjengelig for flest mulig brukere.

01. Typografi - gjør nettsiden din lett å lese

Nettsiden din skal være lett å lese. De som bruker nettsiden kan være svaksynte, de kan ha kognitiv svikt, eller de kan rett og slett ønske å skumlese innholdet på siden. Enkle designgrep som å bruke riktig størrelse på teksten, lengde på linjene og underoverskrifter hjelper til her.

På papir er det vanlig å bruke 12 punkt på tekst, mens på skjerm blir dette svært smått. Det er anbefalt å heller bruke 14 eller 16 punkt. Teksten skal også komme godt fram over bakgrunnen. Unngå at lange tekster ligger oppå bilder, og bruk i stede gjerne ensfarget transparent bakgrunn om nødvendig. 

Lange linjer er tunge å lese, og den lange avstanden fra slutt til starten av neste linje kan også forstyrre flyten i lesingen. For en side med én kolonne er 45 til 75 tegn regnet som god lengde. Det hjelper også med leseflyten at starten på hver linje er lik. Brødtekst bør derfor være justert til venstre, ikke midtstilt. 

Del opp teksten i paragrafer og bruk overskrifter og underoverskrifter. Dette gjør det lettere å forstå strukturen i teksten. Pass på at overskriftene er større slik at de skiller seg fra brødteksten.

02. Kontrast for svaksynte og fargeblinde, men også de som er ute i sola

Mobiltelefon som holdes opp mot sola, med refleksjon på skjermen.

Det hjelper lite at teksten er stor nok hvis du har lys grå tekst på hvit bakgrunn. God kontrast på tekster, knapper og ikoner er svært viktig. Dette er ikke kun for svaksynte, men også for brukere som har lav lysstyrke og kontrast på skjermen sin, for eksempel når man er ute i sola. 

For at innholdet skal komme godt nok fram 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. 

03. Riktig bruk av alt-tekst

Mann med en hvit Guy Fawkes maske står mot kamera foran en grafittivegg.

Alt-tekst er tekster som kan leses av skjermlesere slik at de som ikke kan se bildet får med seg all viktig informasjon på siden.

En typisk feil er å starte alt-teksten med “Bilde av ..”. eller "ikon for ...".  Skjermlesere vet hva innholdet er, men trenger en tekst for å beskrive det for brukeren. Start derfor heller med å beskrive bildet enn å forklare at det er et bilde.

Det er også viktig å være detaljert hvis det er viktig for konteksten. Alt-teksten skal ikke bestå av nøkkelord, men være en fullstendig setning. Eksempel på dårlig alt-tekst her hadde vært “Person med maske, grafittivegg”. En bedre alt-tekst er “Mann med en hvit Guy Fawkes maske står mot kamera foran en grafittivegg.”. Pass også på at teksten ikke blir for lang. Maks lengde på alt-tekster er 125 tegn.

04. La lenkene skille seg ut fra teksten

Lenker i brødteksten kan av og til være vanskelig å oppdage, særlig for svaksynte og fargeblinde. Lenkene bør derfor skille seg tydelig fra teksten rundt, både med en farge og understrek. Men det er ikke bare i designet at man kan gjøre en forskjell. Hvordan man formulerer tekstene er også viktig. Man ser ofte at lenkene heter “her”, og ligger i slutten av en setning. For eksempel “Les om våre tilbud her”.  I stedet vil du fortelle hva lenken gjør eller hvilket innhold som venter i selve lenketeksten. En bedre lenketekst ville vært "Les om våre tilbud".

05. Gjør tekstene lett forståelig

Dette punktet henger mye sammen med det første, men dette går mer på språk og innholdsproduksjon enn design og layout. 

  • Gjør tekstene dine korte og presise. Unngå å skrive lange paragrafer som går over flere temaer. Bruk også gjerne punktlister. 
  • Bruk et enkelt språk. Hvis du bruker forkortelser eller fagbegreper er det lurt å forklare disse første gang de brukes.
  • Del opp sider med bilder og illustrasjoner. Dette hjelper å få fram poenget i teksten.

Kort fortalt

Du vil at nettsiden din skal være tilgjengelig for alle. Jeg har foreslått noen grep man kan gjøre for å forbedre siden, men dette er bare noen tips man kan ha i bakhodet. Har du spørsmål eller trenger hjelp til å gjøre brukeropplevelsen bedre for alle dine brukere, ikke nøl med å ta kontakt med oss.

May 29 2020
May 29

With the imminent release of Drupal 9, it’s a great time to give serious consideration to your update strategy. There is much to look forward to this time around, whether you are a Drupal veteran or new to the family.

The good news is that this will be a much easier process than the most recent major version updates, so if you’ve been using Drupal a while, this should come as a relief. However, It is important to note that while it is not a painful migration process, it’s also more than just a few clicks away. Drupal 9 changes a few assumptions many of us are used to as Drupal site builders, but preparing now will take you far.

Drupal 9 is basically just Drupal 8 with updated dependencies and deprecated code removed, which makes for a fairly straightforward update process, but the devil is in the details.

Getting Started

First, there are some prerequisites you’ll want to keep in mind.

  • Your current site must be running on at least drupal 8.8 to upgrade. This means a fully up to date install.
  • You must use PHP 7.3 or higher. Drupal 9 requires php 7.3
  • In some cases, Drupal 9 needs a newer version of whatever database you're on now, so you may need to upgrade your database. See Environment requirements of Drupal 9 for details.

As you start looking for Drupal 9 compatible modules, you may find yourself a little perplexed as you browse modules on Drupal.org and notice that none seem to have a Drupal 9 compatible release.

They do, but it's a bit hidden.

(Note that you do not have to look up every module you are using on Drupal.org. We'll get to a handy reporting and scanning tool shortly, but it's important to note these changes to how modules will work with Drupal 9.)

You will find Drupal 9 compatibility in the small text under "Project Information."

The concept of modules being tied to a major release is old Drupal, and we're living in the future now. Modules can work with more than one major version of Drupal! So, you won't see a big highlighted box for a Drupal 9 release on module pages.

In the near future, you'll start seeing more module releases using semantic versioning on Drupal.org. A few are already there. The major version of core will no longer be part of the module's version number. You can see this in action on the semver_example module and on the Lightning project page.

Lightning version 5.x.x uses semantic versioning.

Evaluate Your Site

Once you have met the requirements to run Drupal 9, the next step is to evaluate your site. The first course of action is to update all modules to the latest version. There's a good chance they're already D9 compatible. Then, check for deprecations in your themes, contrib modules, and custom modules.

Deprecations are old Drupal 8 functions which have been removed from Drupal 9, and you’ll need to find them to replace them with up-to-date code. To do this, I recommend starting with the Upgrade Status module. This module will scan your codebase for deprecations and provide you with a handy report. Install it in your development environment, and note that it must be installed with composer.

$ composer install --dev
$ composer require 'drupal/upgrade_status:^2.0'

Once you've enabled Upgrade Status and navigate to its report at admin/reports/upgrade-status, you'll see some important information about your environment that will indicate your ability to run Drupal 9.

The top of the Upgrade Status report. Upgrade Status will scan your custom modules and themes and all your contrib projects and give you this lovely output.

One warning per custom project is great news, especially when the fix is as easy as adding core_version_requirement to the project's info file. Further down the report, you'll see the a list of your contrib modules. Even though we've updated our modules, we may still see that they are not all D9 compatible, and Upgrade Status will show those errors.

You may see some text under the module that indicates its status. Module maintainers may optionally provide this very helpful information. Sometimes it might be as simple as "This module is ready for Drupal 9".

If you see something like "Version 1.x-dev is ready for Drupal 9", "dev" means the latest version isn't D9 compatible. They may also indicate which future release will be compatible, and even include a link to an issue on drupal.org with further information about the module's status, and we’ll see an example of that when we dive deeper into evaluating contributed modules.

But wait, you are probably wondering how Admin Toolbar is compatible when it shows 12 warnings!

You'll errors like this sometimes when using Upgrade Status. There are two main reasons why you'd see this:

  1. The problem might be in a test class, like in this example. Tests can't always be scanned, but you can safely ignore them because you won't run test code in production.
  2. The module might have a third party dependency that you don't have installed. That's totally okay -- those dependencies may not even be Drupal modules, so they don't matter to Upgrade Status.

Generally, you can trust the maintainers that the module is indeed "ready for Drupal 9."

You'll get lucky with some modules, and they'll have errors that are pretty easy to fix. Some may be a little more challenging or involve some refactoring, but many will have  a handy link to the API documentation, as below.

If you click one of the nice error messages, you get to the api documentation page for the deprecated function, which may also contain a helpful link to the change record with thorough examples to help you change your code the best way: 

Change records document changes to Drupal core. They will describe the change and the impact of the change. It should include any interface changes, function or hook changes, and it's helpful for understanding how to address these changes with your own code.

Note that not all errors will have a link to further documentation, but that's okay because a little API searching will do the trick.

The deprecation notice.

If you look at the top ten most popular Drupal 8 compatible modules, all are compatible in their dev branch, and 9 of the 10 have full compatible releases. This is incredible progress.

But, as we get further down the popularity list, we're likely to find some incompatible modules.

As you continue your discovery process, it's a great time to evaluate where your pain points will be. Get involved and try to help modules reach their Drupal 9 compatibility goals, or if a module seems stalled or the last commit was 3 years ago, have a backup plan to include a patch or re-evaluate the need for the module at all.

Acquia's Drupal 9 Deprecation Status page is also a great source of information. This shows the status of all contrib projects, and gives you an idea of where the entire Drupal ecosystem stands with regard to Drupal 9 readiness.

Fix Your Errors

Once you've equipped yourself with the prerequisite information, it's time to move on to fixing any errors you have found. I'd start with the easy ones and work your way up.

Now is a great time to introduce the Upgrade Rector module. Upgrade Rector is a UI that uses drupal-rector to help you automatically generate patches. If you install the Upgrade Rector module, since it integrates nicely with Upgrade Status, you'll be able to generate an automatic patch for some modules as you scan them. Rector is limited at this point though, so you may end up with results similar to the following screenshot, but even a couple patches could get you a little ahead of the game and save a bit of time. And, like everything in the Drupal world, development is moving fast. By the time you install Upgrade Rector and scan your site, it's likely you'll be able to automate several of your patches.

Drupal Rector output visible on the Upgrade Status report (admin/reports/upgrade-status). Click the "patch available" link to see the generated patch. Drupal Rector displays the patch in a modal window.

Below, you see the changed lines highlighted, and your custom code is ready to go. There is a caveat, however. If you've found a contrib module that has not yet been patched in the issue queue and you'd like to add one, I can tell you from experience that if you post a patch like this for a contrib module, an experienced maintainer is likely to ask you to make changes to it. In this case, someone could point out that these replacements use the global Drupal class, which is not always the ideal approach in contrib modules, but it's safe to use in your custom projects.

This example used a contrib project, but it's useful to remember that with contrib projects, you aren't alone, so save yourself some work and check the module issue queues to see if the deprecations have already been patched, or even committed. Some maintainers will also have an explicit link to the main Drupal 9 issue in their queue, and this will be visible on the Upgrade Status Report, on the module page, and on the Acquia Deprecation Status tool.

If they haven't, then you can make the changes yourself and submit a patch to the issue queue and do your good deed for the day. With any luck, you'll just have to focus on your custom code.

In short:

  1. Avoid duplicating work.
  2. Check the issue queue first.
  3. Then submit a patch.

Once you have gone through your list and fixed and rescanned until it's all green, or you have gotten as far as you can, next make sure all your automated tests are passing. There is a pretty good chance the Update Status results screen will never be completely green, and that's okay because static analysis is not perfect, and neither are automated tests.

Once you feel like you've exhausted all your options with static analysis, you can try actually testing with Drupal 9 core.

You can test your current status by requiring Drupal 9 like so:

$ composer require 'drupal/core:~9.0'

Now, you may have to do some composer wrestling to get this going, but you'll get there!

You may see errors like this:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: remove drupal/cookieconsent 1.4.0
    - Conclusion: don't install drupal/cookieconsent 1.4.0
    - Conclusion: don't install drupal/core 9.0.0-beta2
    - Conclusion: don't install drupal/core 9.0.0-beta1
    - Conclusion: don't install drupal/core 9.0.0-alpha2
    - Conclusion: don't install drupal/core 9.0.0-alpha1
    - Conclusion: don't install drupal/core 9.1.x-dev
    - Installation request for drupal/cookieconsent ^1.4 -> satisfiable by drupal/cookieconsent[1.x-dev, 1.4.0].
    - Conclusion: remove drupal/core 9.0.x-dev
    - drupal/cookieconsent 1.x-dev requires drupal/core ~8.0 -> satisfiable by drupal/core[8.0.x-dev, 8.1.x-dev, 8.2.x-dev, 8.3.x-dev, 8.4.x-dev, 8.5.x-dev, 8.7.x-dev, 8.8.x-dev, 8.9.x-dev].
    - Can only install one of: drupal/core[9.0.x-dev, 8.8.x-dev].
    - Can only install one of: drupal/core[9.0.x-dev, 8.9.x-dev].
    - Can only install one of: drupal/core[9.0.x-dev, 8.0.x-dev].
    - Can only install one of: drupal/core[9.0.x-dev, 8.1.x-dev].
    - Can only install one of: drupal/core[9.0.x-dev, 8.2.x-dev].
    - Can only install one of: drupal/core[9.0.x-dev, 8.3.x-dev].
    - Can only install one of: drupal/core[9.0.x-dev, 8.4.x-dev].
    - Can only install one of: drupal/core[9.0.x-dev, 8.5.x-dev].
    - Can only install one of: drupal/core[9.0.x-dev, 8.7.x-dev].
    - Installation request for drupal/core ~9.0 -> satisfiable by drupal/core[9.0.0-alpha1, 9.0.0-alpha2, 9.0.0-beta1, 9.0.0-beta2, 9.0.x-dev, 9.1.x-dev].

You may see errors like this. Any modules that don't declare compatibility with Drupal 9 will not install. They need to do that with core_version_requirement in their info file. As a workaround, you could temporarily remove them until they do, and test the rest, or you could bring them in without using composer, and check them that way. That will allow you to identify any missing core_version_requirement keys in sub modules, or other issues that may have slipped through.

Once you have a Drupal 9 codebase, you are not necessarily home free, as static code analysis doesn't catch everything. At this point, you may face errors when trying to run your site. In fact, it's likely. A good way to check for errors is to run drush cr once you've upgraded. In my experience, references to deprecated services may have slipped through, and they'll pop up once you've switched to Drupal 9.

At this point, you may face errors when trying to run your site. In fact, it's likely. A good way to check for errors is to run drush cr once you've upgraded. In my experience, references to deprecated services may have slipped through, and they'll pop up once you've switched to Drupal 9.

For example:

You have requested a non-existent service "entity.manager".
You have requested a non-existent service "path.alias_manager".

Next Steps

If errors are coming from a contrib module, your first stop should be the module's issue queue. Report the error if it has not already been reported. Active maintainers and other contributors are likely to respond to the error quickly, especially in popular modules. If you need to explore further, run the module's tests.

If the error is in your custom code, as in contrib modules, some of these changes will be easier, like simply replacing the old service with the new, and sometimes you'll have to rethink your code a little bit. You may find some guidance in the change records: https://drupal.org/list-changes

Once you have your fixes in place, you should again be ready to make sure any automated tests are passing with Drupal 9. Then, give things a manual test for good measure.

But what if it hasn't gone so smoothly? What other challenges might we face?

The differences between getting custom projects ready for D9, versus contrib projects, are pretty clear. You are in charge of your custom code, and you can define your own timeline for a Drupal 9 compatible release. With contrib projects, the maintainers are the gatekeepers, and you may find yourself temporarily blocked while waiting for patches to be committed. The upside is that once ready, it's an easy update away!

Almost all Drupalers are kind and generous people, as you know, but some are a little busy. Ultimately, it's going to take the efforts of many to get the contrib modules you need ready. And in the meantime, you probably have enough custom code to tackle.

Making Sense of Contrib

As someone who used to spend a lot more time using Drupal than looking at issue queues, I can understand how the process of evaluating a module's readiness, or progress toward readiness can be less straightforward. But I'll show you some key places where I go digging for this information.

Search API is a great example of a helpful status message. You'll find the status when using Upgrade Status and at Acquia's deprecation status page.

You'll see that this module has included a link to an issue which will tell you what you need to know about the status of its Drupal 9 compatibility. This is very convenient.

But now, let's look at reCAPTCHA. You'll notice there is no indication of Drupal 9 compatibility on the module page.

Next, we can check it on Acquia's Deprecation Status page.

This suggests reCAPTCHA is ready to go, but let's try and verify. Note that no Drupal 9 plan is provided to indicate the status of its compatibility.

It's always a good idea to check the issue queue for Drupal 9 progress when it's not linked from the status message. We got lucky, and this post is right near the top. 

There are some good signs in this issue. There's a patch and it was committed.

There are also some less good signs. What are these D9 composer require failures? We don't really know the status based on this. And remember, just because this test isn't running does not necessarily mean this test won't work for you. The only way to know for sure will be when you try it.

So, let's go back to the module page. 

The modules automated tests are another important source of truth.

This page looks less promising. The module's tests currently fail with Drupal 9. If we click the failure notice, we'll see the test failures in detail. 

Here we can see the problem. reCAPTCHA can't be Drupal 9 ready until its depedency, CAPTCHA is. So now's a good time to head over to the CAPTCHA module's page and check its status.

Maybe you could help them move it along!

In this post, I've laid out the major steps toward getting your site ready for Drupal 9.

  1. Update core and all your modules, and satisfy Drupal 9 minimum requirements.
  2. Remove all deprecations in your custom code, and make sure all your contrib modules are ready for Drupal 9.
  3. Upgrade to Drupal 9 and test manually.

In summary, if you start this process now, you'll be a little ahead of the game. If your projects are ready, it's a pretty seamless update, and if not, now is the time to get them there. Keeping your current Drupal 8 site up to date will get you far.


Drupal 9 resources

Drupal 9 Overview Page

Upgrade Status Module

Upgrade Rector Module

Acquia's Drupal 9 Deprecation Status Tool

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

Mediacurrent Multisite+ logo

One of the most powerful features with Drupal is the ability to create multiple site instances from the same base platform. The Drupal multisite system is great for managing university departments, government agencies, and corporate microsites wanting to standardize design and features across many sites.

The problem with the standard multisite setup is that it’s not easy to spin up new sites without the help of a developer. Mediacurrent makes this process painless with our new launch tool for multisite! The Mediacurrent Multisite+ solution allows site administrators to create a new site from a simple web form located in their website’s Drupal 8 admin interface. Creating a new site instance now takes a matter of minutes. 

Read on to find out how this works, or contact us now for a free demo.

Here’s How Multisite+ Works

We will get you up and running in 3 steps. For our initial launch, we support Drupal 8 on Pantheon.io’s hosting platform with Acquia support in Q3, 2020 and Drupal 9 coming soon. 

Step 1 - Configuring the Application

The first thing we will do is set up the application environment to be compatible with a multisite environment. Drupal 8, by default, is built to be multisite-compatible by allowing configuration to be re-used across multiple site instances. 

For the Pantheon hosting environment, we will create a custom Upstream from the desired Drupal 8 application. Our Multisite+ integration will leverage this Upstream to provision new sites, each with their own dedicated resources.

custom upstreams for Area Alert and Rain distributions

Example of Upstreams created by Mediacurrent

Step 2 - Setting up Automation

As a next step, our DevOps team will set up the automation that allows the Drupal application to interact with the hosting environment. This process does the “heavy lifting” of actually spinning up the site instance and running the installation process.

Step 3 - Enabling the Multisite+ Module

Finally, we will add and configure our Multisite+ module for the primary Drupal 8 application that needs to kickoff new site installations. This module connects your application to the automation that does the actual work to set up your new website instance.

When we’re done with this one-time setup, a new form becomes available that administrators can use to initiate a new website build.

Mediacurrent's Multisite+ form setup in Drupal

Multisite+ form example

And that’s it! Now your administrators have the keys to create new campaign sites, microsites, or any other type of site that leverages an existing Drupal 8 application.

Ready to get started?

Mediacurrent would love to work with you to better enable your teams to manage multiple Drupal websites. For more information on how to get your organization set up, please visit our contact page or chat with us right now (see bottom right corner of the page). We would be happy to talk more about your project or schedule a demonstration.

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

4- Drupal Migrations (IV): Debugging Migrations First Part

5- Drupal Migrations (V): Debugging Migrations-II

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.

6- :wq!

[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. The event was an organized to activate as many developers as possible to contribute to the open source project Drupal.

For us at 1xINTERNET it turned out to be a great experience. 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. We paused all client projects on Friday and started with a kickoff meeting, where we went over the days ahead and how we would proceed in updating all of our Drupal projects, supporting each other and anyone that needed help. 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 patches become ‘Reviewed and Tested by the Community’.

Everyone can be Makers of Open Source

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 with 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 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 calls to action (CTAs), icons, and any place where highlighting areas visually is important.
  • Save secondary colors to highlight less critical information, such as secondary CTAs 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's release is more than just around 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 as 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 then update a website to the new version? The answer is below.

Why upgrade a website to the new version: 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, web 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, which we have outlined below.

Getting your site 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 of 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 , they 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, which we are describing next.

How to prepare your site 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 developers’ circles, including our Drupal development & support team’s devs who use them extensively.

Let’s begin with the Drupal Check and the Drupal Rector. These are developer-oriented tools, but they both have a contributed Drupal module based on them. 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 Rector 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 your website for the 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. If you want some help, don't hesitate to entrust the Drupal 9 upgrade preparation of your site 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, and one of the ways to do this 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.


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