The State of Georgia’s Digital Services team (DSGa) supports a network of over 100 websites running on Drupal. Originally built in Drupal 7, DSGa began transitioning to a new Drupal 8 platform in 2019. Until this transition is completed, DSGa is responsible for supporting both Drupal 7 and Drupal 8 sites.
Sites in the network need the capacity to search content from both their own site and other sites, regardless of the version of Drupal being used. While both platforms are hosted on Acquia and use Acquia Search, their Drupal 7 search solution could not incorporate content from the new Drupal 8 sites. This left the DSGa team in an awkward position: either lose functionality while they waited for sites to transition to Drupal 8 or delay the launch of the new platform until all sites were ready.
Fortunately, there was another option. Using the open source Federated Search solution, Palantir collaborated with the DSGa and their development partners to re-launch network-wide search with added functionality in both Drupal 8 and Drupal 7 without any service interruption for site visitors.
What’s new in Drupal 8.7.0?
This release introduces powerful features that will help us all take Drupal to a whole new level. The new stable JSON:API core module as well as the intuitive and accessible stable Layout Builder are game-changing.
Layout Builder is stable
The Layout Builder module was originally introduced as an experimental module in Drupal 8.5.0. As of Drupal 8.7.0, Layout Builder is now stable and ready for production use! It provides a powerful, accessible, mobile-friendly page building tool that is fully compatible with revisions, workflows, and in-context previews.
The Layout Builder enables site builders to rapidly create layout templates for content that speed up the development process. It also permits content authors to easily customize individual pages with unique layouts.
The interface allows drag-and-drop management of your content blocks. It additionally supports keyboard controls and toggling the content preview on and off to give the content editor complete control of their experience while building their layouts.
The result of all these features is a state-of-the art content management solution that streamlines mass-production while also supporting unique creation. 123 individuals and 68 organizations contributed to this feature. More than 40 of the individual contributors volunteered some or all of their time.
Check out this demonstration based on the core Umami demo:
The team is working on implementing translation support for layouts in a future release.
New stable JSON:API support
JSON:API support is now included as a stable core feature. The JSON:API specification is an easy and fast way to build decoupled applications. Drupal core's JSON:API module is feature-complete and easy to use with robust out-of-the-box support and simple setup. JSON:API makes it simpler than ever to build ambitious projects. 147 contributors and 76 organizations contributed to this new feature. Among the individual contributors, more than 50 volunteered some or all of their time.
For example, by simply navigating to a URL like
https://example.com/jsonapi/node/article, you can get a list of available articles on your site, and filter further from there, to display your Drupal content in decoupled websites, mobile applications, and so on.
Improvements in experimental Media Library
The experimental Media Library has numerous significant improvements in this release. The Media Library is built on top of the stable Media module, which allows reuse of images, documents, and even embedded remote media like YouTube videos. Items in the Media Library can be managed with drag-and-drop. This release improves the design and accessibility of the user interface, allows inline media creation in the library, and provides more flexible grid and table views. 310 contributors and 122 organizations contributed to this new feature. More than 100 individuals volunteered some or all of their time!
Check out this demonstration based the core Umami demo with Media Library enabled:
There are various tasks left to make Media Library stable in a future release, including WYSIWYG integration.
Revisionable menus and taxonomy terms
Custom menu links and taxonomy terms are now revisionable, which allows them to be used in editorial workflows (similarly to nodes, media, and custom blocks). The Entity system now also provides a new Update API to support conversion of further entity types. It supports converting the schema of any content entity type between non-revisionable or non-translatable and revisionable or translatable, which also works when there is pre-existing data for the entity type whose schema is being changed. All these changes improve core support for the Workspaces module.
New features in the Umami demo profile
The Umami food magazine demo is now more accessible and demonstrates more features out of the box, including a new welcome tour, Layout Builder integration for recipes, and multilingual features. The profile now includes a curated set of Spanish translations, and more languages are in the works. 187 contributors and 84 organizations have contributed to Umami, with more than 60 individuals volunteering some or all of their time.
Umami empowers first-time users to spin up a Drupal project in no time so that they can use to evaluate Drupal and learn about its major components.
On the way to Drupal 9
Drupal 8.7.0 includes optional support for Twig 2 (for sites that can patch their Composer configuration). Optional support for Symfony 4 also received a lot of contributions and should be complete in 8.8. This is important work, because Drupal 9 is planned for June 3, 2020 and will update various dependencies, primarily Symfony. Testing Drupal with updated third-party dependencies will help us get better feedback on our compatibility with these dependencies and any difficulties sites encounter when upgrading.
What does this mean for me?
Drupal 8 site owners
Update to 8.7.0 to continue receiving bug fixes. The next bugfix release (8.7.1) is scheduled for June 5, 2019. (See the release schedule overview for more information.) As of this release, sites on Drupal 8.5 will no longer receive security coverage. (Drupal 8.6 will continue receiving security fixes until December 4, 2019.)
Note that new Drupal 8.7.0 installs now require at least PHP 7.0.8. Existing sites still work on at least PHP 5.5.9 for now, but will display a warning. Drupal security updates will begin requiring PHP 7 as early as Drupal 8.8.0 (December 2019), so all users are advised to update to at least PHP 7.0.8 now.
Updating your site from 8.6.15 to 8.7.0 with
update.phpis exactly the same as updating from 8.6.14 to 8.6.15. Drupal 8.7.0 also has updates to several dependencies. Modules, themes, and translations may need updates for these and other changes in this minor release, so test the update carefully before updating your production site. Read the 8.7.0 release notes for a full list of changes that may affect your site.
Drupal 6 and 7 site owners
Drupal 7 is fully supported by the community until November 2021, and will continue to receive bug and security fixes throughout this time. From November 2021 until at least November 2024, the Drupal 7 Vendor Extended Support program will be offered by vendors.
You can now use the stable migration path for monolingual Drupal 6 and 7 sites with the built-in upgrade user interface. For multilingual sites, there is experimental support; please keep testing and reporting any issues you may find.
Translation, module, and theme contributors
Minor releases like Drupal 8.7.0 include backwards-compatible API additions for developers as well as new features.
Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.6.x and earlier will be compatible with 8.7.x as well. However, the new version does include some changes to strings, user interfaces, internal APIs and API deprecations. This means that some small updates may be required for your translations, modules, and themes. Read the 8.7.0 release notes for a full list of changes that may affect your modules and themes.
This release has advanced the Drupal project significantly and represents the efforts of hundreds of volunteers and contributors from various organizations, as well as testers from the Minor release beta testing program. Thank you to everyone who contributed to Drupal 8.7!
Earlier this month we saw the passing of Rachel Olivero. Rachel touched a lot of people in both the Drupal and accessibility communities. She worked at the National Federation of the Blind, as the Director of Organizational Technology. I am not sure that this is where she was first exposed to Drupal, but she became involved in the community after attending DrupalCon in her hometown of Baltimore in 2017. It was there where she participated in her first code sprint and contributed her first bug report.
After attending the first-ever Nonprofit Summit at DrupalCon Baltimore, Rachel stepped up to lead an accessibility breakout at DrupalCon Nashville. She was always willing to share her knowledge and never got annoyed no matter how many times she was asked her whether the <aside> element was ever useful to a screen reader. Fortunately, about 20 minutes of the accessibility roundtable was recorded. She engaged with a few folks throughout the week, many remember her from Drupal Trivia Night.
As a technical user who was blind, her opinion was sought often in the Slack Channel. She also engaged with the Drupal Diversity and Inclusion team. Rachel was active in Twitter and other social media platforms too, where she engaged with other members of the Drupal community. As a person who was blind, transgender, and a lesbian, Rachel understood a lot about the importance of diversity.
Rachel became involved in the NTEN Drupal Community of Practice calls a few years ago, when she came on a monthly call to share some accessibility knowledge. Subsequently, she became a more regular attendee of these calls. Johanna Bates and Rachel were slated to co-present a session on accessible content entry for content editors at the upcoming NTEN 19NTC in Portland. This would have been her first ever NTEN NTC.
Rachel also served on the NTEN NTC’s first-ever accessibility committee, contributing her knowledge to making conferences more accessible. This is a perfect example of how willing Rachel was to share her expertise and experience with others. She was generous with her knowledge, kind, collaborative, and extremely funny. The loss of her warmth, humor, and brilliance in the Drupal community, the nonprofit tech community, and in the a11y community is a massive and sad loss.
This fall Rachel contributed an article to the latest 24 accessibility series, Not Your Father’s Navigation Strategy: There’s More Than Just the TAB Key. She argued for developers to invest in proper semantic markup so that screen reader users can make full use of their assistive technology. This annual series of articles really draws on a Who's Who of accessibility.
Rachel was also the president of the NFB’s Amateur Radio Division. As a modern HAM enthusiast, she was active on GitHub working to create a Software-defined radio (SDR) scanner that could continuously record a set of frequencies for on-demand playback. She was interested in public safety.
Rachel had been working on NFB.org’s new Drupal 8 site for a long time. She was so excited to see it launch at the end of January. Rachel had recently been promoted at the NFB to Director of Technology. This launch was a huge piece of her work, and the site looks amazing. It is terrific to see how she was able to modernize the NFB’s website and leverage Drupal to help her create a modern responsive website.
As Rachel said in an NFB Facebook campaign:
“I’m lucky, and thankful, that blindness hasn’t caused a lot of resistance in my life. From the support of family during my early years to the encouragement of friends, to the emergency management director who I never saw blink an eye when I said, “I want to take the CERT class. You can teach me to get people out from under a collapsed wall too, right?” to all those who supported my gender transition. I’ve generally never felt that I couldn’t do something as a blind person. However, it’s the love, hope, and determination of my family in the National Federation of the Blind, that has given me the extra strength and answered the, ‘but how do I…” And that is #WhyImAFederationist”
Rachel was also quoted in a very recent Vox.com article by s.e. smith, Websites need to be more accessible for disabled people. Rachel clearly identified that “Accessibility is still a sidebar when it comes to web development.”
A few community members shared memories of Rachel:
What I admired most about Rachel was her willingness to help at any level necessary and the kindness with which she acted. She was enthusiastic about building community and eager to contribute. She regularly gave time, experience, resources (like her server space, and other infrastructure) and energy to connecting people and working for a future in which technology would be accessible to all. Her unique perspective brought insight, empathy and patience to her work, and I’m sad that the world has lost such a passionate champion for inclusion.
- Nikki Stevens (drnikki)
Rachel was the kind of person who immediately made you feel at ease when you were spending time with her, even if you had just met. She was great about making sure that nobody got left out, and was quick to invite new or shy people at events who might have eaten alone to come sit with her and her friends instead.
She was generous with her time whenever I asked to bounce an idea off of her to see if what I was considering suggesting would actually be helpful for the blind community or not, and she never made me feel like a bother when I asked for her thoughts. To the contrary, she always seemed happy to help. She was encouraging when I was right, and gracious when I was wrong; she never made me feel stupid about an idea if I was off-base, and instead provided valuable insight that I apply to my work to this day.
Rachel was an awesome woman, and I wish that we had gotten to spend more time together. The Drupal community (and the world at large) will definitely be feeling her loss. I hope that we can all put what she has given to each of us to good use to carry forward what was always her mission - to make the world better for people.
- Helena McCabe (helenasue)
Rachel Olivero was really an adventurous spirit. I remember a NFB conference several years ago when Rachel mused "I've always wanted to ride a mechanical bull - y'know do as Texans do in Texas". After fighting the management of the establishment, who were not inclined to let her ride, she got to ride - for a full 30 seconds:-). Everyone at Deque will miss her. Rachel is an inspiration to all those who strive to be true to themselves and the cause of digital equality.
- Preety Kumar
In 2007, Rachel was one of the first accessibility experts I worked with after I joined Deque and I was always impressed with her technical strength and her ability to keep people at the center of any discussion. I remember the demonstration she made to Wal-Mart’s checkout team, that the shopping cart was inaccessible. Their response was getting off-track into technical mumbo-jumbo when Rachel loudly interrupted, “excuse me...excuse me. The point is that I want to put money in your pocket but since the shopping cart won’t work for me, I can’t do that. Do you want me to put my money in Target’s pocket instead?!?!” I always enjoyed working with her on any project and will miss her.
- Wes Dillon
Rachel Olivero will always be an an accessibility super hero to me. From the moment I met her, I knew she was wicked smart and a powerful force for good. She moved a11y forward through her technical work and leadership at NFB and Humana.
Our friendship grew each time we were together...from AHG to NFB to CSUN, to Penn State Web Conf and more. I think some of my favorite memories are from the “accessibility slumber party” at the Margarita Inn with Rachel, Elle, Sharron and others. Elle had brought together a team of a11y experts to solve big problems...we worked night and day...because we care so deeply about equal access for all.
A world without Rachel seems impossible to me. And then I remember how with Rachel, nothing seemed impossible. So I guess we all have to find our way to keep Rachel’s positive energy moving forward. Now It is up to each of us to make Rachel’s a11y dreams become a reality.
So with that, I raise a glass of cherry coke (one of her favs) and toast “To Rachel! To A11Y & Beyond!”
- Glenda Sims
I enjoyed talking with Rachel at both of her DrupalCons. We mostly talked shop. I was very impressed with her knowledge and patience dealing with people interested in learning. I remember talking about getting organizations like the NFB to approach technology more as makers than consumers. We also talked about challenges with procurement and the work that she was doing to revise how technology was purchased. She seemed hopeful and focused. She was clearly a big thinker.
By being involved in the Drupal community, Rachel reminded a lot of us of the importance of building our tools to work for everyone.
We were all looking forward to working with her more. She will be missed.
In lieu of flowers, the family requests that memorial donations be made to the National Federation of the Blind to support projects in which Rachel personally invested her time, treasure, and talent.
Contributions can be mailed to National Federation of the Blind, 200 East Wells Street, Baltimore, Maryland, 21230, or given online at https://nfb.org/donate.
Update: Since the publication of this blog Drupal 9 is closer than ever. To learn what you need to do to be ready for the upcoming release, please consult our pages on Preparing for Drupal 9.
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
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.
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.
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:
- 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.
- 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.
- 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!