20 years ago, the Drupal project started in a dorm room—today it is a billion dollar industry.

PORTLAND, Ore., U.S.A and LOCAL AREA HERE, January 15, 2021—Drupal, the world’s leading open source digital experience platform (DXP), celebrates 20 years of community-driven innovation. Since its founding 20 years ago, Drupal has touched millions of lives. One in 30 sites on the web is powered by Drupal, and that means most users of the web have experienced Drupal—even if they don't know it. 

Drupal has pioneered the evolution of content delivery across multiple channels. Whether powering conversational user interfaces (CUI) for smart devices, pushing content to digital signage for New York Metropolitan Transportation Authority (MTA), or serving as the core content store for augmented reality experiences, Drupal’s sophisticated architecture and platform stand ready for the future of digital content. 

Redefining digital experiences

7 years ago—on the eve of Drupal's birthday—Drupal founder and project lead, Dries Buytaert, laid out his belief that the web was entering a new era. 

Mobile had transformed the web, but I believed this was just the beginning. The mobile web was the first example of a new web defined by digital experiences that conform to a user's context and devices,” says Buytaert. “Since then, Drupal has defined itself as the leading platform for ambitious digital experiences, and as channels and devices proliferate, Drupal will continue to lead the open source DXP market.

Powered by a global community of innovation

As part of this 20 year milestone, we celebrate our community of more than 100,000 contributors who made Drupal what it is today,” says Heather Rocker, executive director of the Drupal Association. “Success at this scale is possible because the Drupal community exemplifies the values of open source and proves that innovation is sustained by healthy communities. One of our key goals at the Drupal Association is to convene the resources necessary for continued project innovation, and we do that through the collaboration of a global community that continues to grow year after year.

In fact, Drupal contribution increased by 13% in a year when many industries contracted due to the COVID-19 pandemic. Drupal's open source model has built a robust and thriving ecosystem of individual contributors, professional service providers, and end-user organizations that is well positioned to capitalize on the next 20 years of digital innovation. 

Drupal continues to evolve, serving needs around the globe and expanding into new markets.  Future-looking priorities include a continued positive impact on the Open Web, the cultivation of a diverse and inclusive open source community, and an increased focus on editorial experience and usability—to make the power of the Drupal digital experience platform even more accessible.  

2021 will be marked with year-long celebrations happening around the world with particular focus at DrupalCon in April. Related 20th birthday events can be found on social media through the hashtag #CelebrateDrupal and at CelebrateDrupal.org.  

About Drupal and the Drupal Association

Drupal is the open source digital experience platform utilized by millions of people and organizations around the world, made possible by a community of 100,000-plus contributors and enabling more than 1.3 million users on Drupal.org. The Drupal Association is the non-profit organization focused on accelerating Drupal, fostering the growth of the Drupal community, and supporting the Project’s vision to create a safe, secure, and open web for everyone.

 
###
 
For more information or interview requests contact Heather Rocker,  heather@association.drupal.org
 

On January 15, 2001, exactly 20 years ago, I released Drupal 1.0.0 into the world. I was a 22 years old, and just finished college. At the time, I had no idea that Drupal would someday power 1 in 35 websites, and impact so many people globally.

As with anything, there are things Drupal did right, and things we could have done differently. I recently spoke about this in my DrupalCon Europe 2020 keynote, but I'll summarize some thoughts here.

Why I'm still working on Drupal after 20 years Me, twenty years ago, in the dorm room where I started Drupal. I'd work on Drupal sitting in that chair.

I started Drupal to build something for myself. As Drupal grew, my "why", or reasons for working on Drupal, evolved. I began to care more about its impact on end users and even non-users of Drupal. Today, I care about everyone on the Open Web.

Optimizing for impact means creating software that works for everyone. In recent years, our community has prioritized accessibility for users with disabilities, and features like lazy loading of images that help users with slower internet connections. Drupal's priority is to continue to foster diversity and inclusion within our community so all voices are represented in building an Open Web.

Three birthday wishes for Drupal Me in 2004, giving my first ever Drupal presentation, wearing my first ever Drupal t-shirt.

Drupal's 20th birthday got me thinking about things I'm hoping for in the future. Here are a few of those birthday wishes.

Birthday wish 1: Never stop evolving

Only 7% of the world's population had internet access when I released Drupal 1 in 2001. Smartphones or the mobile web didn't exist. Many of the largest and most prominent internet companies were either startups (e.g. Google) or had not launched yet (e.g. Facebook, Twitter).

A list of technology events that came after Drupal, and that directly or indirectly impacted Drupal. To stay relevant, Drupal had to adjust to many of them.

Why has Drupal stayed relevant and thrived all these years?

First and foremost, we've been focused on a problem that existed 20 years ago, exists today, and will exist 20 years from now: people and organizations need to manage content. Working on a long-lasting problem certainly helps you stay relevant.

Second, we made Drupal easy to adopt (which is inherent to Open Source), and kept up with the ebbs and flows of technology trends (e.g. the mobile web, being API-first, supporting multiple channels of interaction, etc).

The great thing about Drupal is that we will never stop evolving and innovating.

Birthday wish 2: Continue our growing focus on ease-of-use

For the longest time I was focused on the technical purity of Drupal and neglected its user experience. My focus attracted more like-minded people. This resulted in Drupal's developer-heavy user experience, and poor usability for less technical people, such as content authors.

I wish I had spent more time thinking about the less technical end user from the start. Today, we've made the transition, and are much more focused on Drupal's ease-of-use, out-of-the-box experience, and more. We will continue to focus on this.

Birthday wish 3: Economic systems to sustain and scale Open Source

In the early years of the Open Source movement, commercial involvement was often frowned upon, or even banned. Today it's easy to see the positive impacts of sponsored contributions on Drupal's growth: two-thirds of all contributions come from Drupal's roughly 1,200 commercial contributors.

I believe we need to do more than just accept commercial involvement. We need to embrace it, encourage it, and promote it. As I've discussed before, we need to reward Makers to maximize contributions to Drupal. No Open Source community, Drupal included, does this really well today.

Why is that important?

In many ways, Open Source has won. Open Source provides better quality software, at a lower cost, without vendor lock-in. Drupal has helped Open Source win.

That said, scaling and sustaining Open Source projects remains hard. If we want to create Open Source projects that thrive for decades to come, we need to create economic systems that support the creation, growth and sustainability of Open Source projects.

The alternative is that we are stuck in the world we live in today, where proprietary software dominates most facets of our lives.

In another decade, I predict Drupal's incentive models for Makers will be a world-class example of Open Source sustainability. We will help figure out how to make Open Source more sustainable, more fair, more egalitarian, and more cooperative. And in doing so, Drupal will help remove the last hurdle that prevents Open Source from taking over the world.

Thank you A group photo taken at DrupalCon Seattle in 2019.

Drupal wouldn't be where it is today without the Drupal community. The community and its growth continues to energize and inspire me. I'd like to thank everyone who helped improve and build Drupal over the past two decades. I continue to learn from you all. Happy 20th birthday Drupal!

During the year 2021 we will be focusing on highlighting our work at 1xINTERNET and our solutions made with Drupal. We call this series “Celebrate 20 years of Drupal” where we will highlight 20 projects through the year that we are involved in and where Drupal has been used.

Open-source has the power to change the world, but, as we depend on it for democratic innovation, open-source also depends on us to thrive. At Axelerant, we know and own this; hence we’re constantly engaging in different open web communities, including Drupal’s.

Why are we writing this? First of all, we are always keen to shine a light on our team members because our people-first culture makes Axelerant succeed. Second, in a knowledge sharing spirit, we are willing to put out what has worked for us (and what we struggle with) regarding contributing and our community involvement.

We are celebrating Drupal’s 20th Anniversary, and we are proud of being part of that history for over a decade. What better way to celebrate than recognizing and sharing the stories of the people involved, the makers that keep the ball rolling.  

Celebrating our people and the community has been among our values since the beginning. Drupal’s 20th anniversary is one of those occasions where both of these values come together in demonstrating Axelerant’s commitment to be a productive part of the amazing Drupal community through its team.

Here, we want to share a few stories from team members who recently contributed and inspired us with their Drupal journey.

Last year, Mariano had a proposal: let’s try to automatically deploy after successful testing on Travis. We never had anything like that before, all we had is a bunch of shell scripts that assisted the process. TL;DR: upgrading to CD level was easier than we thought, and we have introduced it for more and more client projects. This is a deep dive into the journey we had, and where we are now.

Today, just 20 years ago, the first version of Drupal, Drupal 1, was released. Many technologies have emerged in these 20 years, became relevant, lost their relevance again and disappeared. But not Drupal. We join in a loud (and somewhat off-key) "Happy Birthday" in our minds for its 20th birthday. Great that Drupal and its wonderful community have been part of the web world for so long!

Today, on Drupal's 20th birthday, we are kicking off celebrations that will last throughout 2021. Together, let’s celebrate 20 years of Drupal and our Community - the inspired makers that keep Drupal innovative. 

As part of this 20-year milestone, we celebrate our community of more than 100,000 contributors who made Drupal what it is today,” says Heather Rocker, executive director of the Drupal Association. “Success at this scale is possible because the Drupal community exemplifies the values of open source and proves that innovation is sustained by healthy communities.”

To kick things off, we have a few ways for you to get involved:

• Promote the official Press Release of Drupal's 20th birthday to your local tech media
• Submit your Drupal birthday celebration to Community Events 
• Post a selfie of your celebration on Celebrate Drupal
• Submit Drupal milestones to the 20 Years of Drupal History timeline
• Share your excitement and what you’re doing to celebrate on social media - and be sure to add the hashtag #CelebrateDrupal
• Participate in our 'Drupal Doodle' event - where we're looking for celebratory banners to feature on Drupal.org
• Propose content for DrupalCon North America 2021 that showcase the ambitious digital experiences you’ve created with Drupal
• Register for DrupalCon

With so much to celebrate, today's activities are only the beginning. Keep an eye on this blog, the @drupalassoc on Twitter, and Drupal Association on Linked In for more activities throughout 2021. 

Drupal and Flutter: native mobile app experiences for your audience Editor Thu, 01/14/2021 - 23:41 Drupal and Flutter: adding native mobile app experiences to Drupal

Even if your Drupal website is doing great, its audience engagement and user experiences can always reach new heights — the heights at which you can almost hear the fluttering of the wings!

It’s the Flutter framework that will be the main topic of this blog post from the Golems Drupal team. We will discuss what Flutter is, how it works, what benefits and features make it the solution of choice for more and more developers, and how Drupal and Flutter are combined for creating native mobile app experiences.

What is Flutter? Brief introduction and overview of benefits

Flutter is a free and open-source cross-platform UI toolkit or framework that helps developers quickly and easily build beautiful apps for mobile, web, and desktop. The applications are natively compiled from a single codebase.

Serving on the Drupal Community Working Group has been one of the most fulfilling experiences of my career in open source. Since 2013, I’ve had both the honor and the privilege to work alongside some of the most thoughtful, patient, and devoted members of our community to help develop processes and structures for community governance, resolve conflicts, and help make the Drupal project and community a more friendly and welcoming place for everyone. That work has at times been challenging, but it has also provided many opportunities for learning and growth.

All good things must come to an end, however, and as announced at DrupalCon Europe last month, I’ve been working with the other members of the CWG over the last year on a plan to step down from my current position on the Conflict Resolution Team and make way for fresh talent and leadership. 

As our Code of Conduct states, “When somebody leaves or disengages from the project, in whole or in part, we ask that they do so in a way that minimizes disruption to the project. This means they should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off.”

In my case, this means that while I will no longer be one of the people responsible for fielding incident reports or acting as a facilitator to help community members resolve conflicts, I will continue to be available to the current members of the team on an as-needed basis to help provide background and context for past issues. I will also continue to serve as a member of the CWG’s Community Health Team, working on projects to proactively improve community health, such as updating our Community Code of Conduct. I also plan to spend more time advocating within the broader open source community for improved community management structures and processes.

With this transition comes an opening within the Conflict Resolution Team, who is currently engaged in a search for new members, which is being led by Tara King (sparklingrobots). You can learn more about the kinds of folks we are looking for in our last call for members from 2018; additionally, all members are expected to abide by the CWG’s Code of Ethics.  

As per the CWG's charter, new members of the CWG’s Conflict Resolution Team are appointed to up to two 3-year terms by the group’s Review Panel, which consists of the two community-elected Drupal Association board members, plus an independent representative appointed by the board as a whole.

If you are interested in being considered, please reach out to Tara or email drupal-cwg@drupal.org. In addition to the openings on the Conflict Resolution Team, we are looking to fill several roles on our Community Health Team for people looking to help make a positive difference in our community.

In closing, I want to thank all of my past colleagues on the CWG: Donna, Angie, Roel, Adam, Mike, Emma, Rachel, Jordana, and Alex, as well as the countless community members who have helped us out in various ways over the years. Drupal is better because of you and your contributions.

I once sat on a mountain and deeply contemplated the mysteries of Drupal development. Actually, I live on a mountain, so I do this every day, and the title of this post isn't a Zen revelation, I stole that from Elon Musk.

I'm not trying to build rockets and send humans to Mars, and I don't want to draw too many parallels between what I do and the complexity of that enterprise, but we do solve some complex problems of critical importance to our clients. Every efficiency we can gain improves outcomes.

Explore a brief tour of Acquia Site Studio and learn why it could be a solid fit for your next project.

What browsers are Drupal sites tested on in 2021?

Internet Explorer is still relevant to a minority of respondents. Unfortunately for DXPR, this number was three times higher in the separate survey that we sent to our clients. Internet Explorer was not only relevant to 60% of our clients... it was relevant to all our "Enterprise" clients which means we cannot drop IE in QA testing our Drupal Layout Builder, even in 2021. 

Safari is becoming less relevant, with 1 out of 4 respondents giving a pass on QA testing in this browser. Edge is still at 75%, but with Edge being based on Chromium I wouldn't be surprised if this number will be lower next year unless they start developing a lot of new features that are not found in Chrome.

What devices are Drupal sites tested on in 2021?

Desktop is still number one but there is only one respondent who does not test on mobile. I wonder if there is a future where Desktop will become less relevant than other device types for Drupal "applications". Maybe the question should be "when" and not "if".

What version(s) of Drupal are we using in 2021?

No surprise that Drupal 9 has the highest score, because all new projects should be starting on Drupal 9. the majority of Drupal sites currently online runs Drupal 7, according to data that depends on the "update module" being turned on, so it's no surprise to see that over half of the respondents are still working on Drupal 7 in 2021.

The same data I linked above, together with the data from this survey, suggests that the upgrade from Drupal 8 to 9 is not really as trivial as advertised.

Bonus question: What Drupal hosting platforms are you working with, in 2021?

It's no surprise to me that Pantheon.io is the most popular choice here, and I'm also happy to see they are getting more competition. Amazee.io with their Lagoon platform is a (relative) newcomer to the Drupal platforms market and they are getting traction.

I had not heard about OpenShift before. Apparently, it's an on-premise cloud platform. An interesting concept considering increased pressure on data security and end-user privacy. 

Who filled out this survey?

This survey was mostly filled out by agency-side Drupal professionals. 14% of respondents are client-side, i.e. working at a company that uses Drupal. 

Thank you

Thank you for helping us and our readers make better decisions about what Drupal environments to support!

Put Drupal glasses or masks on any image using the rokka.io image service:
https://rokka-fun.liip.to/drupal

Make sure to share using twitter using the #CelebrateDrupal hashtag.

Thanks to Christian Stocker for swiftly implementing the idea on rokka.io and Nico Grienauer for providing the gimmicks.

By nature, menus are complicated. They’re not easy to work with, build, or style, and yet they are probably the single most important navigation element of any website. Despite their complication, they need to be perfect to serve their purpose. A menu can make or break a website. They can make your browsing experience a pleasant one, or can drive you to leave a website frustrated and likely never to return.

When it comes to menus and forms, it is best to let Drupal dictate the direction rather than build them independently of Drupal. By adhering to Drupal’s best practices we can save a lot of time, effort, and frustration. For example, rather than writing your menu’s markup before you see it being printed by Drupal, it is best to build your menu in Drupal and see what the markup looks like. Then you can use Drupal’s markup as a starting point for writing your menu’s markup. 

This is going to be a lengthy post (mostly because it includes a lot of code snippets), but this article will cover all you need to accomplish the following:

• Build a multi-level menu component in Pattern Lab using a Twig macro included in Drupal core's menu.html.twig.
• Update Drupal’s menu macro to achieve better markup
• Create a Twig template suggestion for the main menu
• Integrate the Navigation component with Drupal

 Editor's note: This blog was originally published on June 3, 2019, and has been updated to include two new tutorial videos. They can be found at the end of the post. 

Build a Multi-Level Menu Component in Pattern Lab

For the purpose of keeping the content clean, I'll be linking to code snippets from Github Gists.

Let’s start by building a pretty straight forward multi-level menu component in Pattern Lab. If you’ve used Pattern Lab or KSS Node you know most components require at least three files: 

• .twig for the component markup and logic
• .yml or json for demo links or content
• .scss for the menu styles
• In some cases you may also need a Javascript file

For a more in-depth explanation on building and integrating components read our blog series.  
Note: This series is over three years old and many things have changed since then, but the basics of building a component still apply.

Building the component

1. In your theme’s components, location create a new directory called navigation
2. In the navigation directory, create the following three files:
   • navigation.twig
   • navigation.json
   • navigation.scss
3. Inside navigation.json add the code below:
   Menu data structure
4. The data above represents an array of items. You may notice some of the links have nested arrays (i.e. below). These represent submenus in the menu tree. The items array above is only intended to simulate the menu’s data for our component. In Drupal, the array will be provided when we add menu links to Drupal’s Main Menu.
5. Inside navigation.twig add the code below:
   Menu logic and markup
6. If the code above does not look familiar to you it’s probably because you’ve never used a Twig Macro. I will explain the macro in detail shortly, but for now, let’s move on to completing the component.  I have also recorded a screencast on Twig Macros.
7. Finally add the following styles in navigation.scss
   Menu CSS styles

Update Drupal’s Menu Macro to Achieve Better Markup

Not having the right markup for the menu, or any other element for that matter can really complicate things for us when it’s time to style. We are going to modify the macro so it matches the markup of the main-menu component, and as a result, the styles we wrote for the component will apply to the Drupal menu.

Menu Macro Explained

Let’s step through this macro line by line to understand what it does. To keep things simple we are going to ignore all the custom classes we added above and focus on the macro itself.

• Twig macros can be called from other twig templates, and it's also possible to call them from within the same twig template where it was written (as is the case here by using the variable name _self). So, with this import statement, we imported the macro and set it as a variable called menus.
• Using the menus variable we then assign a name to it (menu_links), which will take the following parameters: items, attributes, and 0). This name can be anything you wish.
• Now we declare the macro again but this time with its new name, menu_links, and pass the slightly modified parameters items, attributes, menu_level. 
• Now that we’ve updated the arguments, we self import the macro again to make use of it 
• Before writing any markup, we first check whether there are menu items to render
  • If there are items in our main menu we start writing the markup. However, since we may have a multi-level menu, we want to make sure we identify the top level menu from nested (submenus), menus in the tree.  
  • This is where we first check if the menu_level is 0 (zero).
  • If it is the top level menu, we print a <ul> and we pass Drupal’s attributes in addition to our custom classes.
  • If menu is not top level (submenus), then we simply print a <ul> with its corresponding class.

Learn more about Macros in Twig Templates.

Looping Through the Menu Tree

Looping through the items array allows us to intersect each item and apply classes or attributes.

• First, we loop through the items array (for item in items), and for each item, we print a <li> to which we pass an array of CSS classes using attributes.addClass() method.  However we do this only if we have access to Drupal's attributes ({% if attributes %}).  If not, we manually print the same classes on the list item. 
• For each item and link, we pass a series of things such as:
  • The link title
  • The link url
  • Is the link in the active trail,
  • ... and others.
• Inside the list item, we check to see if that particular item has other items or submenus({% if item.below %})
• When submenus exist, we make use of the macro again to repeat the process of printing the menu. This is where the macro saves us from writing duplicate code.
• For each level of submenus we are increasing the menu_level by 1 and printing it as part of the submenu class. This is handy if we want to target a specific submenu in the tree.
• Finally, we close all previously open actions/tags (i.e. for loops, if statements, lists, and macro).

RESOURCE: I recently ran into a blog post by Tamas Hajas where he has a great way to address classes and states on a menu. Check it out: Drupal 8 Twig: add custom CSS classes to menus. 

Looking at the Rendered Menu after Macro Improvements

Now that we have a better understanding on how the macro works, and after making the improvements discussed above, the markup for the menu would look something like this:

 

These styles are as bare as possible. They are simply to make the menu look presentable and could use a lot of improvements. This is what the multi-level menu looks like:

 

Create a Twig Template Suggestion for the Main Menu

Our ultimate goal is to update Drupal’s menu system to render using the navigation component. 

Follow these steps to enable Twig Debugging in your theme. Then, you can inspect your site, which will allow you to see the various template suggestions that Drupal uses to render the page; including your navigation menu. The debug information looks like this:

Under File Name Suggestions notice two template names: menu.html.twig & menu--main.html.twig. The X next to menu.html.twig indicates Drupal is using this file to render the Main Menu. The second file, menu--main.html.twig, is what Drupal is suggesting we create if we only want to alter the Main navigation and not other menus.  The word "main" in the file name represents the Drupal machine name for that menu.

Under Begin Output notice the path where menu.html.twig can be found, the example above is pointing to Drupal’s stable theme.

To ensure we only affect the main menu and not other menus on our site, we are going to make a copy of Drupal’s menu.html.twig in our theme and then override it. This is recommended rather than modifying Drupal core’s template. Let’s start:

1. Copy the menu.html.twig template from core/themes/stable/templates/navigation/ into [site_root]/themes/custom/<your-theme>/templates/navigation/menu.html.twig (if these folders do not exist yet in your theme go ahead and create them).
2. Following the golden rule “Never hack core”, we want to make a copy of Drupal’s menu template in our own theme. Replace the core theme’s name with your core base theme if you are not using stable.
3. Next, In your theme rename the newly copied template to menu--main.html.twig.
   Copying menu.html.twig into our theme will affect other menus. This is why we are renaming the template so it only affects the main menu (menu--main.html.twig). Replace ‘main’ with whatever your menu’s machine name is if you are not using Drupal’s Main Menu. This can be found in Drupal’s Menus page (admin/structure/menus).
4. After clearing Drupal’s cache, inspect the menu again and you should see the X next to menu--main.html.twig which means Drupal is now using our custom twig template suggestion to render the menu.

Create a Multi-level Menu in Drupal

• Let’s make sure we have a menu we can see in Drupal. Let’s create a multi-level menu using the Main Navigation menu (Structure | Menus | Main Navigation).
• Add as many links as you wish. Be sure to add nested items so we end up with a multi-level menu.
• In addition, ensure each of the submenu’s parent links are set to “show expanded”. You will see the option on the Add/Edit Link page.
• Finally, go to Structure | Block Layout and click Configure next to Main Navigation
  • Change Number of levels to display to Unlimited. This will ensure dropdowns are rendered and display in your navigation.

Integrate the Main Menu component with Drupal’s Menu

The last part of the process is to integrate all the work we’ve done with Drupal, so our Navigation is rendered with the markup, styles, and behavior we implemented when we built the component.  

1. In your editor, open [site_root]/themes/custom/<your-theme>/templates/navigation/menu--main.html.twig
2. Delete all the content in the twig template except for the comments, and then paste the code below into it

{% include '@your-namespace-here/navigation/navigation.twig' %}

1. Clear Drupal’s cache
2. Reload Drupal’s page

Since we moved the macro to the component’s location, all we need to do in the menu--main.html.twig template is to call our Navigation component by using a Twig include statement. 

If we did our job right, Drupal’s menu should now look and behave the same way as our component. In addition, if you inspect the Drupal page, the menu should reflect the same markup as the main-menu component.

Drupal Libraries

As a best practice, we should create a drupal library to attach any styles and javascript to our component. See this article for adding CSS and JS to a page or component.

If your navigation is displaying unstyled that's because a Drupal library does not exist.  Create one as follows:

• Inside /themes/custom/<your-theme>/your-theme.libraries.yml add the following code

navigation: css: component: dist/css/navigation.css: {}

Your compiled css path may be different.

This library has already been attached above inside navigation.twig

By doing this any styles we wrote for the component will apply to the main navigation when it’s rendered in Drupal. Drupal libraries have no effect in Pattern Lab.

After completing the steps above, clear your Drupal’s cache and reload your Drupal site. You should see your Drupal menu being rendered with all the styles and markup we wrote throughout this post,

What about Accessibility?

You should always ensure your menus and navigations are accessible. It is the right thing to do. However, don't yell at me for not following my own advice. In an effort to keeping this tutorial simple, I opted to omit anything related to accessibility. Perhaps part two can focus on that ;-)

Video Tutorials

In Closing

I’d like to admit that I went about the long way to get the main menu working on both, Pattern Lab and Drupal. There are other ways to accomplish this by using contrib modules such as Simplify Menu (full disclosure, I am a co-maintainer of the module), and perhaps Twig Tweak among several others, however, the approach I took here gives you the most control and that can make all the difference if you are dealing with a pretty advanced or complicated menu.

TLDR: Drupal 7 has a much longer lifespan than the (already pushed back) official date, and Drupal 8 has an essentially infinite lifespan because it updates in-place to Drupal 9 easily (and the same will be true of Drupal 10, 11, ∞.). There's no reason to rush an upgrade— but there's no reason to wait either.

That's the short version.

A client recently wrote to Agaric about Drupal 7 / Drupal 8 / Drupal 9 project planning questions:

With the EOL for Drupal 7 in Nov of 2022, and the EOL for Drupal 8 in Nov 2021, is there a reason we should move a D7 site to D8 at all this year? Seems like we might want to move directly to D9? We don’t want to feel pushed up against a wall with a “new” site build in Drupal 8, if we can limp along in D7 for a couple more years while we develop a D9 site with a longer lifespan. I’m wondering if you might have time to discuss pros and cons briefly so we can get a good plan together for moving forward.

I started typing and almost did not stop:

1. No one believes me when i say this, but i repeat my assurance that Drupal 7 will be well-supported commercially until 2030 or later (Drupal 6, released in 2008, still has semi-official long term support until at least February 24th, 2022— and Drupal 7 has a larger install base than Drupal 6 ever did, and currently has the largest install base of any version of Drupal by far, with more than half a million tracked installs.

   Drupal 7 will be supported by the community for a long time. You do not have to feel pushed to a new version, like, ever.

Read more and discuss at agaric.coop.

The news is finally out! We’re pleased to announce that after an unforgettable 2020 for all, we have found our silver lining!  On the 23rd of December, we joined a group of amazing, well-rounded businesses in our new venture.  We are now part of a dedicated team who use their skills in digital strategy, technical support, and integrated marketing to create industry-leading experiences. Joining CTI secures talent for the group’s website and hosting support because together we’re now the largest independent Drupal agency in the UK! In this blog, we’re going to walk you through the businesses and asset now at our fingertips! 

The roles and permissions system in Drupal is powerful, but it can be tricky to configure correctly. Some permissions give a role too much privileged access where others aren’t granular enough.

An excellent example of this is if you need to create a role to manage user accounts.

Drupal comes with the permission “Administer users” which lets you create user accounts, only give this permission to trusted users.

The above mention permission allows you to create user accounts but you can’t assign them roles without “Administer roles and permissions”. But this permission (“Administer roles and permissions”), will enable you to assign any roles, including the default Administrator role.

Essential Modules for Drupal 8 & 9

I presented The Drupal 10 readiness initiative - here we go at DrupalCon Europe a month ago. While I published my slides with plenty speaker notes right away, the session videos just became public. While the live presentation was a month ago, most of the content is still up to date.

Drupal 9 is expected to have the shortest Drupal major release lifetime in recent history with Drupal 10 planned to be released in the middle of 2022 (next year!) and Drupal 9 end of life by end of 2023. In this session, we discussed what it takes to get from Drupal 9 to Drupal 10 and how are we going to manage this transition. We also covered what we learned from the Drupal 8 to 9 transition (so far) and how we plan to make it better for 10.

Check out the recording:

The vast majority of community-contributed Drupal 8 modules now have releases that are compatible with Drupal 9, but what can you do if you need to use a module that doesn’t? Well, you’re likely to find a compatibility patch in the project's issue queue. But the tool most of us use with composer to apply patches, cweagans/composer-patches, is a plugin that can only make its changes after composer reads a package's metadata about its compatibility (and dependencies). So for contrib modules that haven't yet committed their patches, attempting to apply the patch in the usual way doesn't help. For example, using composer to patch commerce_migrate for Drupal 9 compatibility produces an enormous and confusing error:

Your requirements could not be resolved to an installable set of packages. Problem 1 - Conclusion: don't install drupal/commerce_migrate 2.0.0-rc3 - Conclusion: don't install drupal/commerce_migrate 2.0.0-rc2 - Conclusion: remove drupal/core 9.0.9 - Installation request for drupal/commerce_migrate ^2.0@RC -> satisfiable by drupal/commerce_migrate[2.0.0-rc1, 2.0.0-rc2, 2.0.0-rc3]. - Conclusion: don't install drupal/core 9.0.9 - drupal/commerce_migrate 2.0.0-rc1 requires drupal/core ^8.7 -> satisfiable by drupal/core[8.7.0, 8.7.0-alpha1, 8.7.0-alpha2, 8.7.0-beta1, 8.7.0-beta2, 8.7.0-rc1, 8.7.1, 8.7.10, 8.7.11, 8.7.12, 8.7.13, 8.7.14, 8.7.2, 8.7.3, 8.7.4, 8.7.5, 8.7.6, 8.7.7, 8.7.8, 8.7.9, 8.8.0, 8.8.0-alpha1, 8.8.0-beta1, 8.8.0-rc1, 8.8.1, 8.8.10, 8.8.11, 8.8.12, 8.8.2, 8.8.3, 8.8.4, 8.8.5, 8.8.6, 8.8.7, 8.8.8, 8.8.9, 8.9.0, 8.9.0-beta1, 8.9.0-beta2, 8.9.0-beta3, 8.9.0-rc1, 8.9.1, 8.9.10, 8.9.11, 8.9.2, 8.9.3, 8.9.4, 8.9.5, 8.9.6, 8.9.7, 8.9.8, 8.9.9]. - Can only install one of: drupal/core[8.7.0, 9.0.9]. - Can only install one of: drupal/core[8.7.0-alpha1, 9.0.9]. ... - Installation request for drupal/core (locked at 9.0.9) -> satisfiable by drupal/core[9.0.9]. Installation failed, reverting ./composer.json to its original content.

This message goes on and on, including scary messages like 'Conclusion: remove drupal/core', and sometimes about all sorts of seemingly unrelated packages! Ultimately, composer is trying to bend over backwards to use versions of Drupal and its dependencies that would work with the module, but it won't find any. Or if it does, you might find yourself downgraded to an old version of Drupal, which you certainly don't want!

So what's the solution?

We need to override the compatibility metadata for the contrib module.

Drupal sites use https://packages.drupal.org/8 as the metadata provider, which you'll find listed in your project's root composer.json file under a repositories section. This section instructs composer where to get the metadata from ... so if you add your own 'package' repository to be used first, composer will happily use that, ignoring what drupal.org tells it:

"repositories": [ { "type": "package", "package": { "name": "drupal/commerce_migrate", "type": "drupal-module", "version": "dev-8.x-2.x", "source": { "type": "git", "url": "https://git.drupalcode.org/project/commerce_migrate.git", "reference": "9ac26262b3443d20e69cea69652abc2dee39fee5" } } }, { "type": "composer", "url": "https://packages.drupal.org/8" } ],

In this example, for the commerce_migrate module, we specify the latest commit from its development branch (8.x-2.x), as that's what the patch is intended to get ultimately applied to. That branch also matches our requirement in our composer.json file: "drupal/commerce_migrate": "dev-8.x-2.x". (Note that composer needs the dev- prefix when using git branches.)

So this section redefines the module's dev-8.x-2.x version for composer. As we require that version, we get the snapshot of the codebase at that specific commit - skipping the metadata that drupal.org would have added which would restrict its compatibility.

Now, the patch can be added in the usual patches section, and then running composer update drupal/commerce_migrate will apply it successfully!

This technique can also be used to override other package metadata for composer, such as a change in dependencies. But beware - it means you're no longer using the real releases for the package, and in this example, locks to a specific commit. So you will need to keep an eye out for when the patch gets committed to the module, and for any other work in its codebase that should be incorporated over time. It's a little like taking a snapshot of the project, and applying just the specific changes you need - at the cost of losing out on any goodness that the maintainers may add over time. This approach does avoid forking the codebase away at least. As this replaces the module’s metadata entirely, it’s worth checking for any dependencies or other compatibility metadata that its own (potentially now patched) composer.json file might have, and copying them to your project’s root composer.json file.

Given how quickly the community & its leaders have rallied to make modules D9-ready, I wouldn't be surprised if this trick can be removed in a few months' time, as maintainers continue to commit these (often trivial) patches. Any projects that don't, may even get covered automatically some day - plus, if their maintainers aren't doing this, they're also unlikely to be adding much of note in the meantime anyway, so it's pretty safe. I would just keep an eye out for any new releases - especially security ones - to those projects.

Get notified

I suggest finding the issue that currently tracks making the module compatible with Drupal 9. This may be linked to from the project page, or it's usually one of the more recent/active ones in its issue queue. If you're logged into drupal.org (and you should be - sign up if you haven't!), then you can press a 'Follow' link that has a nice green star next to it, to get email notifications of updates. The 'View all releases' link from a project page takes you to a page that has an RSS feed, which can be used to subscribe to notifications of new releases too. That's well worth doing for a number of reasons! If you didn't know it, you can also subscribe to notifications of security releases - head to https://www.drupal.org/security where you'll find instructions at the top of the sidebar (which is below the list of posts if you're on a mobile).

 

Thanks to heddn, dpi and larowlan for this solution. Photo by Josh Carter on Unsplash.