Jan 17 2020
Jan 17

Drupal 9 is scheduled for release on June 3, 2020. And as with any highly anticipated release, questions abound: “What will change from Drupal 8 to Drupal 9?” “What do I need to do to prepare before upgrading?” And top-of-mind is the big question: “What will Drupal 9 be like to work with?”

Read on as we share what you’ll need to know … and what might surprise you.

Anybody who’s upgraded from Drupal 7 to Drupal 8 recalls the giant chasm between the two systems. Almost 200 new features were launched including an entirely new page editor, a new theme engine, a new text editor, and new field types, to name but a few.

This gap doesn’t exist between Drupal 8 and Drupal 9. In fact, on the surface, there IS no difference: Drupal 9 has the same code, functions, and feature set as Drupal 8.9.

So why release it then? As it turns out, there are differences — they’re just not front-and-center on the interface.

Time to Clean House

Throughout its development cycle, Drupal 8 has wound up with a lot of code debt: functions that were created programmatically and used for some time but have been rendered redundant by more efficient functions.

These bits of code clutter up Drupal 8 like your old CDs and DVDs clutter up your bookshelf: There’s nothing wrong with them, but you probably don’t need them anymore now that you have something more efficient.

The result of all this extra code is that programmatically, there might be 10 different ways to do one single thing.

What Drupal has done is marked all of those code items in the backend code base as being “deprecated”. When Drupal 9 comes out, the plan is to remove all the deprecated code on this list, leaving only the latest version of whatever that code’s API is. They’ll also be updating third-party dependencies, such as Symfony and Twig. From Drupal’s site:

“Drupal 9 will be a cleaned-up version of Drupal 8. It will be the same as the last Drupal 8 minor version with our own deprecated code removed and third-party dependencies updated. We are building Drupal 9 in Drupal 8.”

Will Drupal 9 Be Better?

Yes, but not without some minor risks.

Jettisoning all this deprecated code will result in a much faster, cleaner, and better-operating version of Drupal. However, if you have legacy programs whose modules use some of that deprecated code, you could find yourself with some broken processes.

How to Prepare for Drupal 9

In general, upgrading to Drupal 9 is not an onerous process – it can literally be done via a single command. What will take more time is monitoring and auditing code bases to ensure that none of your functionality is dependent upon deprecated code.

Fortunately, Drupal is well prepared for this, and has indicated that the Drupal 8 branch of the Upgrade Status module can be used  to identify and report on any deprecated code:

“This module scans the code of the contributed and custom projects you have installed, and reports on any deprecated code that must be replaced before the next major version. Available project updates are also suggested to keep your site up to date as project will resolve deprecation errors over time.”

In addition, we anticipate that when downloading or updating modules, Drupal will likely advise whether there are compatibility issues due to bad functions. However, that notification system isn’t currently in place (if it indeed happens at all), so your best bet is to work with your development partner, who can audit your code to identify any trouble spots.

Marie Kondo-ing Your Infrastructure

Drupal 9 will be a much faster and more streamlined platform, but it doesn’t exist in a vacuum. If the rest of your operational architecture is similarly full of code debt and redundant processes, updating Drupal 9 will be akin to sending a Lamborghini down a pothole-rutted road: That powerful engine is wasted if the route is slowing it down.

So, going to Drupal 9 is an excellent opportunity to look at your legacy systems, audit them as well, and make sure your entire infrastructure is clean, fast, and free of roadblocks.

The Bottom Line

In general, upgrading to Drupal 9 should not be a complex or lengthy process. By cleaning out the clutter and performing some common dependencies, Drupal is practicing good development hygiene and providing its customers with a more streamlined system that will be faster … but still familiar.

Want to know more? Contact us today!

Jan 17 2020
Jan 17

The World Wide Web with no barriers could be an amazing place for everyone. What about your website — does it follow the web accessibility guidelines?

Our web team respects accessibility and is always ready to help you make your website accessible. We also love to share tips about creating accessible content and making your images accessible in your team’s everyday content editing practices.

This post will sum up everything you wanted to know about accessibility (a11y for short): what it means to make your website accessible, what accessibility tools there are based on your site’s CMS (Drupal modules and WordPress plugins), and much more.

What does it mean for a website to be accessible?

An accessible website is one that is available to all users regardless of their visual, auditory, cognitive or motor disabilities. It is friendly in every aspect — from color contrasts to keyboard navigation.

No user is left behind — the site’s content and UI are easy to comprehend and control in various alternate ways including via assistive technologies.

Why is accessibility important for a website?

  • Website accessibility (a11y) enhances your brand’s reputation because it shows your attitude. According to the Centers for Disease Control and Prevention, roughly one in four adults in the US has some form of impairment. Most people have a friend or acquaintance with a disability, and they appreciate your willingness to follow the guidelines.
  • Make your website accessible and stay protected against possible legal proceedings. The Americans with Disabilities Act (ADA) prohibits the discrimination of people with disabilities. It states that everyone should be provided with equal access and opportunities. Based on this, the world sees a rising number of lawsuits against businesses with inaccessible websites.
  • An accessible site gets a much larger reach. To estimate the figures, consider the above mentioned quarter of the US population and add users with situational issues. These may include broken arms, tired eyes, or even just the need to use your site’s content in a non-native language. In all these cases, users will love your accessible site.
  • By making your website accessible you boost your SEO. Being ready for assistive tools is in many ways similar to being ready for search engines. ALT tags describing the images, clear meta descriptions, video captions, a clear menu hierarchy, and other a11y practices are good SEO practices as well.

How do I add accessibility to my website?

To make your website accessible, you should follow the WCAG (Web Content Accessibility Guidelines). They are the international web standards embracing every aspect of your site’s interaction with users who have an impairment.

The WCAG has been brought to us by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). They are based on four key principles:

  • Content perceivable
  • Interface elements operable
  • Content and controls understandable
  • Content robust enough

WAI has also developed ARIA (Accessible Rich Internet Applications Suite). This is a suite of attributes that make interfaces, especially rich and interactive ones, more understandable to assistive devices. WAI-ARIA attributes (roles, states, and properties) can be added to the HTML markup.

Considering all the above, here are some of the key things required from you to make your website accessible:

  • text equivalents for non-text content (ALT tags for images, captions for videos, transcripts for audios, etc.)
  • the proper HTML markup (with the use of WAI-ARIA where necessary)
  • logical layout
  • keyboard controls
  • clear field labels
  • informative error messages
  • clear and simple language
  • informative link texts
  • sufficient color contrasts
  • text resizability
  • adjustable audio volume
  • no auto-playing media
  • more time to complete regular actions

and much more.

Tools to make your Drupal or WordPress website accessible

If your site is built with a CMS, you are in luck because it should have built-in or add-on plugins to make your website accessible. They are simply installed and configured on your website and take care of various a11y aspects.

Since our agency’s main expertise is Drupal and WordPress, we will list a bunch of helpful extensions for both these CMSs — Drupal modules and WordPress plugins that make your website more inclusive and compliant.

Drupal accessibility modules

Automatic Alternative Text

The Automatic Alternative Text module generates alternate texts to describe images using the Microsoft Azure Cognitive Services API. This is an example of how artificial intelligence helps you make your website accessible.

Automatic Alternate Text - Drupal accessibilty module

CKEditor Accessibility Checker

It’s important that you make your content accessible in everyday editing practices. The CKEditor Accessibility Checker module inspects the content created in Drupal content editor, as well as immediately resolves the issues found. The module may soon become part of the Drupal core.

CKEditor Accessibility Checker Drupal module

Block ARIA Landmark Roles

The use of WAI-ARIA in your site’s markup becomes more advanced with the Block ARIA Landmark Roles Drupal module. Every block in your site’s layout can be assigned an ARIA landmark role and/or ARIA labels directly in the block configuration form.

Block ARIA Landmark Roles - Drupal accessibility modules

High contrast

The High contrast module enables users to switch between the active theme on your Drupal site and a high contrast version of the theme. This will make your website more accessible to users with eyesight problems.

Text Resize

Since adjustable text size is one of the requirements to make your website accessible, the Text Resize module is very helpful. It provides website visitors with a block that has two buttons to make the font size larger or smaller.

Text Resize - Drupal accessibility modules

Text Size (Drupal 7 only)

The Text Size module serves a similar mission. It provides an adjustable text size changer or a zoom feature. Though its zoom capabilities are similar to text zoom in Firefox, the module can also work with variable media objects, pixel images, and vector images.

Text Size - Drupal accessibility modules


The proper HTML markup is essential in making your website accessible. The htmLawed Drupal module gives you the highly customizable control of your HTML. It uses the htmLawed PHP library to restrict and purify the code.

htmLawed - Drupal accessibility modules

WordPress accessibility plugins

WP Accessibility

The WP Accessibility is a multi-functional plugin to help you make your website accessible. Its wide range of features includes enabling the skip links, enforcing ALT tags on images, adding language and text direction attributes, providing a font size and color contrast toolbar, and more.

WP Accessibility Helper (WAH)

Here is another multipurpose plugin with basic a11y tools — WP Accessibility Helper (WAH). It adds a user-friendly accessibility toolbar to your site. Among its key features are skip links menu, adjustable fonts and color contrasts, accessibility error scans, and more.

WP Accessibility Helper (WAH) plugin

Accessibility by UserWay

The UserWay plugin provides smoother browsing experiences on your website, paying great attention to keyboard navigation. It performs smart modifications to your site’s elements in order to make them more compliant with the a11y requirements.

Accessibility by UserWay WordPress plugin

Accessibility Widget

The Accessibility Widget plugin adds a sidebar widget to allow users to easily make the text size larger or smaller in your WordPress website. To achieve this, it offers the “Small”, “Medium” and “Large” text options.

WCAG 2.0 form fields for Gravity Forms

The WCAG 2.0 form fields for Gravity Forms plugin makes the forms created by the famous Gravity Forms builder more accessible on your site. It wraps form fields in a fieldset, adds ARIA attributes, gives on-page error messages with the number of errors and links to them, etc.

WCAG 2.0 form field for Gravity Forms WordPress plugin

Screen Reader WCAG Accessibility Tools

Here is a plugin that makes your website accessible by adding a text-to-speech engine to it. The Screen Reader WCAG Accessibility Tools plugin can read the text in 50+ languages. However, the free version of the plugin is limited to 100 characters.

WP Accessibility Tools & Missing Alt Text Finder

Here is a plugin that helps you make your website accessible in a number of ways. The WP Accessibility Tools & Missing Alt Text Finder offers a missing alt text finder, contrast ratio checker, compliance checklist, automated accessibility audit, and more.

WP Accessibility Tools & Missing Alt Text Finder WordPress plugin

SOGO Accessibility

The SOGO Accessibility plugin for WordPress scans your website’s code and adds the accessibility support automatically. It uses JS and CSS to improve or enable accessibility features.

SOGO Accessibility WordPress plugin

Our experts are ready to make your website accessible

Hopefully, this article has provided a good review of the basic accessibility principles, requirements, and tools based on your CMS.

The above listed Drupal modules and WordPress plugins are just a few of the many. Our web development team can select or create from scratch the ones that will suit your website best. Let us make your website accessible in every aspect!

Jan 17 2020
Jan 17

With the release of Drupal 8.8, Drush is also due for an upgrade — to Drush 10. For this venerable command-line interface that many Drupal developers know intimately well, what does the present and future look like? What considerations should we keep in mind when selecting Drupal Console or Drush? What new features are available in Drush 10 that characterize the new CI/CD approaches we see expanding in the Drupal community?

In this Tag1 Team Talk, join the creator and maintainer of Drush Moshe Weitzman (Senior Technical Architect at Tag1), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), Preston So (Editor in Chief at Tag1), and Michael Meyers (Managing Director at Tag1) for a journey through Drush’s history and promising future. We take a deep look at what made Drush what it is today, the most compelling features in Drush 10, and how a hypothetical Drush in core could look.

[embedded content]
Jan 17 2020
Jan 17

As Dries Buytaert explained in his Plan for Drupal 9 post at the end of 2018 (emphasis mine):

Drupal 8's biggest dependency is Symfony 3, which has an end-of-life date in November 2021. This means that after November 2021, security bugs in Symfony 3 will not get fixed. Therefore, we have to end-of-life Drupal 8 no later than November 2021. Or put differently, by November 2021, everyone should be on Drupal 9.

Working backwards from November 2021, we'd like to give site owners at least one year to upgrade from Drupal 8 to Drupal 9. While we could release Drupal 9 in December 2020, we decided it was better to try to release Drupal 9 on June 3, 2020. This gives site owners 18 months to upgrade. Plus, it also gives the Drupal core contributors an extra buffer in case we can't finish Drupal 9 in time for a summer release.

Here we are 14 months later and while most people took the June 3 release date and took it for granted, it is still not guaranteed! However you can help in various ways to make it much more likely!

Late last fall, we focused on defining what it means if we cannot make the June 3, 2020 release despite our best efforts and what is an early indicator that tells us we are going to miss it. First of all, that meant defining requirements for the first alpha release and requirements for the first beta (API complete) release. Also we needed to set some expectations as to when do we want to see the API-complete beta release to give enough time for the ecosystem to test it and find important problems in time. Based on how soon the beta requirements are met, there are three release scenarios and the best case ending in the June 3, 2020 release date for Drupal 9 has a beta deadline in 6 weeks! Yes, 42 days!

Alpha requirements simplified

The key requirements for the first alpha release are simple. We wanted to update the key dependencies: Symfony to version 4.4 and Twig to version 2, as well as remove frontend polyfills that were not needed and remove most of jQuery UI (which were already deprecated in Drupal 8). This gets our most important dependencies up to shape to what will be in Drupal 9. We also made it possible for contributed projects to depend on Drupal 8 and 9 at the same time, so they will not need to branch for Drupal 9 support.

There are two outstanding things for the Drupal 9 alpha:

  1. Drupal.org does not yet have an automated packaging pipeline that conforms to all the recent composer related improvements and therefore making core releases is error prone. I don't believe you can help with this at this time, the Drupal Association is hard at work on this.
  2. Drupal core should use a major version agnostic update feed for projects which is already being provided by Drupal.org but the core code to consume it is still in the works. While this is actively being worked on, reviews are always helpful. This will make sure Drupal 9's Update Status gets only contributed projects that are actually Drupal 9 compatible, while contributed modules will not need to establish a Drupal 9 branch.

Beta requirements simplified

The beta requirements are a bit more complicated and longer of course because we are looking at being API complete here. Once again, for the June 3, 2020 release date, we need these done in 6 weeks! The issue lists must haves and should haves, however the should have issues should be considered must-have for the June 3, 2020 release date and would only be reconsidered later if that date cannot be met. Here is a simplified rundown of the beta requirements:

  1. We want to keep dependencies up to date. There is no concrete pressing issue here at the moment that I know, but this really depends on how our dependencies evolve.
  2. We'd like to remove all the deprecated APIs themselves. Last year I built a graph to track this, and it shows nicely that we are down to half of them remaining (yay!), but still quite enough to deal with. There are various outstanding issues you can help with here.
  3. We want to make sure people can update to Drupal 9 from Drupal 8 by resolving critical upgrade path bugs. If you cannot update to a later version of Drupal 8 due to some critical bug, then you will be stuck on your version of Drupal 8. Not good. These include views, layout_discovery, taxonomy, menu_content, etc. related issues. All of them need help. If you are on an older version and can reproduce the problems, that is useful. If you have experience in these areas, your input would be useful.
  4. It will only be possible to update to Drupal 9 from Drupal 8.8 or 8.9, so all older update paths and their tests should be removed. Older versions of Drupal 8 will themselves be unsupported already at the time of Drupal 9's release. This issue is getting close but needs reviews.
  5. No new security or data integrity issues should be in Drupal 9. If there are any, they should be resolved. I don't know of any issues at the moment here.
  6. The API should be complete. There are no critical API additions or changes that I know of at the moment in this general category.
  7. We want to make sure people can migrate from Drupal 6/7 to Drupal 9. This needs the remaining multilingual migration paths to go stable. This is an area where we posted several call to actions, but still need your help. There are proposed migration paths for node translations and entity translations that respect revisions but they need at least code reviews to make sure they are good. Otherwise if you had content translations with revisions, the migration will not be correct. Without that, multilingual migrations will not go stable.
  8. PHP requirements should be finalised. It is likely at this time that Drupal 9 will require PHP 7.3 that is being worked on currently and could use a review.
  9. Database requirements should be finalised in terms of MySQL/MariaDB/Percona and PostgreSQL. Both issues need data as to which distributions and hosts support certain versions.
  10. The right security update information should be provided for users taking the one year support cycle and long term support of the last Drupal 8 release. This could also use reviews.
  11. We should put Drupal's base theme on a track so that it can evolve in Drupal 9 finally. This involves creating a new stable9 theme and decoupling the core themes from Classy. Various issues to help with here.
  12. Drupal.org should support multi-core compatibility eg. on project pages, localize.drupal.org, etc. This work is currently deprioritised by the Drupal Association due to the focus on the packaging pipeline blocker that I listed first. Once this gets attention, it will likely uncover core issues to resolve as well.

The two areas that receive the least attention at the moment are upgrade path blockers and the stability of the multilingual migration path, so those two are the most pressing where we need your help!

While the above is a complete rundown of the current beta requirements, it may change later on, so refer to the beta requirements issue later on for up to date information.

What happens if all the above are not done by end of February (in six weeks)

If all goes well, with your help, we'll be done with all the above in six weeks. If that does not work out, we have a plan B and a plan C. Here is how those options unfold. If beta requirements are only done two months later by end of April, then Drupal 9's first beta will be released on the first week of May and Drupal 9 is to be released on August 5, 2020. If the beta requirements are only done by end of August (four more months later), than the first beta will be released than with a Drupal 9 release date of December 2, 2020. In this case a Drupal 8.10 may also be released if needed. These dates are spelled out well in the Drupal core release cycle overview. I created this visual to help understand the alternate timelines:

Drupal 9 release scenarios visualised

While I think it is reassuring that we have plans for what happens if our initial date targets don't work out, unfortunately the end of life date at the end of next year for Drupal 8 is not movable because it is based off of Symfony 3's end of life. So the sooner we can make Drupal 9 happen (while meeting the upgrade and stability requirements) the better. What are you going to work on to help?

Helping with contributed projects

Based on the PHP deprecations our tools can identify, 43% of contributed projects would only need info.yml file updates to be Drupal 9 compatible. An additional 41% of the remaining projects have only issues that are resolvable now (even while keeping support for Drupal 8.7). Solving those anytime between now and Drupal 9's release (whenever it is) would put us to almost six thousand contributed projects compatible with Drupal 9 on day one! While that is a very idealistic number, helping with contributed projects is nonetheless a great avenue to contribute to Drupal 9 readiness. Help at the Drupal Global Contribution Weekend at end of next week or anytime before and after! I prepared a quickstart guide for this occasion.

Jan 17 2020
Jan 17

Last year I embarked on a personal open source challenge, focused on Drupal. Very easy to say: “12 months 12 patches”. Some months my work lent itself naturally to contributions, but when it didn’t, I got creative. Here’s how I made it happen, and inspired others on my team to follow suit. 


I’ve been working with Drupal for quite a few years now. Drupal is open source, and thanks to that, we (and so many other companies) can build powerful websites that match our client’s expectations. Drupal has a very powerful and capable core which offers CMS functionalities that allow you to build powerful sites by clicking around the Drupal UI.

It also has contributed modules, which aren’t used on every site and you can choose to enable for your new site if you need that functionality. There is also a big pool of base themes that you can build upon that will give your site a great starting point and make it look nice.

We often build on top of existing modules and themes. We enhance them or create our own, sometimes tailor-made to the site’s context, sometimes generic enough so the module or theme can be made available to Drupal and therefore to the whole community. 

I’ve always loved this. By sharing it you make the product bigger, more robust, better in general and we don’t need to reinvent the same wheel over and over. 

Modules and Patches

However, building a whole new module or theme is usually not a quick task, or even desired in some cases (if something similar is out there already). So we often find ourselves trying to leverage existing modules. 

Probably the easiest way to contribute to an already big community and an already big set of modules and themes is to help them improve by either fixing little bugs, or by adding new features to them. This is done usually via what we call “patches” (which under other platforms could be called a “pull request”). A patch is just a file that contains changes to the existing source code that will fix or enhance the given project.

For example: if the webform module lacks a type of field for emails, we could create a patch that adds that capability and submit it for the community to review it, and to the maintainer to merge it into the main project. If all goes well, then the webform module will now support emails as a field type, so everybody will benefit from it when updating the module.

The Challenge

At Amazee Labs, we encourage a workflow that lends itself to both contribution and client projects. I knew I wanted to incorporate contribution into my work on an even more regular basis, so my 2019 resolution was to submit (at least) one patch a month to a Drupal module. 

Some months it was easy, especially when opportunities for the contribution came right out of working on a ticket. For others, it wasn’t so easy. When I didn’t see any obvious chances to contribute in my work for the month, I set a practice of searching through the issue queue of any module I was installing and working on one of them. This made me inspect the code, see how it was structured and eventually create a patch for an existing issue.

Working in this manner vastly improved my Drupal knowledge, and cemented my personal resolution to regularly contribute. After each month, I felt like I was helping Drupal (even if it was just a tiny bit) one way or another.

Drupal Patches

I was really happy that I could complete the challenge. Some team members joined during the year and that made the challenge more fun and encouraged me to carry on. Also, as team lead, I had already agreed with some of my team members to set this challenge for them as well for 2020. We have a Slack channel where we share the patches, ask questions, encourage each other, etc.

So if you’re using Drupal and you’d like to contribute more, maybe this could be a challenge that you could also take for 2020.

The Patches

In case you were wondering which patches were submitted, here is the full list:













Happy coding!

Jan 16 2020
Jan 16

Drupal 9 is just around the corner. Do you have a plan to upgrade to Drupal 9? Are you still in the “Why should I upgrade to Drupal 9 after all” phase? Wondering what your next steps should be for Drupal 9 readiness? We have answers to all your questions and a quick Drupal 9 checklist on how to prepare for Drupal 9.

The best way to prepare yourself for tomorrow is to give your best today. And very apparently, the Drupal community has done just that. I know, migrating to Drupal 8 from previous versions was hard. It meant a complete rebuild of the code and a lot of learning. But once you are fully onboard Drupal 8, life gets easier. Think of it as a hard climb for a gorgeous view from the mountaintop. Truly worth all the effort, isn’t it?

The Much-Talked-About Drupal 9 Release Date

One of the most frequently asked Drupal questions lately has been about the Drupal 9 release date. Drupal 9 is currently scheduled to release on June 3rd, 2020. The Drupal community has been successfully releasing minor versions every six months since the adoption of semantic versioning in Drupal 8. Every minor version came with several valuable new features. 

Drupal 8 extensively depends on third-party libraries like Symfony, Twig, Guzzle, CKEditor and must keep up pace with their updates as well. For example, Symfony 3 (Drupal 8’s biggest dependency) will reach EOL (end of life) by November 2021. The same time as Drupal 8 reaches end of life as well. Drupal 9 will be released with the latest Symfony 4.4 support and will not be backwards compatible with Symfony 3. 

Drupal 9The Drupal 9 Readiness Roadmap (Image Credits – Drupal.org)

What’s New in Drupal 9 (Drupal 8 vs Drupal 9)

Drupal 9 is already being built within Drupal 8. Drupal 8.9 will release along with Drupal 9.0 in June 2020. This is because Drupal 9 is going to be the same as Drupal 8.9, except that it will be a cleaned-up version that is updated with support for its third-party dependencies. And hence one of the outstanding Drupal 9 features is that it is so easy to upgrade!

Every new minor version of Drupal 8 saw many new features but it also contained a lot of old code so it could be backwards compatible. This “old code” is also famously known as “deprecated code”. Because of the dependencies on third parties like Symfony, Twig, etc., Drupal 9 will incorporate updates to these dependencies. Drupal contributors and module developers are collectively making the road to Drupal 9 easier by eliminating “bad smelling code” (as Jacob Rockowitz calls it in his blog about deprecating code for his Webform module) from various Drupal 8 modules.

Drupal 9What’s new in Drupal 9.0 (Image Credits - Drupal.org)

From Drupal 9.1 onwards, the same story continues. New Drupal 9 features will continue to be added every six months (Drupal 9.1..Drupal 9.2..Drupal 9.3…and so on) which will be backwards compatible with Drupal 9.

“If Drupal 9 is the same as Drupal 8.9, why should I even upgrade?”. Because Drupal 8 reaches end of life on November 2021 and will stop receiving any security fixes or updates from then on. So once Drupal 9 is released, there is an 18-month window to upgrade to Drupal 9. Sure, long-term support will be offered by Drupal vendors, but do we really want to miss out on all the new Drupal 9 features and enhancements that it will offer?

Drupal 9 Checklist

Regardless whether you’re upgrading from Drupal 7 to Drupal 9 or Drupal 8 to Drupal 9, you will need to start planning for Drupal 9. The scheduled release is soon approaching and now is a good time to get prepared for Drupal 9. 

  • Drupal 7 to Drupal 9
    If you are still on Drupal 7 and looking forward to getting onboard Drupal 9, it isn’t too late. Ideally, it is recommended you upgrade to Drupal 8 now and stay updated with the latest core releases. Migrate content and code to Drupal 8, Check for availability of modules in Drupal 8 using the Upgrade Status Drupal module, upgrade your Drupal 7 modules to Drupal 8 with the help of modules such as Drupal Module Upgrader, remove any deprecated code, upgrade to Drupal 9. And as already discussed, upgrading from Drupal 8’s latest version to Drupal 9 is easy as pie. Upgrading from Drupal 7 to Drupal 9 will take as much resource time (and resource budget) as a Drupal 7 to Drupal 8 to Drupal 9 upgrade. Drupal 7 will reach end-of-life by November 2021 and will continue to receive community support until then. 
  • Stay Up to date with Drupal 8
    With every new minor version release of Drupal 8, the benefits are not only restricted to access to new features and enhancements. It also takes you one step closer to Drupal 9. Since Drupal 8.8 is the last minor release before the Drupal 8.9 release (which also happens at the same time as Drupal 9!), it is the last Drupal 8 version to contain significant feature additions. Drupal 8.9 releases on June 3rd, 2020 and will include more stable modules (that were previously experimental) and a few UX and API enhancements. So, the best thing to do now is to keep Drupal core updated and update your website to Drupal 8.8. 
  • Weed out the Deprecated code
    Make way for new and improved features by removing old and deprecated code from your Drupal 8 codebase. When you keep Drupal core and contributed modules up to date, you are also embracing cleaner code. Updated versions remove usage of deprecated code and API. There are various methods to check for deprecated code. 
    • Sometimes functions are marked with @deprecated annotations that warn the developer that the following code is deprecated and what they should be using instead. 
    • Use a command-line tool like Drupal Check (by Matt Glaman from Centarro) to help check for deprecated code and other bugs. It can also be integrated in continuous integration environments.
    • Leverage the Drupal 8 Upgrade Status module on top of Drupal-Check for a more UI based solution. It can scan your entire Drupal project and generates a report that illustrates any compatibility issues and Drupal 9 readiness. 
    • Drupal.org also offers support to check for Drupal 9 readiness and deprecation within its testing system. Like enabling static analysis with phpStan or by setting a trigger_error() when a deprecated level is reached.

      Once identified, it is time for some manual work to remove the deprecated code and refine existing codebase. Use automated tools like Drupal 8 rector to resolve some code issues, although it does need some manual intervention.

Jan 15 2020
Jan 15

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.

Project News

Get Ready for Drupal 9

The next minor release of Drupal will be 8.9 - to be released simultaneously with Drupal 9.0. The first target window for the release is this coming June, so now is the best time to get ready for the release.

As it turns out, many contributed or even custom modules only need a one-line change to be ready for Drupal 9. Check yours using: the upgrade status module, or the Drupal Check command line tool.

DrupalCon Minneapolis 2020

DrupalCon MinneapolisSpeaking of Drupal 9, DrupalCon Minneapolis is coming up from May 18-20. We expect their to be a large amount of programming and contribution focused on the upcoming release of Drupal 9. Minneapolis will be a great opportunity to get help with checking your module compatibility, or to find someone who can help you get your Drupal 7 or 8 site ready for the upgrade. Get your tickets now, before prices go up!

DrupalCon Europe 2020

Did you hear the news? DrupalCon Europe 2020 has been announced - and DrupalCon is coming back to Barcelona from Sep 14-17th.

Our partnership with Kuoni Congress continues, and we're excited to join you in beautiful Spain to celebrate Drupal 9 together.

Kuoni Congress

Mark your calendars, and bookmark the site - more info coming soon!

Drupal.org Update

Have you unwrapped automatic updates yet?

In November we finished the primary engineering work to support Phase 1 of the Automatic Updates initiative. In December we completed validation and testing, and launched the first stable release of the Automatic Updates module.

In its current form, Automatic Updates is available as a contributed module for both Drupal 7 and Drupal 8. After installing the module you'll be able to take advantage of three new features: 

  • When the Drupal Security Team identifies a critical release, they'll be able to publish a PSA that will be directly displayed in your admin interface. 
  • The module will run automated readiness checks to make sure your site is ready for the update, or to let you know if there are errors you need to fix.
  • The module will automatically apply Drupal core updates. 

What about automatic updates for contributed modules and composer dependencies?

The next phase of work on the Automatic Updates initiative is to support updates for contributed modules, and for sites managing Composer dependencies.

This is where we need your help! We're looking for organizational sponsors to help move this work forward. If you're interested in helping us move the initiative into the next phase, please contact the Association.

We want to thank: The European Commission, Acquia, Tag1, Mtech, and Pantheon for their support of Phase 1.

Expanding Drupal Solution content with Feature pages

About two years ago we decided to start featuring Drupal Solutions on Drupal.org. These Solutions are examples of Drupal being used in the real world in specific use cases. Our first series of this content was the Drupal Industry pages, highlighting the power for Drupal in specific industry verticals.

In December, we've just launched our next set of content, this time focusing on specific features of Drupal that set it apart from the competition. These Feature pages talk about the specific Drupal Solutions that are built around key features of the software.

Updating our packaging pipeline

Do you know what goes into a packaged release of Drupal? It's not just a git clone - and as of Drupal 8.8.0 the package you download from Drupal.org also includes Composer scaffold files.  As Drupal evolves, the way we deliver the software to users has to evolve along with it.

To support the increasingly sophisticated packaging process for Drupal, we started work on overhauling our packaging pipeline for Drupal releases. This work continues into January.

Preparing for contrib Semver

As part of Drupal 9's release we are working to migrate all of the projects on Drupal.org to properly use semantic versioning. Right now, contributed modules typically use a version format like: 7.x-1.6 or 8.x-1.7. The first part of this is just the platform version (D7 vs. D8), and the second part is the Major version and the Patch version.

We'll be migrating this version schema so that the current Major version remains the Major version, the current Patch version becomes the Minor version, and we'll add the ability to define new patch versions.

This enables several improvements. Firstly, contrib maintainers can now follow backwards compatibility policies similar to core, i.e: Major versions with backwards compatibility breaking changes, minor version with new features, and patch versions for bug fixes and security releases.  Secondly, because contributed modules can now be compatible with both Drupal 8 and Drupal 9, contrib semver will be an important part of keeping version management sane.

We've made some initial progress in that direction, and have a roadmap for completing this support.


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

Jan 15 2020
Jan 15

CLI tools is a great way to automate certain tasks for your CI needs. For example you re-use same shell scripts project to project. Or maybe you are integrating with some third-party service. Abstracting these tasks into your own CLI tool could be a great way to go.

You can think about some examples from Drupal world -- each hosting provider has some sort of CLI tool. European Commission has one to automate certain DevOps tasks (https://github.com/openeuropa/task-runner).

In my case I was building one for interacting with Diffy -- visual testing platform. Repository of the CLI tool is https://github.com/DiffyWebsite/diffy-cli

First, when I initially thought about idea of building a CLI tool I thought about the tools I used myself. Among them there were Drush and Terminus (Pantheon’s CLI tool). They both use https://robo.li/ so my choice was obviously to use this framework as well.

Getting started

One of the best parts of Robo is that they is a Starter project (https://github.com/g1a/starter) that will create a code for you and also push it to your github.

Once you’ve done that you can start creating your commands right away.

Command syntax

And that is simply creating classes that extend \Robo\Tasks class.

For example here is a command that saves a configuration variable:

You can definitively recognize annotations if you have build custom Drush commands in the past.


As for configuration Robo already promotes having a config file in your home folder as a YAML file. So for Diffy we store it in ~/.diffy-cli/diffy-cli.yml file.

There is a component https://github.com/consolidation/config/ that is used in Terminus and Drush. It is really great. Allows merging configs (imagine providing defaults and allowing override them) and also getting nested properties (get(‘foo.bar.baz’) type syntax).

But for my case I just needed to save an API key. So I went with a custom Config that simply saved or loaded parsed YAML file https://github.com/DiffyWebsite/diffy-cli/blob/master/src/Config.php.

Distribution as a PHAR file, self:update

Best part of the starter project is an example how you can pack the tool into single PHAR file.

Main idea is to use Travis to build and publish your PHAR file. Main idea is that you will need to use Travis CLI tool and run “travis setup releases”. Make sure to deploy released for tags only.

I have found more detailed instructions here and here.

Because of the starter project sets the setSelfUpdateRepository() for the runner whenever in the future next release will be available -- you can simply run yourcommand self:update to self update the tool.

Jan 15 2020
Jan 15

When migrating content with the Drupal 8 migrate module, the creation and updating of new entities may fire lots of custom module hooks. This may or may not be desired; if you have found yourself here, it probably interferes with the source data in a problematic way, or unnecessarily slows down the migration process.

The cleanest way I found to stop specific hooks for specific migrations, is to add a dummy/meta field to the migration and check for its value in the hook.

Include a dummy field in the migration

In the process section of the migration, add a field with a name that will not interfere with any field name of the target entity:

  1. # This is the field that will provide a custom hook

  2. # with the information about the migration.

  3. _migration:

  4. - plugin: default_value

  5. default_value: 'blog_categories'

This is an example migration with CSV as source and taxonomy terms as target:

  1. id: blog_categories

  2. label: 'Blog category migration'

  3. migration_group: default

  4. source:

  5. plugin: csv

  6. path: 'public://migrations/blog_categories.csv'

  7. delimiter: ','

  8. enclosure: '"'

  9. header_row_count: 1

  10. ids: [tid]

  11. process:

  12. name: name

  13. # This is the field that will provide a custom hook

  14. # with the information about the migration.

  15. _migration:

  16. - plugin: default_value

  17. default_value: 'blog_categories'

  18. destination:

  19. plugin: entity:taxonomy_term

  20. default_bundle: blog_categories

  21. migration_dependencies:

  22. required: {}

  23. optional: {}

Check for the value in an entity hook

  1. /**

  2.  * Implements hook_entity_update().

  3.  */

  4. function my_module_entity_update(Drupal\Core\Entity\EntityInterface $entity) {

  5. if (isset($entity->_migration) && $entity->_migration === 'blog_categories') {
  6. return;

  7. }

  8. // Some undesired custom hook logic.

  9. }

In this case the hook will never fire for this specific migration, but may fire for other migrations. Skipping the second condition will make sure the hook will never fire for migrations where the _migration dummy field is defined.

Jan 15 2020
Jan 15

This blog has been re-posted and edited with permission from Dries Buytaert's blog.

Happy nineteenth birthday

Nineteen years ago today, I released Drupal 1.0.0. Every day, for the past nineteen years, the Drupal community has collaborated on providing the world with an Open Source CMS and making a difference on how the web is built and run.

It's easy to forget that software is written one line of code at the time. And that adoption is driven one website at the time. I look back on nearly two decades of Drupal, and I'm incredibly proud of our community, and how we've contributed to a more open, independent internet.

Today, many of us in the Drupal community are working towards the launch of Drupal 9. Major releases of Drupal only happen every 3-5 years. They are an opportunity to bring our community together, create something meaningful, and celebrate our collective work. But more importantly, major releases are our best opportunity to re-engage past users and attract new users, explaining why Drupal is better than closed CMS platforms.

As we mark Drupal's 19th year, let's all work together on a successful launch of Drupal 9 in 2020, including a wide-spread marketing strategy. It's the best birthday present we can give to Drupal.

Jan 15 2020
Jan 15
What is digital accessibility? Andrew Nevins Wed, 01/15/2020 - 17:05

The word accessibility is used to describe whether something can be used by everyone, regardless of ability. Digital accessibility is referring to websites and apps ensuring that people with disabilities (permanent, temporary or situational) find them easy to use. 

At least 15% of the world’s population - one billion people - have a recognised disability. There are many ways in which a person’s disability may affect the way they perceive information online, and how they navigate within pages. 

Jan 15 2020
Jan 15

This year Drupal Global Contribution Weekend is on January 24-26, 2020 with such varied locations as Delhi, Novosibirsk, Ghent, Frankfurt, Milan, Zurich, Lutsk, London (on two continents!), Boston, Minneapolis, etc. Wow! It is truly a global gathering! With Drupal 9 planned to be released later this year, what better to focus on, than making drupal.org projects Drupal 9 ready?

To help you do that I went in and updated my open source State of Drupal 9 talk. People can use this to present at any location to get people up to speed about Drupal 9. If you need a video recording of it, there is one from DrupalCamp Belarus in May 2019. While the content got slightly updated since then, the recording should help get it.

After or instead of presenting that session, I thought a quickstart guide would be really useful to help people get started with contributing. While this looks like a colorful guide you would print, it is actually full of useful links (some to my earlier blog posts for details), so I suggest you use it in digital form.

What are you planning to do for Drupal Global Contribution Weekend this year?

Jan 15 2020
Jan 15

Testing has become an important topic in recent years thanks to the explosion of testing technologies and continuous integration (CI) approaches but also due to the need for an ever-widening range of tests for a variety of use cases. For many developers, understanding how to incorporate testing into their development workflows can be daunting due to the many terms involved and, worse yet, the many tools available both in software-as-a-service (SaaS) companies and in open-source ecosystems like Drupal.

Yuriy Gerasimov (Senior Back-End Engineer at Tag1 Consulting) presented a session at DrupalCon New Orleans about modern testing approaches and how to decide on the correct suite of tests for your software development workflows. In this four-part blog series, we analyze the concepts in contemporary testing approaches that you need to know in your day-to-day and why they can not only protect but also accelerate your project progress. In this first installment, we take a look at how to sell testing as an important component of client (your stakeholders) projects, as well as why automated testing is an essential component of any web implementation.

Why testing?

Many people around the web development landscape have heard of testing, but when you ask about real-world examples on real-life projects, the same developers admit that their testing infrastructures are sorely lacking. The most important reason for this is that while testing is a compelling value-add for developers, it can be difficult to incorporate testing as a required line item in projects, especially when business stakeholders are looking to save as much money as possible. How to sell testing to clients continues to be a challenging problem, especially because requesting that a client pay for an additional 100 hours on top of the 500 already incurred can be anathema to their sense of frugality.

After all, many customers will respond by arguing that by choosing you as an agency or developer, they already trust you to foster a high-quality outcome. As such, many clients will ask, “Why do we need to spend extra money on testing?” Without the overt benefit that project components like architectural workshops and actual implementation provide, testing is often the forgotten and most easily abandoned stage of a build.

A real-world example of the need for testing

In his talk at DrupalCon New Orleans, Yuriy describes a large project (prior to his time at Tag1) on which he collaborated with many other people on a development team tasked with finishing the implementation in six months. The project was for a local municipality, with many integration points and features. Every feature needed to work perfectly, including critical features for civic life such as applying for permits, and tolerance for dysfunction was low.

By the end of the project, originally slated for six months, Yuriy’s development team ultimately spent six months developing and an additional six months fixing issues and testing functionality. Fortunately for his team, the municipality had already been through a project whose timeline ballooned out of control, and the team was able to deliver the project within a year as opposed to the previous partner, who spent two years on the same project.

One of the most alarming aspects of the project at the time was that all of the testing the team had done until that moment consisted of manual testing sessions. A meeting was convened, and every developer stood up, responsible for describing the rationale for each feature they had built and demonstrating the feature. Every team member would then test each constituent feature and fix issues on the spot, in the moment.

Learning from past mistakes

As one can imagine, this manual testing approach is highly unsustainable for projects that require tight timelines with a high degree of confidence. Yuriy learned many lessons from the project, and in a subsequent implementation six months later, in which he and his collaborators built an application for people with hearing and speech difficulties, he made considerable changes. The project was complex, with several servers communicating with the application through REST APIs and a high expectation for a user experience that would allow users to click icons representing elocutions that would speak in their place.

From the beginning, Yuriy and his team baked in automated testing up front to test communication with the REST APIs and ensure all requests were functioning properly. They built the project to be scalable because they knew that many users would be using the application simultaneously. In the end, the quality assurance (QA) overhead was minimal, because developers on the team could simply run automated tests and show the result to the client. Even though the size of the project was roughly the same, having built-in automated testing with acceptance criteria was a benefit difficult to overstate.

Defending quality: Selling testing to customers

When testing aficionados attempt to sell testing to customers, they must frame the investment in terms of quality and long term vs. short term costs (failing to deal with this in the short term will actually cost you more in the long term). However, it is admittedly difficult to sell something when its success cannot be measured. After all, from the client perspective, a buyer is selecting a vendor based on the quality with which they implement projects. But there are only anecdotal metrics that indicate whether an organization performs better than another with high-quality projects. For this reason, it is essential that developers interested in selling testing as part of their contracts offer metrics that are comprehensible to the customer.

In the end, the sole concern of customers is that software is delivered without bugs. While ease of maintenance is also important, this is generally considered table-stakes among stakeholders (or a problem for the future). In order to provide a high degree of confidence for issue-free builds, we need metrics for traits like performance and code quality (like adherence to Drupal’s coding standards). Thus, when a customer asks about the justification of a metric such as code quality, we can show the results of tools like code audits, which in Drupal consist of a single Drush command that generates a full report. By performing a code audit on a codebase written by a less experienced team, for example, clients can be sold immediately on the value of your team by seeing the results of a highly critical code audit—and will seldom be opposed to your team winning the contract.

Automated testing

For many developers who are new to the concept of automated testing, the term can unleash a torrent of anxiety and concern about the massive amount of work required. This is why Yuriy recommends, first and foremost, building a testing infrastructure and workflow that demands minimum effort while yielding maximum dividends. Nonetheless, successful automated testing requires a robust testing infrastructure and a healthy development culture that is supportive. Without these elements, success is seldom guaranteed.

Fortunately, the up-front cost of automated testing is low owing to the “one and done” nature of automated testing. Though it’s likely you’ll spend a few weeks building out the infrastructure, there is no need to repeat the same process over and over again. Nevertheless, Yuriy recommends exploring the approaches that other software companies and industries undertake to understand how they tackle similar requirements. For example, automated testing for the C language has been around for many years. Moreover, there is no need to write our own continuous integration (CI) server, thanks to the wide variety of services available on the market, including software-as-a-service (SaaS) solutions that charge as little as $50 per month.

Even if you have written a large number of tests for your project, one of the most important aspects of automated testing may seem particularly obvious. If you don’t run automated tests regularly, you won’t receive any benefits. For instance, it is certainly not adequate to inform your customer that you have implemented automated testing unless you are running said tests weekly or monthly based on the project requirements. Otherwise, the value of the time you have spent implementing automated tests becomes questionable.


As you can see, testing is frequently the most easily forgotten component of web projects due to the extent to which clients question its value. However, armed with the right approaches to selling tests, you too can cultivate a culture of quality assurance (QA) not only within your development team but also for your business’s customers. With the help of automated testing, you can reduce the headaches for your team down the road and justify additional time that means extra money in your pocket.

In this blog post, we covered some of the important aspects of modern testing approaches and why customers are beginning to take a second look at the importance of quality in their projects. In the second installment of this four-part blog series, we’ll turn our attention to implementing testing infrastructures and fostering a development culture favorable to testing within your existing projects. We’ll discuss some of the maintenance costs associated with implementing automated testing and begin to look at two of the most prominent areas of testing: code checks and unit testing.

Special thanks to Yuriy Gerasimov, Jeremy Andrews, and Michael Meyers for their feedback during the writing process.

Jan 15 2020
Jan 15

If users have questions, this is great — because this means they are interested. Providing clear and informative answers can give you enormous benefits. So it’s worth including FAQ (Frequently Asked Questions) in your content marketing strategy.

Here we will discuss reasons for this, as well as show how an FAQ section is created. This post will be particularly interesting for those who have a Drupal website, as well as those who are just choosing a CMS. See how a very nice Drupal module — the FAQ Field — creates a FAQ section. Our explanation will be accompanied by a video.

The advantages of an FAQ page or section (+ examples)

An FAQ in any form depending on your website’s needs (a glossary of terms, frequently asked questions with answers, a set of instructions, etc.) could do the following for you:

  • An FAQ section or an FAQ page saves your team’s time in answering the users’ routine questions about your products, services, terms of use, website’s work, etc.

Example of FAQ on a website

  • The questions and answers increase the website’s user-friendliness by helping users quickly reach their goals.
  • Content like this adds authority to your brand by showing that you care for your visitors, willingly share useful information, and possess enough expertise.
  • The question-and-answer sections give a good logical structure to your pages and can be presented in a variety of designs (accordion menu, lists of anchor links, etc.)
  • Listing the common questions just the way users ask them on Google can significantly increase your search traffic.

Example of FAQ on a website

  • This is also the perfect way to get into Google’s featured snippets above all search results. It is the key step in optimizing your website for voice search.
  • Frequently asked questions with answers can help you encourage the buying decisions, resolve some of the common customers’ doubts about your product, share your vision, and more.

Example of FAQ on a website

The FAQ Field Drupal module to create an FAQ section

One of the simplest ways to create a FAQ section on a Drupal website is to use the FAQ field module. Let’s review its features.

Installing the FAQ field module in Drupal 8

A FAQ field for your content

When installed and enabled, the module allows you to add an FAQ field to a content type (article, blog post, product, story, etc.). Your content pieces will get a frequently asked questions section next to them.

FAQ field for content in Drupal 8

The FAQ field module can be compared to another Drupal module in this realm — the FAQ module. The latter creates a content type for FAQ while the former simply creates a field.

Having just a field gives you the additional flexibility to add frequently asked questions to your existing content types (e.g. e-commerce products).

A variety of FAQ designs

The FAQ field module allows you to choose between these design options on the Manage display tab of a content type:

  • HTML definition list
  • jQuery Accordion
  • HTML anchor list
  • simple text (themeable)

Configuring the display of FAQ in Drupal 8

The default for your FAQ section is the accordion menu with the first question opened:

FAQ section in Drupal 8 as jQuery accordion

You can have all questions closed and requiring an action (click) to open. To do this, use the accordion settings cogwheel, set the first default question to “None” and check “fully collapsible.”

Configuring jQuery accordion in Drupal 8 to show all FAQ closed

Now see the “HTML anchor list” option (that can be set as a bullet list or numeric list):

configuring the display of FAQ in Drupal 8 as an anchor list

Other useful features of the module include the FAQ height style adjustment and animation settings. To help your users find questions, it can be used together with modules like the Search API.

To enhance our story, we invite you also to enjoy the video about using the FAQ field Drupal module created by our team.

[embedded content]

Let professionals create an FAQ section on your website!

We have demonstrated a simple but nice way to create a FAQ section on your website. Ask our Drupal development team to build the frequently asked questions section or page that will look exactly in accordance with your wishes.

Jan 15 2020
Jan 15

The beginning of a new year always seems like a good time to take some time for reflection. While we started to do that the past couple of weeks, in an effort to wrap up some end of the year goals and finalize plans for how we wanted to start 2020, we realized that it's been quite a while since we've written about projects we're working on for the site. With Drupal 9's release planned for June of 2020 now is a great time to do this reflecting and planning work.

While much of my time in the past year has been focused around our new Osio Labs products, we've also been beginning to plan for an upgrade and migration to Drupal 8/9. This seems like a good opportunity to share a bit about how our infrastructure is evolving. As we start to plan for a future upgrade, it's important to take an inventory to help give us a sense of how the project is likely to go.

When I first started working on the Drupalize.Me site, shortly after it originally launched, our tools and processes looked quite a bit different than they do now. Back then we had a site built on Drupal 6, and were using a third-party provider to host our videos, and all of our content was exclusively video. We were using svn for version control, and Unfuddle for our project planning. Needless to say, things have changed quite a bit over the years.

Now, we've moved our writing process over to GitHub. This allows us to use issues, projects and milestones, and pull requests to organize the work of content development outside of Drupal. Joe has written about some of the advantages this gives us when it comes to editing and linting tools. Additionally, it's much easier for us to on-board new writers and editors with something like GitHub than it would be if we had built these tools on top of our CMS. We're doing our content work this way on all of our products. When pull requests are merged, our content is imported (or updated) automatically. On the whole, this process has been a big win for our team. Once we have our content created via this import process we then go about adding metadata to the tutorials (video assets, publication dates, tags, etc).

Our Drupalize.Me infrastructure is somewhat of a monolithic site, aside from the tutorial production process. A single codebase then handles everything from user registration, billing, content delivery, and your personal content queue. For our new products we're trying something a bit different.

Looking at our new products from the backend, there are quite a few similarities. We're still using GitHub to help with our content creation process and importing our content into Drupal. Drupal also still helps us out with user management, and billing (thanks to the Recurly module). That is where the similarities end.

Both GatsbyGuides and HeyNode are using the same Drupal-based backend site. When you visit the site as a member you're interacting with sites built on top of GatsbyJS. This decoupling allows us to reuse our work across our sites, while still allowing them to evolve independently. One of the big advantages we've seen using Gatsby so far is that the requirements to host the sites are drastically simplified. Another nice side effect of this decoupling is that these front-end sites are now solely responsible for displaying content. This has made it easier for us to write comprehensive tests, and deploy new code faster.

As we start the process of planning a migration to Drupal 8 (and eventually 9), we have the chance to compare and contrast the monolithic and decoupled approaches. While the planning work is still in it's early stages, the flexibility we've gained by decoupling parts of our site has given us some unique opportunities. Moving forward with our migration work, I'm hoping to continue to provide a bit of a peak behind the curtain into some of the decisions we're making. In my experience real world projects like these provide the best learning opportunities, so if any of you are working on a similar project I'd love to hear about it.

Jan 15 2020
Jan 15
Happy nineteenth birthday

Nineteen years ago today, I released Drupal 1.0.0. Every day, for the past nineteen years, the Drupal community has collaborated on providing the world with an Open Source CMS and making a difference on how the web is built and run.

It's easy to forget that software is written one line of code at the time. And that adoption is driven one website at the time. I look back on nearly two decades of Drupal, and I'm incredibly proud of our community, and how we've contributed to a more open, independent internet.

Today, many of us in the Drupal community are working towards the launch of Drupal 9. Major releases of Drupal only happen every 3-5 years. They are an opportunity to bring our community together, create something meaningful, and celebrate our collective work. But more importantly, major releases are our best opportunity to re-engage past users and attract new users, explaining why Drupal is better than closed CMS platforms.

As we mark Drupal's 19th year, let's all work together on a successful launch of Drupal 9 in 2020, including a wide-spread marketing strategy. It's the best birthday present we can give to Drupal.

January 15, 2020

46 sec read time

Jan 15 2020
Jan 15

What started out as a hobby project of Dries Buytaert, is now a global project with millions of users, active contributors and a strong ecosystem. Drupal is truly a phenomenon. It has continued to see a surfeit of experimentations. Thanks to the perpetual support by the Drupal Community over the years as it has always chosen the path of innovation, reinvention and evolution. 15 January 2020 marks the nineteenth birthday of Drupal.

Infographics with stars on top and bottom and the text for nineteenth 19th birthday for Drupal in the middle

There have been several content management systems bursting onto the scene and fading into thin air. But Drupal, as an open-source project, has always stayed with us, evolved and continued to reach greater heights. It still offers a lot to ponder over, tinker around and build something new. With each passing year, impelled by Drupal Community’s efforts, it has started becoming more easier to use and is constantly growing at a staggering rate.

Tweet showing an image on top left and the text below for Drupal birthday

It all began in 2000 when Dries decided to put an internal site, that was used for socialising between a small group of people, online. Dorp, a Dutch word for village, was supposed to be used for the domain name. A mistyping by Dries eventually paved the way for drop.org. With more members thronging the site, having healthy discussions and using it as an experimentation platform, Dries decided to release the software behind drop.org. Drupal 1.0.0 was thus born on 15 January 2001. Open-sourcing this project allowed others to leverage and extend the experimentation platform and ultimately explore new ways of web development.

Screengrab of project Drupal on git with several lines of programming codeCode commit by Dries on 29 December 2000 where the project was called Drupal for the first time

Not only has Drupal scaled new heights but has also helped Drupal fraternity undergo a lot of personal reinvention. Drupalists, thus, have never missed an opportunity to celebrate Drupal's birthday every year since its launch.

Sometimes, a simple ‘Happy Birthday’ is more than enough to show your gratitude to Drupal.

Tweet showing image of person on top left and zebra below it

At other times, the community members have expressed their merriment on sharing the same birthday date.

Tweet showing an image on top left and text below

The typo, that happened before the birth of Drupal, never seems to get erased from the memories of the community. It has made an indelible mark in the hearts of Drupalists. Drupal Community members leave no stone unturned to show that they can be as witty as any great stand-up comedian. They can use ‘typo’ as the theme of their Drupal birthday celebrations.

Tweet showing images of a person on top left and centre with text covering rest of the area

A quirky style was once applied by Dries himself to celebrate Drupal's birthday.

Tweet showing image of a person on top left and text below

And, a birthday cake is always special. So, we, at OpenSense Labs, organised a cake-cutting ceremony and asked our Drupalists to put forth their love for Drupal on the whiteboard.

A whiteboard with scribbles of Drupal appreciation and number 19 written at the centre and a blue cake below

Teenage is deemed as one of the best periods of our youth. The new sensations, victories and obstacles make for an exciting collection of memories that we hark back to. These are the kind of memories where we immerse ourselves in and go into the state of nostalgia in the later stages of life. Drupal enters its last year of teenage too. A lot of fantastic developments have happened in the last few years vis-à-vis Drupal. There is still a lot of room for improvement and the community knows where the Drupal lags behind.

2019 has especially been wonderful for Drupal as it witnessed an increase in Drupal contributions, plentitude of efforts was taken for making Drupal more diverse and inclusive and the foundation for Drupal 9 release was laid out. We, along with millions of Drupal lovers all around the world, are waiting for the launch of Drupal 9 eagerly and hoping to celebrate many more birthdays of Drupal.

Jan 15 2020
Jan 15

With websites playing a major role in determining customer needs and impacting business sales, a second’s lapse in loading can make a customer think twice about staying on the website. 

As per Amazon’s findings, it stands to lose up to $1.6 BILLION per year if their site was slowed down by just one second. 

A reliable and fast web hosting provider can play a crucial role for your business to retain online users. 

While looking for a hosting provider for your website, what qualifies as the best solution? Does CMS specific hosting really have an impact on website performance?

Let’s find out! 

Why Drupal-Specific Hosting?

Drupal specific hosting is safer and better as it is more compatible out of the box and comes with a bundle of other benefits: 

1. Easier Installation For Quicker Website Building

Choosing Drupal-specific hosting providers helps with quick 1-click installs which can be completed within minutes. It’s best to to opt for CMS friendly web hosting solutions to sync up easily.

2. No Further Cost Associated

A Drupal specific host can provide a server infrastructure that is specifically optimized for running Drupal websites at no extra hidden cost.

3. Flawless User Experience

The benefit of working with Drupal-specific hosting is that it can notify you of any website performance issues or of any upcoming minor or major release and assures seamless user experience.

4. Strong Community Support

Drupal Community support for your website as well as your hosting provider with a plethora of huge libraries of modules and extensions can support you if you get stuck.

What are Drupal Web Hosting Requirements?

It is essential to choose a hosting provider which can match the setup of the CMS you’re using. 

With Drupal being a  CMS which has numerous modules running, it would need a hosting solution which can offer a huge spacing model. A basic Drupal site will need around 2 GB of RAM and 10 GB of total storage, MySQL 5.5 or higher for Drupal 8 and MySQL 5.0.15 or higher for Drupal 7. Also, the core installation takes about 100 MB on the web server, depending upon the modules, themes and content needed for your website. 

What Qualities Determine Best Hosting Provider?


With multiple options of popular web hosting available out there, choosing the right Drupal hosting can be a humongous task. Not just fast server speeds, but qualities to look in a hosting provider include robust security, one-click Drupal installs, migration assistance, scalable hosting, daily backups, and which come with Drupal utilities pre-installed. 

We have curated a list of things which you should consider in the hosting provider for your website. They’re listed as follows:


  • Higher Uptime Percentage: While choosing a hosting provider, ensure that it has a reputable uptime percentage, preferably above 99.5%, which shows how much time your hosted website will be online for its users. A weak server and unstable network connections of a hosting provider can often make your website offline.
  • Better Page Load Speed: Server speed is different than website speed. There’s no use optimizing your website if it is sluggish on the server it’s hosted on. With only 3 seconds to catch a visitor’s attention, you don’t want to lose one with a slow server response time. To stand out amongst million websites on the web, a super-fast loading website can transform a visitor to a customer.
  • Reliable Customer Support: This is an important aspect for your web hosting and should not be overlooked. Your provider should offer support on emails, chat, phone and much more and should have a responsive reputation in their support department. 
  • Automated Backup Restore: A good host will ensure daily website backup of all content, files, and code in case of unpreventable accidents.
  • Standard Development Workflows: An ideal Drupal hosting solution will usually come with three environments (dev, stage and live) in the cost of the subscription. Dev environment is used only by the development team to build and test new features, stage environment for bug fixes before they are launched to your live/production site, live environment being client facing with live content
  • Cost-Effectiveness: Well, who doesn’t want an affordable and reliable web host? 

Srijan’s Recommendations For Drupal Website Hosting

We’ve chalked out a list of some of the best Drupal platforms that are trusted and proven to provide the best service for small to enterprise business.

AcquiacloudimageAcquia Cloud platform tops our list of the best Drupal hosting providers. A trustable name in the hosting industry, it is not only secure and compliant, but also is improved to be able to support Drupal 8 sites. The provider has a huge support staff and is the most preferred channel for big names like BBC world.  Its starting price for small businesses is $141/month and ranges to $795/month for mid-size businesses. Users could try the free version before deciding to go for it. 


Pantheon offers a competitive price for Drupal hosting with uncompromisable performance. Makes your Drupal run faster, this hosting provider handles traffic spikes without any hiccups. Big names like Apigee, Tableau rely on it and stands strong based on user reviews. Offering in-built dev, staging and live environments, it is developer friendly provider helping them deploy code securely, using a continuous integration workflow. Its most popular plan starts from $114/month and is apt for traffic-intensive websites.


Siteground hosting provider is tailored as per your Drupal website needs. Well backed by Drupal experts, the plan comes with an easier start, alongwith 1-click Drupal install and no-downtime for your website. Here’s a list of its amazing features:

  • 30 daily backup of website
  • 100% security from attacks
  • 24/7 uptime monitoring
  • Latest technology hardware used
  • 24*7 Drupal expert support available

It offers affordable hosting plans starting from $3.95/month. 

AWS offers a cloud hosting platform for your Drupal website. Its extensive computing power and faster content delivery can help your businesses scale and grow rapidly. It offers various services to host Drupal 8 in a distributed environment.

It is considered best for medium to large enterprises. You can check the pricing details here and use the calculator to see if the cost suits your budget.

A2hostingimageHigh powered hosting to meet your needs, it offers 20 times faster speed for your Drupal website at four affordable plans for shared, reseller, VPS and dedicated server hosting. It is optimized for speed and performance, with Drupal being pre-installed with every hosting plan. Here’s a highlight of what it offers:

  • Fast servers for a supreme user experience
  • Friendly and knowledgeable support team available 24/7/365
  • Completely risk free money back guarantee
  • 99.9% uptime commitment

While there are numerous providers for hosting a site and some of them appearing just tailor made specific to unique needs of Drupal sites, if you need assistance in deciding which one suits your needs, contact us. Experts at Srijan can guide you to opt for the best hosting solution as per your Drupal needs.

Jan 14 2020
Jan 14

Content management systems (CMSs) are the engine that drive content creation on the web today. They form the foundation that we build on for publishing and sharing information, creating digital experiences and conducting online retail. WordPress and Drupal are staples in the CMS world and they have both been around a long time. WordPress is known for its intuitive and easy-to-use interface. Drupal is known for its flexibility and complexity. While both have their strengths and weaknesses, the usability gap between WordPress and Drupal is changing. This article will show you the current state of Drupal’s admin user experience in a side-by-side comparison with WordPress, the most widely used CMS. If you’re familiar with one CMS but not the other, this comparison is also a good introduction to the other.

TL;DR: The primary goal of this article is to dispel the perception that Drupal is widely different and harder for administrators to use than WordPress. If you don’t care about the background behind this perception, just skip down to the direct comparison.

WordPress is easy, Drupal is hard… why does this perception exist

But first, a little background. The dominant CMS in terms of number of sites running on it is WordPress. It’s estimated to power about 62% of all websites that use a CMS, meaning multiple millions of websites are using it. Why is WordPress so popular? WordPress started as a blogging engine with a focus on being easy-to-use. This proved to be incredibly important because it meant that nearly anyone could get a WordPress site up and running fast and be able to use it with little-to-no training. The idea caught fire with both individuals and local businesses who just wanted a simple, low-cost website that others could find online. Web developers and agencies also finally had a framework that allowed their clients to make simple content edits within an admin environment that was friendly. Of course, WordPress today can be used for much more than a simple website, but it is still ideal for simple websites. Another key takeaway here is this perception of WordPress as being easy-to-use. This reputation holds true just as much today as it ever did in the past.

This article isn’t actually meant to praise and promote WordPress. Instead, much of this article will focus on another popular CMS, Drupal. Drupal is a fantastic CMS and is incredibly powerful when used correctly. In many web development circles, Drupal is the go-to solution for providing a robust solution for today’s CMS driven website development. It’s thriving both in usage and as a community of enthusiasts, but while WordPress sits in #1 spot with 62% of the market share, Drupal holds steady at #3 with about 3%. It still means there are many hundreds of thousands of websites powered by Drupal, but the number of websites using it pales in comparison to WordPress.

Why isn’t Drupal more popular? Well, anyone who knows Drupal (and even many who don’t) will tell you that Drupal is best suited for large websites with high traffic and complex requirements. Universities, government, nonprofits and online retailers are a sample of who uses Drupal. Drupal out-of-the-box isn’t as ready to use as WordPress, so it’s unlikely a suitable fit for simple websites. For individuals, configuring Drupal is a steep learning curve. For local web agencies, it takes more time to setup which means they must charge more. These reasons alone largely take Drupal out of the running for many websites, so for Drupal it’s more about use case than mass adoption.

With that said, Drupal’s ability to be configured and developed on literally means it can handle nearly any situation required of it, whether that means selling products for enterprise businesses or being the integration layer between multiple platforms. While this inherent flexibility is great for software developers, Drupal’s perception of complexity combined with a historically underwhelming admin experience has cemented a reputation that Drupal is unintuitive and difficult to use for the end user, the people who will be using it every day. While in my opinion this isn’t true of today’s Drupal, like WordPress it’s reputation precedes it. In Drupal’s case, however, this reputation isn’t as flattering and it’s something that our sales and outreach teams battle with often.

For Drupal, it’s time for change

Like WordPress, Drupal is open source software. It’s free to use and anyone has full access to the underlying code to modify and build upon. Both platforms have a core team for advancing key initiatives and a massive community of individuals and organizations that support the initiatives while also adding additional functionality through plugins (WordPress lingo) or modules (Drupal lingo).

While usability has always been important to WordPress (since it started as a blogging platform), Drupal was historically more focused on being open and flexible. It’s user experience has continuously improved with each version release, but late in 2018 marked the beginning of a big push towards modernizing the Drupal admin user interface (UI). Drupal is really amazing software and it’s time that the admin experience catches up.

Introducing Claro, Drupal’s new admin UI

Drupal 8 Claro admin theme
Claro interface design mockup courtesy of Drupal.org

Claro is the new admin theme being built as part of the Admin UI Modernization initiative. It’s included with every Drupal 8 site, new and old, and can be enabled right now if you so choose. Just be aware that it is currently considered “experimental” while progress continues to be made. It’s not yet in its finished state, but you can view the development roadmap here to see what is still left to do.

Side-by-side: WordPress & Drupal Admin UI Comparison

On to the comparison!

For WordPress, I’m using version 5.3.2 (released Dec. 18, 2019) which comes with its own Twenty Twenty default theme and content.

For Drupal, I’m using version 8.8.1 (also released Dec. 19, 2019. How about that!) and the new, but experimental, Claro admin theme. If you’re looking at this at a later date, some aspects may be different (for the better!) as development of the theme continues. I’ve also installed Drupal using the official Umami demo install profile so that I have a theme and some content to work with.

In each of the 10 comparison categories below, I’ll give my opinion on which CMS has the edge out-of-the-box and why I think this. I’ve used both platforms and do have some bias towards Drupal, but I’ll do my best to keep that in check.

Category quicklinks
  1. Admin toolbar
  2. Login dashboard
  3. Managing media
  4. Creating pages
  5. Editing pages
  6. Managing widgets and blocks
  7. Managing menus
  8. Managing users, roles and permissions
  9. Site status report
  10. Plugins and modules
  11. WordPress & Drupal comparison summary

1. Admin toolbar

The admin toolbar is always present on the page of both WordPress and Drupal.


WordPress admin toolbar

In WordPress, a single toolbar is used as a jump-off point for common admin pages, but you can also start the content creation process and access your account profile and information.


Drupal 8 admin toolbar

Drupal has a similar admin toolbar except you have access to everything including creating new content. Every admin page that your user role has permission to view is available through this menu. While it’s more to look at initially, experienced users enjoy fewer clicks to get where they want to go.

Edge: Drupal

While the learning curve to know where everything is might be a bit steeper, experienced Drupal users enjoy being able to access everything in one familiar way. With that said, new users may find this larger menu intimidating.

2. Login dashboard

After logging in, the login dashboard is the first page you see. WordPress and Drupal both take a different approach to their login dashboard.


WordPress login dashboard

WordPress has a robust dashboard right out of the gate. This dashboard takes admins away from the site frontend and into an interface that only they can see. The left side has a larger menu for accessing the rest of the admin interface. The main content area mix of useful information about your site and information specific to WordPress as a whole, such as training resources and upcoming WordPress events. The panes on this page can be toggled on and off and plugins can add new panes.


Drupal 8 login dashboard

This is the first area where Drupal takes a different approach. Instead of a robust dashboard, you don’t actually get much of anything. The admin toolbar already gives you access to the entire site, so Drupal keeps you on the website frontend and instead shows you your “user page”. This page is entirely customizable although you will most likely need third-party or IT support to do so. It’s an open canvas to do with as you like. For ecommerce, you might show a customer their information, recently viewed products and their last order placed. For content creators, you might show a custom dashboard with quick links to their common tasks. What you do here is entirely up to you.

Edge: WordPress

Although it’s not entirely useful, WordPress actually has a dashboard which is a nice touch for new users. Drupal's clean slate offers a lot of exciting potential for admins and visitors alike, but any potential must first be realized before this page is useful.

3. Managing media

Images, videos, documents and more are uploaded and organized within a media manager. Both WordPress and Drupal offer a convenient content editor plugin which makes selecting and adding media into content easy.


WordPress media manager

WordPress really defined the way media can be managed within a CMS. Their interface for managing media contains a handy drag-to-upload feature and each piece of media is shown in a grid format by default. Media can be filtered by date, type and name.


Drupal 8 media manager

Drupal admittedly isn’t as clean as WordPress in this interface yet but it’s functionality is essentially the same and solid for most users. The visual interface will improve as the development of Claro progresses. By default, Drupal displays media in a list, but you can toggle between list and grid. There are also similar filtering options. Like all other aspects of Drupal, advanced users can customize media types beyond what you see here and entirely new media types can be created. This advanced functionality is unique to Drupal and isn’t as easily done in WordPress.

Edge: WordPress

WordPress does a great job of making media easy to manage. Drupal will continue to see improvements in the near future, but right now it still feels clunky.

4. Creating pages

Creating new pages, such as general content pages and blog posts, is a common interaction that most admin users will need to do.


WordPress new page Gutenberg editor

As of version 5.0, WordPress includes their much anticipated Gutenberg editor experience. This editing format is sleek, modern, and very intuitive. You start with a title and then continue piecing together chunks of content by selecting various types of “blocks” to build the page with. Blocks are a single, reusable type of content such as a heading or paragraph of text, an image or gallery, a list, a quote, etc. Custom blocks can be created and plugins may also add additional blocks that content creators can use. Along the right side of the page is a settings pane. This pane provides various page specific settings and customizations such as page visibility, featured image, an option to allow comments, etc. Additional settings for the currently selected content block also appears here.


Drupal 8 new page creation

Out-of-the-box, creating a new piece of content looks like the screenshot above. Content in Drupal could potentially be something wildly different than just a basic page, so Drupal defaults to a standard “field based” editing interface where the different fields that are configured to make up the content are laid out on the page. All editors need to do is fill in the blanks. Field types can be text (with an optional WYSIWYG editor), and image, a file upload, a date, and anything else you can imagine. This again is where Drupal’s flexibility is both an advantage and a curse. The advantage is that a type of content can be anything you can imagine, but the downside is that someone has to configure that content type first. The field based editing experience is provided by default to ensure the editing experience is consistent across different content types.

Here’s the important thing to know about Drupal. Drupal doesn’t like to make assumptions as to what your editing experience should be. As an example, a used car dealership, a national newspaper, and an online retailer will all have entirely different content editing requirements. Drupal doesn’t want to get in your way and it doesn’t try to. What it does do is give you a solid foundation to create YOUR ideal editing experience. This might not be ideal for organizations and businesses with simple website requirements, but for those with complex workflows and unique requirements, Drupal is ideal.

One last important note to make on this topic is that Drupal does also have a Gutenberg editing experience, it just doesn’t come packaged with Drupal out-of-the-box. This module and other editing interface modules and initiatives can be installed in Drupal to make the default editing experience more capable and modular.

Edge: WordPress

When based solely on out-of-the-box functionality, WordPress pre-packaged Gutenberg editing experience is modern and intuitive for new and experienced users. However, it’s important to note that Drupal modules exist that greatly improve Drupal’s default experience. You can even add the same Gutenberg experience.

5. Editing pages

Once a page has been created, sometimes you still need to go back and edit it once in a while. This is a different experience from creating new content, so let’s now look at how it works with each CMS.


WordPress editing existing pages

Pretty standard, as a logged in administrator you have access to editing content by viewing the page on the website frontend and using one of the various “edit” buttons. You’re then brought to the same Gutenberg interface that you see when creating content.


Drupal 8 edit existing pages

I would say Drupal has the upper hand for editing existing content. Similar to WordPress, as a logged in administrator you have access to page edit links when viewing the content which brings you back to the same interface as when the content was created. However, in Drupal you also have additional links to view content revisions as well as the view and edit page translations for multi-language sites.

Drupal 8 inline page editor

The current version of Drupal, Drupal 8, also includes an additional edit icon that contains a new “quick edit” option. Depending on the content, the quick edit allows on-page inline editing (shown above) instead of taking you to a separate page! This makes simple edits quick and easy. Furthermore, the edit icon also appears when administrators hover over menus and other configurable page elements too, giving you a quick way to access their configuration.

Edge: Drupal

While WordPress has the edge when creating new content, Drupal’s on-page inline editing feature makes editing existing content quick and easy by keeping content editors on the website frontend.

6. Managing widgets and blocks

Widgets (WordPress lingo) and blocks (Drupal lingo) are two words for essentially the same thing. While not limited to these locations, the header, footer and often left and right columns beside the main content area contain defined regions where certain elements can be placed. I’m talking about slogans, menus, a search bar, your copyright, recent posts, social feeds, etc. WordPress and Drupal have similar but different ways to manage these elements.


WordPress widgets page

WordPress includes a backend and frontend methods for editing page widgets, both of which are quite basic and lack a lot of real capability.

The backend method (shown above) is accessed through the backend Appearance menu. This page gives you a nice list of available widgets on the left side and another list of active widgets within the available regions on the right. A simple drag and drop interface lets you move elements around and opening each widget allows for basic configuration.

WordPress widgets live editor

The frontend method is through a”Live Preview” mode (shown above) where a version of the site theme is presented and widgets are managed through the left column. Settings for existing widgets can also be quickly opened by clicking its blue edit icon, as you can see in the image above.

Out-of-the-box, it’s difficult to understand exactly where a widget will appear throughout the site because you don’t have the ability to see or control which pages accept the widget. Some third-party plugins are available to give you this functionality, but they must be added. New widgets are also a bit more difficult to add as they must be created by a developer or added though a plugin.


Drupal 8 block layout page

Like WordPress, Drupal has the ability to manage blocks from both the backend and frontend of the website, although Drupal handles both situations better.

The backend method (shown above) is accessed through the admin toolbar’s Structure menu. Here you can view all available regions and the blocks contained within each. Regions are a big part of Drupal theme creation, so you will often see 10+ available regions to choose from. If you’re not sure of your themes regions, the “Demonstrate block regions” link above the list of regions will give you a preview. Each region has a “Place block” button for adding new pre-configured blocks. Existing blocks can be moved dragged between regions and each block can be configured independently. Block configuration in Drupal is very robust, including but not limited to control over what pages the block is visible on and what account roles can view it. Like content, blocks can be translated and even have revisions.

Custom blocks can also be created by more advanced Drupal users in a similar way that new media and content types are created. In the screenshot above there is a link to the “Custom block library,” which is where new blocks can be created. Like WordPress, modules can also be installed which will add new blocks.

Drupal 8 frontend block quickmenu

Drupal’s frontend method for managing blocks takes on the same familiar editing experience that we discussed for editing content. When logged in and viewing the website frontend, navigating to a page and hovering your cursor over an element will reveal an edit icon if that element is a configurable block. Options for the block are then given. The block in the screenshot above contains a menu, so we see options to configure the block and edit the menu. In this case, clicking one of these options will take you to the backend page for performing these actions. If the block contained text, we would also be given an option to edit the text directly on the page, just like we can with content.

Edge: Drupal

Simply put, Drupal’s block management is robust yet not too difficult. Being able to manage existing blocks directly from the website frontend is both user friendly and familiar given that existing pages can also be managed in the same way.

7. Managing menus

Menus connect the pages within a website. Commonly you’ll find a primary navigation and some sort of footer menu, but menus are used in many other places as well.


WordPress menu management

The menu system in WordPress is a bit strange at first, but overall it’s pretty simple. You create a menu (or select an existing one using the menu selection dropdown), then add links by selecting pages, categories, or by creating custom links (add menu items in image above), then use a drag and drop interface for moving and nesting the menu items (menu structure in image above). Each menu item within the menu structure can be opened for a bit of customization.

The menu settings area controls where the menu is displayed within predefined template locations. Just check the box and the menu will appear once saved. Any menu created here can also be assigned to region as a widget or through the template live preview screen.

One odd thing I’ve found with WordPress is that, when editing a page, you’re not able to add it into a menu. I’m sure there are plugins that allow this, but out-of-the-box you have to add the page through the menu system or check a setting within the menu that all new pages get added… but then you might have to remove some.


Drupal 8 menu management

Drupal’s approach to menus is what I wond consider more standard. You navigate the “menus” page which lists all of the menus that have been created, then you create a new menu or edit an existing menu. The screenshot above is what you see when editing a menu. Here you manage this menu’s links by either adding a new one or manipulating the existing ones. When adding a new link you can easily search for content that the link will link to or specify a custom link.

Pages can also be added to a menu when the page is being created or edited. Within the page settings, all you do is select the menu and specify a link title.

Like WordPress, once you create a menu you can then add it into a region of the site as a block. However, within the menu itself you don’t have the ability to put the menu anywhere.

Edge: Drupal

A more standard approach makes managing menus clearer and more user friendly. Also being able to choose if a page should be included in a menu while creating the page is a nice feature. That said, I appreciate being able to manage a menu in its entirety on a single page like you do in WordPress.

8. Managing users, roles and permissions

Managing users is common for both controlling who can edit the website and who can login for other reasons, such as non-admin accounts for an online store or community.


WordPress user management

WordPress has six predefined user roles: Super Admin, Administrator, Editor, Author, Contributor, and Subscriber. Each has varying degrees of what they can do, but it’s pretty clear for the most part and goes back to when WordPress was mainly a blogging platform. Users can be created and managed through a “users” page (shown above), which is laid out in a straightforward manner displaying

But WordPress has some major drawbacks here. First, WordPress doesn’t have any frontend user self-management, meaning users can’t view or edit their own profiles. Second, the predefined roles and their associated permissions don’t work for everyone and actually complicate user management when you don’t need it. Third, there is nowhere to really manage role permissions in a granular way. These drawbacks can be fixed through custom development and/or various plugins, but many consider this to be a general weak point of WordPress.


Drupal 8 user management

User management is another area where Drupal shines. In contrast to WordPress, Drupal only starts with three default roles: Anonymous, Authenticated and Administrator. Anonymous is a user who is not logged in, authenticated is a user who has an account but isn’t someone who typically isn’t managing content and site configuration, and administrator is a user with full site and admin access. These three roles are minimal, clear and cover all of the basic needs of most sites. If and when another role with different permissions are created, this is easy to do right out-of-the-box.

The image above shows Drupal’s version of the current list of users. It follows a similar look and style to the rest of the admin pages, giving administrators a place to add and manage user accounts, including assigning users to specific roles. Anonymous and authenticated users can also create or manage their own account through the website frontend (although this functionality can be turned off in desired).

Drupal 8 user permissions page

Drupal’s strength in user management comes in the form of roles and permissions. When a role is created, a column of permission checkboxes for the role is added to the Permissions page (shown above). Almost every piece of functionality within Drupal has an associated permission. Simply checking the boxes determines what each role can and can’t do. It’s powerful and easy.

Edge: Drupal

A simple yet powerful user management system combined with frontend self-service functionality gives Drupal a clear edge over WordPress.

9. Site status report

Both WordPress and Drupal include a site status page that gives you information about the website and server configuration as well as an overall health report that outlines any issues. These automated health checks help keep your CMS up-to-date and secure.


WordPress site health page

The “Site health” page (shown above) gives you an overall health status and list of any issues. This status page is clean and each item can be expanded for more information, but there is no visual urgency that makes the “2 critical issues” stand out. In my opinion, critical issues should be resolved and so highlighting these issues in some way is a necessary UX improvement.

An info tab at the top of the page can be opened which gives more information about your installation of WordPress, the server, the PHP version, and the database.


Drupal 8 status report page

Drupal contains both site information and site health in one “Status report” page (shown above). Like WordPress, this page gives you everything you need to know at a glance about your Drupal installation and the other components that make it run. Here we can also clearly see what errors and warnings have been found and some information on how they can be resolved.

Edge: Drupal

While both WordPress and Drupal have similar pages that show similar information, Drupal’s status report does a better job at laying out the information and visually capturing the severity of any issues.

10. Plugins and modules

Plugins (WordPress lingo) and modules (Drupal lingo) extend core CMS functionality and add new features. Extensions are usually created by third-party developers and released to the platform communities for anyone else to use. Whether it’s to increase performance, enhance SEO capabilities or create an online store, extensions are a powerful way to improve and adapt the CMS platform.


WordPress plugins page

Visiting the “Plugins” page (shown above) is a quick way to see what additional plugins are currently packaged with your WordPress installation and can be activated if desired. Plugins shown here all provide some sort of new functionality or feature that is not part of the core WordPress software.

WordPress plugin search page

When you need new functionality, WordPress provides an excellent and convenient plugin library browser (shown above) accessible within the website backend. Here you can search for, view, and install plugins easily with the click of a button.


Drupal 8 extend page

Drupal’s module list is where you can see all current extensions, activated or not, for your Drupal installation. The big difference here between WordPress and Drupal is that for Drupal you are able to see all modules installed, even those that are part of the core software. Modules are also nicely grouped which nicely organizes the large list.

Installing new modules isn’t nearly as easy in Drupal. Unlike WordPress, Drupal doesn’t include a module library browser within the backend interface. Instead, users must search for modules within a web browser and manually install them. Finding modules can be difficult if you’re not familiar with the process.

Edge: WordPress

While both platforms have a massive library of extensions, WordPress offers users a much friendlier and intuitive way of finding and installing extensions that users of any skill level can appreciate. This may or may not be an issue for you if you have a capable IT team or development partner, but for small teams WordPress has the clear edge.

WordPress & Drupal comparison summary

I hope after going through this comparison you now have a good understanding of the differences and similarities between WordPress and Drupal. As you can see, both platforms out-of-the-box have different strengths and weaknesses, but it’s important to know that all of the weaknesses can be overcome through platform extensions and experience. In extreme cases, both platforms support custom development to overcome unique problems.

For convenience, here is a quick summary showing which CMS has the edge in the 10 categories compared. However, I would recommend that you go back and read the edge summary for each category, if you haven’t done so already.

Comparison category WordPress Drupal Admin toolbar   ✓ Login dashboard ✓   Managing media ✓   Creating pages ✓   Editing pages   ✓ Managing widgets and blocks   ✓ Managing menus   ✓ Managing users, roles and permissions   ✓ Site status report   ✓ Plugins and modules ✓  

A final word of advice

In my opinion, you shouldn’t be turned off from one platform or the other simply because you’ve heard that one is better or easier to use. Both platforms are mature and constantly improving, user experience is top of mind, and usability gaps have become less of an issue in recent years.

My advice, select the platform you use based on your requirements. WordPress is a great authoring tool and is good for small and medium sized organizations. Drupal is fantastic for medium and large sized organizations or anyone who has complex workflows, products, and/or a need to integrate with other platforms. That’s a pretty general summary, but if you’re considering either of these platforms, first know what your requirements of the platform are and then start talking to the experts for each.

Acro Media is an ecommerce consultation and development agency who can help you in this regard. We specialize in open source ecommerce and a large part of our work is based around Drupal. Drupal typically works better for our clients but we know WordPress, too. If you’re researching your requirements or evaluating your options, hit us up for a quick chat, we would love to help. Otherwise, check out some of these related resources.

Contact Acro Media Today!

Related resources

Jan 14 2020
Jan 14

New legislation from the EU means that public sector websites must comply with the EU Web Accessibility Directive if they are launched after 23rd September 2019. For existing websites, public sector organisations have slightly longer to make their services accessible to everyone. With the next deadline for existing sites in September 2020, not too far away, this guide explores the practical steps organisations can take to comply. 

What is the EU Web Accessibility Directive?

An estimated 80 million people in the EU live with a disability, making it more necessary than ever to ensure everyone has equal access to digital products and services. The EU Web Accessibility Directive is a new piece of legislation which aims to consolidate accessibility standards, making web accessibility a legal requirement.

The Directive requires that member states have processes in place to “ensure that public sector bodies take the necessary measures to make their websites and mobile applications more accessible”. 

As with most legislation, there are some exclusions which apply. These include broadcasters, some schools and nurseries, and private organisations, along with non-government organisations (such as charities) which “provide services that are not essential to the public or services that do not specifically address the needs of persons with disabilities”.

Unlike the Web Content Accessibility Guidelines (WCAG), the Directive does not include rules about how to make websites and mobile applications accessible. However, the four WCAG principles which provide the foundation for accessibility (perceivable, operable, understandable and robust) are present throughout. This begins to unify the digital accessibility standards for EU member states, by putting WCAG at the core.

How does this affect public sector organisations?

Any new websites launched after 23rd September 2019 must meet accessibility standards and must have an accessibility statement.

If a public sector organisation launched a website before 23rd September 2019, the website must meet the accessibility standards by 23rd September 2020. Improving accessibility for an existing website is notoriously more difficult than building with accessibility in mind from the beginning. Organisations with older sites therefore have slightly longer to meet the required standards.

Accessibility standards also apply to mobile apps, however, organisations have until 23rd June 2021 to meet that deadline.

While organisations are progressing in their efforts to make services more accessible, it’s clear there is a lot more to do for existing websites and apps - and they are running out of time. With the next deadline approaching rapidly, what practical steps can public sector bodies take to raise their accessibility game?

Audit your websites

A recent survey revealed that 40% of local authority homepages aren’t accessible to people with disabilities. Organisations must therefore first understand how an existing website is performing in terms of accessibility.

Common issues include: failing to provide a good heading structure and links with sufficient context, not using visible indicators to show where the keyboard focus is, not adding skip links to jump over repetitive page content and not having sufficient contrast between text and its background. 

Completing an accessibility audit will help find where there are barriers for people with disabilities and help plan in any remediation work necessary to meet the standards.

Add an accessibility statement

The Directive set a deadline of 23rd December 2018 for public sector organisations to add an accessibility statement to their websites. 

When an accessibility audit or accessibility evaluation has taken place, the results from the audit can be used to help write an accessibility statement. The accessibility statement should be regularly updated and the W3C suggests including the following as a minimum:

  • A commitment to accessibility for people with disabilities
  • The accessibility standard applied, such as WCAG 2.1
  • Contact information in case people encounter problems
  • Any known limitations of the website, to avoid frustrating your visitors
  • Measures taken by your organization to ensure accessibility

Make the content as accessible as possible

The most difficult stage for any organisation is making the content as accessible as possible. While building accessibility in from the start of a web development project is always the best route to ensure your services are accessible to everyone, it is vital the team responsible for planning, updating and writing content are also committed to high accessibility standards.  

Web accessibility isn’t a one-time task, it’s an on-going commitment. Website content and development work needs to be constantly monitored and updated to achieve ongoing compliance. Performing regular audits or evaluations and asking people with disabilities to test products and services ensures websites and apps are as accessible as possible.

This article originally appeared on Open Access Government published on the 10th December 2019. 

Can we help you on your accessibility journey with an healthcheck, audit or consultancy? Get in touch

Jan 14 2020
Jan 14

It’s really awkward when our clients or prospects ask: “Why do you suggest moving to Drupal 8 while it’s about to reach the end of life as well as Drupal 7? I’m not buying this.”

Well, first of all, Drupal 7 is not going to be abandoned - it will be set for the Drupal 7 Vendor Extended Support at least for 3 years.

As for Drupal 8, its last minor release (8.9) will be put for the LTS program from June 2020 until the end of life in November 2021. Also, this very last release will be the basis for Drupal 9.0. 

So let’s check out why we think it’s high time for Drupal 7 update that we all love. 

Updated Drupal 8 means being Drupal 9-ready

Staying on Drupal 7 means the necessity to execute a migration to Drupal 9. Moving from Drupal 8 to Drupal 9 will look like a minor website update that you usually do in less than a day.

Limited Drupal 7 support

Drupal 7 will be supported by vendors (not by the Drupal Security Team nor the Drupal Core team) at least until 2024. 

What this support means:

  1. No more core commits 
  2. Features development on-demand only
  3. No community support at large when it comes to massive bug fixing, documentation writing

Besides, it’s supposed to be a bad practice to use unsupported software due to security issues. 

No new Drupal 7 websites will appear as well: this point should be taken into account by the dev teams who maintain some specific Drupal 7 solutions.

Drupal 8 utilizes a widespread tech stack and approaches

Drupal 8 has a tech stack that allows more developers to embrace this CMS.

  1. Symfony components
  2. Twig -” the flexible, fast, and secure template engine for PHP” as it’s described on the official website
  3. OOP approach
  4. Composer support
  5. RESTful Web Services

Drupal 8 is more secure and has minor releases more often

Drupal 8 has a minor release once in 6 months which is quite nice: the new functionality can be added to the core more frequently. For example, these features were added within minor Drupal 8 releases (ask your developers why these features are cool):

  • Media (standardized and improved media management)
  • Workflows and Content Moderation
  • Layout Builder (page layout management and the possibility to add different elements and blocks through UI and drag-n-drop)
  • BigPipe for better performance

Also, the patch releases provide consistent secure updates, bug fixes and peace of mind.

Drupal 8 is feature-rich

One might think that migration is just an act of creating a hassle for no reason. Say, a website works well, the workflow is okay, and web developers always find a way out. 

Cutting the costs on web development also throws you back on your way to improvement. You won’t pay more for development but you also won’t earn more money with the help of your website.

These features in Drupal 8 will ease website development and management:

  1. New editor convenient for non-tech managers
  2. Quick Edit right on the page
  3. Drupal 8 is mobile-friendly out of the box
  4. Responsive images
  5. Better accessibility (which is trending now)
  6. The better multilingual feature implementation and its support
  7. Built-in Web Services: RESTful Web Services and JSON API out-of-the-box. All of this opens the world of the Internet of things (the devices that can be connected and communicate some data to each other), mobile apps and multi-channel integrations (PC, TV, tablets, etc), internal services and so on.
  8. The decoupled approach allowed out-of-the-box, including the static websites generator Gatsby
  9. The convenient migration tool Migrate API will ease the migration from Drupal 6 and Drupal 7. Also, there are tools that allow migrating from Wordpress.
    It’s worth saying that now popular contributed modules have stable Drupal 8 versions and that significantly reduces the migration effort. 
    When it comes to Drupal 9, in April 2019 46% of contributed modules were ready for Drupal 9, states Dwayne McDaniel from Pantheon.

There are big changes (planned) for new Drupal versions

Below are just a few things that are already in progress or planned for the nearest future.

  • New admin user interface managed by a React application
  • The API-First initiative
  • New Configuration Management
  • Content workflow improvement
  • Further improvements for Media management
  • Automatic updates for Drupal websites (!)

Are you ready for the big changes already? Invest, not cut costs - it will pay off. 

Useful links

7 reasons to migrate to Drupal 8 (and don’t wait for Drupal 9)

Why migrate from Drupal 6 to Drupal 8

Jan 14 2020
Jan 14

In my 2019 Acquia retrospective, I reflect on our business momentum and the evolution of the Acquia Experience Platform.

Wow, what a year 2019 was for Acquia!

Acquia 2018 business metrics

At the beginning of every year, I like to publish a retrospective to look back and take stock of how far Acquia has come over the past 12 months. I take the time to write these retrospectives because I want to keep a record of the changes we've gone through as a company and how my personal thinking is evolving from year to year.

If you'd like to read my previous retrospectives, they can be found here: 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009. This year marks the publishing of my eleventh retrospective. When read together, these posts provide a comprehensive overview of Acquia's growth and trajectory.

Our product strategy remained steady in 2019. We continued to invest heavily in (1) our Web Content Management solutions, while (2) accelerating our move into the broader Digital Experience Platform market. Let's talk about both.

Acquia's continued focus on Web Content Management

In 2019, for the sixth year in a row, Acquia was recognized as a Leader in the Gartner Magic Quadrant for Web Content Management. Our tenure as a top vendor is a strong endorsement for the "Web Content Management in the Cloud" part of our strategy.

We continued to invest heavily in Acquia Cloud in 2019. As a result, Acquia Cloud remains the most secure, scalable and compliant cloud for Drupal. An example and highlight was the successful delivery of Special Counsel Robert Mueller's long-awaited report. According to Federal Computer Week, by 5pm on the day of the report's release, there had already been 587 million site visits, with 247 million happening within the first hour — a 7,000% increase in traffic. I'm proud of Acquia's ability to deliver at a very critical moment.

Time-to-value and costs are big drivers for our customers; people don't want to spend a lot of time installing, building or upgrading their websites. Throughout 2019, this trend has been the primary driver for our investments in Acquia Cloud and Drupal.

  • We have more than 15 employees who contribute to Drupal full-time; the majority of them focused on making Drupal easier to use and maintain. As a result of that, Acquia remained the largest contributor to Drupal in 2019.
  • In September, we announced that Acquia acquired Cohesion, a Software-as-a-Service visual Drupal website builder. Cohesion empowers marketers, content authors and designers to build Drupal websites faster and cheaper than ever before.
  • We launched a multitude of new features for Acquia Cloud which enabled our customers to make their sites faster and more secure. To make our customer's sites faster, we added a free CDN for all Cloud customers. All our customers also got a New Relic Pro subscription for application performance management (APM). We released Acquia Cloud API v2 with double the number of endpoints to maximize customer productivity, added single-sign on capabilities, obtained FIPS compliance, and much more.
  • We rolled out many "under the hood" improvements; for example, thanks to various infrastructure improvements our customers' sites saw performance improvements anywhere from 30% to 60% at no cost to them.
  • Making Acquia Cloud easier to buy and use by enhancing our self-service capabilities has been a major focus throughout all of 2019. The fruits of these efforts will start to become more publicly visible in 2020. I'm excited to share more with you in future blog posts.

At the end of 2019, Gartner announced it is ending their Magic Quadrant for Web Content Management. We're proud of our six year leadership streak, right up to this Magic Quadrant's end. Instead, Gartner is going to focus on the broader scope of Digital Experience Platforms, leaving stand-alone Web Content Management platforms behind.

Gartner's decision to drop the Web Content Management Magic Quadrant is consistent with the second part of our product strategy; a transition from Web Content Management to Digital Experience Management.

Acquia's expansion into Digital Experience Management

We started our expansion from Web Content Management to the Digital Experience Platform market five years ago, in 2014. We believed, and still believe, that just having a website is no longer sufficient: customers expect to interact with brands through their websites, email, chat and more. The real challenge for most organizations is to drive personalized customer experiences across all these different channels and to make those customer experiences highly relevant.

For five years now, we've been patient investors and builders, delivering products like Acquia Lift, our web personalization tool. In June, we released a completely new version of Acquia Lift. We redesigned the user interface and workflows from scratch, added various new capabilities to make it easier for marketers to run website personalization campaigns, added multi-lingual support and much more. Hands down, the new Acquia Lift offers the best web personalization for Drupal.

In addition to organic growth, we also made two strategic acquisitions to accelerate our investment in becoming a full-blown Digital Experience Platform:

  1. In May, Acquia acquired Mautic, an open marketing automation platform. Mautic helps open up more channels for Acquia: email, push notifications, and more. Like Drupal, Mautic is Open Source, which helps us deliver the only Open Digital Experience Platform as an alternative to the expensive, closed, and stagnant marketing clouds.
  2. In December, we announced that Acquia acquired AgilOne, a leading Customer Data Platform (CDP). To make customer experiences more relevant, organizations need to better understand their customers: what they are interested in, what they purchased, when they last interacted with the support organization, how they prefer to consume information, etc. Without a doubt, organizations want to better understand their customers and use data-driven decisions to accelerate growth.

We have a clear vision for how to redefine a Digital Experience Platform such that it is free of any silos.

A diagram shows how Acquia solutions unify experience creation, content and user data across different platforms.

In 2020, expect us to integrate Lift, Mautic and AgilOne, as well as make them the best solution for Drupal. We believe that this will benefit not only our customers, but also our agency partners.


Demand for our Open Digital Experience Platform continued to grow among the world's most well-known brands. New customers include Liverpool Football Club, NEC Corporation, TDK Corporation, L'Oreal Group, Jewelers Mutual Insurance, Chevron Phillips Chemical, Lonely Planet, and GOL Airlines among hundreds of others.

We ended the year with more than 1,050 Acquians working around the globe with offices in 14 locations. The three acquisitions we made during the year added an additional 150 new Acquians to the team. We celebrated the move to our new and bigger India office in Pune, and ended the year with 80 employees in India. We celebrated over 200 promotions or role changes showing great development and progression within our team.

We continued to introduce Acquia to more people in 2019. Our takeover of the Kendall Square subway station near MIT in Cambridge, Massachusetts, in April, for instance, helped introduce more than 272,000 daily commuters to our company. In addition to posters on every wall of the station, the campaign — in which photographs of fellow Acquians were prominently featured — included Acquia branding on entry turnstiles, 75 digital live boards, and geo-targeted mobile ads.

Last but not least, we continued our tradition of "Giving back more", a core part of our DNA or values. We sponsored 250 kids in the Wonderfund Gift Drive (an increase of 50 from 2018), raised money to help 1,000 kids in India to get back to school after the floods in Kolhapur, raised more than $10,000 for Girls Who Code, $10,000 for Cancer Research UK, and more.

Some personal reflections

With such a strong focus on product and engineering, 2019 was one of the busiest years for me personally. We grew our R&D organization by about 100 employees in 2019. This meant I spent a lot of time restructuring, improving and scaling the R&D organization to make sure we could handle the increased capacity, and to help make sure all our different initiatives remain on track.

On top of that, Acquia received a substantial majority investment from Vista Equity Partners. Attracting a world-class partner like Vista involved a lot of work, and was a huge milestone for the company.

It feels a bit surreal that we crossed 1,000 employees in 2019.

There were also some low-lights in 2019. On Christmas, Acquia's SVP of Engineering Mike Aeschliman, unexpectedly passed away. Mike was one of the three people I worked most closely with and his passing is a big loss for Acquia. I miss Mike greatly.

If I have one regret for 2019, it is that I was almost entirely internally focused. I missed hitting the road — either to visit employees, customers or Drupal and Mautic community members around the world. I hope to find a better balance in 2020.

Thank you

2019 was a busy year, but also a very rewarding year. I remain very excited about Acquia's long-term opportunity, and believe we've steered the company to be positioned at the right place at the right time. All of this is not to say 2020 will be easy. Quite the contrary, as we have a lot of work ahead of us in 2020, including the release of Drupal 9. 2020 should be another exciting year for us!

Thank you for your support in 2019!

January 13, 2020

22 sec read time

Jan 13 2020
Jan 13

For a nonprofit, raising enough funds to do the most good is at the forefront of goal setting this new year. Direct and recurring donations have always been time-proven and effective ways to achieve this goal. But how can a nonprofit differentiate themselves and maximize the revenue available to aid their cause? Adding an e-commerce store with profitable products that both connect to your organization’s vision and add funds to fuel your efforts can be a game-changer.

Charity:Water’s success in the e-commerce space is both aspirational and strategic genius. By implementing an e-commerce solution, powered by a payments processor similar to the Commerce iATS module available for both Drupal 7, 8 and the iATS extension on CiviCRM, Charity:Water has turned branded products into additional brand recognition, a compelling story, and increased financial support. They are successfully speaking the language of millennials, providing authentic alternatives to traditional donations.  

While nonprofits explore different income streams, there are important considerations.

Make an Impact with your Product Selections

Reflect on the demographics of your donors when choosing products to boost profit possibilities. Some products will appeal to different age groups and doing your research ahead of time will allow you to curate the most appealing product lineup.

Keep your Nonprofit’s Mission Top of Mind

The e-commerce addition that best represents the values and aspirations of your organization are more likely to be received as genuine by your existing donors. 

Protect your Organization

Avoid costly fraud complications by selecting a payment processor that is secure and easy to use. With the payment processing modules and extensions already available for Drupal 7, Drupal 8 and CiviCRM, you’ll have your store up and running in no time.

Ready to get started or have questions? Feel free to reach out for more information.

Jan 13 2020
Jan 13

Too often, compliance with WCAG 2.1, to ensure web accessibility for people with disabilities, is an afterthought of the web development process. WCAG 2.1 compliance is a multifaceted endeavor, and when accessibility is incorporated into every phase of development, the result is greater efficiencies and superior outcomes.

Let’s look at the key phases of the web development workflow, and the advantage of keeping accessibility top of mind every step of the way. 

Planning and Wireframes

When planning and wireframing out a website project, accessibility needs to be considered at the very outset. During this phase, different functionalities of the website are flushed out, but  accessibility tends to not be a top-of-mind. Here are a few practices to help keep the workflow on track for an accessible site and avoid unwelcome setbacks later in the process. 

  1. During planning and wireframing processes, developers and site architects need to take notes and continuously question: “How is this going to work?”  “How will we make this component accessible?” This initial inquiry helps in planning and anticipating certain “pain points” or larger components -- such as a Calendar of Events -- that might take more time to be made accessible.
  2. When planning out specific or custom functionality, it’s important to always stop and consider how it will be conveyed to a user who is visually or hearing impaired. 


The design phase represents an whole new range of accessibility considerations that need to be taken into account. While color contrast is the most obvious issue, other issues such as focus styles or link text size are more likely to be overlooked. Below are a few of the many accessibility checks that need to be in place during the design phase. 

  1. Evaluate elements of the website from the perspective of a person with color blindness, age-related sight loss, or other visual impairments. Can the text be clearly distinguished from the background image? Contrast checking resources and WCAG 2.1 provide support and guidelines for ensuring adequate contrast between the text and background elements.
  2. Every website design should include a style guide that encompasses heading sizes, button styles, and other elements. Often, however, the style guide is not detailed enough and certain elements are forgotten or specific accessibility checks are missed. For example:
    • different font sizes require different color contrast ratios between the foreground and the background,
    • accessibility for heading colors varies by font size,
    • alert boxes need to be legible with adequate contrast, and
    • primary and secondary colors need to be checked for accessibility with the site background.


If accessibility has been top-of-mind up to this point, developers will be well positioned to avoid accessibility related setbacks and surprises. Notes taken during planning and wireframing can help to guide an accessibility roadmap during development. Below are a few items that are often overlooked:

  1. “Read More” links. Almost every site created within the past 10 years has “Read More” links on landing pages, blog posts, and throughout interior pages. It is not accessible, however, to have the same text on multiple links that direct the user to different places. Link text needs to be descriptive and specific to the page, such as “Get Further Insights,” “Check Out this Special Offer,”  or “Learn the Key Benefits.” 
  2. Forms and error messages. Forms are extremely common sources of accessibility issues. Ensuring accessible forms involves many distinct elements that need to be developed properly.
    • All form elements need to have proper labels with properly linked “for” attributes. Inputs with invalid “for” attributes cause the labels to not link to the inputs.
    • All accessible form elements require properly set up labels with descriptive text, and linked “for” attributes. 
    • Error messages need to be adequately informative for screen-reader users. Error messages such as, “This field is required,” don’t provide enough context for a visually impaired person using a screen reader. Consider more specific error messages such as, “Phone number required."

While accessibility considerations might feel like time-consuming additional steps, getting it right during development represents a significant savings of time and resources. It takes far more time and effort to find and fix accessibility issues once a site goes live, or even before it reaches the quality assurance (QA) phase than it does to understand the full scope of accessibility while the site is under construction.

Rules and Tools - It’s QA Time

Once development is complete and the site enters the QA phase, it is critical that QA testers are fully knowledgeable concerning what to check for from an accessibility standpoint and are familiar with WCAG 2.1 accessibility guidelines and testing tools. 

If accessibility issues arise during the QA phase, there needs to be a proper workflow and documentation processes in place for the QA team to successfully explain the scope of the issues, along with recommended fixes.

Want to Know More?

At Promet Source, we’re passionate about accessibility. We develop accessible sites, audit sites to uncover accessibility issues, remediate existing websites for accessibility, consult with clients on accessibility, provide accessibility training, and much more. Contact us today for help with any or all of your web accessibility needs. 

Jan 13 2020
Jan 13

My journey with Drupal contributions started in Oct 2019 and I started by understanding basic issues and reviewing  patches created by the experienced contributors.  

As we start a New year, I am proud that my contribution has played an important part in moving Unimity to Page one of the Service Providers list. I wish to share in this blog my learnings and I hope that this will inspire organizations and developers to contribute in the new year! 

Five aspects I have learnt through my contributions are:

  1. Understanding of  how Drupal software is built

  2. Connecting  with core contributors

  3. Improving my Technical knowledge

  4. Staying up to date with Drupal

  5. Mentoring  others

Understanding of  how Drupal software is built:-

Drupal is built from community contributions from all over the world. Lot of hard work by core contributors results with the successful implementation of this open source software. Other aspects about Drupal and the issue queues include:

  1. Understanding the  issue workflow from how an issue starts from active to needs work, needs work to needs review and needs review to reviewed & tested by community, RTBC to fixed.
  2. The different ingredients of this software include: modules/components, issue queues, core contributors, patches, tags, version control, credits, commits
  3. Understanding Drupal’s roadmap and the features mapped to each of the releases
  4. Initiative leads & initiative meetings

Connecting  with core contributors:- 

Had the privilege of interacting with top 10 core contributors:  Kjamlaluno, Jrockowitz, RajabNatshah, VolkswagenchickBojanz, Alonaoneill, Thalles, Wim Leers, Webchick, Lauri, Jhodgdon, Xjm and few others.

It was a truly wonderful experience to get appreciated by core Drupal maintainers for my work .

Recognized by Alexpott


Recognized by Webchick


Improving my Technical knowledge:-

Drupal Contributions also helped me in gaining the technical knowledge in many areas such as :

  1. Drupal’s folder structure
  2. Concepts such as Layout Builder, View modes, JSON API, Help topics
  3. Front end CSS, JS and TWIG implementations
  4. Writing Test Cases
  5. Documentations

Staying Up to date with Drupal:-

Drupal Contributions introduced me to Drupal roadmap. Following the roadmap helped me to stay updated with  new features. When Drupal 8.8 was rolled out, I knew about the New Administration Theme Claro and Media Library. I also follow core maintainers on twitter and have recently started working on the new Olivero Theme that Dries spoke at length during his session at DrupalCon Amsterdam.

Mentoring  others:- Contributions improved my role as Drupal Trainer at Unimity. I started being a mentor to all those willing to contribute and give back to Drupal. 

It has been an exciting journey and I thank Unimity for sponsoring the time to contribute. I also want to share few other members at Unimity who have Contributed to Drupal in 2019 are:

  1. Gayathri: Contributed in various areas as :- Help Topics , Media Library Documentation, Umami Profile 
  2. Madhura: Contributed in areas such as :- Migration, Help_topics
  3. Vinodhini:- Contributed in Claro new Admin Theme, Deprecated code
  4. Gnanagowthaman:- 
  5. Tarun: Contributed in Olivero New Front end theme
  6. Iyyappan:- Contributed in Migration
  7. Punam:- Contributed in Migration 

Together Unimity contributed: 13 core patches, 3 olivero patches, 1 Claro patches, 38 contributed patches.
I welcome more users from the Drupal community to join and benefit from the contributions.

Are you looking for help to climb the Drupal Contribution ladder? Just reach out to  me "Shimpy" on drupal_ contribute slack channel! Happy to help :) 

Jan 11 2020
Jan 11

Your website can be the mirror of your business ideas reflecting them in every detail. Displaying data exactly in the desired ways makes your website more user-friendly. Today, we discuss how relationships in Drupal 8 Views can be helpful if you want to show related content. The video will make our story more vivid.

Benefits of showing related content

By showing related content we mean including the content somehow related to the main one into the page display. It’s great when you can show, for example, the favorite articles of a user, the reviews and blog posts about a product together with their author pictures, and so on. The unquestionable benefits of showing related content are:

  • the pages look more interesting
  • this creates a richer content ecosystem
  • users are kept engaged and stay on the site
  • your website’s session duration increases
  • the chance for conversion grows

Luckily, there are great tools for this. Relationships in Drupal 8 Views allow you to show related content in very flexible ways with no limits to your ideas. Let’s get acquainted with them step by step.

What are Views in Drupal 8?

Whatever Drupal website you see, many of its pages are likely to be built with Views. Drupal Views is the SQL query builder that fetches data from your website’s database (content, users, comments, etc.) and displays them on your site as a data collection.

Example of Drupal Views on a website

This does not require coding — Views has a user interface to configure which data you want to display and how. You can sort and filter the results, choose to show dynamic data via contextual filters in Drupal 8 Views, and so on.

The Views is built into Drupal and does not require installation, which is among the best Drupal 8 benefits. However, dealing with Drupal Views requires a profound understanding of Drupal and should better be entrusted to a web development team.

What are relationships in Drupal 8 Views?

When created, every Drupal view is configured to retrieve the data from a particular database table.

Choosing base table in Drupal 8 Views

To create richer displays and show related content, relationships in Drupal 8 Views connect your initially chosen table to others. So, thanks to relationships added, the view becomes able to display the data from different tables together.

Here are a few scenarios when relationships in Drupal Views can help you show related content. For example, you can:

  • show related author pictures in articles
  • show related user pictures in comments
  • show related favorite content in user profiles
  • show related real estate properties in owner profiles
  • show related user mentos’ pictures in user profiles

and much more.

How to use relationships in Drupal 8 Views?

Let’s create relationships in Drupal 8 Views that will help us display customer reviews together with their pictures. We will need to show the data from the “Content” table together with the related data from the “Users” table.

1. Creating the Review content type

Let’s go to Structure — Content types and create a new content type called “Review.”

Creating a Drupal 8 content type

2. Adding a user field

Our reviews will belong to particular customers who are users on the Drupal website. So we need to add a “user” field to the Review content type. It will be a referenced entity. We will name it “Review author.”

Adding a referenced entity user field to a Drupal 8 content typeGiving a name to a user field in a Drupal 8 content type

3. Adding test reviews

For testing purposes, we then add a few actual reviews in “Add content — Reviews”. We assign a different test user to each of them in the “Review author” field.

Adding Drupal content with the author field

4. Creating a view based on reviews

In Structure — Views we add a new view:

  • give it a name “What our customers say”
  • set it to display content of the Review type
  • choose “create a page”
  • set its display format to “Grid of fields”
Creating Drupal 8 Views

5. Adding fields to the view

Our view is based on fields, so let’s add the ones we need:

  • review author
  • body

The review title, the default field for a content type, will not be needed and can be removed from our view.

Adding fields to Drupal 8 Views

6. Adding a relationship to the view

We will also need an author picture, for which we go to the “Advanced” section in Views, click on “Relationships,” and add a new relationship. By searching through the available options, we choose “User referenced from field_review_author.”

Adding relationships to Drupal 8 Views

By clicking “Add and configure relationship,” we are almost done — we may only check “Require this relationship.”

Then we come back to the Views fields and add the “User Picture” field. When configuring the field, make sure the “field_review_author” relationship is selected. To make all pictures look standard, apply an image style.

Adding user picture field to Drupal 8 Views that has a relationship

Now the user picture will be fetched to our page from every review author profile to make it all look much more colorful now. This is our page with customer reviews created via a relationship in Drupal 8 Views! But, of course, it is a rough version that needs good theming.

Drupal 8 Views with a relationship

Video about adding a relationship in Drupal 8 Views

It becomes a good tradition to share the information in a video, so enjoy watching our example of how to use relationships in Drupal 8 Views.

[embedded content]

Entrust our team with displaying your website’s data right

The above was a very simple example of how to use relationships in Drupal 8. There is really no limit to how your data can be displayed and your pages built. You can display related content in any way or anything else you might have an idea about.

Share your ideas with our Drupal maintenance and support team so they will come up with a good solution and bring it to life.

Jan 11 2020
Jan 11

The large business world knows no compromise. Your website should stand out from the competitors and keep up with all the business requirements. And not just keep up — a site can move your business forward by offering advanced digital experiences to customers.

Whether the website is capable of doing this, largely depends on the choice of the platform to build it with. In this post, we discuss why it’s worth choosing Drupal for large business website development.

How large business website development can benefit from Drupal

If you have an idea to create a large business website, it may have some specific needs. For example, this site needs to be content-heavy, complex in architecture, high in traffic, unique and robust in functionality, and so on. See how Drupal, an enterprise-level CMS and CMF in one, can help you build a big website for your big idea.

Exceptional and unlimited functionality

Provide your large business website users with any functionality desired. Drupal empowers developers with creating even the most complex and specific site features.

It has 44+ thousand free contributed modules for various spheres of your site’s work — content display, search, security, third-party integration, SEO, access control, e-commerce functionality, etc. And, of course, any custom features can be created by a development team to match your business scenarios exactly.

The Tesla’s site (Drupal + Adobe Experience Manager):

Tesla website

Modern technology inside

Efficient development workflows, clean code, and fast performance of your large website also depend on what is “under the hood” of a CMS. Drupal 8 uses OOP (object-oriented programming), the Twig theming engine, the modern PHP 7, Symfony components, and more.

Your brand’s multichannel reach

Your large business website can be part of a whole multichannel ecosystem for your brand. It can share its content to iOS or Android applications, JavaScript-based web apps, various Internet-of-Things devices, and so on. The “Create Once, Publish Everywhere” (COPE) method will speed up your content management.

Make use of the API-first principle and the exceptional support of third-party integration in Drupal 8! There also are plenty of add-on modules, helpful development kits for third-party frameworks, etc.

Going global with a multilingual site

Large business website development can also let you go global. Having a multilingual site means multiplying your audience and profits as well.

D8 has strong multilingual features that are among its “visiting cards.” To help you create a big website that speaks different languages, it offers an extremely easy setup, a hundred languages supported out-of-the-box, flexible options as to what website elements should be translatable, RTL support, and much more.

Multisite support

If you want to create a complex website, here is another idea that might be interesting. Large organizations and businesses often need more than one site but a collection of related sites that are easy to manage.

Drupal offers a multisite feature that allows you to run multiple sites from the same Drupal installation. They are created, managed, and updated from one place.

Powerful search even on complex sites

Large and complex sites especially need ways for users to quickly find things. Drupal allows you to create the most advanced search features.

They include faceted search, alternate spellings, content suggestions, result highlighting, search in attachments, multilingual and multisite search, and much more. This is thanks to such modules as Search API, Search API Solr Search, Elasticsearch Connector, Facets, etc.

The General Electric’s site:

General Electric site on Drupal

Easy content workflows

If your large business website is content-heavy, Drupal can save your editorial team’s time a lot. Drupal 8 has a user-friendly CKEditor for content publishing. The Media system provides for the easy media handling in Drupal 8 and enriching the content with various videos, audios, remote videos, etc.

There are strong built-in capabilities to have flexible editorial workflows thanks to the Content Moderation and Workflows modules. Another novelty for large websites is the Workspaces module that allows you to quickly deploy tons of content from a stage to a live environment.

Outrunning your competitors in SEO

Let your large business website be better found through search engines thanks to such a SEO-friendly CMS as Drupal.

It has plenty of built-in and add-on modules for SEO that take care of its every aspect. For example, SEO-friendly URLs (including automatic, pattern-based URL creation on large sites), keyword optimization, meta tags, XML sitemap, broken link fixing, and much more.

A high level of security

Cybercriminals never sleep and try to find vulnerabilities in sites that they could exploit for malicious purposes. A large business website faces more risks than smaller ones because it has more to lose.

When it comes to security, Drupal has a very good reputation. It stands against the most critical security vulnerabilities of the web. This is thanks to the vigilant security team, strong coding standards, a watchful community, a flexible system of site roles and permissions, and more. Here is why governments trust Drupal a lot in different countries of the world.

The Pfizer’s site:

Pfizer site on Drupal

High website speed

Create a big website that loads fast — it’s easy with Drupal. D8 uses flexible approaches to caching and has robust built-in caching modules. One of them is the BigPipe that loads the unchanged parts of the page instantly to not keep your users waiting.

There are also plenty of add-on performance modules to speed up Drupal sites. Finally, it’s a hot trend to combine Drupal 8 with JavaScript frameworks like React, Vue, or Angular to rich exceptional speed and interactivity.

Hire experts to create a large business website

We have outlined the key reasons why choose Drupal for a big website. Let’s discuss more details in a conversation. Entrust your large business website development to our professional Drupal team and let your large site help your large business flourish!

Jan 10 2020
Jan 10

Drupal 8 and higher provide a continuous upgrade path with a deprecation policy that requires old APIs to be marked deprecated and retained until the next major version. Drupal 8.8 was the final release to introduce new deprecations that will be removed in Drupal 9. This means that all new deprecations in 8.9 and higher will be retained in Drupal 9 and marked for removal in Drupal 10 instead.

For now, in order to continue work on issues that add new deprecations without causing disruption and noise for Drupal 9 readiness tools that detect deprecations, issues with new deprecations for Drupal 10 should be moved to the 9.1.x branch.

9.1.x is not yet open for development and so patches will not apply to it, but work can continue on these patches in the meanwhile by testing them against 9.0.x instead when the patch is uploaded:

The 'Test with' select field on Drupal.org issue file uploads

We may change our policy in the future and allow 10.0.x deprecations to be backported to 8.9.x and 9.0.x in certain cases (discussion in issue #3088246). Otherwise, 9.1.x will open for development in either March or April, depending on progress on Drupal 9 release blockers.

Jan 10 2020
Jan 10

Migrating content from an existing site or an external data source can help reduce the effort required by content editors to get a new site ready for launch. As a result, constructing and executing content migrations is a common task we undertake as part of the site build process. While these migrations can vary in type, typically spreadsheets are exported in a comma separated value (CSV) format due to their simplicity.

While Drupal has robust support for migrating in from a CSV file, the current structure can struggle when presented with large CSV files. In particular, the migration import process can run out of memory part way through the migration process. We encountered this problem while migrating tens of thousands of locations for a client. Increasing the PHP memory limit for the migration was an initial step, but proved not to be enough:

Memory usage is 1.21 GB (80% of limit 1.51 GB), reclaiming memory.


Memory usage is now 1.21 GB (80% of limit 1.51 GB), not enough reclaimed, starting new batch

Even though the migration module attempts to reclaim memory and start a new batch, the process does not always complete.

Some approaches to get around this issue include scripting your migration and utilizing the limit option when running a migration. However, we wanted a solution that could be more versatile and wouldn’t require custom scripting for each new migration we would write.

As a result, we wrote a custom Drush command that acts as a wrapper around the default Migrate import command. Our custom command splits a large CSV file into smaller files that can be imported in batches.

As an example, the following command may be run:

drush migrate:import:batch sample_migration --batch-size=100

When the migration is run, the CSV source file for the sample_migration is split into smaller CSV files with 100 lines each. The migration runs for each of these files. These files are temporarily stored in the private files directory and are cleaned up after the migration is finished.

Other migration operations run like normal and all of the default options may be passed in. Migration mapping hashes are maintained, so the migration may be rolled back like normal, too.

The module’s code currently exists in a Github repository which also contains more information on the module’s usage, but we plan on releasing it as a contributed module on Drupal.org in the future. Feel free to give it a try on your project and let us know how it works for you!

Fall migration copy by ashokboghani licensed under CC BY-NC 2.0.

Jan 10 2020
Jan 10

If you're currently running a Drupal 8 site and are interested in upgrading to Drupal 9 when it is released in the summer of 2020, the first step is to update to the recently-released Drupal 8.8. Drupal 8.8 contains both the deprecated APIs and the new APIs that will become standard in Drupal 9, so once your site is on 8.8, you can begin to review your contrib modules and update your custom code to move from deprecated APIs to the state of the art. No new features will be added in the 9.0 release, which means that 8.8 has feature parity to streamline the upgrade path between 8.x and 9.x.

The update to 8.8 is more involved than previous Drupal 8 point releases because 8.8 renames some configuration variables and changes the core drupal packages and dependency structure in composer.json, which means that updates need to be made to both settings.php and composer.json.

At Palantir, our team maintains many Drupal 8 sites in both active development and support, and we've documented some important tips that are important to keep in mind when updating your site to 8.8. We also want to give a shout-out to the folks at PreviousNext for their post on what they learned when updating to the 8.8 beta release.

Update process overview

  1. Contrib module conflicts: If your site is using the contrib modules Pathauto, Workspace, or Coder, update those first.
  2. Update settings.php: Change the temp and config sync directory variables settings.php
  3. Update composer.json: Manually update your composer.json
  4. Run the Drupal database updates
  5. Export changed config

Contrib module conflicts


We use the Pathauto module on all of the sites we build, and Pathauto needs some handholding in this update process. If you don't update Pathauto while you're still on Drupal core 8.7, you could lose your path alias data!

  1. While your site is still running Drupal 8.7, update Pathauto to the latest release (8.x-1.6):
    composer require drupal/pathauto:^1.6
  2. Deploy the updated code
  3. Run the database updates:
    drush updatedb
  4. Begin your Drupal 8.8 update

Workspace isn't common on our sites, so running into an issue with it usually means doing some research. The contrib Workspace module has been moved into core, and renamed "Workspaces"; installing both modules on the same site creates code-level conflicts. Additionally, the Drupal 8.8 release introduces an incompatibility between core Content Moderation module and the contrib Workspace module.

As of December 2019, there is no ready-made upgrade path from the contrib module to the core module; the recommendation is to uninstall the contrib module -- which will delete all workspace content that is not yet live -- and then install core's module (documentation).


If you're using Coder to do automated code review against the Drupal coding standards, you may need to update. Drupal 8.8 requires a minimum of version 8.3.2.

  1. Check your coder version:
    composer show drupal/coder
  2. You'll see the package information with the version -- in this case, 8.2.10:
    [ 3:15P ~/repos/example] (develop) $ composer show drupal/coder
    name : drupal/coder
    descrip. : Coder is a library to review Drupal code.
    keywords : code review, phpcs, standards
    versions : * 8.2.10
    type : library
  3. Update the package:
    composer require drupal/coder:^8.3.2

Updating settings.php

First, find your settings.php file; this will be within your Drupal site at sites/default/settings.php, or may be an include file named like sites/default/settings.*.php.

Config sync directory

The config sync directory is where Drupal stores your exported configuration YAML files. Before Drupal 8.8, you could configure multiple directories for exporting config; now there's only one, and the variable name has changed.

Check settings.php files for the $config_directories variable:

$config_directories = [];
$config_directories[CONFIG_SYNC_DIRECTORY] = '../config/sites/default';

Replace this (using your original path) with:

$settings['config_sync_directory'] = '../config/sites/default';
More information
Temporary (temp) directory

The temp directory is usually specific to your host or the environment where your Drupal site is running, so you may need to set this differently for production vs. local development.

Check your settings.php files for the temp directory configuration:

$config['system.file']['path']['temporary'] = $_ENV['TEMP'];

Replace this (using your environment-specific path) with:

$settings['file_temp_path'] = $_ENV['TEMP'];
More information

Update composer.json

Drupal 8.8 introduced scaffolding in core and separated dev dependencies into a separate package. The scaffolding manages core files like index.php and .htaccess, which are required for Drupal to run but don't live within the core/ directory. You might already be using drupal-composer/drupal-scaffold for this purpose, which will need to be replaced.

Because these changes involve replacing existing packages and updating composer plugin configuration, they need to be manually applied to your composer.json.

Use the drupal/core-composer-scaffold package

Edit your composer.json and to the require section, add:

        "drupal/core-composer-scaffold": "^8.8",

This should replace the drupal-composer/drupal-scaffold package, if you were using it.

This is a composer plugin, and needs to be configured in the extra section of your composer.json. Add or update the drupal-scaffold configuration:

        "drupal-scaffold": {
"locations": {
"web-root": "web/"
"allowed-packages": [
"file-mapping": {
"[web-root]/.htaccess": {
"mode": "replace",
"path": "web/core/assets/scaffold/files/htaccess",
"overwrite": false

Double check the web-root location and change web/ if necessary -- for example, if you're hosting on Acquia, set this to docroot/.

Also check the file-mapping section and make sure the value for path is correct. This file-mapping configuration will prevent your .htaccess file from being overwritten if you've customized it, but can be left out otherwise.

More information

This will install your core Drupal requirements.

Edit your composer.json and in the require section, replace the drupal/core package with:

        "drupal/core-recommended": "^8.8",
Add the new drupal/core-dev package to your Composer dev requirements

This will install optional, development-specific core dependencies so that you can run things like automated testing.

Edit your composer.json and to the dev section, add:

        "drupal/core-dev": "^8.8",

This should replace the webflo/drupal-core-require-dev package, if you were using it.

More information
Finally, run Composer

Now that you've updated your composer.json file, run Composer to update your packages. In order to update only the packages you've changed (and not every package all at once), run:

composer update --lock
Troubleshooting Composer

After making these changes to your composer.json, you may see the following error when you run composer install or composer update:

Installation failed, reverting ./composer.json to its original content.
Could not delete /srv/users/serverpilot/apps/sandbox/drupal/web/sites/default/default.services.yml:

This happens because the scaffolder (which runs on composer install and update) is trying to write files to your sites/default/ directory, but doesn't have the permissions. You can resolve this with:

chmod +w web/sites/default

See Troubleshooting: Permission issues prevent running Composer for more details.

Running the update scripts

Finally, you'll need to do the normal Drupal update process: run the database exports, and export any config changes:

drush updatedb
drush config:export
Troubleshooting the database updates

If you're testing the database updates multiple times on the same environment, you may run into this error:

[error] Update failed: system_update_8804

This happens because system_update_8804 creates new database tables. If you are using drush sql-sync to test and re-test the update against a copy of the production database, you'll need to clear your local database with drush sql-drop first, in order to delete tables created by a previous run.

What next?

Once your site has been updated to Drupal 8.8, you'll be in good shape for the upgrade to Drupal 9, which is currently anticipated on or around June 3, 2020. Between now and then, we'll be working alongside other Drupal contributors to make sure that key contributed modules are ready for Drupal 9, as well helping our clients make sure that custom code and modules on their sites are free of deprecated APIs. Stay tuned for more!

Jan 10 2020
Jan 10

Developers and webmasters who oversee websites with millions of users need to provide a solution to keep their infrastructure from getting overloaded with requests. Scaling up web and database servers is one option, but it can be costly and inefficient. Instead, people have increasingly turned to a Content Delivery Network, or CDN, as a type of protective layer in front of their web and database servers.

What does a CDN do?

The CDN provides a cached layer of content close to the user, often referred to as “the edge.” When a user requests a homepage, for example, they are directed to the cached static version of that page on the CDN rather than overloading the web server or accessing the database, thereby scaling content delivery.

scaled content deliverIllustrating scaled content deliver supporting millions of requests while only passing on a small percentage of those requests to a web server, which in turn makes even fewer requests to a database server.

The CDN serves static content. So, what happens when web content is updated? There are a few different options here:

  • The cache can be programmed to expire after a certain number of hours or days.
  • Cache entries can be proactively purged when updates are made.
  • Changes to individual page content can be fetched as each page is requested by a user.

More problematic, however, are the changes that affect each and every page. For example, a global banner or a menu often changes the header or footer. This is where our recent work with Edge Side Includes comes in.

Edge Side Includes

Edge Side Includes (ESI) is both a web standard and an XML-based language that enables the dynamic generation of HTML pages at “the edge”. We recently worked with one client to solve the problem: How can we enable our cached content to remain fresh even after we make updates to some of the global parts?

We used Drupal to solve this problem by generating and rendering this global content as ESI fragments. These ESI fragments could then be included by all of our client’s web properties by using ESI include statements, regardless of how they were built.

Pseudocode of static markupIllustrating pseudocode of static markup on a web page, where each web page must include that markup and therefore each page must be retrieved from cache, the web server, and may require a shorter cached lifetime.Pseudocode of ESI includesIllustrating pseudocode of ESI includes and their corresponding ESI fragments indicating that now each web page may be able to have a longer cache lifetime since the ESI fragments are referenced and can have their own cache lifetime.

How ESI Works

For our client, we developed a way to render ESI fragments in Drupal that included page parts (specifically the header and footer) on non-Drupal sites so that when those page parts change in Drupal, the non-Drupal sites get those changes automatically. To accomplish this, at the cache layer we have all of these pages that have unique page content and then the same content on each page for including the header and the footer.

Using ESI fragments, if a request is made for a page, the first thing that happens is a request for the header content, and then for the cached footer content. Now if something in the header is changed, only one page needs to be updated.

Drupal and Edge Side Includes

The use case that we solved here was specifically for the header and the footer, but our client wanted to have similar branding across all of their web properties, and they wanted it to be governed by the content management that's done with Drupal. Drupal can do this by rendering the actual ESI fragments at two different endpoints.

Our custom module defines two routes, one for the header and one for the footer. Our controller maps to both of those routes and returns an empty render. Then, in the dot module files, we made sure that we're only including the sort of meta tags that we need and the libraries that we want. In our theme, we have special templates for the ESI fragments. We also made sure that we leveraged some of the core functionality by still going through the render API.

We're rendering blocks, we're rendering menus, we're using libraries, and we're respecting cache tags.

Breakdown of responsibilitiesIllustrating the breakdown of responsibilities between Drupal modules (route definition, controller creation, page attachment alters), themes (templates, library definition), and core (render process for various entities, libraries, and cache api).

Our client developed page templates that use business logic to set whatever variables might be needed to deliver their page content, adding our ESI include statements to actually grab the header and the footer content. They’re hosting all of their non-Drupal pages on a server that will provide this ESI service. Our client also determines the cache lifetime, both for their page templates and for the ESI fragments that Drupal's actually hosting.

Breakdown of responsibilities for ESI implementersIllustrating the breakdown of responsibilities for ESI implementers/consumers (business logic, variables parameters for fragments, page templates with variables and includes) and service providers (cache lifetime configuration, ESI fragment routes, ESI service / hosting).

Personalization Through ESI

So, what’s next for Drupal and ESI? Another implementation that we're using in Drupal with ESI is a content model where a URL can reference internal or external endpoints and then include content from a URL that references static assets. This is CSS that we can include for personalization. This will allow us to do things like get data from Google tag manager or from Marketo or Mailchimp or a similar platform and make some decisions about the route, which could be a view page. Then, we could dynamically write the ESI include source based on the content they want to render personalized. We’ll let you know as we progress!

Jan 10 2020
Jan 10

Integrating With Key Systems

One of the overall goals when embarking on this redesign was to create an experience that mimicked the streamlined usability of an ecommerce site. HonorHealth wanted to create a place where patients could easily make choices about their care and schedule appointments with minimal effort. In order to provide this experience, it was imperative that the new platform could play well with HonorHealth’s external services and created a firm foundation to integrate more self-service tools in the future.

In particular, Palantir integrated with three services as part of the build: SymphonyRM, Docscores, and Clockwise.

  • SymphonyRM offers a rich set of data served by a dynamic API. HonorHealth leverages SymphonyRM’s Provider Operations services to hold its practice location and physician data. Palantir worked closely with Symphony to help define the data structure. Through this work, HonorHealth was able to reduce the number of steps and people required to maintain their provider and location data. By leveraging the strategy work done and the technical consultation of Palantir’s Technical Architecture Owner, HonorHealth was able to keep focused on the most valuable content to their users throughout all of their integrated systems.
  • Docscores provides a platform for gathering high-quality ratings and review data on healthcare practitioners and locations. Palantir integrated this data directly with the physician and location data provided from SymphonyRM to create a research and discovery tool for HonorHealth users. On the new HonorHealth website, users can find physicians near a specific location and read about other patients’ experiences with them.
  • Clockwise provides real-time wait estimates for people looking for Urgent Care services in their area. Each of these individual “under the hood” integrations don’t represent a significant shift for website users, but when all of these changes are coupled with the intense focus on putting the user experience of the site first, the result speaks for itself: a beautiful website that works well and empowers people to engage in their ongoing healthcare in meaningful ways.

Each of these individual “under the hood” integrations don’t represent a significant shift for website users, but when all of these changes are coupled with the intense focus on putting the user experience of the site first, the result speaks for itself: a beautiful website that works well and empowers people to engage in their ongoing healthcare in meaningful ways.

Jan 10 2020
Jan 10

A few weeks ago, I earned my first ever Drupal contribution credit for my DrupalCamp Colorado keynote. While I am oddly excited about that, I also find it somewhat ironic, as that keynote should not be mistaken for my first contribution to Drupal.

According to my Drupal.org profile, I’ve been a community member for over twelve years. In that time, I’ve presented keynotes for three other DrupalCamps, presented sessions and participated in panels going back to DrupalCon Boston 2008, led the RFP process for the redesign of Drupal.org, chaired DrupalCon Chicago 2011, served on the board of the Drupal Association for nine years and, most recently, served on the Executive Director Search committee. That is but a partial tally of my individual contributions; of course my company, Palantir.net, has also made considerable contributions of time, talent, and treasure over all these years.

Recognition is not my motivation for these efforts; like so many open source contributors, I give back to Drupal because I am committed to stepping up when I see a need or an opportunity. When I was new to the community, the karma earned from such efforts, code and non-code, was informally held in the living memory of those who were there. I always felt that I had earned the credibility and support of those with whom I collaborated closely to move on to the next opportunity, to tackle and solve the next problem. In many ways, as a woman on/of the internet, I appreciated the relative anonymity of it.

In that way, Drupal has become the largest independent community-driven open source project. And many of us believed that our collective success and the impact we made was enough to sustain the virtuous cycle of open source. But was it?

Open source has won: we now have legions of people and companies who rely on Drupal and other open source tools and products; however, these companies picked the best tool, which just happened to be an open source tool, and they don’t necessarily yet know the open source way. Twelve years ago, the Drupal community was small enough that those established norms and expectations were passed on person-to-person, along with the lore and the legends. The old ways of influencing behavior and enforcing norms through social bonds (aka peer pressure) aren’t strong or explicit enough for the swells of newcomers.

There is a lack of shared understanding, visibility, and support for what it takes to not just keep Drupal sustainable, but to have it thrive and win in a competitive landscape. This lack of clarity has led to the emergence of multiple subcultures within the commercial ecosystem and a worrying disparity between those who benefit the most from Drupal versus those who give the most.

In his Amsterdam 2014 keynote, Dries noted that while open source has a long history of credit (for code) to the individual contributors, this does not adequately recognize (or incentivize) the organizations. He proposed a simple way to give organizations credit in addition to individual credits for the core issues their teams either performed directly or sponsored, which the Drupal Association released in late 2015. Over time, this system has been expanded to capture more than just code contributions.

And yet, the contribution credit system has not wholly replaced karma. As my own experience shows, so much of the vital work that Drupal relies on is not yet captured in credits. Due to my privilege (not looking for a job, having well-established connections in the community, etc.), the lack of visibility was a feature, not a bug, for me as an individual contributor.

However, wearing my Palantir CEO hat I’ve come to realize that the failure to capture fully what and how companies do (and are expected to) contribute is far more problematic for the sustainability of the project. Some of the most essential work in the community (Drupal Association Board of Directors, the Community Working Group (CWG), the Security Team and non-code Core team work including release management, communication, sprint organizing, and overall project and initiative coordination) is severely undervalued or all-in-all ignored by the contribution system. George DeMet's ongoing commitments as the chair of the CWG often average anywhere from ¼ - ½ of his time (more at intense times) and over the last year he received four credits (the other members of the CWG received even less!). The community and the project suffer because this invisibility obscures, and indeed over time deteriorates, the community expectations and norms by measuring what is easy to measure, rather than what matters.

When Drupal 7 was released, the firms that built Drupal enjoyed a competitive advantage: those who wanted to use Drupal knew which firms meaningfully contributed and why it mattered. However, over the last five years, the Drupal ecosystem has expanded to include many new, larger firms that leveraged partnership and sponsorship programs to establish their Drupal credentials.

These programs and the new implementers and agencies they ushered into the Drupal community are essential to Drupal’s growth and adoption. They are a welcome addition to the ecosystem. However, there are serious problems with the ways that these programs have been structured to date and their unintended impact on our culture of contribution:

  • Status within these programs is primarily pay-to-play and non-financial contributions to the project are not required.
  • The programs do not directly support or indirectly incentivize the time or talent contributions on which the Drupal project depends.
  • The financial proceeds of such programs benefit infrastructure initiatives (Drupal.org and more broadly the Association) and market visibility, which are not necessarily the areas of greatest need for the project or community.
  • These programs have undermined the reputational system that prioritized successful outcomes (successful client implementations AND contributions back to the project) and replaced it with one that favored outputs (financial success and client list).

Allowing companies to position themselves as leading experts in Drupal without validation that these firms are contributing commensurate with the benefits derived from Drupal has been corrosive to the sustainability of the project. This has tacitly supported the commoditization of Drupal services, devalued the competitive advantage received from direct contribution, and simultaneously incentivized and conditioned all in the ecosystem to increase indirect contribution (sponsorship and advertising on Drupal.org and events including DrupalCon).

As I noted on a panel at OSCON, I see all of this as a success problem. Having more companies, including large scale implementers and agencies, working with Drupal is a good and necessary thing. What we need to improve is the way that we onboard, recognize, and differentiate those who help sustain and innovate Drupal to (re)establish a culture of contribution for Drupal. Doing this well will involve creating new and easy-to-access avenues for contribution that match the project’s weighted needs and companies’ available resources (be they time, talent or treasure). A concerted focus on what matters will shore up Drupal’s path to long-term sustainability.

Jan 10 2020
Jan 10

Palantir was excited to return to Denver as a sponsor for DrupalCamp Colorado 2019!

Keynote: Learning @ Work

Our CEO, Tiffany Farriss, discussed the role of organizational culture and open source projects like Drupal in the success of tech companies. 

Have you ever stared at your backlog and gone cross-eyed? You have a hundred well-defined tickets, all placed in their sprints or waiting for their chance to be slated for work. Your team is resourced. You have an idea of the feature you’re cranking out next. But does it ever feel like your backlog is a monster to-do list instead of a map of where you’re going? How do you keep a 10,000-ft view of the thing you’re building when you’re heads down in your user stories?

User Story Mapping (pioneered by Jeff Patton) is not a new concept, but it will transform the way you approach Drupal projects. Senior Web Strategist and UX Architect, Jill Farley, presented a session on how to structure an initial map-building workshop.

Jan 10 2020
Jan 10

Identifying “Top Tasks”

The biggest negative factor of the previous ETF site’s user experience was its confusing menus. The site presented too many options and pathways for people to find information such as which health insurance plan they belong to or how to apply for retirement benefits, and the pathways often led to different pages about the same topic. Frequently, people would give up or call customer support, which is only open during typical business hours.

Palantir knew the redesign would have the most impact if the site was restructured to fit the needs of ETF’s customers. In order to guarantee we were addressing customers’ most important needs, we used the Top Task Identification methodology developed by customer experience researcher and advocate Gerry McGovern.

Through the use of this method, we organized ETF’s content by the tasks site users deemed most important, with multiple paths to get to content through their homepage, site and organic search, and related content.

Jan 10 2020
Jan 10

Open source looks very different now compared to 20 years ago, and with such a vast community of developers, it is difficult to define the exact role of a “good” open source citizen.

Palantir is thrilled to have participated in Keeping Open Source Open, a spirited discussion on open source strategy and the future of open source including CEO Tiffany Farriss as well as Zaheda Bhorat (Amazon Web Services) and Matt Asay (Adobe).

Jan 10 2020
Jan 10

Design System artifacts go by many names - Living Style Guides, Pattern Libraries, UI Libraries, and just plain Design Systems. The core idea is to give digital teams greater flexibility and control over their website. Instead of having to decide exactly what all pages should look like in one big redesign and then sticking with those templates until the next redesign, a design system gives you a “lego box” of components the team can use to create consistent, beautiful interfaces. Component-based design is how you SCALE.

At Palantir we build content management systems, so we’ve named our design system artifact a “style guide” in a nod to the editorial space.

Our style guides are organized into three sections:

  1. 'Design Elements' which are the very basic building blocks for the website.
  2. 'Components' which combine design elements into working pieces of code that serve a defined purpose.
  3. 'Page Templates' which combine the elements and components into page templates that are used to display the content at destination URLs.

But how do we help our clients determine what the list of elements, components and page templates should be?

How to Identify Elements for Your Design System

In this post I’ll walk through how we worked with the University of Miami Health System to create a style guide that enabled the marketing team to build a consistent, branded experience for a system with 1,200 doctors and scientists, three primary locations, and multiple local clinics.

1. Start by generating a list of your most important types of content.

Why are people coming to your site? What content helps them complete the task they are there to do? This content list is ground zero for component ideation: how can design support and elevate the information your site delivers?

Table of content types

The list of content serving user needs is your starting point for components. In addition, we can use this list to identify a few page templates right off the bat:

  • Home page
  • Treatment landing page
  • Search page
  • Listing page: Search results, news, classes
  • Clinical trials landing page
  • Clinical trial detail page
  • Location landing page
  • Appointment landing page
  • Appointment detail page
  • Basic page (About us, contact us, general information)

This is just the start of the UHealth style guide; we ultimately created about 80 components and 17 page templates. But it gives you a sense of how we tackled the challenge!

2. Sort your list of important types of content into groups by similarities.

Visitors should be able to scan your website for the information they need, and distinctive component designs help them differentiate content without having to read every word. In addition, being rigorous about consistently using components for specific kinds of information creates predictable interfaces, and predictable interfaces are easy for your visitors to use.

In this step, you should audit the design and photo assets you have available now, and assess your capacity to create them going forward. If, for example, you have a limited photo library and no graphic artist on staff, you’ll want to choose a set of components that don’t heavily rely on photos and graphics.

Component example for UHealth site

In this example, we have three component types: News, Events/Classes, and a Simple Success story.

  1. News Component: This component has no images. This is largely about content management; UHealth publishes a lot of news, and they didn’t want to create a bottleneck in their publishing schedule by requiring each story to have a digital-ready photo.
  2. Events/Classes Component: This component has an option for images or a pattern. Because UHealth wants visitors to take action on this content by signing up, we wanted these to have an eye-catching image. Requiring a photo introduces a potential bottleneck in publishing, so we also gave them the option to make the image a pattern or graphic.
  3. Simple success story: This is the most visually complex component because successful health narratives are an important element of UHealth’s content strategy. We were able to create a complex component here because there’s a smaller number of success stories compared to news stories or classes and events. That means the marketing team can dedicate significant time and resources to making the content for this component as effective as possible.

3. Now that you’ve sorted your list by content, do a cross-check for functionality.

Unlike paper publications, websites are built to enable actions like searching, subscribing, and making appointments. Your component set should include interfaces for your functionality.

Some simple and common functions for the UHealth site included searching for a treatment by letter, map blocks, and step forms.

In a more complex example, the Sylvester Cancer Center included a dynamic “Find a lab” functionality that was powered by a database. We designed the template around the limitations of the data set powering the feature, rather than ideating the ideal interface. Search is another feature that benefits from planning during the design phase.

For example, these components for a side bar location search and a full screen location search require carefully structured databases to support them. The design and technical teams must be in alignment on the capacity and limits of the functionality underlying the interface.

4. Differentiate components by brand.

UHealth is an enormous health care system, and there are several centers of excellence within the system that have their own logos and distinct content strategies. As a result, we created several components that were differentiated by brand.

UHealth navigation bars

In this example, you see navigation interfaces that are different by brand and language. Incorporating the differentiated logos for the core UHealth system and the Centers of Excellence is fairly straightforward. But as you can see the Sylvester Center also has three additional top nav options: Cancer treatments, Research, and For Healthcare Professionals.

That content change necessitated a different nav bar - you can see that it’s longer. We also created a component for the nav in Spanish, because sometimes in other languages you find that the menu labels are different lengths and need to be adjusted for. In this case, they didn’t, but we kept it as a reference for the site builders.

5. Review the list: can you combine any components?

Your overall goal should be creating the smallest possible set of components. Depending on the complexity and variety of your content and functionality, this might be a set of 100 components or it might be just 20. The UHealth Design System has about 80 components, and another 17 page templates.

The key is that each of the components does a specific job and is visually differentiated from components that do different jobs. You want clear visual differences that signal clear content differences to your audience, and you don’t want your web team spending time trying to parse minor differences - that’s not how you scale!

In my experience, the biggest stumbling block to creating a streamlined list of components is stakeholders asking for maximum flexibility and control. I’ve found the best way to manage this challenge is to provide stakeholders with the option to differentiate their fiefdoms through content rather than components.

UHealth component examples

In this example, we have the exact same component featuring different images, which allows for two widely different experiences. You can also enable minor differentiation within a component: maybe you can leave off a sub-head, or allow for two buttons instead of one.

6. Start building your design system and stay flexible.

The list you generated here will get you 80% of the way there, but as you proceed with designing and building your design system, you will almost certainly uncover new component needs. When you do, first double-check that you can’t use an existing component. This can be a little tricky, because of course content can essentially be displayed any way you want.

At Palantir, we solve for this challenge by building our Style Guide components with real content. This approach solves for a few key challenges with building a design system:

  1. Showing the “why” of a component. Each component is designed for a specific type of content - news, classes, header, testimonial, directory, etc. This consistency is critical for scaling design: the goal is to create consistent interfaces to create ease of use for your visitors. By building our Style Guides with real content, we document the thought process behind creating a specific component.
  2. Consistency. Digital teams change and grow. We use content in our Style Guide to show your digital team how each component should be used, even if they weren’t a part of the original design process.
  3. Capturing User Testing. Some of our components, like menus, are heavily user-tested to ensure that we’re creating intuitive interfaces. By building the components with the tested content in place, we’re capturing that research and ensuring it goes forward in the design.
  4. Identifying gaps. If you’ve got a piece of content or functionality that you think needs a new component, you can check your assumptions against the Style Guide. Does the content you’re working with actually fit within an existing pattern, or is it really new? If it is, add it to the project backlog!


The most important takeaway here is that design systems let your web team scale. Through the use of design systems, your digital team can generate gorgeous, consistent and branded pages as new needs arise.

But don’t take our word for it! Tauffyt Aguilar, the Executive Director of Digital Solutions for Miller School of Medicine and UHealth, describes the impact of their new design system:

“One of the major improvements is Marketing’s ability to maintain and grow their site moving forward. Previously each page was designed and developed individually. The ability to create or edit pages using various elements and components of the Design System is a significant improvement in the turnaround time and efficiency for the Marketing department.”

My favorite example of a new page constructed with the UHealth design system is this gorgeous interface for the Sports Medicine Institute.

Sports Medicine homepage

The Sports Medicine audience has unique needs and interests: they are professional and amateur athletes who need to get back in the game. The UHealth team used basic components plus an attention-grabbing image to create this interface for finding experts by issue.

And ultimately, that’s Palantir’s goal: your digital team should have the tools to create gorgeous, effective websites.

Jan 10 2020
Jan 10

Palantir recently partnered with a patient engagement solutions company that specializes in delivering patient and physician education to deliver improved health outcomes and an enhanced patient experience. They have an extensive library of patient education content that they use to build education playlists which are delivered to more than 51,000 physician offices, 1,000 hospitals, and 140,000 healthcare providers - and they are still growing.

The company is in the process of completely overhauling their technical stack so that they can rapidly scale up the number of products they use to deliver their patient education library. Currently, every piece of content needs to be entered separately for each product it can be delivered on, which forces the content teams to work in silos. In addition, because they use a dozen different taxonomies and doing so correctly requires a high level of context and nuance, any tagging of content can only be done at the manager level or above. The company partnered with Palantir.net to remove these bottlenecks and plan for future scalability.

Jan 10 2020
Jan 10

The new, stable version 2.0 of Droopler – Droptica’s Drupal-powered distro is coming soon, offering numerous new features aimed primarily at corporate websites. 

You can already test the new release at demo.droopler.com, you can also install the latest beta version, which is available at drupal.org and github.com

Below, you can find a selection of the most important changes.

New demo

Let’s start with the most notable and striking change, which can be seen right after setting Droopler up. The new demo presenting Droopler’s features is now much more extensive and provides an excellent foundation for you to build your own website. It contains subpages, as well as a full demonstration of the new menu and the footer. You should also take a look at the mobile version of the menu.

New Droopler demo

Media and Media Library

2019 brought a very important new feature in Drupal – its version 8.8 introduced the stable Media Library module for managing multimedia on a website, and Droopler 2.0 takes full advantage of its capabilities. We got rid of the previous way of adding photos to paragraphs, which was deemed inconvenient and inflexible. Now, you can add all the media on the website using a special library with reusable elements. What is more, you are no longer limited to static images! Paragraphs can now be illustrated in the background with Vimeo and YouTube videos. Droopler 1.4 users can take advantage of the full migration path to version 2.0, which encompasses converting the “image” type fields to the new solution.

Droopler media library


Version 2.0 brings totally new and more dynamic colour schemes. Of course, if you want, you can stick to the existing colours. Various shades of blue were replaced with deep red, which is better suited to corporate websites. We decided to change both the backgrounds and small accents.

SEO and website performance

We made every effort to ensure that websites powered by Droopler rank as high as possible in search engines. We focused on optimising page loading speed according to Google Page Speed, we also improved accessibility standards. From now on, content editors can have an impact on SEO by changing types of paragraph headings (H1 through H5).

Choosing header type in Droopler

Mega Menu

Droopler 2.0 features a brand-new menu, similar to the features you can find on large corporate websites. You can configure each submenu to be displayed in columns, with graphic elements and different sets of links. The menu is fully compatible with mobile devices. In addition, we introduced another feature, allowing you to use a second menu with less important links. Easily configured social media icons are another important new feature.

MegaMenu in Droopler

New footer

We redesigned the footer – it is now divided into several areas and uses a column model. This approach makes it easier to create pages for large clients, who need it to fit several addresses and key links at the bottom of each page.

New footer in Droopler

Paragraph settings

You are now able to change paragraph settings in Droopler. Using a couple of checkboxes, you can now invert their colours or stretch them to the entire width of the page. Styling individual paragraphs was also made much easier than before. Before, you had to reference them in CSS stylesheets using less-than-convenient IDs. From now on, every paragraph on your website will be able to have its own class, assigned from the editing form.

Paragraph settings in Droopler

“Reference Content” paragraph

To date, Droopler offered no way to show users the list of the latest blog articles on a single subpage. The new “Reference Content” paragraph adds this feature – and makes it amazingly flexible, since it allows you to change its display settings and select articles, which will remain pinned. The remaining spaces will be filled with articles sorted in descending order, according to the publication date, allowing you to display, for example, two sponsored posts and two latest news posts.

New blog paragraph in Droopler

“Side by Side” paragraph

Ever since we started working on our distro, we paid close attention to the needs and behaviours of the users, which is why the subsequent Droopler releases included a variety of useful paragraphs, which divided the page into two columns, enabling users to add text, photos, maps, videos and galleries. However, there were some restrictions, which prevented them from using any combination of these types of content. Droopler 2.0 gets rid of these obstacles by introducing the universal “Side by Side” paragraph. Each of its columns can contain independent elements – as of now, the choices include text with a graphic background and a reference to an entity, for example a product.

New Side by Side paragraph in Droopler


We squashed hundreds of bugs, including those reported by users on GitHub and drupal.org, which allowed us to build an even cleaner and more stable codebase, developed according to the latest standards. Many of Droptica’s frontend and backend experts worked on the 2.0 release, and the project repository saw more than 1000 new commits and 180 pull requests. We have improved adding content, in particular the integration with the Geysir module.

Updated libraries and drupal.org compatibility

Until recently, Droopler’s architecture was not fully compatible with a slightly outdated distribution building system on drupal.org, which – in some rare cases – led to conflicts and errors when updating the websites. We managed to overcome these issues for the 2.0 release. What is more, we already started working on adapting Droopler to make sure that it is compatible with the upcoming Drupal 9. In addition, we eliminated various bugs, which popped up in connection with various latest Drupal 8 features. All these improvements will lead to greater security and long-term support for your websites.


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