Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Jul 21 2020
Jul 21

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

DrupalCon Global Driesnote presentation

Last week, Drupalists from around the world gathered for DrupalCon Global. This DrupalCon was the first ever virtual event of this scale for the Drupal community.

As a matter of tradition, I delivered the opening keynote. You can watch a video recording of my keynotedownload a copy of my slides (212 MB), or read the brief summary below.
 

A screenshot of the first ever virtual DriesNote. The virtual conference tool showed my slides, my webcam, and real-time chat.
A screenshot of the first ever virtual DriesNote. The virtual conference tool showed my slides, my webcam, and real-time chat.

I announced that we are targeting the release of Drupal 10 around June 2022.

Next, I spent the majority of my presentation proposing five strategic initiatives for Drupal 10. While it seems early to speak about Drupal 10, we need to start working on these strategic goals now to have them ready by the time Drupal 10 is released.

The goal of my presentation was to propose five well-balanced initiatives for Drupal 10.
The goal of my presentation was to propose five well-balanced initiatives for Drupal 10.

We decided to go with just five initiatives so we're more focused and because the Drupal 10 release cycle will be shorter than Drupal 9's. Selecting only five initiatives was hard. I spent 35 minutes walking the audience through the selection process. The five proposed initiatives:

  1. Drupal 10 readiness
  2. An easier out-of-the-box experience
  3. A new front-end theme (Olivero)
  4. Automated updates for security releases
  5. An official JS menu component for React and Vue

1. Drupal 10 readiness

Drupal depends on third-party software components, many of which will go end-of-life (EOL) in the next few years. When a component goes EOL, it will no longer receive security support.

The "Drupal 10 Readiness" initiative will focus on upgrading these third-party components. Not only does this keep Drupal secure, it also allows us to take advantage of any new capabilities that come with these updated components.

Some of the third-party components that need to be updated in preparation for Drupal 10.
Some of the third-party components that need to be updated in preparation for Drupal 10.

2. Easy out-of-the-box

Improving Drupal's ease-of-use remains the number one most impactful item for the community to work on.

Drupal 9 dramatically improved Drupal's ease-of-use. Several of our most promising improvements made it very far, but still need some finishing touches. Specifically, our new Media Library, Layout Builder and Administration Theme (Claro) are not yet enabled by default.

I proposed the "Easy out-of-the-box" initiative to work towards enabling these features by default. I believe this initiative will be very impactful in terms of attracting new users to Drupal.

The 'Easy out of the box' initiative consists of finishing Media, Layout Builder and Claro.
The 'Easy out of the box' initiative consists of finishing Media, Layout Builder and Claro.

3. Front end theme

One of the most important features to complete is our modern front end theme, Olivero. While there has been a lot of progress in this area, Olivero does not ship with Drupal yet. We want to make sure this beautiful front end theme is available by default.

A screenshot of the upcoming front-end theme called Olivero.
A screenshot of the upcoming front-end theme called Olivero.

4. Automatic updates

As shown by the Drupal 2020 Product Survey, by far the most requested feature is automated updates.

Fortunately, it's something we have been working on for some time. Our first milestone will be to automate security updates so all site owners can sleep well at night, no matter when security releases are taking place.

Beyond security, automated updates help us work towards our long-term vision of building a composable — or Assembed Web — architecture for Drupal.

The four major architectural building blocks of the Automated Updates initiative.
The four major architectural building blocks of the Automated Updates initiative.

5. JavaScript menu component

As I have been saying for years now, many websites are evolving into personalized, omnichannel digital experiences. It's a multi-decade trend, and one of the most powerful ones in our industry.

Drupal needs to keep evolving with this trend in mind. On the back end, we need to continue to make Drupal the best structured data engine and web service platform. On the front end, JavaScript continues to grow fast. While Drupal is recognized as a capable headless or decoupled CMS, there is still more we can do.

Furthermore, the second most requested feature in the Drupal 2020 Product Survey was a more modern administration UI. These kinds of UIs are typically built using JavaScript and web service APIs. When done well, a JavaScript UI can offer major usability improvements.

Clearly, there is more than one reason to invest in web service APIs and to embrace more JavaScript in Drupal:

  1. Many of Drupal's end users are focused on building decoupled front ends and omnichannel digital experiences.
  2. Drupal could improve its own administration UI with more WYSIWYG, drag-and-drop, and other ease-of-use features.

To make a start toward improving Drupal's headless capabilities and administration UI, I proposed we start to add official Drupal JavaScript components to Drupal Core.

As a first step, I recommended implementing a JavaScript menu component in Vue and React. This would mark the first official JavaScript component in Drupal.

'Planting the flag' for providing official JavaScript menu components for Drupal.
'Planting the flag' for providing official JavaScript menu components for Drupal.

Developing a JavaScript menu component solves a very real problem that many front end developers face. This menu component would render a menu and could be placed in a front end JavaScript application. The content of the menu comes from Drupal. This would allow content authors and non-developers to make simple menu changes without the need for custom code.

Releasing a first official JavaScript component will require us to set up the tools and processes to manage and release JavaScript components. This will establish a pattern or recipe for more components. Once we build one component, it will be easier to add many more in parallel.

The path to having a first official JavaScript component is longer than it may appear.
The path to having a first official JavaScript component is longer than it may appear.

Let's do this!

A fictitious or forward-looking press release for Drupal 10 in June 2022.
A fictitious or forward-looking press release for Drupal 10 in June 2022.

With the release of Drupal 10 targeted for June 2022, our community has a big opportunity to make the beginner and non-developer experiences much simpler, while still keeping Drupal's power as strong as ever for experts. I believe the proposed strategic initiatives will help achieve that.

For more details, I recommend you watch the recording of my presentation.

Whether you're just getting started with Drupal or have been here for years, we want you to contribute to Drupal 10! The best way to get involved in any of these initiatives is to join their discussion channels on Drupal Slack:

  • Drupal 10 readiness: #d10readiness
  • Claro: #admin-ui
  • Olivero: #d9-theme
  • Automated updates: #autoupdates
  • JS Menu Component: #js-menu-component

Thank you to everyone who attended the very first Drupalcon Global and contributed to the event's success. Even though we were unable to meet in person, I was blown away by the energy of everyone involved, and grateful for the time to connect with old and new friends.

Jul 17 2020
Jul 17

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

We are targeting to release Drupal 10 around June 2022. That is less than two years from today!

Why so fast, you ask?

Drupal 9's biggest dependency is Symfony 4, which has an end-of-life date in November 2023. This means that after November 2023, security bugs in Symfony 4 will not get fixed. Drupal has to adopt Symfony 5 (or later) and end-of-life Drupal 9 no later than November 2023.

For security purposes, all Drupal 9 users will need to upgrade to Drupal 10 by November 2023. We like to give site owners at least one year to upgrade from Drupal 9 to Drupal 10, therefore we are targeting Drupal 10 to be released in June 2022.

A timeline showing that Drupal 10 is targeted for June 2022 because Symfony 4 is end-of-life in November 2023.

Will the upgrade to Drupal 10 be easy?

Yes, it will be easy, and here is why.

New functionality for Drupal 10 is actually added to Drupal 9 releases. This means module developers can start adopting any new APIs right away. Along the way, we deprecate old functionality but keep backwards compatibility. Once we are ready to release Drupal 10, we remove all deprecated code. Removing deprecated code breaks backwards compatibility, but because module developers had a chance to stay up to date with API changes, the upgrade to Drupal 10 should be easy.

If that makes your head spin, think of it this way: Drupal 10 is identical to the last version of Drupal 9, with its deprecations removed. Because of that, there should be no last-minute, big or unexpected changes.

We used this approach for Drupal 9, and it was successful: 95 of the top 100 contributed modules were ready the day Drupal 9.0.0 was released. We know from Drupal 9 that this approach to upgrades works, and we'll continue to refine it going forward.

Jul 10 2020
Jul 10

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

I remember the first gathering of Drupal contributors back in 2005. At the time, there were less than 50 people in attendance. In the 15 years since that first gathering, DrupalCon has become the heartbeat of the Drupal community. With each new DrupalCon, we introduce new people to our community, demonstrate the best that Drupal has to offer, and reconnect with our Drupal family.

Next week's DrupalCon Global is going to be no different.

Because of COVID-19, it is the first DrupalCon that will be 100% virtual. But as much as we may miss seeing each other in person, the switch to virtual has opened opportunities to bring in speakers and attendees who never would have been able to attend otherwise.

There are a few moments I'm particularly excited about:

  • Mitchell Baker, CEO of the Mozilla, is joining us to talk about the future of the Open Web, and the importance of Open Source software.
  • Jacqueline Gibson, Digital Equity Advocate and Software Engineer from Microsoft, will be talking about Digital Inequity for the Black community – a topic I believe is deeply important for our community and the world.
  • Leaders of current Drupal strategic initiatives will be presenting their progress and their calls for action to keep Drupal the leading CMS on the web.
  • And of course, I'll be giving my plenary presentation to celebrate the community's accomplishment in releasing Drupal 9, and to talk about Drupal's future.

Beyond the sessions, I look forward to the human element of the conference. The side conversations and reunions with old friends make attending DrupalCon so much more powerful than simply watching the recordings after the fact. I hope to see you at DrupalCon Global next week!

Jun 19 2020
Jun 19

This blog has been re-posted and edited with permission from Greg Boggs' blog.

With Drupal 9 here, the upgrade process from Drupal 8 to 9 is short and impressive. Upgrading is similar to a Drupal 8 minor upgrade. After some testing, your Drupal 9 website is ready to go. But, what about Drupal 8 modules? Thanks to the smooth upgrade path to Drupal 9, most large modules are ready to go! But, what about the smaller modules that haven't been maintained in a few years? Enter the Maintainers Project!

What is the Maintainers Project?

The Maintainers Project is a community organized effort started by Damien Mckenna from Media Current and I to improve the support of Drupal contributed modules. Maintaining a large collection of modules is a big undertaking. So, I focus on issues marked "Reviewed and Tested by the Community" or "Needs Review" and testing releases. Rather than trying to write new code, the goal is to ensure more people get responses to their contributions.

Do You Have a Module That Needs Support?

We've started with modules over 3000 that haven't had support in a while and modules we've worked on before. But, we're expanding to as many modules as we can. The best way to get us involved in your module is to join us on Drupal Slack. Or, if Slack isn't for you, you can add Greg Boggs (careful of the space) as a maintainer on your project, or file an issue on the maintainers project, and I'll do my best to jump in to help.

What's the Long Term Plan?

Today, I'm focused on providing support to get Drupal Contrib ready for Drupal 9. To make the project sustainable, we'll need to grow the team. With just the small team we have, when I work on a module, the community springs to life and people from all over the world are already helping to get the work done.

Kudos to Mrinalini Kumari from @Srijan. She's doing great work helping getting patches polished for the release of several of the #Drupal 9 contrib modules I'm working on. It's super awesome opening an issue I'm about to finish and finding the work already done!

— Greg Boggs (@gregory_boggs) June 8, 2020

Jun 09 2020
Jun 09

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

Lat week, we released Drupal 9.0.0! This is a big milestone because we have been working on Drupal 9 for almost five years.

I updated my site to Drupal 9 earlier today. It was so easy, it's hard to believe.

As I write this, I'm overwhelmed by feelings of excitement and pride. There is something very special about building and releasing software with thousands of people around the world.

However, I find myself conflicted between today's successful launch and the tragic events in the United States. I can't go about business as usual. Discrimination is the greatest threat to any community, Drupal included.

I have always believed that Drupal is a force for good in the world. People point to our community as one of the largest, most diverse and most supportive Open Source projects in the world. While we make mistakes and can always be better, it's important that we lead by example. That starts with me. I am committing to the community that I will continue to learn more, and fight for equality and justice. I can and will do more. Above all else, it's important to stand in solidarity with Black members of the Drupal community — and the Black community at large.

During this somber time, I remain incredibly proud of our community for delivering Drupal 9. We did this together, as a global community made up of people from different races, ethnicities, genders, and national origins. It gives me some needed positivity.

If you haven't looked at Drupal in a while, I recommend you look again. Compared to Drupal 8.0.0, Drupal 9 is more usable, accessible, inclusive, flexible, and scalable than previous versions. We made so much progress on such important things:

  • Drupal 9 is dramatically easier to use for marketers
  • Drupal 9 is easier to maintain and upgrade for developers
  • Drupal is innovating with its headless or decoupled capabilities

It's hard to describe the amount of innovation and care that went into Drupal since the first release of Drupal 8 almost five years ago. To try and grasp the scale, consider this: more than 4,500 individuals contributed to Drupal core during the past 4.5 years. During that time, the number of active contributors increased by almost 50%. Together, we created the most author-friendly and powerful version of Drupal to date.

Thank you to everyone who made Drupal 9 happen.

Jun 08 2020
Jun 08

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

We’re so close to the release of Drupal 9 and the excitement is alive all throughout the Drupal community. It has been 5 years since Drupal 8.0 was released and in that time, thousands of contributors and organizations have worked together to create a more powerful, accessible and innovative Drupal experience based on the input of people all around the world. As we await the reveal, we know that you are eager to know what Drupal 9 will mean for your sites and the next generation of web experiences. 

We recently joined Drupal founder Dries Buytaert in a webinar hosted by The Drupal Association and Acquia to answer your top Drupal 9 questions. Since we weren’t able to cover everyone’s questions, we wanted to cover some of the most popular ones here. Keep reading to find out what’s in store for Drupal going forward.  

Making the Migration

What are the migration options for users currently on Drupal 7? 

Gabor: Prior to the release of Drupal 9, we’ve been recommending people move to Drupal 8 first because the upgrade from 8 to 9 is much simpler. However, once Drupal 9 is released, people can use the Drupal 7 to Drupal 9 migration path directly built into Drupal 9.

The question comes down to whether the extensions that you are using are already available for Drupal 9 or not. Drupal has 9,000 extensions and more than 2,200 of them are already Drupal 9 compatible. We’re seeing hundreds of extensions added each week. The majority of people find that most/all of their extensions are already Drupal 9 compatible, in which case it is easiest to go directly from Drupal 7 to Drupal 9.

To track all of the great progress we’re making toward getting all of the Drupal extensions compatible, you can check out the Drupal 9 Deprecation Status Tracker.

Angie: Acquia also has a new tool in development for Drupal 7 to 9 migrations called Acquia Migration Accelerator, which we'll talk about more in a later section!

Do you expect support for Drupal 7 will be extended beyond November 2021?

Gabor: Currently, community support for both Drupal 7 and Drupal 8 will end in November 2021. However, Acquia is a member of the Drupal 7 Vendor Extended Support Program and will be providing commercial support for Drupal 7 until 2024

What migration tools are recommended to support the upgrade to Drupal 9?

Gabor: Drupal 9 has the same migration capabilities as 8.9, meaning that the standard migration tools can be applied when migrating to Drupal 9. The three main tools we recommend are:

  1. The Core Migrate Module suite - Migrates your content and site configuration  
  2. The Upgrade Status Module - Provides information about contributed project availability
  3. For Drupal 8 sites, the Upgrade Rector module automates updates of many common deprecated code to the latest Drupal 9 compatible code
  4. For Drupal 7 sites, the Drupal Module Upgrader - Scans and converts outdated code on your site. (This was recently upgraded by Acquia to generate code that is compatible with Drupal 8 and 9 at the same time where it can do transformations.) 

Angie: We’re also excited that Acquia will soon be offering the Acquia Migration Accelerator. This tool, which is currently in development, will help automate parts of the Drupal 7 to 9 migration process by giving companies access to a dashboard to view their data migration, provide module replacement recommendations, and offer insights into things like validation and migration errors.

Accessibility and Security 

What accessibility features will Drupal 9 have built-in? 

Angie: Drupal 9 is going to continue the strong commitment to accessibility that began in Drupal 7. Drupal's Core Accessibility Gate, required for all core changes, is a major show of dedication to accessibility efforts, and it makes sure that any new feature added will be accessible right out of the box. We’ve made a lot of positive strides when building Drupal 8 with full keyboard support, voice-to-text support for visually impaired users and media and layout enhancements. There was a lot of care put into the issue of accessibility and it’s something that will continue to be refined and worked on as part of the future of Drupal 9. 

Gabor: We’re also excited that the new Claro Administration theme, which was specifically optimized to feature an accessible design, will become the eventual default backend theme in future versions of Drupal 9. 

What security enhancements should we expect in Drupal 9?

Gabor:  A large part of the reason for the Drupal 9 upgrade itself is to ensure Drupal is more secure and compatible with modern system requirements. Also, Drupal 9 removes deprecated code so you’re working with a smaller codebase. This means there is less chance for potential security risks or errors. 

In general, Drupal has always shown itself as a secure choice. Drupal’s trusted by some of the biggest names from NASA to Tesla to NBCSports, so we’re confident it will continue to meet these high standards. The open source model creates shared responsibility throughout the community, meaning that security is a constant focus.  

Headless/Decoupled Drupal 

Is there going to be any movement toward more robust headless support and non-web content?

Gabor: We know there’s a huge interest in headless and non-web content with things like chatbots and IoT devices right now. While there aren’t currently any set plans to expand into more decoupled features, the push for change and innovation will be driven by the community. Anyone interested in advancing the current decoupled Drupal capabilities should submit their thoughts in Dries’ 2020 Drupal Product Survey, which is used to inform the strategic roadmap of Drupal’s future. 

Angie: Drupal 9 will still have all of the diverse options around traditional, partially decoupled and fully decoupled Drupal. For anyone looking for more support for their decoupled modules and content, there are tons of great contributed modules dedicated to decoupled and headless support. 

The Future of Drupal   

Will Drupal 9 include more “no/low code” features and features for non-developers?

Gabor: Definitely. Making Drupal more intuitive for all users is a big priority. There’s the Automated Updates Initiative in the works that began during Drupal 8. Funding for the second phase is being collected right now. That would help a lot of organizations with their site upkeep and maintenance without requiring a lot of dev resources.

Angie:  We’ve also got the new front-end theme, Olivero under development, that’s optimized for accessibility and tailored to front-end experiences. It’s made for people like marketers, site designers and content editors with a huge focus on responsiveness. 

Beyond core, users who want an easier experience on the front end should check out Acquia Cohesion, a low-code site building tool that lets people create new sites really quickly and easily. 

What sets Drupal 9 apart from other enterprise CMS platforms? 

Gabor: It’s the best and most modern version of Drupal, which has long been a CMS that offers the most variety, flexibility and freedom. Drupal's foundation was always in structured data which naturally caters itself to today's needs of multichannel interactions. Also Drupal has one of the biggest open source communities on the planet. There are thousands of people and over a thousand companies working on it to add more features, to improve security and to create new extensions.

Plus, those open source roots mean that companies that choose Drupal aren’t limited or trapped if one proprietary software company suddenly decides to switch vendors. They always have the option to move to another provider.  

Angie: Drupal is amazing because it’s always on the cutting edge. There’s no waiting around for one company to catch up with the digital roadmap. For example, a few years back when Pinterest had just come out and was becoming popular, Drupal had a plug-in for it in just two days! We have a community of thousands of developers that can embrace change right away as these big developments happen and I think that’s a big advantage when it comes to web experience. 

---

Drupal 9 marks another huge milestone in the world of web content management and digital experience. As you prepare for Drupal 9’s release, we’ve got the Ultimate Guide to Drupal 9 to help guide you on this exciting journey.  

Jun 08 2020
Jun 08

PatrickContinuing our short series of articles highlighting ways that the Drupal software and its community are building solutions to help combat the effect of COVID-19, today we hear from Patrick Corbett of Redfin Solutions. Here, he describes their project at the  Rural Aspirations Project.

The Rural Aspirations Project was created to expand educational opportunities in rural Maine that develop and honor the community while stimulating the innate curiosity of the students and teachers. When the Maine state government shut down the schools to limit the spread of COVID-19, parents and teachers found their roles turned upside down. Rural Aspirations saw the need for a service to connect Maine families and teachers with the wide array of activities and resources offered by Maine organizations.

In light of this growing need, Redfin Solutions collaborated with Rural Aspirations to launch an improved Community Learning for ME website. The new website had to be capable of addressing immediate needs in the community: collegial support for teachers, a way for organizations to explore and pilot innovative virtual connections, and a quick and easy resource for families that are struggling to manage what some have called “crisis schooling.”

With communitylearningforme.org, local educational organizations such as the University of Maine Cooperative Extension, the Portland Public Library, and the Maine Audubon can post their resources, learning activities, and links to live events. With Drupal, we were able to use taxonomy and views with exposed filters to empower the teachers and parents to find the perfect resource while enabling them to discover more. Users can filter and search by subject, age group, and duration for a resource that fits a specific need. They can also browse through the website to learn more about what Community Learning for ME has to offer. Teachers can create schedules for their students to follow along with at home. Parents can find resources to support them in engaging their child, and fun activities for their child to work on. 

screenshot of website

Community Learning for ME is a volunteer-driven, grassroots effort. The website is best served by Drupal because it allows administrators to grant trusted organizations access to manage their own pages on the site through a custom publication workflow. Before using Drupal, the administrators spent hours each day on a Wix-based site creating and updating resources manually. Now, with the time they save, they can focus on providing targeted support to those in the rural Maine community who need it the most.
 

May 28 2020
May 28

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

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

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

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

We encourage you to join in the fun!

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

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

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

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

May 27 2020
May 27

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

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

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

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

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

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

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

Screenshot of STEM website

May 20 2020
May 20

Peter OroszvariContinuing our short series of articles highlighting ways that the Drupal software and its community are building solutions to help combat the effect of COVID-19, today we hear from Peter Oroszvari of Cheppers. Here, he describes their project at the Mayor’s Office of the 15th District of Budapest, Hungary.

The coronavirus pandemic triggered a critical situation in Hungary that forced local government authorities to move fast in the digitalization of services. Cheppers, a Drupal-focused development company has already been working with local governments on e-government solutions, supporting authorities in their digital transformation. 

As the Hungarian government ordered restrictions on free movement in March 2020, organizing care for the elderly and persons in need became the responsibility of local authorities. The Mayor’s Office of Budapest’s 15th District called upon Cheppers to build a mobile application and website that serves as a platform for locals in difficult situations to ask for help from the Mayor’s Office, while supporting the Office in tracking requests filed through various platforms. A Drupal-based solution seemed fitting for three reasons:

  • A Drupal-based backend simultaneously provides content for various end points while operating as a suitable platform to store incoming requests. 
  • Compliance with personal data security measures is a key requirement in the public sector. As Drupal conforms to the OWASP standards, its application guarantees the prevention of hazards to citizens’ personal data. 
  • Fast response to the challenges triggered by the pandemic was essential. Thus speed was one of the main reasons we built the Covid Helper tool in Drupal: the website and the first version of the mobile app was ready in less than 3 weeks using Drupal Contribution and core functionalities. 

Covid Helper registered more than 100 requests and 1000 visitors per day right after its release. As the pandemic evolved, the District Mayor’s Office came back with a demand for extended functionalities: version 2 allows for the registration of volunteer helpers, reducing pressure on the District Mayor’s Office. 

screenshot

Due to the severe economic crisis triggered by the pandemic, many of the requests registered on the platform were applications for financial aid. This induced the digitalization of the financial aid application process in the District, which will be also available through the Covid Helper website. 

The District Mayor’s Office issued a marketing campaign informing citizens about the Covid Helper tool on city billboards and through an animated video.

Besides all the challenges, covid-19 does seem to have kicked off the digitalization process at government authorities and public services. Tools developed to solve the current situation may be the source of best practices to create an effective e-government system in the near future. 
 

May 14 2020
May 14

Harish R Rao portraitContinuing our short series of articles highlighting ways that the Drupal software and its community are building solutions to help combat the effect of COVID-19, today we hear from Harish R. Rao of Interpersonal Frequency. Here, he describes their project at San Mateo County.

Under normal circumstances, a client asking for a new website “today” might seem laughable. But in the age of COVID-19, a quick turnaround on a new site could literally be a matter of life and death. In mid-March, San Mateo County, California reached out to the Interpersonal Frequency (I.F.) Solutions & Support team because their county, home to roughly 750,000 residents, had been one of the first in the U.S. to adopt a shelter-in-place order. The traffic on their county website had more than quintupled, and their current homepage was not working to convey vital and quickly evolving information in simple and accessible ways. 

Fortunately, San Mateo’s Drupal site was well-suited to the challenge. We knew we had the foundation for a solution, equipped to handle even a surge of visitors and able to support the rapid deployment of new content templates. 

We knew that our company was well-suited to the challenge, as well. Having collected aggregated analytics data and best practices from other civil emergencies, we understood the essentials needed, and we had clear indications of an urgent public need for COVID-19-related responses from municipal digital infrastructure. I.F. assembled a team of seven experts in content, user experience, and Drupal development. The team dove in to solve the specifics with the goal of supporting San Mateo’s residents and County staff as efficiently and effectively as possible. 

screenshot of the websiteOur team worked with the client to marry best practices with their specific needs, such as clearly communicating and providing access to the public services still available online and breaking down information silos between government departments. We identified priorities and set out to provide a one-stop-shop for local COVID-19 updates that would be accessible, mobile-responsive, user-centered, and easy to maintain and update. We also set out to create a solution that could launch and assist the public even as the county was still developing new interior pages and that could morph to support new priorities as the situation evolved. We needed a site that would work now, next week, next month, and beyond. 

Drupal allowed us to address all of these goals. After a near round-the-clock effort over six days -- including a weekend -- we deployed. The design launched as a system of content cards that could be rearranged and repurposed as needed. It was purposely mobile-forward and flexible. The county has continued to shape and adjust the site as the situation and their priorities evolve, and you can see the latest iteration at SMCgov.org
 

May 12 2020
May 12

This post was written collaboratively by tedbow and hestenet.

Project Update Bot now enabled for all projects

The initial testing period for the Project Update Bot is now complete, and the Bot has been enabled for all projects.

If you are a project maintainer and would like to understand how to control the bot for your projects, please consult the instructions on the bot's account page.

 

Drupal 9.0.0-beta2 has been released, and Drupal 9.0.0 is scheduled to be released on June 3, 2020. The upgrade from Drupal 8 to Drupal 9 should be the easiest major version update in the last decade of Drupal’s history. One of the reasons for this is because over 1,700 contributed modules already have a Drupal 9 compatible release. Making a module that's already compatible with Drupal 8 compatible with Drupal 9 just requires removing deprecations. When looking at just one module, these changes are usually trivial, but when we consider managing over 8,800  Drupal 8 modules on drupal.org the upgrade process could easily take hundreds or thousands of hours from the Drupal community.

Fortunately we can accelerate this process dramatically by using Drupal Rector, a tool developed by Palantir.net and  Pronovix. Drupal Rector can be used by developers to automatically fix many of the deprecations needed to make a module Drupal 9 compatible. In fact Drupal Rector can currently fix deprecations in more than 2000 existing projects on Drupal.org. Although using Drupal Rector is not difficult, running it manually on all Drupal 8 modules would have taken hundreds of developer hours to complete.

To accelerate upgrading of modules to Drupal 9 the Drupal Association has partnered with Acquia and Palantir to automatically provide patches generated by Drupal Rector for all contributed modules possible. For many modules these patches will be able to make the modules fully compatible with Drupal 9. For some modules it will still be necessary for a developer to manually replace other deprecations. Patches will also be provided for contributed themes but preparing a theme for Drupal 9 will require other changes such as updates for Twig 2.

These patches will be posted to issues created by the new Project Update Bot. An example issue can be seen here: https://www.drupal.org/project/entity_block_visibility/issues/3134823

The Project Update Bot is not associated with any individual or company and therefore will not affect issue credits for any individual or company. If maintainers find the patches provided by the bot useful they are welcome to credit the bot account as a way to provide feedback on this initiative.

It will be up to the project maintainers to decide if they want to use these patches but in many cases the patches can help speed up the process of updating a module for Drupal 9 dramatically.

Maintainer Options

For project maintainers there are a few options for dealing with these issues

  1. Leave the issue open and apply the provided patch to remove some or all Drupal 9 deprecations. The Project Update Bot will check weekly if Drupal Rector is able to remove new deprecations and post a new patch if possible.

  2. Remove the “ProjectUpdateBotD9” tag from the issue to stop new patches from being posted. If you would like to use the issue and the patch as a starting point simply remove this tag and the bot will not post any new patches. Add the tag back and the bot will post new patches if possible.

  3. Close the issue to stop the bot from posting new patches. If you are already handling deprecations in another issue or otherwise don’t find the patches helpful simply close the issue and the bot will not post any new patches

Providing feedback

If there are problems with one of the patches posted by the Project Update Bot, such as it does not correctly replace a deprecation, you can file an issue in the Rector issue queue. For other issues with the bot, for instance if the issue summary created by the bot is unclear,  use the Infrastructure project issue queue using the component “Bot: Drupal Rector”.

How can you help?

While Drupal Rector can currently fix some or all of the deprecations in over 2000 contributed modules to Drupal 9 it currently only covers 50% of total Drupal 9 deprecations. New Rector rules are being added with every new release of Drupal Rector. You can help by making new Drupal Rector rules which will make it possible for Drupal Rector to upgrade even more modules.

May 06 2020
May 06

Drupal 9 is going to be the easiest major version upgrade in a decade. With the release of Drupal 9, the project has proven its vision of transforming the development process with an emphasis on continuous innovation and a regular update cycle. Over the course of Drupal 8's lifecycle, we've seen this new strategy come to fruition with six-month minor releases including major feature improvements. With Drupal 9's release, we prove that major version upgrades are easier than ever before. 

D8 to What?

For the last 5 years, Drupal 8 has used its own dedicated drop logo, and as the release comes closer and closer, it's only become more important that we update the brand to help unify Drupal's identity across the ecosystem.

With Drupal 9's release less than 30 days away, we're confident that we've achieved the easy upgrade goal, and we are doubling down on that success with the new Drupal brand.

The new brand represents the fluidity and modularity of Drupal, and our community value of coming together to create a greater whole. The new logo can be used by itself, or alongside the Drupal wordmark.

This new design was chosen for its ability to represent Drupal not just at a single moment in time (for a single major release), but onward into the future. We expect to continue using this new iteration of the Drupal drop for the Drupal 9 lifecycle, through Drupal 10, and beyond.

While this continuity is the central element of this new design, there is sometimes a need to represent a specific version of Drupal. That could be for celebrating a particular release, or highlighting new features in a minor version. For that reason, the new Drupal drop may also be used with a version number at its side. 

Drupal Drop Stand Alone        Drupal Drop + Wordmark - Vertical        Drupal Drop + Version

How did we arrive at this new design?

Late last year the Drupal Association put together a request for proposals for design firms to help us develop the evergreen brand for Drupal. All of the responses we received were excellent, reflecting the incredible passion and pride in their work of the design firms that work in the Drupal space. Ultimately, we selected SixEleven who had previously helped us design the brand for DrupalCon.

Thank you, Sixeleven

We brought together a team of people to navigate this process. Dries Buytaert as project founder was joined by Drupal Association staff members Heather Rocker, Carrie Lacina, and myself, board members Audra Martin-Merrick and Suzanne Dergacheva, and longtime community leaders Angie Byron and Gábor Hojtsy.

SixEleven provided a series of initial design concepts which were reviewed by this team, each providing a different take on the classic Drupal brand. How would we emphasize human contribution? Drupal's evolutionary path? Continual innovation and growth?

Eventually we realized that we'd addressed these questions before. When working on the DrupalCon brand several years earlier we created an inner drop that represented all of these ideas, while still remaining classically and recognizably Drupal.

As many design undertakes often do, our vision suddenly came together - each drop falling into place to create the new brand. 

Brand Consistency 

When the inner drop design from the DrupalCon brand became a front-runner for the Drupal brand itself, we realized there was an important opportunity to create consistency across all of the Drupal brands.
Drupal Association         DrupalCon

As such, we've updated the Drupal Association brand as well, to use the new inner drop surrounded by our simple blue circle, representing all of the ways that the Association surrounds and supports the Drupal project. The DrupalCon brand will continue to use the drop on a colorful field of triangles, representing the diverse voices and communities we bring together with the event. 

What about the Druplicon?

The beloved community mascot hasn't gone anywhere. The new branding simply replaces the Drupal 8-specific logo that was in use for the past 5 years during Drupal 8's life cycle; it does not replace the Druplicon. The Druplicon still exists as an emblem of the Drupal Community and a mascot to be remixed and reused by local community organizations, as it has been throughout Drupal's history.

Here are just a few examples from https://www.druplicon.org/ 

Druplicon    Druplicon Remixes

Spreading the word

In the coming weeks, we'll be updating materials across Drupal.org to reflect the updated brand. We encourage you to update your own materials using the resources and brand guidelines we have made available.

We'd like to see all of the organizations that provide Drupal services, or that create software that integrates with Drupal, adopting the new brand in their own materials as well. Consistent use of the Drupal brand across the ecosystem helps us achieve the goal of creating more market recognition of the brand. Together we can spread the message of what Drupal has become. 

Download the new brand kit

May 04 2020
May 04

Paul johnsonContinuing our short series of articles highlighting ways that the Drupal software and its community are building solutions to help combat the effect of COVID-19, today we hear from Paul Johnson of CTI Digital. Here, he describes their project at the Arts Council England.

Arts Council England support and help fund cultural activities within local communities, arts organisations, museums and libraries. After the UK government mandated the closure of all cultural venues including national parks and theatres, The Arts Council have made available 160 million GBP of emergency funding  to offer individuals and organisations working in the cultural sector new financial support during this crisis.

The Arts Council is providing:

  • Up to 90 million for National Portfolio Organisations (NPOs) and Creative People and Places (CPPs) lead organisations
  • 50 million for organisations that are not in receipt of regular funding from the Arts Council
  • 20 million for artists, creative practitioners and freelancers

(These figures are correct at time of writing)

Their Drupal platform is central to making the funding available by providing information and access to funding applications. With an urgent need to accept and process high volumes of applications, the Arts Council found themselves in a strong position as their existing Drupal website easily accommodating rapid creation of new site sections without need for developer intervention.

Arts Council England quickly created detailed pages using existing components that lead users through the application process. Clear and accessible design patterns help users hone in on useful information that answers everything from where the funding comes from, to how to use the funding application system. 

This information is available alongside videos and help articles. All of the content is also entirely accessible and provides a smooth user experience at what can be a distressing time.

screenshot of arts council website

Critically, the Arts Council is able to continue to build new pages, extend pages, and update content as the government introduces new measures. 

The funding applications currently push through a dedicated grant-based system, but Arts Council England have the capability to manage applications directly within their Drupal platform if required at a later date. 

Learn more about the Arts Councils support for arts organisations and individuals on their website

Apr 28 2020
Apr 28

Portrait of Mike AnsleyContinuing our short series of articles highlighting ways that the Drupal software and its community are building solutions to help combat the effect of COVID-19, today we hear from Mike Ansley of Colorado Interactive. Here, he describes their project at the Colorado Department of Public Health & Environment and the Colorado Governor's Office.

Official State COVID19 Website

Colorado Interactive (CI) hosts, manages, and supports over 300 state and local government websites on its Drupal platform as the official portal integrator for Colorado’s Statewide Internet Portal Authority. In March 2020, Colorado Interactive proactively engaged the Department of Public Health & Environment (CDPHE), the agency leading the State’s COVID19 response. Leveraging Drupal’s flexibility and configurability, the CI team ultimately worked with CDPHE to develop, provision, and launch an entirely new, fully responsive COVID19 website.

The site immediately served as the State’s primary source of updates, aggregated data, and general information. To promote the resource, CI created a custom banner application in Drupal to implement universal COVID-19 messaging and links for its 300+ websites. 

CI’s Drupal platform enables CDPHE staff to manage site content and leverage custom design elements to provide the public with clear, uniform information, including the integration of data visualizations from the State’s Tableau server to graphically illustrate the number of cases, by county, age, date, etc. This data visualization site consistently has 67% of the entire site traffic across all hours of the day. At 4:00 pm each day, when CDPHE publishes the latest pandemic data set on the site, traffic grows from roughly 1,500 to tens of thousands of users on the site.

The highest number of users to the site was 99,684 users at 7:00 am on Thursday March 27, shortly after the Colorado Emergency Operations center included the site’s url in the message to announce the State’s Stay at Home Executive Order via the Emergency Alert System (distributing cell-phone alerts to statewide residents). Over its initial two weeks, there have been over 12 million page views and over 2 million user visits to the COVID-19 website, with average visit duration exceeding 2 minutes. In the initial month, over 3.6 million users visited the website.

Governor’s Stay-At-Home Resource Website

Colorado Interactive (CI) hosts, manages, and supports over 300 state and local government websites on its Drupal platform as the official portal integrator for Colorado’s Statewide Internet Portal Authority. CI developed and provisioned the State’s official COVID19 resource, a Drupal website for the Colorado Department of Public Health & Environment in March. In early April, immediately following the Governor of Colorado’s statewide Stay-At-Home Executive Order, CI responded to the Governor’s Office’s urgent request for a new website to aggregate resources for Coloradoans during the Order.

CI led a collaboration among the Governor’s Office, the Governor’s Innovative Response Team (IRT), and volunteers from the Citizen Software Engagement Group (CSEG) to design and publish an entirely new, fully responsive Drupal 8 website in less than 48 hours. The site features an online directory of services and resources available to Coloradoans as they face an extended period of a stay-at-home order. Visitors of the site can utilize extended predefined lists and key term search functionality to find resources. Via an integration with CI’s application tool, businesses and organizations can submit an online form to be included in the public-facing directory. The CI team also designed a new theme, including custom blocks to showcase highlight calls-to-action, drive ease of use, and accommodate easy admin management. The Governor’s Office, as well as a variety of public and private sector stakeholders, have since acknowledged CI’s Drupal website as a valuable resource in helping Coloradoans during the crisis.
 

Apr 24 2020
Apr 24

Taco PotzeTo open our short series of articles highlighting ways that the Drupal software and its community are building solutions to help combat the effect of COVID-19, today we hear from Taco Potze as they describe their project at the Biotechnology Innovation Organization.

The BIO Coronavirus Hub was rapidly created and deployed in 48 hours by the internal BIO Digital Team and Open Social. The Hub was developed as a response to the many requests from medical research centers, biopharmaceutical companies, testing developers, and testing sites for various supplies.

Open Social helped launch the new BIO Coronavirus Hub to connect companies and organizations that have relevant supplies, capacities, and resources to share, with those companies, researchers, or healthcare providers in need of those items. Already there 1200+ users with over 400 requests made inside the Hub.

BIO is the global trade association representing the biotechnology industry. Their role in this effort is to serve as a conduit to connect those in need with those who can share, many of whom may be BIO members. We do this through the BIO Coronavirus Hub, which is a public platform open to anyone in need and anyone who can help.

Drupal empowers Open Social to use its modules for people to use and build upon. Our existing ‘out of the box’ features included many of the functionalities BIO required. The most useful feature for them is the creation of a new supply/demand topic, which, when tagged with “supplies,” would be moved to a closed group after creation. The members of that group would then coordinate and process it.

The Group module in Open Social helped a lot here. We were able to quickly identify the tag and then move it to the group. This module ensured that we could empower BIO to achieve its mission. BIO could focus on configuring and filling their platform.

The speed with which this community was launched is a testament to how flexible Open Social and Drupal are. In this fast-moving environment, time is of the essence, through this hub BIO, and their partner Healthcare Ready was able to connect medical research centers, biopharmaceutical companies, and testing sites requesting supplies and inquiring about manufacturing capacity. 

Open Social continues to work together with BIO to improve the online Hub. 

Mar 31 2020
Mar 31

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

Blue heart

Today, I'm asking for your financial support for the Drupal Association. As we all know, we are living in unprecedented times, and the Drupal Association needs our help. With DrupalCon being postponed or potentially canceled, there will be a significant financial impact on our beloved non-profit.

Over the past twenty years, the Drupal project has weathered many storms, including financial crises. Every time, Drupal has come out stronger. As I wrote last week, I'm confident that Drupal and Open Source will weather the current storm as well.

While the future for Drupal and Open Source is in no doubt, the picture is not as clear for the Drupal Association.

Thirteen years ago, six years after I started Drupal, the Drupal Association was formed. As an Open Source non-profit, the Drupal Association's mission was to help grow and sustain the Drupal community. It still has that same mission today. The Drupal Association plays a critical role in Drupal's success: it manages Drupal.org, hosts Open Source collaboration tools, and brings the community together at events around the world.

The Drupal Association's biggest challenge in the current crisis is to figure out what to do about DrupalCon Minneapolis. The Coronavirus pandemic has caused the Drupal Association to postpone or perhaps even cancel DrupalCon Minneapolis.

With over 3,000 attendees, DrupalCon is not only the Drupal community's main event — it's also the most important financial lever to support the Drupal Association and the staff, services, and infrastructure they provide to the Drupal project. Despite efforts to diversify its revenue model, the Drupal Association remains highly dependent on DrupalCon.

No matter what happens with DrupalCon, there will be a significant financial impact to the Drupal Association. The Drupal Association is now in a position where it needs to find between $400,000 and $1.1 million USD depending on if we postpone or cancel the event.

In these trying times, the best of Drupal's worldwide community is already shining through. Some organizations and individuals proactively informed the Drupal Association that they could keep their sponsorship dollars or ticket price whether or not DrupalCon North America happens this year: Lullabot, Centarro, FFW, Palantir.net, Amazee Group and Contegix have come forward to pledge that they will not request a refund of their DrupalCon Minneapolis sponsorship, even if it will be cancelled. Acquia, my company, has joined in this campaign as well, and will not request a refund of its DrupalCon sponsorship either.

These are great examples of forward-thinking leadership and action, and is what makes our community so special. Not only do these long-time Drupal Association sponsors understand that the entire Drupal project benefits from the resources the Drupal Association provides for us — they also anticipated the financial needs the Drupal Association is working hard to understand, model and mitigate.

In order to preserve the Drupal Association, not just DrupalCon, more financial help is needed:

  • Consider making a donation to the Drupal Association.
  • Other DrupalCon sponsors can consider this year's sponsorship as a donation and not seek a refund should the event be cancelled, postponed or changed.
  • Individuals can consider becoming a member, increasing their membership level, or submitting an additional donation.

I encourage everyone in the Drupal community, including our large enterprise users, to come together and find creative ways to help the Drupal Association and each other. All contributions are highly valued.

The Drupal Association is not alone. This pandemic has wreaked havoc not only on other technology conferences, but on many organizations' fundamental ability to host conferences at all moving forward.

I want to thank all donors, contributors, volunteers, the Drupal Association staff, and the Drupal Association Board of Directors for helping us work through this. It takes commitment, leadership and courage to weather any storm, especially a storm of the current magnitude. Thank you!

Mar 26 2020
Mar 26

Drupal 9.0.0-beta2 has been released, and we are expanding the scope of our beta testing program for minor releases of Drupal core, to include this major release as well.

We need help testing the following upgrade paths:

Agencies and other organizations who are supporting ambitious Drupal 8 sites are invited to be part of the beta testing program. By participating, you can help core maintainers by following the guidelines of the Beta Testing Program to install the beta core release on real-world examples of Drupal websites, in their staging environments. Beta testers can then provide feedback to the core maintainers about any issues they see running the beta core release in a structured way.

Being part of the Beta Testing Program is a key contribution to the Drupal project and also helps organizations to be very aware of any changes relevant to their supported websites.

Would your organization, and the Drupal project, benefit from participating in the Beta Testing Program? We'd like to get as many organizations involved as possible, so we can have a robust test of Drupal 9 before the release date. 

You can apply to join here:

Apply to participate in the program

Who should apply?

Agencies and site owners who maintain large and complex Drupal 8 production sites. In particular, sites that use a wide range of contributed and custom modules or have large volumes of content.

How can I get ready? 

To prepare for testing these upgrade paths, the best thing to do is to install and run the Upgrade Status module. This module will tell you which of your installed modules are already ready for Drupal 9. You can also check your custom code using the Drupal Check command line tool, and even generate fixes for common incompatibilities using Drupal Rector

How will participants benefit from contributing in this way?

  • All organizations and individuals taking part in the testing will receive contribution credit for both testing the update and fixing any issues that arise.
  • Updating early helps find issues beforehand, rather than after the release is out.
  • Reporting issues encountered lets you tap the wealth of experience of the Drupal core contributors that you'd not have the same level of access to if you update on your own after the release.
  • You'll have satisfaction in the knowledge that you helped shape the next major release of Drupal core.
Mar 20 2020
Mar 20

Drupal 9.0.0-beta1 is available now. This release includes all the dependency updates, updated platform requirements (web server, PHP, and database versions), stable APIs, and features that will ship with Drupal 9. The stable Drupal 9.0.0 release is scheduled for June 3, 2020!

The beta release marks Drupal 9 as API-complete, so now is a great time to start getting your projects ready for Drupal 9. Most projects need a few small changes. A single project release can now be compatible with Drupal 8 and 9 at the same time, so you don't even need to release a new branch of your project to support Drupal 9.

Drupal 8.9.0 will also be released on June 3, 2020. It will contain the same features as Drupal 9.0.0 while keeping backwards compatibility with Drupal 8. This final minor version of Drupal 8 will receive long-term support, with bug fixes and security coverage until November 2021. Meanwhile, Drupal 9 will continue to receive new features in Drupal 9.1 (out in December, 2020) and beyond.

Mar 19 2020
Mar 19

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

The world is experiencing a scary time right now. People feel uncertain about the state of the world: we're experiencing a global pandemic, the OPEC is imploding, the trade war between the US and China could escalate, and stock markets around the world are crashing. Watching the impact on people's lives, including my own family, has been difficult.

People have asked me how this could impact Open Source. What is happening in the world is so unusual, it is hard to anticipate what exactly will happen. While the road ahead is unknown, the fact is that Open Source has successfully weathered multiple recessions.

While recessions present a difficult time for many, I believe Open Source communities have the power to sustain themselves during an economic downturn, and even to grow.

Firstly, large Open Source communities consist of people all around the world who believe in collective progress, building something great together, and helping one another. Open Source communities are not driven by top-line growth -- they're driven by a collective purpose, a big heart, and a desire to build good software. These values make Open Source communities both resilient and recharging.

Secondly, during an economic downturn, organizations will look to lower costs, take control of their own destiny, and strive to do more with less. Adopting Open Source helps these organizations survive and thrive.

Open Source continues to grow despite recessions

I looked back at news stories and data from the last two big recessions — the dot-com crash (2000-2004) and the Great Recession (2007-2009) — to see how Open Source fared.

According to an InfoWorld article from 2009, 2000-2001 (the dot-com crash) was one of the largest periods of growth for Open Source software communities.

Twenty years ago, Open Source was just beginning to challenge proprietary software in the areas of operating systems, databases, and middleware. According to Gartner, the dot-com bust catapulted Linux adoption into the enterprise market. Enterprise adoption accelerated because organizations looked into Open Source as a way to cut IT spending, without compromising on their own pace of innovation.

Eight years later, during the Great Recession, we saw the same trend. As Forrester observed in 2009, more companies started considering, implementing, and expanding their use of Open Source software.

Red Hat, the most prominent public Open Source company in 2009, was outperforming proprietary software giants. As Oracle's and Microsoft's profits dropped in early 2009, Red Hat's year-over-year revenue grew by 11 percent.

Anecdotally, I can say that starting Acquia during the Great Recession was scary, but ended up working out well. Despite the economic slump, Acquia continued to grow year-over-year revenues in the years following the Great Recession from 2009 to 2011.

I also checked in with some long-standing Drupal agencies and consultancies (LullabotPhase2 and Palantir.net), who all reported growing during the Great Recession. They attribute that growth directly to Drupal and the bump that Open Source received as a result of the recession. Again, businesses were looking at Open Source to be efficient without sacrificing innovation or quality.

Why Open Source will continue to grow and win

Fast forward another 10 years, and Open Source is still less expensive than proprietary software. In addition, Open Source has grown to be more secure, more flexible, and more stable than ever before. Today, the benefits of Open Source are even more compelling than during past recessions.

Open Source contribution can act as an important springboard for individuals in their careers as well. Developers who are unemployed often invest their time and talent back into Open Source communities to expand their skill sets or build out their resumes. People can both give and get from participating in Open Source projects.

That is true for organizations as well. Organizations around the world are starting to understand that contributing to Open Source can give them a competitive edge. By contributing to Open Source, and by sharing innovation with others, organizations can engage in a virtuous and compounding innovation cycle.

No one wants to experience another recession. But if we do, despite all of the uncertainty surrounding us today, I am optimistic that Open Source will continue to grow and expand, and that it can help many individuals and organizations along the way.

Feb 13 2019
Feb 13

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

An abstract image of three boxes

The web used to be server-centric in that web content management systems managed data and turned it into HTML responses. With the rise of headless architectures a portion of the web is becoming server-centric for data but client-centric for its presentation; increasingly, data is rendered into HTML in the browser.

This shift of responsibility has given rise to JavaScript frameworks, while on the server side, it has resulted in the development of JSON:API and GraphQL to better serve these JavaScript applications with content and data.

In this blog post, we will compare REST, JSON:API and GraphQL. First, we'll look at an architectural, CMS-agnostic comparison, followed by evaluating some Drupal-specific implementation details.

It's worth noting that there are of course lots of intricacies and "it depends" when comparing these three approaches. When we discuss REST, we mean the "typical REST API" as opposed to one that is extremely well-designed or following a specification (not REST as a concept). When we discuss JSON:API, we're referring to implementations of the JSON:API specification. Finally, when we discuss GraphQL, we're referring to GraphQL as it used in practice. Formally, it is only a query language, not a standard for building APIs.

The architectural comparison should be useful for anyone building decoupled applications regardless of the foundation they use because the qualities we will evaluate apply to most web projects.

To frame our comparisons, let's establish that most developers working with web services care about the following qualities:

  1. Request efficiency: retrieving all necessary data in a single network round trip is essential for performance. The size of both requests and responses should make efficient use of the network.
  2. API exploration and schema documentation: the API should be quickly understandable and easily discoverable.
  3. Operational simplicity: the approach should be easy to install, configure, run, scale and secure.
  4. Writing data: not every application needs to store data in the content repository, but when it does, it should not be significantly more complex than reading.

We summarized our conclusions in the table below, but we discuss each of these four categories (or rows in the table) in more depth below. If you aggregate the colors in the table, you see that we rank JSON:API above GraphQL and GraphQL above REST for Drupal core's needs.

REST JSON:API GraphQL Request efficiency Poor; multiple requests are needed to satisfy common needs. Responses are bloated. Excellent; a single request is usually sufficient for most needs. Responses can be tailored to return only what is required. Excellent; a single request is usually sufficient for most needs. Responses only include exactly what was requested. Documentation, API explorability and schema Poor; no schema, not explorable. Acceptable; generic schema only; links and error messages are self-documenting. Excellent; precise schema; excellent tooling for exploration and documentation. Operational simplicity Acceptable; works out of the box with CDNs and reverse proxies; few to no client-side libraries required. Excellent; works out of the box with CDNs and reverse proxies, no client-side libraries needed, but many are available and useful. Poor; extra infrastructure is often necessary client side libraries are a practical necessity, specific patterns required to benefit from CDNs and browser caches. Writing data Acceptable; HTTP semantics give some guidance but how specifics left to each implementation, one write per request. Excellent; how writes are handled is clearly defined by the spec, one write per request, but multiple writes is being added to the specification. Poor; how writes are handled is left to each implementation and there are competing best practices, it's possible to execute multiple writes in a single request.

If you're not familiar with JSON:API or GraphQL, I recommend you watch the following two short videos. They will provide valuable context for the remainder of this blog post:

Request efficiency

Most REST APIs tend toward the simplest implementation possible: a resource can only be retrieved from one URI. If you want to retrieve article 42, you have to retrieve it from https://example.com/article/42. If you want to retrieve article 42 and article 72, you have to perform two requests; one to https://example.com/article/42 and one to https://example.com/article/72. If the article's author information is stored in a different content type, you have to do two additional requests, say to https://example.com/author/3 and https://example.com/author/7. Furthermore, you can't send these requests until you've requested, retrieved and parsed the article requests (you wouldn't know the author IDs otherwise).

Consequently, client-side applications built on top of basic REST APIs tend to need many successive requests to fetch their data. Often, these requests can't be sent until earlier requests have been fulfilled, resulting in a sluggish experience for the website visitor.

GraphQL and JSON:API were developed to address the typical inefficiency of REST APIs. Using JSON:API or GraphQL, you can use a single request to retrieve both article 42 and article 72, along with the author information for each. It simplifies the developer experience, but more importantly, it speeds up the application.

Finally, both JSON:API and GraphQL have a solution to limit response sizes. A common complaint against typical REST APIs is that their responses can be incredibly verbose; they often respond with far more data than the client needs. This is both annoying and inefficient.

GraphQL eliminates this by requiring the developer to explicitly add each desired resource field to every query. This makes it difficult to over-fetchdata but easily leads to very large GraphQL queries, making (cacheable) GET requests impossible.

JSON:API solves this with the concept of sparse fieldsets or lists of desired resource fields. These behave in much the same fashion as GraphQL does, however, when they're omitted JSON:API will typically return all fields. An advantage, though, is that when a JSON:API query gets too large, sparse fieldsets can be omitted so that the request remains cacheable.

REST JSON:API GraphQL Multiple data objects in a single response Usually; but every implementation is different (for Drupal: custom "REST Export" view or custom REST plugin needed). Yes Yes Embed related data (e.g. the author of each article) No Yes Yes Only needed fields of a data object No Yes; servers may choose sensible defaults, developers must be diligent to prevent over-fetching. Yes; strict, but eliminates over-fetching, at the extreme, it can lead to poor cacheability.

Documentation, API explorability and schema

As a developer working with web services, you want to be able to discover and understand the API quickly and easily: what kinds of resources are available, what fields does each of them have, how are they related, etc. But also, if this field is a date or time, what machine-readable format is the date or time specified in? Good documentation and API exploration can make all the difference.

REST JSON:API GraphQL Auto-generated documentation Depends; if using the OpenAPI standard. Depends; if using the OpenAPI standard (formerly, Swagger). Yes; various tools available. Interactivity Poor; navigable links rarely available. Acceptable; observing available fields and links in its responses enable exploration of the API. Excellent; autocomplete feature, instant results or compilation errors, complete and contextual documentation. Validatable and programmable schema. Depends; if using the OpenAPI standard. Depends; the JSON:API specification defines a generic schema, but a reliable field-level schema is not yet available. Yes; a complete and reliable schema is provided (with very few exceptions).

GraphQL has superior API exploration thanks to GraphiQL (demonstrated in the video above), an in-browser IDE of sorts, which lets developers iteratively construct a query. As the developer types the query out, likely suggestions are offered and can be auto-completed. At any time, the query can be run and GraphiQL will display real results alongside the query. This provides immediate, actionable feedback to the query builder. Did they make a typo? Does the response look like what was desired? Additionally, documentation can be summoned into a flyout, when additional context is needed.

On the other hand, JSON:API is more self-explanatory: APIs can be explored with nothing more than a web browser. From within the browser, you can browse from one resource to another, discover its fields, and more. So, if you just want to debug or try something out, JSON:API is usable with nothing more than cURL or your browser. Or, you can use Postman (demonstrated in the video above) — a standalone environment for developing on top of an anyHTTP-based API. Constructing complex queries requires some knowledge, however, and that is where GraphQL's GraphiQL shines compared to JSON:API.

Operational simplicity

We use the term operational simplicity to encompass how easy it is to install, configure, run, scale and secure each of the solutions.

The table should be self-explanatory, though it's important to make a remark about scalability. To scale a REST-based or JSON:API-based web service so that it can handle a large volume of traffic, you can use the same approach websites (and Drupal) already use, including reverse proxies like Varnish or a CDN. To scale GraphQL, you can't rely on HTTP caching as with REST or JSON:API without persisted queries. Persisted queries are not part of the official GraphQL specification but they are a widely-adopted conventionamongst GraphQL users. They essentially store a query on the server, assign it an ID and permit the client to get the result of the query using a GETrequest with only the ID. Persisted queries add more operational complexity, and it also means the architecture is no longer fully decoupled — if a client wants to retrieve different data, server-side changes are required.

REST JSON:API GraphQL Scalability: additional infrastructure requirements Excellent; same as a regular website (Varnish, CDN, etc). Excellent; same as a regular website (Varnish, CDN, etc). Usually poor; only the simplest queries can use GET requests; to reap the full benefit of GraphQL, servers needs their own tooling. Tooling ecosystem Acceptable; lots of developer tools available, but for the best experience they need to be customized for the implementation. Excellent; lots of developer tools available; tools don't need to be implementation-specific. Excellent; lots of developer tools available; tools don't need to be implementation-specific. Typical points of failure Fewer; server, client. Fewer; server, client. Many; server, client, client-side caching, client and build tooling.

Writing data

For most REST APIs and JSON:API, writing data is as easy as fetching it: if you can read information, you also know how to write it. Instead of using the GET HTTP request type you use POST and PATCH requests. JSON:API improves on typical REST APIs by eliminating differences between implementations. There is just one way to do things and that enabled better, generic tooling and less time spent on server-side details.

The nature of GraphQL's write operations (called mutations) means that you must write custom code for each write operation; unlike JSON:API the specification, GraphQL doesn't prescribe a single way of handling write operations to resources, so there are many competing best practices. In essence, the GraphQL specification is optimized for reads, not writes.

On the other hand, the GraphQL specification supports bulk/batch operations automatically for the mutations you've already implemented, whereas the JSON:API specification does not. The ability to perform batch write operations can be important. For example, in our running example, adding a new tag to an article would require two requests; one to create the tag and one to update the article. That said, support for bulk/batch writes in JSON:APIis on the specification's roadmap.

REST JSON:API GraphQL Writing data Acceptable; every implementation is different. No bulk support. Excellent; JSON:API prescribes a complete solution for handling writes. Bulk operations are coming soon. Poor; GraphQL supports bulk/batch operations, but writes can be tricky to design and implement. There are competing conventions.

Drupal-specific considerations

Up to this point we have provided an architectural and CMS-agnostic comparison; now we also want to highlight a few Drupal-specific implementation details. For this, we can look at the ease of installation, automatically generated documentation, integration with Drupal's entity and field-level access control systems and decoupled filtering.

Drupal 8's REST module is practically impossible to set up without the contributed REST UI module, and its configuration can be daunting. Drupal's JSON:API module is far superior to Drupal's REST module at this point. It is trivial to set up: install it and you're done; there's nothing to configure. The GraphQL module is also easy to install but does require some configuration.

Client-generated collection queries allow a consumer to filter an application's data down to just what they're interested in. This is a bit like a Drupal View except that the consumer can add, remove and control all the filters. This is almost always a requirement for public web services, but it can also make development more efficient because creating or changing a listing doesn't require server-side configuration changes.

Drupal's REST module does not support client-generated collection queries. It requires a "REST Views display" to be setup by a site administrator and since these need to be manually configured in Drupal; this means a client can't craft its own queries with the filters it needs.

JSON:API and GraphQL, clients are able to perform their own content queries without the need for server-side configuration. This means that they can be truly decoupled: changes to the front end don't always require a back-end configuration change.

These client-generated queries are a bit simpler to use with the JSON:API module than they are with the GraphQL module because of how each module handles Drupal's extensive access control mechanisms. By default JSON:API ensures that these are respected by altering the incoming query. GraphQL instead requires the consumer to have permission to simply bypass access restrictions.

Most projects using GraphQL that cannot grant this permission use persisted queries instead of client-generated queries. This means a return to a more traditional Views-like pattern because the consumer no longer has complete control of the query's filters. To regain some of the efficiencies of client-generated queries, the creation of these persisted queries can be automated using front-end build tooling.

REST JSON:API GraphQL Ease of installation and configuration Poor; requires contributed module REST UI, easy to break clients by changing configuration. Excellent; zero configuration! Poor; more complex to use, may require additional permissions, configuration or custom code. Automatically generated documentation Acceptable; requires contributed module OpenAPI. Acceptable; requires contributed module OpenAPI. Excellent; GraphQL Voyager included. Security: content-level access control (entity and field access) Excellent; content-level access control respected. Excellent; content-level access control respected, even in queries. Acceptable; some use cases require the consumer to have permission to bypass all entity and/or field access. Decoupled filtering (client can craft queries without server-side intervention) No Yes Depends; only in some setups and with additional tooling/infrastructure.

What does this mean for Drupal's roadmap?

Drupal grew up as a traditional web content management system but has since evolved for this API-first world and industry analysts are praising us for it.

As Drupal's project lead, I've been talking about adding out-of-the-box support for both JSON:API and GraphQL for a while now. In fact, I've been very bullish about GraphQL since 2015. My optimism was warranted; GraphQL is undergoing a meteoric rise in interest across the web development industry.

Based on this analysis, for Drupal core's needs, we rank JSON:API above GraphQL and GraphQL above REST. As such, I want to change my recommendation for Drupal 8 core. Instead of adding both JSON:API and GraphQL to Drupal 8 core, I believe only JSON:API should be added. That said, Drupal's GraphQL implementation is fantastic, especially when you have the developer capacity to build a bespoke API for your project.

On the four qualities by which we evaluated the REST, JSON:API and GraphQL modules, JSON:API has outperformed its contemporaries. Its web standards-based approach, its ability to handle reads and writes out of the box, its security model and its ease of operation make it the best choice for Drupal core. Additionally, where JSON:API underperformed, I believe that we have a real opportunity to contribute back to the specification. In fact, one of the JSON:API module's maintainers and co-authors of this blog post, Gabe Sullice (Acquia), recently became a JSON:API specification editor himself.

This decision does not mean that you can't or shouldn't use GraphQL with Drupal. While I believe JSON:API covers the majority of use cases, there are valid use cases where GraphQL is a great fit. I'm happy that Drupal is endowed with such a vibrant contributed module ecosystem that provides so many options to Drupal's users.

I'm excited to see where both the JSON:API specification and Drupal's implementation of it goes in the coming months and years. As a first next step, we're preparing the JSON:API to be added to Drupal 8.7.

Special thanks to Wim Leers (Acquia) and Gabe Sullice (Acquia) for co-authoring this blog post and to Preston So (Acquia) and Alex Bronstein(Acquia) for their feedback during the writing process.

 February 11, 2019

 11 min read time

 Permalink

Feb 07 2019
Feb 07

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

I'm frequently sent examples of how Drupal has changed the lives of developers, business owners and end users. Recently, I received a very different story of how Drupal had helped in a rescue operation that saved a man's life.

The Snowdonia Ultra Marathon website

In early 2018, Race Director Mike Jones was looking to build a new website for the Ultra-Trail Snowdonia ultra marathon. He reached out to a good friend and developer, Rob Edwards, to lead the development of the website.

A photo of a runner at the Ultra-trail Snowdonia ultramarathon

© Ultra-trail Snowdonia and No Limits Photography

Rob chose Drupal for its flexibility and extensibility. As an organization supported heavily by volunteers, open source also fit the Snowdonia team's belief in community.

The resulting website, https://apexrunning.co/, included a custom-built timing module. This module allowed volunteers to register each runner and their time at every aid stop.

A runner goes missing

Rob attended the first day of Ultra-Trail Snowdonia to ensure the website ran smoothly. He also monitored the runners at the end of the race to certify they were all accounted for.

Monitoring the system into the early hours of the morning, Rob noticed one runner, after successfully completing checkpoints one and two, hadn't passed through the third checkpoint.

A photo of a runner at the Ultra-trail Snowdonia ultramarathon

© Ultra-trail Snowdonia and No Limits Photography

Each runner carried a mobile phone with them for emergencies. Mike attempted to make contact with the runner via phone to ensure he was safe. However, this specific area was known for its poor signal and the connection was too weak to get through.

After some more time eagerly watching the live updates, it was clear the runner hadn't reached checkpoint four and more likely hadn't ever made it past checkpoint three. The Ogwen Mountain Rescue were called to action.

Due to the terrain and temperature, searching for the lost runner on foot would be too slow. Instead, the mountain rescue volunteers used a helicopter to scan the area and locate the runner.

How Drupal came to the rescue

The area covered by runners in an ultra marathon like this one is vast. The custom-built timing module helped rescuers narrow down the search area; they knew the runner passed the second checkpoint but never made it to the third.

After following the fluorescent orange markers in the area pinpointed by the Drupal website, the team quickly found the individual. He had fallen and become too injured to carry on. A mild case of hypothermia had set in. The runner was airlifted to the hospital for appropriate care. The good news: the runner survived.

Without Drupal, it might have taken much longer to notify anyone that a runner had gone missing, and there would have been no way to tell when he had dropped off.

NFC and GPS devices are now being explored for these ultra marathon runners to carry with them to provide location data as an extra safety precaution. The Drupal system will be used alongside these devices for more accurate time readings, and Rob is looking into an API to pull this additional data into the Drupal website.

Stories about Drupal having an impact on organizations and individuals, or even helping out in emergencies, drive my sense of purpose. Feel free to keep sending them my way!

Special thanks to Rob EdwardsPoppy Heap (CTI Digital) and Paul Johnson (CTI Digital) for their help with this blog post.

Jan 29 2019
Jan 29

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

The European Commission worked with the Drupal Security Team to set aside 89,000€ (or roughly $100,000 USD) for a Drupal bug bounty.

An image of a shield with the Drupal mascot

The European Commission made an exciting announcement; it will be awarding bug bounties to the security teams of Open Source software projects that the European Commission relies on.

If you are not familiar with the term, a bug bounty is a monetary prize awarded to people who discover and correctly report security issues.

Julia Reda — an internet activist, Member of the European Parliament (MEP) and co-founder of the Free and Open Source Software Audit (FOSSA) project — wrote the following on her blog:

Like many other organizations, institutions like the European Parliament, the Council and the Commission build upon Free Software to run their websites and many other things. But the Internet is not only crucial to our economy and our administration, it is the infrastructure that runs our everyday lives.

With more than 150 Drupal sites, the European Commission is a big Drupal user, and has a large internal Drupal community. The European Commission set aside 89,000€ (or roughly $100,000 USD) for a Drupal bug bounty. They worked closely with Drupal's Security Team to set this up. To participate in the Drupal bug bounty, read the guidelines provided by Drupal's Security Team.

Over the years I've had many meetings with the European Commission, presented keynotes at some of its events, and more. During that time, I've seen the European Commission evolve from being hesitant about Open Source, to recognizing the many benefits that Open Source provides for its key ICT services, to truly embracing Open Source.

In many ways, the European Commission followed classic Open Source adoption patterns; adoption went from being technology-led (bottom-up or grassroots) to policy-led (top-down and institutionalized), and now the EU is an active participant and contributor.

Today, the European Commission is a shining example and role model for how governments and other large organizations can contribute to Open Source (just like how the White House used to be).

The European Commission is actually investing in Drupal in a variety of ways — the bug bounty is just one example of that — but more about that in a future blog post.

 January 28, 2019

 1 min read time

 Permalink

Jan 25 2019
Jan 25

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

Do I build my website with Drupal's built-in templating layer or do I use Drupal's decoupled or headless capabilities in combination with a JavaScript framework?

The pace of innovation in content management has been accelerating — driven by both the number of channels that content management systems need to support (web, mobile, social, chat) as well as the need to support JavaScript frameworks in the traditional web channel. As a result, we've seen headless or decoupled architectures emerge.

Decoupled Drupal has seen adoption from all corners of the Drupal community. In response to the trend towards decoupled architectures, I wrote blog posts in 2016 and 2018 for architects and developers about how and when to decouple Drupal. In the time since my last post, the surrounding landscape has evolved, Drupal's web services have only gotten better, and new paradigms such as static site generators and the JAMstack are emerging.

Time to update my recommendations for 2019! As we did a year ago, let's start with the 2019 version of the flowchart in full. (At the end of this post, there is also an accessible version of this flowchart described in words.)

A flowchart of how to decouple Drupal in 2019

Different ways to decouple Drupal

I want to revisit some of the established ways to decouple Drupal as well as discuss new paradigms that are seeing growing adoption. As I've written previously, the three most common approaches to Drupal architecture from a decoupled standpoint are traditional (or coupled), progressively decoupled, and fully decoupled. The different flavors of decoupling Drupal exist due to varying preferences and requirements.

In traditional Drupal, all of Drupal's usual responsibilities stay intact, as Drupal is a monolithic system and therefore maintains complete control over the presentation and data layers. Traditional Drupal remains an excellent choice for editors who need full control over the visual elements on the page, with access to features such as in-place editing and layout management. This is Drupal as we have known it all along. Because the benefits are real, this is still how most new content management projects are built.

Sometimes, JavaScript is required to deliver a highly interactive end-user experience. In this case, a decoupled approach becomes required. In progressively decoupled Drupal, a JavaScript framework is layered on top of the existing Drupal front end. This JavaScript might be responsible for nothing more than rendering a single block or component on a page, or it may render everything within the page body. The progressive decoupling paradigm lies on a spectrum; the less of the page dedicated to JavaScript, the more editors can control the page through Drupal's administrative capabilities.

Up until this year, fully decoupled Drupal was a single category of decoupled Drupal architecture that reflects a full separation of concerns between the presentation layer and all other aspects of the CMS. In this scenario, the CMS becomes a data provider, and a JavaScript application with server-side rendering becomes responsible for all rendering and markup, communicating with Drupal via web service APIs. Though key functionality like in-place editing and layout management are unavailable, fully decoupled Drupal is appealing for developers who want greater control over the front end and who are already experienced with building applications in frameworks like Angular, React, Vue.js, etc.

Over the last year, fully decoupled Drupal has branched into two separate paradigms due to the increasing complexity of JavaScript development. The so-called JAMstack (JavaScript, APIs, Markup) introduces a new approach: fully decoupled static sites. The primary reason for static sites is improved performance, security, and reduced complexity for developers. A static site generator like Gatsby will retrieve content from Drupal, generate a static website, and deploy that static site to a CDN, usually through a specialized cloud provider such as Netlify.

What do you intend to build?

The top section of the flowchart showing how to decouple Drupal in 2019

The essential question, as always, is what you're trying to build. Here is updated advice for architects exploring decoupled Drupal in 2019:

  1. If your intention is to build a single standalone website or web application, choosing decoupled Drupal may or may not be the right choice, depending on the features your developers and editors see as must-haves.
  2. If your intention is to build multiple web experiences (websites or web applications), you can use a decoupled Drupal instance either as a) a content repository without its own public-facing front end or b) a traditional website that acts simultaneously as a content repository. Depending on how dynamic your application needs to be, you can choose a JavaScript framework for highly interactive applications or a static site generator for mostly static websites.
  3. If your intention is to build multiple non-web experiences (native mobile or IoT applications), you can leverage decoupled Drupal to expose web service APIs and consume that Drupal site as a content repository without its own public-facing front end.

What makes Drupal so powerful is that it supports all of these use cases. Drupal makes it simple to build decoupled Drupal thanks to widely recognized standards such as JSON:APIGraphQLOpenAPI, and CouchDB. In the end, it is your technical requirements that will decide whether decoupled Drupal should be your next architecture.

In addition to technical requirements, organizational factors often come into play as well. For instance, if it is proving difficult to find talented front-end Drupal developers with Twig knowledge, it may make more sense to hire more affordable JavaScript developers instead and build a fully decoupled implementation.

Are there things you can't live without?

The middle section of the flowchart showing how to decouple Drupal in 2019

As I wrote last year, the most important aspect of any decision when it comes to decoupling Drupal is the list of features your project requires; the needs of editors and developers have to be carefully considered. It is a critical step in your evaluation process to weigh the different advantages and disadvantages. Every project should embark on a clear-eyed assessment of its organization-wide needs.

Many editorial and marketing teams select a particular CMS because of its layout capabilities and rich editing functionality. Drupal, for example, gives editors the ability to build layouts in the browser and drop-and-drag components into it, all without needing a developer to do it for them. Although it is possible to rebuild many of the features available in a CMS on a consumer application, this can be a time-consuming and expensive process.

In recent years, the developer experience has also become an important consideration, but not in the ways that we might expect. While the many changes in the JavaScript landscape are one of the motivations for developers to prefer decoupled Drupal, the fact that there are now multiple ways to write front ends for Drupal makes it easier to find people to work on decoupled Drupal projects. As an example, many organizations are finding it difficult to find affordable front-end Drupal developers experienced in Twig. Moving to a JavaScript-driven front end can resolve some of these resourcing challenges.

This balancing act between the requirements that developers prioritize and those that editors prioritize will guide you to the correct approach for your needs. If you are part of an organization that is mostly editorial, decoupled Drupal could be problematic, because it reduces the amount of control editors have over the presentation of their content. By the same token, if you are part of an organization with more developer resources, fully decoupled Drupal could potentially accelerate progress, with the warning that many mission-critical editorial features disappear.

Current and future trends to consider

A diagram showing a spectrum of site building solution; low-code solutions on the left and high-code solutions on the right

Over the past year, JavaScript frameworks have become more complex, while static site generators have become less complex.

One of the common complaints I have heard about the JavaScript landscape is that it shows fragmentation and a lack of cohesion due to increasing complexity. This has been a driving force for static site generators. Whereas two years ago, most JavaScript developers would have chosen a fully functional framework like Angular or Ember to create even simple websites, today they might choose a static site generator instead. A static site generator still allows them to use JavaScript, but it is simpler because performance considerations and build processes are offloaded to hosted services rather than the responsibility of developers.

I predict that static site generators will gain momentum in the coming year due to the positive developer experience they provide. Static site generators are also attracting a middle ground of both more experienced and less experienced developers.

Conclusion

Drupal continues to be an ideal choice for decoupled CMS architectures, and it is only getting better. The API-first initiative is making good progress on preparing the JSON:API module for inclusion in Drupal core, and the Admin UI and JavaScript Modernization initiative is working to dogfood Drupal's web services with a reinvented administrative interface. Drupal's support for GraphQL continues to improve, and now there is even a book on the subject of decoupled Drupal. It's clear that developers today have a wide range of ways to work with the rich features Drupal has to offer for decoupled architectures.

With the introduction of fully decoupled static sites as an another architectural paradigm that developers can select, there is an even wider variety of architectural possibilities than before. It means that the spectrum of decoupled Drupal approaches I defined last year has become even more extensive. This flexibility continues to define Drupal as an excellent CMS for both traditional and decoupled approaches, with features that go well beyond Drupal's competitors, including WordPress, Sitecore and Adobe. Regardless of the makeup of your team or the needs of your organization, Drupal has a solution for you.

Special thanks to Preston So for co-authoring this blog post and to Angie ByronChris HamperGabe SulliceLauri EskolaTed Bowman, and Wim Leers for their feedback during the writing process.

Accessible version of flowchart

This is an accessible and described version of the flowchart images earlier in this blog post. First, let us list the available architectural choices:

  • Coupled. Use Drupal as is without additional JavaScript (and as a content repository for other consumers).
  • Progressively decoupled. Use Drupal for initial rendering with JavaScript on top (and as a content repository for other consumers).
  • Fully decoupled static site. Use Drupal as a data source for a static site generator and, if needed, deploy to a JAMstack hosting platform.
  • Fully decoupled app. Use Drupal as a content repository accessed by other consumers (if JavaScript, use Node.js for server-side rendering).

Second, ask the question "What do you intend to build?" and choose among the answers "One experience" or "Multiple experiences".

If you are building one experience, ask the question "Is it a website or web application?" and choose among the answers "Yes, a single website or web application" or "No, Drupal as a repository for non-web applications only".

If you are building multiple experiences instead, ask the question "Is it a website or web application?" with the answers "Yes, Drupal as website and repository" or "No, Drupal as a repository for non-web applications only".

If your answer to the previous question was "No", then you should build a fully decoupled application, and your decision is complete. If your answer to the previous question was "Yes", then ask the question "Are there things the project cannot live without?"

Both editorial and developer needs are things that projects cannot live without, and here are the questions you need to ask about your project:

Editorial needs

  • Do editors need to manipulate page content and layout without a developer?
  • Do editors need in-context tools like in-place editing, contextual links, and toolbar?
  • Do editors need to preview unpublished content without custom development?
  • Do editors need content to be accessible by default like in Drupal's HTML?

Developer needs

  • Do developers need to have control over visual presentation instead of editors?
  • Do developers need server-side rendering or Node.js build features?
  • Do developers need JSON from APIs and to write JavaScript for the front end?
  • Do developers need data security driven by a publicly inaccessible CMS?

If, after asking all of these questions about things your project cannot live without, your answers show that your requirements reflect a mix of both editorial and developer needs, you should consider a progressively decoupled implementation, and your decision is complete.

If your answers to the questions about things your project cannot live without show that your requirements reflect purely developer needs, then ask the question "Is it a static website or a dynamic web application?" and choose among the answers "Static" or "Dynamic." If your answer to the previous question was "Static", you should build a fully decoupled static site, and your decision is complete. If your answer to the previous question was "Dynamic", you should build a fully decoupled app, and your decision is complete.

If your answers to the questions about things your project cannot live without show that your requirements reflect purely editorial needs, then ask two questions. Ask the first question, "Are there parts of the page that need JavaScript-driven interactions?" and choose among the answers "Yes" or "No." If your answer to the first question was "Yes", then you should consider a progressively decoupled implementation, and your decision is complete. If your answer to the first question was "No", then you should build a coupledDrupal site, and your decision is complete.

Then, ask the second question, "Do you need to access multiple data sources via API?" and choose among the answers "Yes" or "No." If your answer to the second question was "Yes", then you should consider a progressively decoupled implementation, and your decision is complete. If your answer to the second question was "No", then you should build a coupled Drupal site, and your decision is complete.

 Permalink

Jan 16 2019
Jan 16

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

Eighteen years ago today, I released Drupal 1.0.0. What started from humble beginnings has grown into one of the largest Open Source communities in the world. Today, Drupal exists because of its people and the collective effort of thousands of community members. Thank you to everyone who has been and continues to contribute to Drupal.

Eighteen years is also the voting age in the US, and the legal drinking age in Europe. I'm not sure which one is better. :) Joking aside, welcome to adulthood, Drupal. May your day be bug free and filled with fresh patches!

Jan 09 2019
Jan 09

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

Last year, I talked to nearly one hundred Drupal agency owners to understand what is preventing them from selling Drupal. One of the most common responses raised is that Drupal's administration UI looks outdated.

This critique is not wrong. Drupal's current administration UI was originally designed almost ten years ago when we were working on Drupal 7. In the last ten years, the world did not stand still; design trends changed, user interfaces became more dynamic and end-user expectations have changed with that.

To be fair, Drupal's administration UI has received numerous improvements in the past ten years; Drupal 8 shipped with a new toolbar, an updated content creation experience, more WYSIWYG functionality, and even some design updates.

A visual comparison of Drupal 7 and Drupal 8's administration UI

A comparison of the Drupal 7 and Drupal 8 content creation screen to highlight some of the improvements in Drupal 8.

While we made important improvements between Drupal 7 and Drupal 8, the feedback from the Drupal agency owners doesn't lie: we have not done enough to keep Drupal's administration UI modern and up-to-date.

This is something we need to address.

We are introducing a new design system that defines a complete set of principles, patterns, and tools for updating Drupal's administration UI.

In the short term, we plan on updating the existing administration UI with the new design system. Longer term, we are working on creating a completely new JavaScript-based administration UI.

A screenshot of the content administration using Drupal 8's Carlo theme

The content administration screen with the new design system.

As you can see on Drupal.org, community feedback on the proposal is overwhelmingly positive with comments like Wow! Such an improvement! and Well done! High contrast and modern look..

A screenshot of the spacing guidelines of Drupal 8's Carlo theme

Sample space sizing guidelines from the new design system.

I also ran the new design system by a few people who spend their days selling Drupal and they described it as "clean" with "good use of space" and a design they would be confident showing to prospective customers.

Whether you are a Drupal end-user, or in the business of selling Drupal, I recommend you check out the new design system and provide your feedback on Drupal.org.

Special thanks to Cristina ChumillasSascha EggenbergerRoy ScholtenArchita AroraDennis CohnRicardo MarcelinoBalazs KantorLewis Nyman,and Antonella Severo for all the work on the new design system so far!

We have started implementing the new design system as a contributed theme with the name Claro. We are aiming to release a beta version for testing in the spring of 2019 and to include it in Drupal core as an experimental theme by Drupal 8.8.0 in December 2019. With more help, we might be able to get it done faster.

Throughout the development of the refreshed administration theme, we will run usability studies to ensure that the new theme indeed is an improvement over the current experience, and we can iteratively improve it along the way.

Acquia has committed to being an early adopter of the theme through the Acquia Lightning distribution, broadening the potential base of projects that can test and provide feedback on the refresh. Hopefully other organizations and projects will do the same.

How can I help?

The team is looking for more designers and frontend developers to get involved. You can attend the weekly meetings on #javascript on Drupal Slack Mondays at 16:30 UTC and on #admin-ui on Drupal Slack Wednesdays at 14:30 UTC.

Thanks to Lauri EskolaGábor Hojtsy and Jeff Beeman for their help with this post.

File attachments:  drupal-7-vs-drupal-8-administration-ui-1280w.png carlo-content-administration-1280w.png carlo-spacing-1280w.png
Jan 05 2019
Jan 05

The Drupal Security Team is using funding from the EU-FOSS to pay for valid security issues found in Drupal 7 and 8 and top contributed modules. This program is open for participation by anyone.

The Drupal Security Team will be authorizing payment anywhere from €350 ($401) – €15.000 ($17,100) per issue. The more serious the issue, the more the Drupal Security Team will authorize for payment.

Who is running this program?

The Drupal Security Team with funds from the EU-FOSSA on the intigriti reporting platform.

What is covered?

Third-party libraries, even those bundled with Drupal core or contributed projects, are excluded from this program.

Can anyone participate?

You may not participate in this program if you fall into one of the following categories:

  • If you are a project maintainer (module, theme, etc), or you contribute a large amount to a project, you may not get paid for the project you maintain. This does not apply to Drupal Core.
  • You cannot report a bug you yourself created or committed. (If you find one, however, do report it via our normal processes (https://www.drupal.org/security-team/report-issue)

To get paid, you must have an account on Drupal.org.
Security Team members that are involved with the administration of this program and/or its funds are not eligible for payouts under the program.
This program is only valid for new issues submitted after 2019-01-29. (Duplicate reports of in-progress issues known to the Security Team may not eligible for payment.)
All issues submitted must be original research. Do not copy and paste results from a scanner without validating them first.

How can I get started?

Install a local copy of Drupal 8 or Drupal 7 from git (https://www.drupal.org/project/drupal/git-instructions). Find security issues such as XSS, SQL Injection, CSRF, Access Bypass etc.
Any submissions about a public Drupal website (including Drupal.org) will result in your account being blocked from any further payments. This bounty program applies to public Drupal open source code only. Not hosted website that run Drupal.

If you find a security issue you should:

  1. Write up the steps to reproduce the issue.
  2. Make sure you have a Drupal.org account created. Include this in your submission.
  3. Go to the intigriti platform and create a new report.
  4. WAIT, do not discuss or post anything anywhere yet. Members of the intigriti team and the Drupal Security Team must validate your report. This can take up to 3 weeks depending on the report and the complexity involved.
  5. If you have a valid report, we will issue payment. You still can not disclose this bug until we publish a release that fixes the bug.
  6. If you do not have a valid report, we will inform you as well.

What must be included in the report?

  • The reporter must provide a detailed explanation of the issue and steps to reproduce the issue.
  • The quality of the report will be taken into account when assigning a value to it.
  • We will also take into account the severity of the security issue.
  • Reporters will also need to confirm that the Drupal Security team will be the group to release the information.
  • Include your Drupal.org username.
  • Issues will be confirmed by the security team before payment is approved.

Do all security issues count?

Your testing should be done on a local environment, testing should NEVER be done on live Drupal sites. Any testing on ANY Drupal site that is not under your control (local or server you own) will automatically be rejected and your account blocked from further payment. We have a page on how to get started installing Drupal locally.

If a task requires the attacker to have advanced permissions as listed on our permission policy page (e.g. 'Access site reports', 'Administer users', 'Translate interface', etc.) will not be eligible for a payout. Other advanced permissions that are not white listed are at the discretion of the security team. Contributed modules (non-core code) must be eligible for a security advisory according to the security advisory policy. A list of projects currently eligible for the program is available.

Security issues excluded from the bounty program

The following are not being considered; while some may be legitimate security issues, they are out of scope for this bounty program.

  • Descriptive error messages (e.g. Stack Traces, application or server errors).
  • HTTP 404 codes/pages or other HTTP non-200 codes/pages.
  • Fingerprinting / banner disclosure on common/public services.
  • Disclosure of known public files or directories (e.g. robots.txt).
  • Clickjacking and issues only exploitable through clickjacking.
  • CSRF on forms that are available to anonymous users (e.g. the contact form).
  • Logout Cross-Site Request Forgery (logout CSRF).
  • Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.
  • Lack of Secure/HTTP-Only flags on non-sensitive Cookies.
  • Lack of Security Speedbump when leaving the site.
  • User enumeration.
  • Missing HTTP security headers
  • Any Denial of service attack.
  • Other exceptions not listed.
  • We would still like to know about issues in these categories, and you may still get credit for reporting them, but we will not be issuing payments for them.

Other questions?

Questions regarding additional specifics of this program should be emailed to [email protected].

Dec 21 2018
Dec 21

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

Drupal 8 has been growing 40 to 50 percent year over year. It's a healthy growth rate. Regardless, it is always worth exploring how we can continue to accelerate that growth.

Earlier this week, I wrote about the power of removing obstacles to growth, and shared how Amazon approaches its own growth blockers. Amazon identified at least two blockers for long-term growth: (1) shipping costs and (2) shipping times. For more than a decade, Amazon has been focused on eliminating both. They have spent an unbelievable amount of creativity, effort, time, and money to eliminate them.

In that blog post, I promised to share my thoughts around Drupal's own growth barriers. What obstacles can we eliminate to fuel Drupal's long-term growth? Well, I believe the limitations to Drupal's growth can be summarized as:

  1. Make Drupal easy to evaluate and adopt
  2. Make Drupal easy for content creators and site builders
  3. Reduce the total cost of ownership for developers and site owners
  4. Keep Drupal relevant and impactful
  5. Promote Drupal and help Drupal agencies win

For those that have read my blog or watched my DrupalCon keynote presentations, none of these will come as a surprise. Just like Amazon's examples, fixing these obstacles have been, and will be, multi-year efforts.

A mountain images with 5 product strategy tracks leading to the top

Drupal's five product strategy tracks. A number of current initiatives is shown on each track.

1. Make Drupal easy to evaluate and adopt

We need to make it easy for more people to try Drupal. To help evaluators explore Drupal's possibilities, we improved the download and installation experience, and included a demonstration site with core. We made fantastic progress on this in 2018.

Now that we have improved the evaluator experience, I'd love to see us focus on the "new user" experience. When you put yourself in the shoes of a new Drupal user, you'd still find it hard to set up a local development environment. There are too many options, too little direction, and no one official way for how to get started with Drupal. The "new user" is not receiving enough attention, and that slows adoption so I'd love to see us focus no that in 2019.

2. Make Drupal easy for content creators and site builders

One of the most powerful trends I've noticed time and time again is that simplicity wins. People expect software to be functionally powerful and easy to use. This is especially true for content creators and site builders.

To make Drupal easier to use for content creators and site builders, we've introduced WYSIWYG and in-place editing in Drupal 8.0, and now we're working hard on media management, layout building, content workflows and a new administration and authoring UI.

A lot of these initiatives add tools to the UI that empower content creators and site builders to do more with less code. Long term, I believe that we need to more of these "no-code" or "low-code" capabilities in Drupal.

3. Reduce the total cost of ownership for developers and site owners

Developers want to be agile, fast and deliver high quality projects that add value for their organization. Developers don't want their tools to get in the way.

For Drupal this means that they want to build sites, including themes and modules, without being bogged down by complex upgrades, expensive migrations or cumbersome developer workflows.

For developers and site owners we have made upgrades easier, we adopted a 6-month innovation model, and we extended security coverage for minor releases. This removes the complexity from major upgrades, gives organizations more time to upgrade, and allows us to release new capabilities more frequently. This is a very big deal for developer and site owners!

In addition, we're working on improving Drupal's Composer support and configuration management capabilities. This will help developers automate and streamline their day-to-day work.

Longer term, improved Composer support could act as a stepping stone towards automated updates, which would be one of the most effective ways to free up a developer's time.

4. Keep Drupal relevant and impactful

The innovation in the Drupal ecosystem happens thanks to Drupal contributors. We need to attract new contributors to Drupal, and keep existing contributors excited. This means we have to keep Drupal relevant and impactful.

To keep Drupal relevant, we've been investing in making Drupal an API-first platform for many years now. Headless Drupal or decoupled Drupal is one of Drupal's competitive advantages. Drupal's web service APIs allow developers to use Drupal with their JavaScript framework of choice, push content to different channels, and better integrate Drupal with different technologies in the marketing stack.

Drupal developers can now do unprecedented things with Drupal that weren't available before. JavaScript and mobile application developers have been familiarizing themselves with Drupal due to its improved API-first capabilities. All of this keeps Drupal relevant, ensures that Drupal has high impact, and that we attract new developers to Drupal.

5. Promote Drupal and help Drupal agencies win

While Drupal is well-known as an Open Source project, there isn't a deep understanding of how Drupal is evolving or how Drupal compares to its competitors.

Drupal is improving rapidly every six months with each new minor version release, but I'm not sure we're getting that message out effectively. We need to promote our amazing progress, not only to everyone in the web development community, but also to marketers and content managers, who are now often weighing in heavily on CMS decisions.

We do an incredible job collaborating on code — thousands of us are helping to build Drupal — but we do a poor job collaborating on marketing, education and promotion. Imagine what could happen if these thousands of individuals and agencies would all collaborate on promoting Drupal!

That is why the Drupal Association started the Promote Drupal initiative, and why we're trying to rally people in the community to work together on creating pitch decks, case studies, and other collateral to promote and market Drupal.

Here are a few things already happening:

  • There is an updated Drupal Brand Book for organizations to follow as they design Drupal marketing and sales materials.
  • A team of volunteers is creating a comprehensive Drupal pitch deck that Drupal agencies can use as a starting point when working with new clients.
  • DrupalCon will have new Content & Digital Marketing Track for marketing teams responsible for content generation, demand generation, user journeys, and more; and a "Agency Leadership Track" for those running Drupal agencies.
  • We will begin work on a competitive comparison chart — contrasting Drupal with other CMS competitors like Adobe, Sitecore, Contentful, WordPress, Prismic, and more.
  • A number of local Drupal Associations are hiring marketing people to help promote Drupal in their region.

Just like all open source contribution, it takes many to move things forward. So far, 40 people have signed up to help with these marketing efforts. If your organization has a marketing team that would like to contribute to the marketing of Drupal, check out the Promote Drupal initiative page and please join the Promote Drupal team.

Educating the world about how Drupal is evolving, the amazing use cases we support, and how Drupal compares to old and new competitors will go a very long way towards raising awareness of the project and growing the businesses built on and around Drupal.

Final thoughts

After talking to hundreds of Drupal users and would-be users, as well as dozens of agency owners, I believe we're working on the right things. Overcoming these growth obstacles are multi-year efforts. While the various initiatives might change, I believe we'll keep working on these four tracks for the next decade. We've been making steady progress the last few years but need to remain both patient and committed to driving them home. Just like Amazon continues to work on their growth obstacles after more than a decade, I expect we'll be working on these four obstacles for many years to come.

File attachments:  product-strategy-mountain-december-2018.jpg
Dec 12 2018
Dec 12

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Unfortunately Dries' blog does not allow for comments at the moment, feel free to post them here.

At Drupal Europe, I announced that Drupal 9 will be released in 2020. Although I explained why we plan to release in 2020, I wasn't very specific about when we plan to release Drupal 9 in 2020. Given that 2020 is less than thirteen months away (gasp!), it's time to be more specific.

Shifting Drupal's six month release cycle

A timeline that shows how we shifted Drupal 8's release windows

We shifted Drupal 8's minor release windows so we can adopt Symfony's releases faster.

Before I talk about the Drupal 9 release date, I want to explain another change we made, which has a minor impact on the Drupal 9 release date.

As announced over two years ago, Drupal 8 adopted a 6-month release cycle (two releases a year). Symfony, a PHP framework which Drupal depends on, uses a similar release schedule. Unfortunately the timing of Drupal's releases has historically occurred 1-2 months before Symfony's releases, which forces us to wait six months to adopt the latest Symfony release. To be able to adopt the latest Symfony releases faster, we are moving Drupal's minor releases to June and December. This will allow us to adopt the latest Symfony releases within one month. For example, Drupal 8.8.0 is now scheduled for December 2019.

We hope to release Drupal 9 on June 3, 2020

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.

A timeline that shows we hope to release Drupal 9 in June 2020

Planned Drupal 8 and 9 minor release dates.

We are building Drupal 9 in Drupal 8

Instead of working on Drupal 9 in a separate codebase, we are building Drupal 9 in Drupal 8. This means that we are adding new functionality as backwards-compatible code and experimental features. Once the code becomes stable, we deprecate any old functionality.

Let's look at an example. As mentioned, Drupal 8 currently depends on Symfony 3. Our plan is to release Drupal 9 with Symfony 4 or 5. Symfony 5's release is less than one year away, while Symfony 4 was released a year ago. Ideally Drupal 9 would ship with Symfony 5, both for the latest Symfony improvements and for longer support. However, Symfony 5 hasn't been released yet, so we don't know the scope of its changes, and we will have limited time to try to adopt it before Symfony 3's end-of-life.

We are currently working on making it possible to run Drupal 8 with Symfony 4 (without requiring it). Supporting Symfony 4 is a valuable stepping stone to Symfony 5 as it brings new capabilities for sites that choose to use it, and it eases the amount of Symfony 5 upgrade work to do for Drupal core developers. In the end, our goal is for Drupal 8 to work with Symfony 3, 4 or 5 so we can identify and fix any issues before we start requiring Symfony 4 or 5 in Drupal 9.

Another example is our support for reusable media. Drupal 8.0.0 launched without a media library. We are currently working on adding a media library to Drupal 8 so content authors can select pre-existing media from a library and easily embed them in their posts. Once the media library becomes stable, we can deprecate the use of the old file upload functionality and make the new media library the default experience.

The upgrade to Drupal 9 will be easy

Because we are building Drupal 9 in Drupal 8, the technology in Drupal 9 will have been battle-tested in Drupal 8.

For Drupal core contributors, this means that we have a limited set of tasks to do in Drupal 9 itself before we can release it. Releasing Drupal 9 will only depend on removing deprecated functionality and upgrading Drupal's dependencies, such as Symfony. This will make the release timing more predictable and the release quality more robust.

For contributed module authors, it means they already have the new technology at their service, so they can work on Drupal 9 compatibility earlier (e.g. they can start updating their media modules to use the new media library before Drupal 9 is released). Finally, their Drupal 8 know-how will remain highly relevant in Drupal 9, as there will not be a dramatic change in how Drupal is built.

But most importantly, for Drupal site owners, this means that it should be much easier to upgrade to Drupal 9 than it was to upgrade to Drupal 8. Drupal 9 will simply be the last version of Drupal 8, with its deprecations removed. This means we will not introduce new, backwards-compatibility breaking APIs or features in Drupal 9 except for our dependency updates. As long as modules and themes stay up-to-date with the latest Drupal 8 APIs, the upgrade to Drupal 9 should be easy. Therefore, we believe that a 12- to 18-month upgrade period should suffice.

So what is the big deal about Drupal 9, then?

The big deal about Drupal 9 is … that it should not be a big deal. The best way to be ready for Drupal 9 is to keep up with Drupal 8 updates. Make sure you are not using deprecated modules and APIs, and where possible, use the latest versions of dependencies. If you do that, your upgrade experience will be smooth, and that is a big deal for us.

Special thanks to Gábor Hojtsy (Acquia), Angie Byron (Acquia), xjm(Acquia), and catch for their input in this blog post.

Dec 10 2018
Dec 10

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

This week I was in New York for a day. At lunch, Sir Martin Sorrell pointed out that Microsoft overtook Apple as the most valuable software company as measured by market capitalization. It's a close call but Microsoft is now worth $805 billion while Apple is worth $800 billion.

What is interesting to me are the radical "ebbs and flows" of each organization.

In the '80s, Apple's market cap was twice that of Microsoft. Microsoft overtook Apple in the the early '90s, and by the late '90s, Microsoft's valuation was a whopping thirty-five times Apple's. With a 35x difference in valuation, no one would have guessed Apple to ever regain the number-one position. However, Apple did the unthinkable and regained its crown in market capitalization. By 2015, Apple was, once again, valued two times more than Microsoft.

And now, eighteen years after Apple took the lead, Microsoft has taken the lead again. Everything old is new again.

As you'd expect, the change in market capitalization corresponds with the evolution and commercial success of their product portfolios. In the '90s, Microsoft took the lead based on the success of the Windows operating system. Apple regained the crown in the 2000s based on the success of the iPhone. Today, Microsoft benefits from the rise of cloud computing, Software-as-a-Service and Open Source, while Apple is trying to navigate the saturation of the smartphone market.

It's unclear if Microsoft will maintain and extend its lead. On one hand, the market trends are certainly in Microsoft's favor. On the other hand, Apple still makes a lot more money than Microsoft. I believe Apple to be slightly undervalued, and Microsoft is to be overvalued. The current valuation difference is not justified.

At the end of the day, what I find to be most interesting is how both organizations have continued to reinvent themselves. This reinvention has happened roughly every ten years. During these periods of reinvention, organizations can fall out of favor for long stretches of time. However, as both organizations prove, it pays off to reinvent yourself, and to be patient product and market builders.

Dec 05 2018
Dec 05

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Last week, WordPress Tavern picked up my blog post about Drupal 8's upcoming Layout Builder.

While I'm grateful that WordPress Tavern covered Drupal's Layout Builder, it is not surprising that the majority of WordPress Tavern's blog post alludes to the potential challenges with accessibility. After all, Gutenberg's lack of accessibility has been a big topic of debate, and a point of frustration in the WordPress community.

I understand why organizations might be tempted to de-prioritize accessibility. Making a complex web application accessible can be a lot of work, and the pressure to ship early can be high.

In the past, I've been tempted to skip accessibility features myself. I believed that because accessibility features benefited a small group of people only, they could come in a follow-up release.

Today, I've come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.

As you can see in Drupal's Values and Principles, we are committed to building software that everyone can use. Accessibility should always be a priority. Making capabilities like the Layout Builder accessible is core to Drupal's DNA.

Drupal's Values and Principles translate into our development process, as what we call an accessibility gate, where we set a clearly defined "must-have bar." Prioritizing accessibility also means that we commit to trying to iteratively improve accessibility beyond that minimum over time.

Together with the accessibility maintainers, we jointly agreed that:

  1. Our first priority is WCAG 2.0 AA conformance. This means that in order to be released as a stable system, the Layout Builder must reach Level AA conformance with WCAG. Without WCAG 2.0 AA conformance, we won't release a stable version of Layout Builder.
  2. Our next priority is WCAG 2.1 AA conformance. We're thrilled at the greater inclusion provided by these new guidelines, and will strive to achieve as much of it as we can before release. Because these guidelines are still new (formally approved in June 2018), we won't hold up releasing the stable version of Layout Builder on them, but are committed to implementing them as quickly as we're able to, even if some of the items are after initial release.
  3. While WCAG AAA conformance is not something currently being pursued, there are aspects of AAA that we are discussing adopting in the future. For example, the new 2.1 AAA "Animations from Interactions", which can be framed as an achievable design constraint: anywhere an animation is used, we must ensure designs are understandable/operable for those who cannot or choose not to use animations.

Drupal's commitment to accessibility is one of the things that makes Drupal's upcoming Layout Builder special: it will not only bring tremendous and new capabilities to Drupal, it will also do so without excluding a large portion of current and potential users. We all benefit from that!

Dec 05 2018
Dec 05

The Drupal Association seeks volunteer organizations from Agency and Drupal site owners running production Drupal 8 sites for the creation of an official minor-release beta-testers program.

Since Drupal 8.0's release in November 2015, the Drupal community has successfully transitioned to a scheduled release process whereby two minor releases are made every year.

The most recent of these releases was Drupal 8.6, released in September 2018.

In a significant change from Drupal 7, these minor releases may contain new features and maintain backwards compatibility. This means that every six months there are new features in Drupal core, instead of waiting for the next major release.

This rapid acceleration in feature development has resulted in the need for greater real-world testing of upgrade paths and backwards compatibility. Drupal core has a vast automated test-suite comprising almost 25,000 tests—however, these can be greatly complemented by real-world testing of production sites. There are an infinite number of ways to put Drupal together that cannot always be handled in automated tests.

In order to improve the reliability of the minor-releases, the Drupal community—in conjunction with the Drupal Association—aims to develop a minor-release beta testers panel comprised of agencies and site-owners who maintain complex Drupal 8 production sites.

Many companies and Drupal users are looking to help with core development but aren't always sure where to start. Membership in this panel presents a new way to help the development of software that powers their website.

Who should apply?

Agencies and site owners who maintain large and complex Drupal 8 production sites. In particular, sites that use a wide range of contributed and custom modules or have large volumes of content.

What is involved?

When the beta release becomes available, the Drupal core committers will work in conjunction with the Drupal Association to contact the members of the beta-testing panel to advise that the next minor release is ready for testing.

Members of the panel will be asked to attempt updating to the beta using a staging version of their site (not straight-on production) and report back any issues found. New issues will be opened to track and resolve reported issues. The community will try to resolve the issue before the release deadline. If an issue cannot be resolved in time for the scheduled release, it will be documented in the release notes, or if it is severe enough, release managers may opt to revert the change that introduced the issue. Participants whose testing participation lapses may be removed from the program.

At the moment, testing of the new release occurs in a largely ad-hoc fashion, but once the program is established, this will become more structured and maintainers will have access to statistics regarding the breadth of testing. This will then inform release management decisions in regards to release preparedness.

What's in it for participants?

  • Updating early helps find issues beforehand, rather than after the release is out.

  • Reporting issues encountered lets you tap the wealth of experience of the Drupal core contributors that you'd not have the same level of access to if you update on your own after the release.

  • All organizations and individuals taking part in the testing will receive issue credits for both testing the update and fixing any issues that arise.

  • Satisfaction in the knowledge that you helped shape the next minor release of Drupal core.

  • Advanced preview of upcoming features in Drupal core.

Apply to participate in the program

Nov 14 2018
Nov 14

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

After months of hard work, the Drupal Governance Task Force made thirteen recommendations for how to evolve Drupal's governance.

If you want to go quickly, go alone. If you want to go far, go together.

Drupal exists because of its community. What started from humble beginnings has grown into one of the largest Open Source communities in the world. This is due to the collective effort of thousands of community members.

What distinguishes Drupal from other open source projects is both the size and diversity of our community, and the many ways in which thousands of contributors and organizations give back. It's a community I'm very proud to be a part of.

Without the Drupal community, the Drupal project wouldn't be where it is today and perhaps would even cease to exist. That is why we are always investing in our community and why we constantly evolve how we work with one another.

The last time we made significant changes to Drupal's governance was over five years ago when we launched a variety of working groups. Five years is a long time. The time had come to take a step back and to look at Drupal's governance with fresh eyes.

Throughout 2017, we did a lot of listening. We organized both in-person and virtual roundtables to gather feedback on how we can improve our community governance. This led me to invest a lot of time and effort in documenting Drupal's Values and Principles.

In 2018, we transitioned from listening to planning. Earlier this year, I chartered the Drupal Governance Task Force. The goal of the task force was to draft a set of recommendations for how to evolve and strengthen Drupal's governance based on all of the feedback we received. Last week, after months of work and community collaboration, the task force shared thirteen recommendations (PDF).

The proposal from the Drupal Governance Task Force

Me reviewing the Drupal Governance proposal on a recent trip.

Before any of us jump to action, the Drupal Governance Task Force recommended a thirty-day, open commentary period to give community members time to read the proposal and to provide more feedback. After the thirty-day commentary period, I will work with the community, various stakeholders, and the Drupal Association to see how we can move these recommendations forward. During the thirty-day open commentary period, you can then get involved by collaborating and responding to each of the individual recommendations below:

I'm impressed by the thought and care that went into writing the recommendations, and I'm excited to help move them forward.

Some of the recommendations are not new and are ideas that either the Drupal Association, myself or others have been working on, but that none of us have been able to move forward without a significant amount of funding or collaboration.

I hope that 2019 will be a year of organizing and finding resources that allow us to take action and implement a number of the recommendations. I'm convinced we can make valuable progress.

I want to thank everyone who has participated in this process. This includes community members who shared information and insight, facilitated conversations around governance, were interviewed by the task force, and supported the task force's efforts. Special thanks to all the members of the task force who worked on this with great care and determination for six straight months: Adam BergsteinLyndsey JacksonEla MeierStella PowerRachel LawsonDavid Hernandez and Hussain Abbas.

Nov 12 2018
Nov 12

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Layout Builder, which will be in the next release of Drupal 8, is unique in that it can work with structured and unstructured content, and with templated and free-form pages.

Content authors want an easy-to-use page building experience; they want to create and design pages using drag-and-drop and WYSIWYG tools. For over a year the Drupal community has been working on a new Layout Builder, which is designed to bring this page building capability into Drupal core.

Drupal's upcoming Layout Builder is unique in offering a single, powerful visual design tool for the following three use cases:

  1. Layouts for templated content. The creation of "layout templates" that will be used to layout all instances of a specific content type (e.g. blog posts, product pages).
  2. Customizations to templated layouts. The ability to override these layout templates on a case-by-case basis (e.g. the ability to override the layout of a standardized product page)
  3. Custom pages. The creation of custom, one-off landing pages not tied to a content type or structured content (e.g. a single "About us" page).

Let's look at all three use cases in more detail to explain why we think this is extremely useful!

Use case 1: Layouts for templated content

For large sites with significant amounts of content it is important that the same types of content have a similar appearance.

A commerce site selling hundreds of different gift baskets with flower arrangements should have a similar layout for all gift baskets. For customers, this provides a consistent experience when browsing the gift baskets, making them easier to compare. For content authors, the templated approach means they don't have to worry about the appearance and layout of each new gift basket they enter on the site. They can be sure that once they have entered the price, description, and uploaded an image of the item, it will look good to the end user and similar to all other gift baskets on the site.

The Drupal 8 Layout Builder showing a templated gift basket

Drupal 8's new Layout Builder allows a site creator to visually create a layout template that will be used for each item of the same content type (e.g. a "gift basket layout" for the "gift basket" content type). This is possible because the Layout Builder benefits from Drupal's powerful "structured content" capabilities.

Many of Drupal's competitors don't allow such a templated approach to be designed in the browser. Their browser-based page builders only allow you to create a design for an individual page. When you want to create a layout that applies to all pages of a specific content type, it is usually not possible without a developer.

Use case 2: Customizations to templated layouts

While having a uniform look for all products of a particular type has many advantages, sometimes you may want to display one or more products in a slightly (or dramatically) different way.

Perhaps a customer recorded a video of giving their loved one one of the gift baskets, and that video has recently gone viral (because somehow it involved a puppy). If you only want to update one of the gift baskets with a video, it may not make sense to add an optional "highlighted video" field to all gift baskets.

Drupal 8's Layout Builder offers the ability to customize templated layouts on a case per case basis. In the "viral, puppy, gift basket" video example, this would allow a content creator to rearrange the layout for just that one gift basket, and put the viral video directly below the product image. In addition, the Layout Builder would allow the site to revert the layout to match all other gift baskets once the world has moved on to the next puppy video.

The Drupal 8 Layout Builder showing a templated gift basket with a puppy video

Since most content management systems don't allow you to visually design a layout pattern for certain types of structured content, they of course can't allow for this type of customization.

Use case 3: Custom pages (with unstructured content)

Of course, not everything is templated, and content authors often need to create one-off pages like an "About us" page or the website's homepage.

In addition to visually designing layout templates for different types of content, Drupal 8's Layout Builder can also be used to create these dynamic one-off custom pages. A content author can start with a blank page, design a layout, and start adding blocks. These blocks can contain videos, maps, text, a hero image, or custom-built widgets (e.g. a Drupal View showing a list of the ten most popular gift baskets). Blocks can expose configuration options to the content author. For instance, a hero block with an image and text may offer a setting to align the text left, right, or center. These settings can be configured directly from a sidebar.

The Drupal 8 Layout Builder showing how to configure a block

In many other systems content authors are able to use drag-and-drop WYSIWYG tools to design these one-off pages. This type of tool is used in many projects and services such as Squarespace and the new Gutenberg Editor for WordPress (now available for Drupal, too!).

On large sites, the free-form page creation is almost certainly going to be a scalability, maintenance and governance challenge.

For smaller sites where there may not be many pages or content authors, these dynamic free-form page builders may work well, and the unrestricted creative freedom they provide might be very compelling. However, on larger sites, when you have hundreds of pages or dozens of content creators, a templated approach is going to be preferred.

When will Drupal's new Layout Builder be ready?

Drupal 8's Layout Builder is still a beta level experimental module, with 25 known open issues to be addressed prior to becoming stable. We're on track to complete this in time for Drupal 8.7's release in May 2019. If you are interested in increasing the likelihood of that, you can find out how to help on the Layout Initiative homepage.

An important note on accessibility

Accessibility is one of Drupal's core tenets, and building software that everyone can use is part of our core values and principles. A key part of bringing Layout Builder functionality to a "stable" state for production use will be ensuring that it passes our accessibility gate (Level AA conformance with WCAG and ATAG). This holds for both the authoring tool itself, as well as the markup that it generates. We take our commitment to accessibility seriously.

Impact on contributed modules and existing sites

Currently there a few methods in the Drupal module ecosystem for creating templated layouts and landing pages, including the Panels and Panelizer combination. We are currently working on a migration path for Panels/Panelizer to the Layout Builder.

The Paragraphs module currently can be used to solve several kinds of content authoring use-cases, including the creation of custom landing pages. It is still being determined how Paragraphs will work with the Layout Builder and/or if the Layout Builder will be used to control the layout of Paragraphs.

Conclusion

Drupal's upcoming Layout Builder is unique in that it supports multiple different use cases; from templated layouts that can be applied to dozens or hundreds of pieces of structured content, to designing custom one-off pages with unstructured content. The Layout Builder is even more powerful when used in conjunction with Drupal's other out-of-the-box features such as revisioning, content moderation, and translations, but that is a topic for a future blog post.

Special thanks to Ted Bowman (Acquia) for co-authoring this post. Also thanks to Wim Leers (Acquia), Angie Byron (Acquia), Alex Bronstein (Acquia), Jeff Beeman (Acquia) and Tim Plunkett (Acquia) for their feedback during the writing process.

Nov 09 2018
Nov 09

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

If you are still using PHP 5, now is the time to upgrade to a newer version of PHP.

PHP, the Open Source scripting language, is used by nearly 80 percent of the world's websites.

According to W3Techs, around 61 percent of all websites on the internet still use PHP 5, a version of PHP that was first released fourteen years ago.

Now is the time to give PHP 5 some attention. In less than two months, on December 31st, security support for PHP 5 will officially cease. (Note: Some Linux distributions, such as Debian Long Term Support distributions, will still try to backport security fixes.)

If you haven't already, now is the time to make sure your site is running an updated and supported version of PHP.

Beyond security considerations, sites that are running on older versions of PHP are missing out on the significant performance improvements that come with the newer versions.

Drupal and PHP 5

Drupal 8

Drupal 8 will drop support for PHP 5 on March 6, 2019. We recommend updating to at least PHP 7.1 if possible, and ideally PHP 7.2, which is supported as of Drupal 8.5 (which was released March, 2018). Drupal 8.7 (to be released in May, 2019) will support PHP 7.3, and we may backport PHP 7.3 support to Drupal 8.6 in the coming months as well.

Drupal 7

Drupal 7 will drop support for older versions of PHP 5 on December 31st, but will continue to support PHP 5.6 as long there are one or more third-party organizations providing reliable, extended security support for PHP 5.

Earlier today, we released Drupal 7.61 which now supports PHP 7.2. This should make upgrades from PHP 5 easier. Drupal 7's support for PHP 7.3 is being worked on but we don't know yet when it will be available.

Thank you!

It's a credit to the PHP community that they have maintained PHP 5 for fourteen years. But that can't go on forever. It's time to move on from PHP 5 and upgrade to a newer version so that we can all innovate faster.

I'd also like to thank the Drupal community — both those contributing to Drupal 7 and Drupal 8 — for keeping Drupal compatible with the newest versions of PHP. That certainly helps make PHP upgrades easier.

Nov 02 2018
Nov 02

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Configuration management is an important feature of any modern content management system. Those following modern development best-practices use a development workflow that involves some sort of development and staging environment that is separate from the production environment.

Configuration management example

Given such a development workflow, you need to push configuration changes from development to production (similar to how you need to push code or content between environments). Drupal's configuration management system helps you do that in a powerful yet elegant way.

Since I announced the original Configuration Management Initiative over seven years ago, we've developed and shipped a strong configuration management API in Drupal 8. Drupal 8's configuration management system is a huge step forward from where we were in Drupal 7, and a much more robust solution than what is offered by many of our competitors.

All configuration in a Drupal 8 site — from one-off settings such as site name to content types and field definitions — can be seamlessly moved between environments, allowing for quick and easy deployment between development, staging and production environments.

However, now that we have a couple of years of building Drupal 8 sites behind us, various limitations have surfaced. While these limitations usually have solutions via contributed modules, it has become clear that we would benefit from extending Drupal core's built-in configuration management APIs. This way, we can establish best practices and standard approaches that work for all.

Configuraton management initiative

The four different focus areas for Drupal 8. The configuration management initiative is part of the 'Improve Drupal for developers' track.

I first talked about this need in my DrupalCon Nashville keynote, where I announced the Configuration Management 2.0 initiative. The goal of this initiative is to extend Drupal's built-in configuration management so we can support more common workflows out-of-the-box without the need of contributed modules.

What is an example workflow that is not currently supported out-of-the-box? Support for different configurations by environment. This is a valuable use case because some settings are undesirable to have enabled in all environments. For example, you most likely don't want to enable debugging tools in production.

Configuration management example

The contributed module Config Filter extends Drupal core's built-in configuration management capabilities by providing an API to support different workflows which filter out or transform certain configuration changes as they are being pushed to production. Config Split, another contributed module, builds on top of Config Filter to allow for differences in configuration between various environments.

The Config Split module's use case is just one example of how we can improve Drupal's out-of-the-box configuration management capabilities. The community created a longer list of pain points and advanced use cases for the configuration management system.

While the initiative team is working on executing on these long-term improvements, they are also focused on delivering incremental improvements with each new version of Drupal 8, and have distilled the most high-priority items into a configuration management roadmap.

  • In Drupal 8.6, we added support for creating new sites from existing configuration. This enables developers to launch a development site that matches a production site's configuration with just a few clicks.
  • For Drupal 8.7, we're planning on shipping an experimental module for dealing with environment specific configuration, moving the capabilities of Config Filter and the basic capabilities of Config Split to Drupal core through the addition of a Configuration Transformer API.
  • For Drupal 8.8, the focus is on supporting configuration updates across different sites. We want to allow both sites and distributions to package configuration (similar to the well-known Features module) so they can easily be deployed across other sites.

How to get involved

There are many opportunities to contribute to this initiative and we'd love your help.

If you would like to get involved, check out the Configuration Management 2.0 project and various Drupal core issues tagged as "CMI 2.0 candidate".

Special thanks to Fabian Bircher (Nuvole), Jeff Beeman (Acquia), Angela Byron (Acquia), ASH (Acquia), and Alex Pott (Thunder) for contributions to this blog post.

Oct 29 2018
Oct 29

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

The cover of the Decoupled Drupal book

Drupal has evolved significantly over the course of its long history. When I first built the Drupal project eighteen years ago, it was a message board for my friends that I worked on in my spare time. Today, Drupal runs two percent of all websites on the internet with the support of an open-source community that includes hundreds of thousands of people from all over the world.

Today, Drupal is going through another transition as its capabilities and applicability continue to expand beyond traditional websites. Drupal now powers digital signage on university campuses, in-flight entertainment systems on commercial flights, interactive kiosks on cruise liners, and even pushes live updates to the countdown clocks in the New York subway system. It doesn't stop there. More and more, digital experiences are starting to encompass virtual reality, augmented reality, chatbots, voice-driven interfaces and Internet of Things applications. All of this is great for Drupal, as it expands its market opportunity and long-term relevance.

Several years ago, I began to emphasize the importance of an API-first approach for Drupal as part of the then-young phenomenon of decoupled Drupal. Now, Drupal developers can count on JSON API, GraphQL and CouchDB, in addition to a range of surrounding tools for developing the decoupled applications described above. These decoupled Drupal advancements represent a pivotal point in Drupal's history.

Decoupled Drupal sites

A few examples of organizations that use decoupled Drupal.

Speaking of important milestones in Drupal's history, I remember the first Drupal book ever published in 2005. At the time, good information on Drupal was hard to find. The first Drupal book helped make the project more accessible to new developers and provided both credibility and reach in the market. Similarly today, decoupled Drupal is still relatively new, and up-to-date literature on the topic can be hard to find. In fact, many people don't even know that Drupal supports decoupled architectures. This is why I'm so excited about the upcoming publication of a new book entitled Decoupled Drupal in Practice, written by Preston So. It will give decoupled Drupal more reach and credibility.

When Preston asked me to write the foreword for the book, I jumped at the chance because I believe his book will be an important next step in the advancement of decoupled Drupal. I've also been working with Preston So for a long time. Preston is currently Director of Research and Innovation at Acquia and a globally respected expert on decoupled Drupal. Preston has been involved in the Drupal community since 2007, and I first worked with him directly in 2012 on the Spark initiative to improve Drupal's editorial user experience. Preston has been researching, writing and speaking on the topic of decoupled Drupal since 2015, and had a big impact on my thinking on decoupled Drupal, on Drupal's adoption of React, and on decoupled Drupal architectures in the Drupal community overall.

To show the value that this book offers, you can read exclusive excerpts of three chapters from Decoupled Drupal in Practice on the Acquia blog and at the Acquia Developer Center. It is available for preorder today on Amazon, and I encourage my readers to pick up a copy!

Congratulations on your book, Preston!

Sep 17 2018
Sep 17

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Last week, nearly 1,000 Drupalists gathered in Darmstadt, Germany for Drupal Europe. In good tradition, I presented my State of Drupal keynote. You can watch a recording of my keynote (starting at 4:38) or download a copy of my slides (37 MB).

Drupal 8 continues to mature

I started my keynote by highlighting this month's Drupal 8.6.0 release. Drupal 8.6 marks the sixth consecutive Drupal 8 release that has been delivered on time. Compared to one year ago, we have 46 percent more stable Drupal 8 modules. We also have 10 percent more contributors are working on Drupal 8 Core in comparison to last year. All of these milestones indicate that the Drupal 8 is healthy and growing.

The number of stable modules for Drupal 8 is growing fast

Next, I gave an update on our strategic initiatives:

An overview of Drupal 8's strategic initaitives

Make Drupal better for content creators

A photo from Drupal Europe in Darmstadt

© Paul Johnson

The expectations of content creators are changing. For Drupal to be successful, we have to continue to deliver on their needs by providing more powerful content management tools, in addition to delivering simplicity though drag-and-drop functionality, WYSIWYG, and more.

With the release of Drupal 8.6, we have added new functionality for content creators by making improvements to the Media, Workflow, Layout and Out-of-the-Box initiatives. I showed a demo video to demonstrate how all of these new features not only make content authoring easier, but more powerful:

We also need to improve the content authoring experience through a modern administration user interface. We have been working on a new administration UI using React. I showed a video of our latest prototype:

Extended security coverage for Drupal 8 minor releases

I announced an update to Drupal 8's security policy. To date, site owners had one month after a new minor Drupal 8 release to upgrade their sites before losing their security updates. Going forward, Drupal 8 site owners have 6 months to upgrade between minor releases. This extra time should give site owners flexibility to plan, prepare and test minor security updates. For more information, check out my recent blog post.

Make Drupal better for evaluators

One of the most significant updates since DrupalCon Nashville is Drupal's improved evaluator experience. The time required to get a Drupal site up and running has decreased from more than 15 minutes to less than two minutes and from 20 clicks to 3. This is a big accomplishment. You can read more about it in my recent blog post.

Promote Drupal

After launching Promote Drupal at DrupalCon Nashville, we hit the ground running with this initiative and successfully published a community press release for the release of Drupal 8.6, which was also translated into multiple languages. Much more is underway, including building a brand book, marketing collaboration space on Drupal.org, and a Drupal pitch deck.

The Drupal 9 roadmap and a plan to end-of-life Drupal 7 and Drupal 8

To keep Drupal modern, maintainable, and performant, we need to stay on secure, supported versions of Drupal 8's third-party dependencies. This means we need to end-of-life Drupal 8 with Symfony 3's end-of-life. As a result, I announced that:

  1. Drupal 8 will be end-of-life by November 2021.
  2. Drupal 9 will be released in 2020, and it will be an easy upgrade.

Historically, our policy has been to only support two major versions of Drupal; Drupal 7 would ordinarily reach end of life when Drupal 9 is released. Because a large number of sites might still be using Drupal 7 by 2020, we have decided to extend support of Drupal 7 until November 2021.

For those interested, I published a blog post that further explains this.

Adopt GitLab on Drupal.org

Finally, the Drupal Association is working to integrate GitLab with Drupal.org. GitLab will provide support for "merge requests", which means contributing to Drupal will feel more familiar to the broader audience of open source contributors who learned their skills in the post-patch era. Some of GitLab's tools, such as inline editing and web-based code review, will also lower the barrier to contribution, and should help us grow both the number of contributions and contributors on Drupal.org.

To see an exciting preview of Drupal.org's gitlab integration, watch the video below:

Thank you

Our community has a lot to be proud of, and this progress is the result of thousands of people collaborating and working together. It's pretty amazing! The power of our community isn't just visible in minor releases or a number of stable modules. It was also felt at this very conference, as many volunteers gave their weekends and evenings to help organize Drupal Europe in the absence of a DrupalCon Europe organized by the Drupal Association. From code to community, the Drupal project is making an incredible impact. I look forward to celebrating our community's work and friendships at future Drupal conferences.

A summary of our recent progress

Sep 14 2018
Sep 14

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Seven months ago, Matthew Grasmick published an article describing how hard it is to install Drupal. His article included the following measurements for creating a new application on his local machine, across four different PHP frameworks:

Platform Clicks Time Drupal 20+ 15:00+ Symfony 3 1:55 WordPress 7 7:51 Laravel 3 17:28

The results from Matthew's blog were clear: Drupal is too hard to install. It required more than 15 minutes and 20 clicks to create a simple site.

Seeing these results prompted me to launch a number of initiatives to improve the evaluator experience at DrupalCon Nashville. Here is the slide from my DrupalCon Nashville presentation:

Improve technical evaluator experience

A lot has happened between then and now:

  • We improved the download page to improve the discovery experience on drupal.org
  • We added an Evaluator Guide to Drupal.org
  • We added a quick-start command to Drupal 8.6
  • We added the Umami demo profile to Drupal 8.6
  • We started working on a more modern administration experience (in progress)

You can see the result of that work in this video:

Thanks to this progress, here is the updated table:

Platform Clicks Time Drupal 3 1:27 Symfony 3 1:55 WordPress 7 7:51 Laravel 3 17:28

Drupal now requires the least time and is tied for least clicks! You can now install Drupal in less than two minutes. Moreover, the Drupal site that gets created isn't an "empty canvas" anymore; it's a beautifully designed and fully functional application with demo content.

Copy-paste the following commands in a terminal window if you want to try it yourself:

mkdir drupal && cd drupal && curl -sSL https://www.drupal.org/download-latest/tar.gz | tar -xz --strip-components=1
php core/scripts/drupal quick-start demo_umami

For more detailed information on how we achieved these improvements, read Matthew's latest blog post: The New Drupal Evaluator Experience, by the numbers.

A big thank you to Matthew Grasmick (Acquia) for spearheading this initiative!

Sep 13 2018
Sep 13

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Since the launch of Drupal 8.0, we have successfully launched a new minor release on schedule every six months. I'm very proud of the community for this achievement. Prior to Drupal 8, most significant new features were only added in major releases like Drupal 6 or Drupal 7. Thanks to our new release cadence we now consistently and predictably ship great new features twice a year in minor releases (e.g. Drupal 8.6 comes with many new features).

However, only the most recent minor release has been actively supported for both bug fixes and security coverage. With the release of each new minor version, we gave a one-month window to upgrade to the new minor. In order to give site owners time to upgrade, we would not disclose security issues with the previous minor release during that one-month window.

Old Drupal 8 security policy for minor releases

Illustration of the security policy since the launch of Drupal 8.0 for minor releases, demonstrating that previous minor releases receive one month of security coverage. Source: Drupal.org issue #2909665: Extend security support to cover the previous minor version of Drupal and Drupal Europe DriesNote.

Over the past three years, we have learned that users find it challenging to update to the latest minor in one month. Drupal's minor updates can include dependency updates, internal API changes, or features being transitioned from contributed modules to core. It takes time for site owners to prepare and test these types of changes, and a window of one month to upgrade isn't always enough.

At DrupalCon Nashville we declared that we wanted to extend security coverage for minor releases. Throughout 2018, Drupal 8 release managers quietly conducted a trial. You may have noticed that we had several security releases against previous minor releases this year. This trial helped us understand the impact to the release process and learn what additional work remained ahead. You can read about the results of the trial at #2909665: Extend security support to cover the previous minor version of Drupal.

I'm pleased to share that the trial was a success! As a result, we have extended the security coverage of minor releases to six months. Instead of one month, site owners now have six months to upgrade between minor releases. It gives teams time to plan, prepare and test updates. Releases will have six months of normal bug fix support followed by six months of security coverage, for a total lifetime of one year. This is a huge win for Drupal site owners.

New Drupal 8 security policy for minor releases

Illustration of the new security policy for minor releases, demonstrating that the security coverage for minor releases is extended to six months. Source: Drupal.org issue #2909665: Extend security support to cover the previous minor version of Drupal and the Drupal Europe DriesNote.

It's important to note that this new policy only applies to Drupal 8 core starting with Drupal 8.5, and only applies to security issues. Non-security bug fixes will still only be committed to the actively supported release.

While the new policy will provide extended security coverage for Drupal 8.5.x, site owners will need to update to an upcoming release of Drupal 8.5 to be correctly notified about their security coverage.

Next steps

We still have some user experience issues we'd like to address around how site owners are alerted of a security update. We have not yet handled all of the potential edge cases, and we want to be very clear about the potential actions to take when updating.

We also know module developers may need to declare that a release of their project only works against specific versions of Drupal core. Resolving outstanding issues around semantic versioning support for contrib and module version dependency definitions will help developers of contributed projects better support this policy. If you'd like to get involved in the remaining work, the policy and roadmap issue on Drupal.org is a great place to find related issues and see what work is remaining.

Special thanks to Jess and Jeff Beeman for co-authoring this post.

Pages

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