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:
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):
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:
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.