If you have been reading my updates, then you already saw that I was rerunning my experiment from 2019, checking all the contrib modules for Drupal 9 readiness. Except this time, I was using upgrade_status, which also takes into account several things drupal-check does not.
The numbers…
Without further ado, here are the results I am seeing:
Conclusions:
6353 total modules checked.
2498 total ‘d9 ready’ modules
The percentage breakdowns:
39.32% = D9 ready*
15.11% = 1 error
7.02% = 2 errors
4.39% = 3 errors
3.07% = 4 errors
2.57% = 5 errors
2.16% = 6 errors
1.18% = 7 errors
1.21% = 8 errors
8.36% = 9+ errors
15.61% = Other issues
You can read all the results I parsed in this Google Drive spreadsheet.
*= still need to update the info.yml to say d9 ready
I based all these numbers of appearances of keywords and phrases found within Drupal API Deprecation documentation and deprecations of twig files, composer files, Drupal libraries found within upgrade_status.
The tooling and the XML documents I used to accomplish all of this can be found on the Gitlab project page.
I based almost everything on grep and other built in Bash tools, so you should be able to replicate anything I did on a mac or linux box. I used Ubuntu 19.10 for all this.
What do you mean by ‘error’?
Let me state, in an effort to be clear, when I am using the term error, it is not that the code is not correct to have a successful site, it is a keyword I `greped` from the tooling’s reports.
As was pointed out to me in Drupal chat there exists many an error that is needed for supporting Drupal 8.7. I realize it is not fair to call good code ‘full of errors’ but I am at a loss of how else to phrase it.
And I completely recognize that not all error are the same. Some of these are readily fixable with a line replacement. Some are going to be hard to deal with. We will figure it out, I believe.
Didn’t check the dev branch
I think some of these issues are probably (hopefully) fixed in a dev branch somewhere or just not released yet. I wanted to simulate what someone would pull off the shelf with a ‘standard’ install and whatever composer default grabbed.
Side note: Composer, while I am on the subject, is the slowest part of this whole experiment. The reporting tooling I built ran a loop of about 800 keywords against 6300+ modules in 8 hours total. To produce the XML reports for 100 of those modules tool, on average, of 90 minutes. This was mostly due to needing to uninstall and composer remove the modules to not break the running site install. Without the help of Arrow a.k.a Aaron Feledy and ccjjmartin a.k.a Christopher Martin I would not likely have finished before mid April.
Given that there are errors that can’t be addressed in the main release yet, I am confident that the Drupal community is going to deliver and this is going to be a smooth transition in the long run.
Historical context
I said about a year ago “About 43.7% of all projects I analyzed have “No error”. That was what I said confidently the first time out. I said a lot of things back then and I said it when someone was financially backing me doing this. This time around I am doing it while working for myself. But enough digression.
Here is how the numbers stack up:
If you click on that linked image it takes you to the Google report sheet again. The project from last year is located here.
That ‘biggest offender’ from last year wasdrupal_set_message() use has dropped from 1692 modules using it down to 1058 today. This is the trend we all love to see. .
On the surface it would be easy to say ‘well, our Drupal 9 readiness went down.”, but Let’s face it, D9 is a moving target with so many deprecations added over each 6 month release cycle. Also, I think this is due to better methodology and tooling from last time as well. ‘Upgrade_status’ simply reports more and all the test this time around were performed against running Drupal installs, which was made easier by the the magical Drupal 8 Quick Start Command.
Let’s not brush past the Drupal 8.8.x issue. If you look at the Deprecation API page and look at 8.7 vs 8.8, there are simply 150 more deprecations since last time I ran the report. Each module that contains one of the deprecations that explicitly calls out Drupal 9 is listed on this tab of the Google sheet.
Now is the time! Let’s make it happen.
In an ideal world, we would have no issues at all and we would be ready now. In our real, messy world,we are not in that bad of shape. We don’t have to roll out D9 on June 3rd if we don’t want. We are not another CMS that talks about forced updates. We are Free (as in Freedom) Open Source and the price we pay for that is we have to make it happen. Let’s do this!
The tooling has never been better and the fixes, while many, are mostly fixable with a find/replace and some testing. The #d9readiness channel awaits you on Drupal slack where you can ask any and all questions. It is full of awesome people, like Gábor Hojtsy, who I can not thank enough for asking me about all this and getting me excited about the D9 readiness for the first time in a little while.
Let’s build something beautiful together!
Please direct all conversation to me via either Drupal Slack (mcdwayne) or Twitter, as comments are not reliable at the moment.