Drupal 9

I am an initiative coordinator on Drupal 9, here is my writing on tools and processes getting there.

First beta of Upgrade Status for Drupal 8 out with highly improved reporting, helps to best collaborate with project maintainers

On our way to Drupal 9 every site will need to take care of making updates to their custom code as well as updating their contributed projects. However this time, instead of needing to rewrite code, only smaller changes are needed. Most contributed modules will only need to deal with a couple changes. Collaborating with project maintainers is the best way to get to Drupal 9. The first beta of the Upgrade Status module alongside recent drupal.org changes focus on making this much easier.

Upgrade Status beta provides better insight into Drupal 9 readiness

Take the first beta of the Upgrade Status module and run it on your site. It will provide executive summaries of results about all scanned projects and lets you inspect each individually.

Custom and contributed projects are grouped and summarised separately. You should be able to do all needed changes to your custom code, while for contributed projects you should keep them up to date in your environment and work with the maintainers to get to Drupal 9. The later is facilitated by displaying available update information inline and by pulling the Drupal 9 plan information from drupal.org projects and displaying it directly on the page.

This is how the summary looks like after scanning a few projects:

Upgrade Status summary page after scanning several projects.

Digging deeper from the executive summary, you can review each error separately. The beta release now categorizes issues found to actionable (Fix now) and non-actionable (Fix later) categories with a Check manually category for items where it cannot decide based on available information. For custom projects, any deprecation is fixable that has replacements in your environment while for contributed projects supporting all core versions with security support the window is shifted by a year. Only deprecations from two or more releases earlier can be fixed (compared to the latest Drupal release) while keeping Drupal core support. So somewhat ironically, Upgrade Status itself has deprecated API uses that it cannot yet fix (alongside ones it could fix, but we have them for testing purposes specifically):

Upgrade Status project issue list categories

The module is able to catch some types of PHP fatal errors (unfortunately there are still some in projects that we need to figure out the best way to catch). The @deprecated annotation information guiding you on how to fix the issues found are also displayed thanks to lots of work by Matt Glaman.

Own a Drupal.org project? Direct contributors to help you the way you prefer!

If you own a Drupal.org project that has Drupal 8 code, you should specify your Drupal 9 plans. It is worth spending time to fill in this field to direct contributors to the best way you prefer them help you, so contributions can be a win-win for you and your users alike. Whether it is a META issue you plan to collect work or a specific time in the future you will start looking at Drupal 9 deprecations or a funding need to be able to move forward, letting the world know is important. This allows others to engage with you the way you prefer them to. Additionally to it being displayed in Upgrade Status's summary it is also displayed directly on your project page!

Go edit your project and find the Drupal 9 porting info field to fill in. Some suggestions are provided for typical scenarios:

Drupal 9 porting info field on a project

This will then be displayed on your project page alongside usage and security coverage information. For example, check it out on the Upgrade Status project page.

Thanks

Special thanks for dedicated contributors and testers of the Upgrade Status module who helped us get to beta, especially Karl Fritsche (bio.logis), Nancy Rackleff (ThinkShout), Tsegaselassie Tadesse (Axelerant), Bram Goffings (Nascom), Travis Clark (Worthington Libraries), Mats Blakstad (Globalbility), Tony Wilson (UNC Pembroke), Alex Pott (AcroMedia, Thunder), Charlie ChX Negyesi (Smartsheet), Meike Jung (hexabinær Kommunikation). Thanks to Neil Drumm (Drupal Association) and Angela Byron (Acquia) for collaboration on the Drupal 9 plan field.

State of Drupal 9 - May 2019 session recording

I created and shared an open source set of editable slides with plenty speaker notes titled "State of Drupal 9" early in May, based on my webinar with Dries and then the Drupal 9 parts of the DrupalCon Seattle Driesnote. I hope that we can bring this know-how to a lot of conferences, meetups and to companies so people are more aware of what is coming, what happens to Drupal 8 and 7, what's so great about Drupal 9 and what are the key tools involved.

Before I even presented the slideshow first, I already got improvement suggestions from people presenting it elsewhere. So the first time I got to present this session in Minsk, Belarus at the kind invitation of DrupalCamp Belarus organizers, it was already improved from when I first published it. I will keep updating the slides and present where I can in the coming months. Please, do it yourself too! Translate, shorten, lengthen, etc. to match your audience and timing needs, as long as the key messages get through. Be an important contributor to Drupal 9 this way!

Here is the recording from DrupalCamp Belarus:

Analysis of top uses of deprecated code in Drupal contributed projects in May 2019

Dwayne McDaniel did some thorough reporting of deprecated code use in all Drupal 8 contributed modules in March. Ultimately this kind of reporting would be best to have on drupal.org but while that is figured out, Dwayne's data set provides a very nice way to mine data about Drupal 9 readiness of contributed modules and to inform our tooling to improve the process. His original numbers showed that almost 44% of contributed modules had no deprecated code use at the time. What I was interested in was how to help the rest of the 56%.

Dwayne created an updated process and a new repository this week with fresh data. I was still curious so I delved right into the data and started mining it. A key question I was interested in is how much of the most widespread deprecations are actionable right now. An actionable deprecation is something core deprecated in a previous version that is not supported anymore, so you can update your code to remove the use of that API. Currently Drupal 8.6 and 8.7 are supported, so deprecations there should only be acted on for your custom code. However deprecations in and before 8.5 are entirely fine to act on.

First I counted the top list of deprecated APIs used from Dwayne's data across all of contributed projects. Then I wrote a script to collate api.drupal.org documentation to the deprecation notices. Ideally phpstan itself would report these messages directly and Matt Glaman is working on that. However since that is still blocked on the phpstan side, one needs a different data source to find the deprecation documentation for each occurrence, so I took to api.drupal.org to get that for now. Once that is found, we can categorize the deprecations into actionable, not actionable and actionable for custom code only. For the later case you know which core version you are using, and that should be an up to date minor version. So you don't need to deal with what core branches the community supports otherwise.

The results look really promising so far in terms of how much contributed modules can make progress on even today. If all already actionable deprecations get resolved, there will be very little left at least of the deprecations we already know.

A month ago Dezső Biczó created a set of proof of concept Rector fixes to automate some of these deprecation fixes, so I opened an issue with this new data set to try and cover the top ones that are not just actionable but approachable to automate.

Screenshot of deprecation status PDF

As with all interesting data sets, this summary is just the tip of the iceberg. There is huge potential to mine this data set for other uses, such as finding modules that potential contributors at an event could contribute fixes to. I don't know yet how much I can continue to work with this data myself, and of course others doing analysis of their own would be more than welcome.

Are you a drupal.org project maintainer? Now would be a good time to fill in your Drupal 9 porting information in your project, so you can let contributors know how to best engage with your in the process towards Drupal 9.

Disclaimer: The data is based on the state of contributed projects on May 20, 2019 based on Drupal core's 8.8.x development branch on May 20, 2019. The lookup on api.drupal.org was not perfect and I found some bugs there that are being resolved as well so the data gets more accurate. Also, as contributed modules will get updated, there will be less uses of deprecated APIs. As core will introduce more deprecations, the data could get worse. There may also be phpstan Drupal integration bugs or missing features, such as not finding uses of deprecated global constants yet. This is a snapshot as the tools and state of code on all sides evolve, the resulting data will be different.

Present your own "State of Drupal 9" session, get slides here!

I am about to present about Drupal 9 at DrupalCamp Belarus in May and then at Drupal Developer Days Transylvania in June . I already presented an Acquia webinar with Dries Buytaert on the topic, and was on the Lullabot Podcast discussing Drupal 9 with Angie Byron and Nathaniel Catchpole. I am a firm believer that this know-how should spread as far and wide as possible. I should not be needed to travel around the globe to present the topic and people should not spend the same time again to redo slides for their local presentations. There is no intellectual property here to hide, as many people should be aware and excited and participating as possible. The topic should be presented at Drupal Meetups, Camps, and inside your own companies. So the natural next step for me was to create an open source slideshow.

Screenshot of the first 16 slides of the 1.1 version of the slideshow

I took all that we learned from the webinar and Dries' keynote at DrupalCon Seattle as well as new technology that emerged since then. I also used a free slide template and Google Slides so you can make a copy for yourself and add your own contact information as well as edit the slides down to shorter or longer timeslots. The 51 slides in my test run for about 35 minutes, leaving 10 minutes for discussion in a 45 minute slot. You would likely need to cut content for shorter sessions. There are only basic buildup animations, so if you need to present offline that is also an option. Edit in your contact/introduction info and export and present as PDF.

The 1.0 version of the slides have been presented by Christian Fritsch at DrupalCamp Munich last week and I updated some content to the current 1.1 version as it is available now. I'll keep updating slides based on all your feedback. I shared the slides with public comments allowed, so keep the feedback coming there, comments here or some other way you can get ahold of me.

Resources to watch/listen to learn more include:

  1. Dries' State of Drupal presentation from DrupalCon Seattle
  2. Lullabot Podcast on Drupal 9
  3. Acquia Webinar on Drupal 9

Thanks to Acquia for funding me to create this slideshow and thank you for presenting it!

Estimate your site's Drupal 9 compatibility easily with Upgrade Status

Dries Buytaert recently published a great post on how to prepare for Drupal 9. He explains how we build Drupal 9 in Drupal 8 using deprecations and the tools to use to detect use of deprecated code. Acquia funded me and Zoltán Herczog to work on one of the tools in the past few weeks. Zoltán just released the second alpha of Upgrade Status. It is definitely worth a try!

Here is how it works: