 So I think we are ready to start. I got the moderator sign on to start. Okay, let's do it. Thank you for joining. Today we'll be talking about upgrading to Drupal 9. We'll go through a little bit of the basics and then real life example. Just to be sure we are on the same page. This is for upgrading from Drupal 8 to Drupal 9. So let's start. Hi, my name is Karen Perez. I'm Senior Drupal Developer here at Drupal Web. I've been Drupal Developer since eight years ago. So I love Drupal flexibility and capabilities and love teaching. So that's me. As I said, I work for Drupal Web. This is a web design and development agency based in Montreal, Canada. With more than 10 years of experience, we consider our service as a community of experts. So just an announcement. We provide in-depth Drupal training. These are the next courses for the following month. So we have a complete Drupal training in November. Also advanced Drupal module development at the end of this month. And also a landing page architecture and teaming for Drupal. It's starting on November. This one will use a new blend training format, which will include pre-recorded videos, exercises, and for live training sessions and also one-on-one sessions. Feel free to send us an email and we'll give you a discount on that. Also, you can request a customized training for your team. Just send us an email and we'll figure it out for you. Nice to meet you. So this is the agenda for today. We'll start talking about the Drupal development roadmap. Also main changes in different Drupal versions. How to prepare your site for Drupal 9. What are some tools? So it's the upgrade to Drupal 9. How to actually do the upgrade. I'll talk a little bit about a real-life example. Q&A at the end of the session. So Drupal development roadmap. Here you can see the life cycle for the different Drupal versions. So right now we are almost at the end of 2020. Right now we have support in three different Drupal versions. Drupal 7, Drupal 8, and Drupal 9. The support for Drupal 8 will end at the end of the next year. Just a minor update on this image. Drupal 7 of life was extended one more year due to all this pandemic situation we are all living. Drupal 9 was just launched a couple of months ago. We expect Drupal 10 to be launched in June 2022. So these are some of the key dates of Drupal development. Just a reminder signs Drupal 8. We get a new minor version of Drupal every six months. So it means that Drupal 9.0 was launched in June this year. So we'll get Drupal 9.1 in December this year. Let's talk a little bit about the main changes between the recent Drupal versions. So if you went through the changes from Drupal 7 to Drupal 8, or you may still be going through that, you can know that it was a full rewrite of the Drupal core. We introduced minor releases in the life cycle of Drupal 8. So now we have an incremental approach in each of the minor releases. A couple of examples of this incremental approach is that in Drupal 8.2, big pipe and inline entity errors were introduced. Media and content moderation modules were introduced in 8.5. Also in 8.6, media library and workspace modules were introduced in the core. Like the builder and JSON API were introduced in 8.7. And the new admin team named Claro was introduced in Drupal 8.8. So yeah, there is a lot of development going through each of the minor versions. And that's one of the nice things starting from Drupal 8.0. And for sure we also have in Drupal 9. When Drupal 9.0 was launched around four months ago, it's pretty much the same than Drupal 8.9. There are only some changes. So Symphony was upgraded to number four. Tweak was upgraded to version two. And all of the deprecated code was removed from the Drupal core. A quote from Andreas, the big deal about Drupal 9.0 is that it should not be a big deal because there are no new features in Drupal 9.0. However, this is still the most powerful Drupal version ever because we can continue upgrading the core within each one of the minor releases. So as an example, in December, Drupal 9.1 will be launched and that will include Olivero, which is the new Drupal team. It will still be an experimental team, but it will now be in core. It was official except like, I don't know, two, three days ago, something like that. So the drop is always moving. Prepare your site for Drupal 9.0. So yeah, we already talked about the good things that are coming in Drupal 9.0. Drupal 9.0, the ability to keep upgrading your site. So how to prepare your Drupal X site to be upgraded to Drupal 9.0. So this is a little bit of an overview of the process. Your code base should be using Composer. You should ensure country and custom models compatibility. You should be using Drudge 10.0. You need to check for some platform requirements and then you need to do the actual upgrade. So let's go through each one of these items. Composer code base. As I said, your code base should be using Composer and it should be using the new recommended project, which was introduced in Drupal 8.8. So if your code base is being built from a turbo, so it's not using Composer, the first thing you need to do is to convert it to use Composer. Also, if you created your site using Composer, but previously to Drupal 8.8, which means you are using the country Composer project, you also need to change your code base to use the recommended project. How to do that? There are a couple of links here on how to do this process. You need to be careful, but it's something that you could do maybe in one hour. So it's not really a big deal. Next step, you need to ensure all of your country modules are compatible with Drupal 9. First thing to do, you need to update your modules to the latest available version. And now you need to start checking if your modules are compatible with Drupal 9. How to do this? We'll look into this in a couple of minutes. I pulled some statistics from this Akiya dashboard about the Drupal 9 compatibility. I pulled the statistics like two or three days ago, and it's pretty promising. So 42.9% of Drupal 8 modules are Drupal 9 ready. There's nothing to do with them. They are very compatible with Drupal 9. Also, 97.5% of the top 200 country modules are ready to use for Drupal 9. This means that only five modules of this top 200 are missing something to be compatible, which is great. If you remember from Drupal 7 to Drupal 8, Drupal 8 came out. I don't remember the date, but the modules that were most used in Drupal 7, we had to wait a lot for them to become available to Drupal 8. Now the reality is totally different. 32.9% of Drupal 8 modules needs only that info.yaml or composer.yason or automated changes. So it's a big percentage of modules that only need just a few tweaks to make them compatible with Drupal 9. This is also great. And 75% of Drupal 8 modules are either explicitly compatible or needs really small changes. So if you look this your way around, there is only 25% of modules that actually need some manual intervention or some manual intervention to make them compatible with Drupal 9, which is great. Next step, you need to ensure your custom modules are compatible with Drupal 9. In this section, unless your site is pretty complex and have pretty complex logic into your custom modules, the changes in this site are really, really small. So yeah, this is something that you need to do, but usually the changes here are small. And we'll also see how to verify the compatibility in a couple of slides. Next step, you need to ensure you are using DrushTank and how to do that, you just need to require Drush and add the constraint for version number 10. Most of the time this will just work if you have something really complex or if you have some dependencies on your site. Maybe you'll need to figure it out if you find an error with Composer, but as I said, most of the time it will just be running this command and it will be there. That's pretty good. Next step, check platform requirements ensure that your hosting supports Drupal 9, which means if you are using Apache, it should be version 2.4.7 or greater. For sure you're using PSP. So PSP should be 7.3 or greater. My SQL should be 5.7.8 or if you are using MariaDB it should be 10.3.7 or greater than those versions. Also, this is something that if you are using something like a platform as a service, they will prepare the platform for you. So it's probably that you don't have nothing to do on this end. Now, I promise that we'll talk a little bit about some tools to is the upgrade to Drupal 9. So in this section we'll be talking about upgrade status, we'll be talking about Rector. Upgrade status is a Drupal module that provides all-around support for preparing your site for upgrading to Drupal 9. How to install it? As any other module that Composer requires, Drupal is that upgrade status. Here you can add a version constraint. In this case, I'm adding and suggesting version constraint for 2.0 is stable. And then you need to enable the module and just use it before going to this user thing. I found out a couple of days ago that there is a 3.x version in development which already has a couple of, I guess, alpha, beta or something like that versions. I personally haven't tested it, I want to do it, but I haven't had the chance to do that. And I'm pretty sure it will get a lot of improvements. I saw some of the discussions in Drupal Slack channel, so I'm pretty sure that's going to be a good improvement to what we currently have. So that's something that you definitely need to check out. So once you install the module, you need to run the analysis for each one of your modules. You can do this through the UI or you can also do it through the command line through Drush. If you're doing that through Drush, it's just Drush US-A and the module is, and this will run the analysis for this module, and then it doesn't matter if you're running through the UI or if you're running through Drush, you'll still get the report in the UI. You can get the report in the UI. We'll see how that looks. When you load the upgrade status page in Drupal, you get something like this. So it will initially show you the compliance or not of the platform level requirements that I just mentioned. Also, it will show you if you are in the latest Drupal 8 version so that you can easily upgrade. So, yeah, it's this. Once you run the analysis, as I said, either from the UI or from Drush, you'll start getting the summary here. So in this case, it says that my site at that point had 19 errors, a lot of warnings, and that there were some modules that were checked but that didn't have any errors. Some modules I hadn't checked when I took that screenshot. Each one of the modules will look like this. It says admin toolbar, it's green. So it means it's good. There are still some warnings. So my recommendation is that it doesn't matter if you have errors or warnings, yeah, go open that by clicking on the status column and you'll get a window like the one at the right and you can manually look through all of the warnings, errors, and understand what's the issue with them because in some cases it could be false positives. So as an example, in this screenshot that I added to the slide, these are errors related to the test, but I don't have the test sheet enabled in this site, so it's okay that we have those errors. I also found something really interesting. It was with the bootstrap team and in this case it was showing a lot of errors, but it was because the maintainers of the team did some polyfills for the function that were being removed in Drupal 9. So upgrade status was showing all of that as errors, but they actually had polyfills for that so that it doesn't break in Drupal 9 version. So that's something good, and that's why you really need to carefully read the errors or warnings that upgrade status gives to you and take actions from there. These actions could be applying some patches, could be if you are a coder, it could be writing some patches and contributing them to Drupal or something like that. So yeah, go ahead and do that. And how to do that? For sure, some of the things you need to do then manually. Actually, I'm going to go back here. And if you can read here, it says check manually. It is because of the status groups, the warnings, the things that it found, it groups in two or three different sections. I don't exactly remember, but I remember it groups in things that could be automated with Rector and things that need to be manually done. So there are things that you could automate with Rector. This is a project that can save you a lot of manual work by automating code upgrades to Drupal 9. How to install it? It's a Composer package. In this case, it's not a module. It's a package that you need to install, that you need to require with Composer, but you don't need to install it. There are presentations and links to the documentation, but once you install it, you need to copy a config file, and then you need to run a comment. When you run this comment, it will go through the modules that you give to Rector and will try to do the automated upgrades that it can do based on the list of stuff that it can automatically fix. This is a list of things that it's continuously growing because people maintaining Rector are hardworking on that to ensure that it can cover as much as possible to automate the upgrade to Drupal 9, which is great for us who maintain Drupal 8 sites. This is a screenshot on how Rector looks. It just goes and fixes the errors, and it will show you as a diff of the things that it changed. Let's say that you are really prepared for your site, so you check that platform requirements are OK, that you are using Drupal 10, that your codebase is using Composer Recommend Project, that all of your contrib and custom modules are compatible with Drupal 9, so now the next step is to do the actual upgrade to Drupal 9. And here, when I was doing it, I found something that I call it the chicken egg problem, which is that the module is itself almost compatible with Drupal 9. It only needs a change in that info, that YAML file, so you add this as a patch in your Composer.json file, and now you are ready to upgrade your site to Drupal 9, so you have some patches using Composer patches, and now you have everything compatible with Drupal 9, upgrades that report that everything is ready, so you run the Composer command to upgrade to D9, and now it fails. Why does it fail? Because that info, that YAML file, defines in Drupal.or in class structure the Drupal core version constraint, so even if you add it as a patch for that info, that YAML file, it doesn't mean that this module will be able to install in Drupal 9, so when you try to upgrade, it will fail because there are some modules that can be installed on Drupal 9, so how to fix this? First and all, the actual real solution will be to contribute to make the module compatible. This means that if the module is unmanned and you have some time, you can offer yourself to be a commentator of the module and try to push the module forward to be Drupal 9 compatible. If it needs a patch, you could provide the patch in the issue queue and wait for the maintainer. If you have time, wait for the maintainer to commit your patch, things like that. That would be the real solution to actually contribute to make the module compatible, but in the real world, maybe you need to do the upgrade because your client is asking for that or because you actually want to try Drupal 9. So how to work around this case, this situation? There are four options to do this that I found so far. Maybe there could be a little bit more, but I want to discuss these four options. Option number one is that you use Composer Alliances. In this case, you say that the Drupal 9 version that you are inside should be treated in Composer as the latest Drupal 8.9 version. This could work, but I have a feeling that this could get messy in the future, so I really don't like these options. It's an option, it's there. If it fits for you, it could be good. I personally don't recommend it. Another option, I mean, the three remaining options are using Composer Repositories, but different types of repositories. The first type is PASS. This involves adding the actual country code into your site repo and then link it using a PASS repository, a PASS Composer repository. Again, this could work, but this is adding a lot of country files to your repo, maybe it will make your PRs difficult to review, maybe it will get things a little bit messy. It's an option, but maybe it could not work as good as it could. Another option is using, again, Composer Repositories, but in this case, using Type VCS and forking the projects to your personal repo, maybe to your GitHub, maybe to your GitLab as VCS repositories in your Composer.JSON file. This will work, this is a little bit less messy than the previous solutions, but this will mean that you will end up having several forks in your repos and maybe you actually are not going to be actively contributing to them, so this option may not suit to your needs, but it's an option and it could work. The latest option, which is what I really like the most is adding the repositories to Composer, but using Type Package. This is a cleaner option, it only needs a little change in the Composer.JSON file and it will work, you don't need to for, you don't need to add files to the repo, you just need to declare the package in the, as a Composer repository using Type Package, so that Composer when Composer resolve dependencies, it won't care about the version constraint because it will be there and declare, so this could work. Let's see how does this work. So this is an example, here I am defining the context metadata module as our Package repository, you can see the first line, it says Type Package, I'm declaring the version here, the source I'm pointing to the actual git.trupalcode.org with a commit, it could be a branch, it could be a tag, whatever you need, and that's all that you need. When you run the Composer update comments, it will just work because it won't care about the version, the version constraint, the required, the Drupal requirement, it will work. Just creating to Larryland and DPI, this is an idea that came from then in Drupal Slack when someone asked about this problem, so yeah, this works, it works pretty well. So now that you fixed that, you need to do the actual update, and it's just a couple of Composer comments, in this case, Composer required, you require all of the different packages, this time using 9.0 version constraint, and I'm adding here the no update flags so that you can run another Composer required comment, which is this one, in this case, because I also had the dependencies installed in my project, and once I run those two comments, I run the actual Composer update comment, I need to wait for some time in order to give Composer time to run because it will take some time, so maybe you can go grab a coffee and wait for it, and it should just work. Once it finishes, you need as with every other Drupal update, you need to run the database updates, you need to export Composer changes, and that's all, welcome to Drupal 9, it should be working on your local environment, now you only need to push that and ensure it works in your dev staging or broad environment, hopefully you will get through all of them, dev environment, you verify it works, now you push the stage and finally you push Drupal. So this was like the generic how to do it now to put things in perspective, I would like to tell a little bit about a couple of sites that I upgraded recently to Drupal 9, so in one of the sites, for the country stuff, I for sure had to update the modules, so I had to apply some module updates, and for the patches I had to patch for modules, all of the rest of the stuff was okay, so only added four patches to make things somebody will be Drupal 9, also for the custom code I only had to do some small changes here and there entity.manager was deprecated, so change that to entity.type.manager adding the core version requirement in that info, that YAML file, so this kind of really, really small changes at this point, this was the first site that I was upgrading to Drupal 9, so at this point I didn't know about this composer problem that I just mentioned, so I tried to run the upgrade and I got this error, the error is not always clear, in this case it's kind of clear but at some point it wasn't that clear, so I can upgrade because this module needs a Drupal 8, and you are upgrading to Drupal 9, so fix it, that's basically what composer is saying, so I had to do the fix, in this case I had to do the fix I think it was like for 3 modules, something like that so I just had the repositories declaring these modules as package type repositories once I did that run again the upgrade this time it worked as I said Drush of DB, Drush config export, and that's all it just worked, so if you remember if you have had previously upgraded aside from Drupal 7 to Drupal 8, it was really an aimer because you actually had to start from scratch, migrate stuff things like that, I'm pretty sure it was the same from Drupal 6 to Drupal 7, I didn't actually work on that kind of projects but in this case from Drupal 8 to Drupal 9 it just I don't know, maybe 4 hours something like that half a day, one day and it works so this is a pretty good improvement to the developer experience having to maintain lots of Drupal sites upgrading them to Drupal 9 so yeah the experience is way better than it was before so that's what I wanted to share and if you have any questions on this, I think it was bad, so that's not one of you have any questions yeah, unfortunately I shared this slide so I actually tried to in the event chat once I get out of the session sure, thank you Marc I put it also in the background here in the slides I'm also leaving some useful links links to the change records which is the best place to go and look for how things should be now done in Drupal 9 so that's an excellent resource there is also a link what are the changes regarding Tweet because Tweet was upgraded from version 1 to version 2 so this is something you also need to keep in mind when upgrading your code and also some documentation about duplication checking and correction tools and the source on Drupal on how to do the actual update from Drupal 8 to Drupal 9 so that's all for me thank you