Lessons learned from helping port the top contrib projects to Drupal 10

MATT GLAMAN:
Bright and early, thanks for coming in. So this is lessons learned from helping port the top contrib projects to Drupal 10. My name is Matt Glaman. I'm a principal software engineer at Acquia and also the maintainer of phpstan-Drupal and a major contributor to Drupal-rector. Hopefully, you've had some nice experience using those tools. We're gonna talk about them a little bit today. But first, who has made their project sites Drupal 10 ready so far?

SPEAKER:
All of them?

MATT GLAMAN:
OK. How many have started? Or at least like It's not all the way, oh, OK. There we have more people there. OK, Good start. I know it's not always the easiest process, and we're gonna be talking about ways that we can make that better. Alright. So let's go for another sub audience that who has made contributed modules Drupal 10 ready? OK. How about half the people that have worked in their Drupal 10 site means you probably had to make a patch or work on something. Well, some good news is that as of April 12th, 2900 projects are stable and ready for D ten. 1500 need stable releases. So some are on devs, some say RC just if you're a module maintainer, don't be scared of stable releases. Just go for it. You can, releases are cheap. And then there's still a handfull that need work done. This is taken from dev.acquia.com under resources there's like a deprecation dashboard. Maybe you've seen this, maybe you haven't. But it's a cool way that shows the entire ecosystems results. I'll talk about that page a little bit later.

So this is lessons learned from my team and we tracked over 180 contributed modules as part of our Drupal ten Readiness Initiative. As part of that, we were credited on over 90 modules getting to Drupal ten ready and three Drupal core issues. And I actually really wanna take a minute to pause about the Drupal core issues. It's important to work on your modules early so you can find problems in the next major version. Drupal nine deprecated temporary query, temporary tables in your database like MySQL temporary tables. And it was removed in a Drupal ten. Search API DB relies on that to work, So as part of our D ten readiness for Acquia search, we need to get search API D ten ready. Acquia search uses solar. We don't use the database, but we got that functionality back in core to unblock search API. So that was like a really great effort. And then also two things around CK editor five because one of my modules, the dam module does a lot of CK editor five stuff. So there and then also the entity embed module needed the CK editor five plugins needed to allow derivatives to work.

So by working on module readiness you uncover the things that aren't quite there ready in the next major version. So it's really important to work on those things. And so this was our goal, like our mission statement for, we did this from Q three to Q four. So it was like June to December of 2022. Ensure all of Acquia's product modules and dependencies were ready for the release of Drupal ten. And then we're like, Oh yeah, let's include the top-use modules as well. Let's make sure they get over. I know Sasha took care of token and redirect, but we were gonna help track and make sure and give assistance if needed. So what team is this? It's Acquia's Drupal integration team. We maintain Acquia's product module. So Acquia Connector, Acquia Search, Acquia DAM, media Acquia DAM, things like that. You might be more familiar with the DAT team, which used to be OKTA, like Drupal acceleration team. The Drupal acceleration team, they work on Drupal core, we are in the contrib space. And I really wanted to highlight the team that was part of this effort because hopefully you've seen their names on some of the modules and it was Acquia kind of colliding on this that made it all possible.

Jakob Perry was one of the leads and I call him our semantic versioning champion and customer experience. We had lots of arguments about releases and semantic versioning, which I'll talk about there to try to make sure that end users had the best experience. Then there's myself. I worked more on Drupal-rector and phpsan-Drupal and trying to figure out how to make everything automatic and robotic for you in this process. Attila, Abhishek, Balint, and Nejc, they were like, say, like our worker bees. They're the ones that swarm the issues. And Balint is the one that really, he spent like a month on entity embed in CK editor five, and Wim Leers trying to make sure that entity embed could be possible even in Drupal ten. Now, here's the question. Did you know that there's something big happening next year? Drupal 11 is coming in 2024. It is. There's a policy issue it's doo-I3330791. The plan is for August 2024 with a fallback to December. They'll mind you the same thing that happened to Drupal ten.

It was originally slated for August, but due to CK editor was fell back to Drupal or to december. Same thing for Drupal 11 just next year. So we got what, year and a half? Which means we've got like probably eight, nine months before we should start thinking about Drupal 11 readiness. Yeah. So it's one year away and I'm not actually scared or worried about the fact that there's another like readiness initiative and I want this session to kind of help alleviate any fears you have in ways that we can make the upgrade from Drupal ten to 11 even easier than it was from eight to nine and nine to ten. So what have we learned from this process of Drupal nine to Drupal ten and how can we make upgrading to Drupal 11 even easier? So one thing we need to do is look back at the changes that went from nine to ten. You know, maybe you're like, I'm gonna upgrade my site and I'm just gonna fix some deprecations, but there's more. So there was a lot of major version bumps in our dependencies. We had, of course, Drupal nine to ten, everybody's dependency PHP from 7.4 minimum supported to 8.1.

Now technically people should have already been on PHP eight because 7.4 with end of life. But let's be real. There still sites run on PHP 5.2 out there. People don't upgrade stuff when they need to. PHP unit went from 8.5 to nine. Guzzle six to seven, which was a whole thing of itself as well. And then Symfony four to six, we skipped five like Drupal ten Alpha one supported Symfony five and then they dropped it. So there's like that little gap of a bridge. And then of course CK editor four to five, which was one reason that the Drupal ten release was delayed. And something new that we didn't have with Drupal nine is JavaScript changes and library removals. jQuery once, you know the library that everybody writes. So that way Drupal Ajax doesn't put something on the page 5000 times that was moved to a new once library that doesn't have a dependency on Drupal core. So that was a big change. jQuery UI gone, moved to contrib. I don't know how many people were aware of that, but I know that caught us at 9.3 or 9.4 going.

The contrib modules for jQuery UI aren't even D ten ready, but you can't depend on them because they're deprecated libraries, and then backbone and underscore these are libraries, not everybody is using contrib. I did because of course I found a way and these weren't able to be removed yet because it was really entangled in our JavaScript, their libraries from like 2012. But they were marked internal, which means that you shouldn't use them because they'll eventually go away. All of this is pain from a long Drupal eight life cycle. I have, I couldn't get my speaker notes up, but Drupal eight was released like November 2017. No, before that it was a six-year life. It is on the slide. There we go. Way to go, old me. So November 2015 is when Drupal eight released. I remember being at mid-camp as like the last like rush for this to happen and then 8.9 dot whatever patch version, the last patch version was released November 2021. That is six years for software to exist and the world change around it.

So yeah, like Drupal nine was a two-year window to say, Oh, we need to upgrade and fix everything. So I don't think Drupal ten to 11 will be as bad because we're not gonna have such a large amount of cleanup to have to do. So like i said, this is a lot of work, a lot of changes and we needed to track our progress. 180 modules. It's a lot of things. That's a lot of patches. There is that readiness dashboard I showed up that's hosted on Dev.acquia.com. It's maintained by Gabor on the DAT team, our community manager. I'm sure many of you have seen Gabor, but the way that it works is there's a Jenkins job that scans all the contrib projects on Drupal.org and it pushes that to an artifact. And then you've got to download the artifact and you've got to upload it and then you get a chart. But that job was very fragile. Sometimes it didn't work. Then involved pinging and mixed logic from the DA's and hey, can you run this on top of getting GitLab ready? And it wasn't very active. Like you can't track patches on it.

Like you can't go to an issue and say, hh, there is a D ten patch, incorporate it to this result. And actually, the code for this dashboard is available at slash project deprecation underscore status if you wanna check it out. And then the asterisk because Bjorn stabilized this project data sourcing onto GitLab CI. So now we can do it weekly and it doesn't really fail. There's a few hiccups, but it's much more streamlined and I'll be talking about that later on too. So this is how we did it. We decided upfront that we needed to track this progress and we needed it to be very instantaneous since it's gonna move fast. So we built a canary, or at least that's what we call it. Like a canary in the coal mine. Because our jobs was failing, the site would fail if there were things that we said were D-ten ready but actually failed checks. So this was invented at DrupalCon Portland when I was at the booth with Jacob, and we're like, Well, we know we got to do this in two months. How are we gonna do it?

So we use composer meta-packages to group modules. So we have a stable meta package dev and unstable and anything that's unstable has to have a stable release otherwise the validation fails. Dev means it's a dev release or patched and then unstable means that it's not gonna pass. But we had CI jobs that would say, OK, remove all the unstable projects, run, upgrade status, and verify. We also had another one because Guzzle seven upgrade is that some modules used Guzzle seven, Guzzle six or used a dependency that was a hard set on Guzzle six or PSR bridges, Guzzle seven was kind of a really big knot untangle. So we did a job that just said, composer why not Guzzle seven so we could go nudge like I think Content Hub, the Content Hub team had a library that needed to be fixed, like nudging that. OK. Can you support both? So that way we had daily jobs that would tell us if things are passing or not, what modules we need to go back and open new issues for, and also distribute it to our entire organization.

And we could take patches, apply them. It would show us how many patches were replied and what things need to be fixed. So that's how we were tracking it. Let's walk through the process of fixing a module for Drupal ten, right? So step one is you scan it, you got to find the deprecations and changes. For this, you're using upgrade status, or you're using Drupal check or you've got PHP sin running on your own which leverages PHPstan-Drupal. Great, you've found the problems. Now you fix them. Those little error messages say how you should fix it. You can do that manually. Or you could use Drupal rector for php-based problems. So you've made the changes. You've got a patch-up. Now you just need to get somebody to commit it. And they did so, whoo-whoo right, the module is Druple ten ready. The fix has got committed and it's compatible with Drupal ten. You can wipe your hands clean and walk away. But wait, there's more. Is it really ready? So did you test that change on Drupal 9.4 and 9.5 and Drupal ten?

Because I've got a good guess. If you fix everything for Drupal ten it's broken on 9.4. Because by fixing deprecations that were introduced in 9.5 you're using code that was added in 9.5. That doesn't exist in 9.4. So you broke the module and there could also be new deprecations Aquia DAM used Popper JS and Popper JS was ripped out at the final hour of 9.5, so I thought we were Drupal ten ready, but we weren't because as soon as you went to go use CK editor it crashed because Popper JS was removed and I didn't catch that. So and then also release needs to be made. I didn't talk about a release and that's like our biggest blocker. Things get merged and then a release never comes because you might fix Drupal ten early and I don't wanna make a release yet, what if there's more changes? Like I said Git tags are cheap, releases are cheap, at least often. Just don't let it languish. So that's the process and some of the problems there. So here are what we learned, here's some things we learned about this process.

Tooling. This falls in my realm. We need improved tooling to facilitate these required changes and the tooling gets out of date. Another question for the audience who tried to use Rector and then it just exploded or wouldn't install with composer because of who knows why? Handful yeah, because Rector changes ten times a day and sometimes it's broken because it is like beta software and Thomas does a great work, but it's really hard to have a tool that integrates with it because it's always changing. So about three times a year I end up, that's my main contribution to Rector it's like, OK, does it still run? No, it doesn't. So our tooling can get out of date really fast. PHPStan isn't as bad, but it is a major problem if we're not maintaining our tooling regularly. So then we also got to talk about the cadence. We act like Drupal ten, nine, all these things are coming out of left field and we didn't know. But every six months there's a release of Drupal core that tells us things are deprecated but we don't fix things until the last minute.

So why don't we should set a better cadence before like before every major release. We just need to do it like at every minor release. And just like get the patches in. But the problem is this whole backwards compatibility, that's a lot of work and we're gonna find another way that we can improve that. Best practices. We need, there are no best practices. There's no doc, you can link to a maintainer 'cause I feel like that was part of our work is we found like the ImageMagick module and like its dependency, the person did all these like breaking changes, and then created a new major version and said, I'm good to go, but you can't get from two to three that way unless you upgrade that module with Drupal core, which could cause other issues. So it'd be great like if Jacob and I are talking to somebody and they go, you're full of it. Look, there's actually community doc, where we decided these are the best ways to do things and this is how you should resolve these problems. We don't have that yet.

And yes, it's open source. Maybe I should have opened that by now. That is my fault. So if anybody feels empowered by that, come talk to me and we can actually make that happen. Which ties into coordination. It is very ad hoc and it would be nice if we had, I know everybody's doing this in the free time, I don't have all the time in the world, but some kind of committee that was just always active. It's getting better and it seems to be that way. There is a D11 readiness channel already on Slack, but just some way of coordinating a little bit more of the efforts. So let's dive into some more specifics that were covered. Like backwards compatibility. So Drupal core support, there's technically three versions of Drupal Core supported at any single time. Right now and modules should. They don't have to, but they should support all those versions. Some might say well only two. I don't, I only want a year worth of Drupal support. That's up to the maintainer, but ideally, it should support at least those three.

So like right now drupal 10.0 is available. So as 9.5 and 9.4, we have one year of Drupal code that is still under security support. 9.4 drops security support in June when 10.1 is released, but that still means we have six months of Drupal nine code like one minor release that still should be supported by modules. Yeah. So fixing the, as I said before fixing the deprecation uses new code that didn't exist. So if you fix the deprecations in 9.5, you run it at a 9.4, it goes this service doesn't exist because it's still a function. So we need these modules to provide backward compatibility layers for people so it doesn't matter what version you've installed. I found modules that support 8.9 to nine to ten. It's possible there are modules that can work and even complex modules that could support Drupal eight, which is gone. So these backward compatibility layers help ease end users, most of you with your process of upgrading your sites. So here's one example and Drupal 9.1, early days they changed the signature for event dispatcher to match what Symfony did to be forward compatible.

Now you don't need a backwards compatibility layer, but you would get a ton of deprecation messages all the time and clog up your logs. So what we did is we compared the version number and said, Hey, if it's greater than or equal to 9.1 for Drupal, put the event object first and then the name. Otherwise, so at this time 8.8 and 8.9, sorry. 8.9, 9.0, 9.1. So if you're on 8.9 or 9.0, do the old way that has always been. So these are what I mean by backwards compatibility layers. Another one was in 9.4, a kind of quirky one was Git implementations was deprecated for invoke all with, again the same thing. It's does the method exist on the module handler service? Great. Use it if not, fall back to the old way. And this allows your module to work with Drupal nine dot anything to Drupal ten. Now these backward compatibility layers. I had to go back every single time and look it up in our code. The thing about what we did. And I think all change records should have this in here, the change record says before or after.

I think as part of the sign-off and I don't know how to make this like an official policy, if you will, but if we have that the signed-off published change records should have that example of how to add it to your module with backwards compatibility. So module maintainers, copy, paste, tweak. Now, they don't have to think that cognitive load is gone or contributors, right? Contributors wanna help fix modules. It can now be a junior task. One thing we realized is a lot of this work is like a junior mid-level developer fix, but you end up needing senior-plus people because there's nuances. But speaking of nuances, let's talk about releases and semantic versioning. Again, another place that we need guidelines and recommendations for. Semantic versioning already like nobody can agree on what it really means. PHP says it's semantically versioned. It's kind of, it's a very loose concept, but with the guidelines that we wanted to set. When you make a new major version of your module, when you're breaking changes from Symfony or other dependencies.

Like Guzzle six, seven, if you have a dependency that doesn't bridge between the two. An example of a major version. (COUGHS) Sorry. If you're on like the old version of 8.x, whatever it would be 8.x3 from two or 2.0 to 3.0. A minor version bump is when you're adding support for a new version of Drupal Core. But while you're doing that, you're gonna drop a previous version. So I have an example that will show that, but adding support for a new major and at the same time you're dropping a previous minor support. So old way would be 2.8 to 2.9 because technically that dot is considered a minor in the old ways. Or here it would be 2.0 to 2.1. And then patch releases, we saw so many people make major version upgrades 'cause they added Drupal ten support. If you use backward compatibility layers, it should just be a patch release. It's like a bug fix like it's a small change. Don't make major releases and cause your end users pain when trying to upgrade their modules or if your module is a dependency of another module.

And now that module needs to figure out how to make it work. We saw a lot of that as well. So again, adding a new Drupal core version. If you use backwards compatibility layers, it's a patch version, it's a small fix. And with that, that's where you need to create releases that bridge versions of Drupal. So that way we don't have the problem of I need to get to Drupal ten, but I can't just say composer upgrade Drupal core, it's Drupal core, and this module and that module I try to make it so they don't need to upgrade everything at once. So an example of that would be you have version two that supported Drupal nine and then eventually, like, you know what, I'm gonna drop 9.0, 9.1, 9.2. 9.3 is my baseline. For that you create a minor version. And then for 2.1 or for 2.2 actually I'm gonna drop to just. 9.4. So I need 9.4, 9.5, and Drupal ten. Done. So you create a new minor 2.2 that supports that range. Then you decide, You know what, I'm gonna create a new major version of three. Because I want all the goodies of PHP 8.1 and Drupal ten.

I don't want any backwards compatibility stuff. I want all the cool stuff. The main point is that this 2.2 allows people to use their Drupal nine site, upgrade your module and then upgrade to ten and choose to get the next major version. It's a seamless process for them and not a composer nightmare that says cannot resolve packages. All the reasons. And also supporting a new PHP version isn't a breaking change. Just because you adopt PHP 8.1 doesn't mean you're gonna start using annotations and union types and whatever else you can just support 8.1, fix some deprecations. And then do another major release that kills off like PHP seven code. It doesn't always need to be a drastic change by supporting something new. Which again is why we need these guidelines, because it's a conversation that just kept going and going and can be very exhausting like mentally. And then we got a fun one. What about adding dependencies to fix deprecations in libraries? This is a good question. jQuery UI was removed.

Do you make a minor version to add that dependency or is it a patch version because composer magic or is it a major version? I don't know. I've asked a few of these questions like the Laravel community and this one's kind of out the door. 'Cause it's really unique to Drupal. Jacob wrote a great blog post. I do the slides online because medium or you can get the slides from the node on midCamp. There's no like short URLs for medium, so there's a bear to look at. But Jacob wrote a blog post called Don't go making major version Changes. I wante him to title it to like that TLC song Don't go chasing waterfalls. So that's how you remember not to always make a major version. Then there's also the challenge for releases of getting maintainers to commit fixes. We have lots of modules. I'm guilty, yep, I wrote that. ISF orientation, totally forgot I maintained it, created it. Lucas Hedding was like, hey, can I become a CO maintainer to merge and release this? I was like, yes, thank you. I forgot that I'm a maintainer for this.

So get him to commit or there's the whole commit i'll come back later in release. Tick tock, tock, release never actually happens. Or you have a maintainer that can merge but can't do releases because we do have that kind of granularity. For that, there is the Drupal ten readiness product project adoption initiative. So there's actually a group that's out there. Lucas is one of them. He sent me a nice email that said, I appreciate your work in the past, but can I be a short-time maintainer to help get this for Drupal ten? Really nice way that they're doing things and it was something we were kind of missing from eight to Drupal nine. This is a new one. So yeah, JavaScript fixes. There's no tools. We have nothing. And when I went on the internet, I was like, somebody has got to do like a Rector for JavaScript. Well, there is kind of, there's a few tools, the one that I found was JS Code Shift. Which is a code mod toolkit by Facebook. Here's a gobbledygook example, but it takes JavaScript, parses it to an abstract syntax tree, and then you can rewrite your code in place.

I did an experiment on my GitHub. So it's Mglaman/jquery-once-jscodeshift. It worked, I used it. I couldn't figure out how to package it as a standalone. But ironically, Theo Nod used the same tool in the Drupal core issue that migrated Drupal core away from jQuery once library. And he shared me a link and there's a patch and there's the JS code shift tooling in that patch. But then it got removed. So he used it for Drupal core and then contrib had to go write its own. So the question is should Drupal core provide these scripts? Like if Drupal core builds a script to migrate away, should it be available or made in such a way that contrib can use it? Or is it another standalone tool that somebody has to maintain? I'm not sure yet 'cause we haven't had enough of this to really know, but Drupal ten is adding more JavaScript deprecations around like theming functions. So this is a new era of tooling. So if anybody is hot to trot on JavaScript. It could be an interesting way to contribute and help make major versions possible.

Not possible, easier. So PHPStan learnings. This is my domain. So I gave a talk at Florida Drupal camp last year. It was last year about how we need to start doing scans at level two because right now Drupal check upgrade status to level zero. Basically, this is PHPStan. I don't care about anything else. Just tell me the deprecations, where level one and two say this method doesn't exist. You're talking to something that is imaginary and we're silencing those right now. So here's hopefully an example that you can see on your screen. So hook node insert, right? It does entity interface note. It says, you're gonna receive an entity of entity interface. Great nodes implement that it passes. But there was a deprecated method in Drupal eight called get revision author. At level zero, PHPStans like yeah, it looks good, but if you turn it to level two, it says hold on, get revision author is an undefined method. It doesn't exist in entity interface. So it'd go, Oh you're right. So you'd edit your code and say actually hook its node entity interface I'm getting.

There's no harm in changing your types on hooks unless you do the wrong one. Now PHPStan would go oh, get revision author, yes, that is a method. That error is gone. But know what shows up? the deprecation. And with 8.9 to ten there are so many bug reports thrown at me because of this. So that's why I believe that we need to start doing level two, which I did at the end of Portland, Drupal check now runs at level two. Unfortunately, that means maintainers got a lot of patches that had extra type changes in it when there's maybe no Drupal ten deprecations because if you tell a junior run Drupal check, fix what it says, go forward, they're not gonna know like actually, this change is kind of junk. Like yes, it's a good improvement, but it's not unblocking Drupal ten. So now maintainers are getting these patches and they're looking at me being like. What's this extra noise? But again, I think we'll get there and it will be useful. It's gonna make life easier in the long run. This goes, there's custom rules that PHPStan Drupal provides.

This goes to the whole like needing to have updated tooling. One example is deprecated global constants. Global constants aren't available via the Reflection API. So we have a custom rule that has to track them. So if a constant is deprecated in Drupal core, I need to know the change record happened so I can copy it or usually Gabor holds me pretty good to that, like tracks it. My favorite change of all is that content entities on entity queries must call access check. It can't be implicitly implied anymore. You need to explicitly do it. That was about six months of work to get PHPStan Drupal to actually scan and recognize these. To find out that actually, it should exclude config entities and there's bugs on config entity count queries. And then also like we deprecated the usage of Symfony CMF routing. So this meant like, this was tricky, we were gonna remove a dependency, but we couldn't mark them as deprecated because we don't own the code. So I had to write custom code that checked for instances and usages of that code and said, hey, this is gonna go away in a few months.

And then a few things with like renders arrays and callbacks Upgrade status. I actually didn't have anything for this. And then at the final hour, I realized what if upgrades could say, hey, jQuery UI was removed. You need to add jQuery UI or whatever modules as Dependencies to your composer.JSON. This was a gap and I think it would have been great if we made that patch for upgrade status. I can't remember if I made an issue yet for it, but that way if anything in Drupal core gets moved to a contrib upgrade status can warn you better. It might already have a warning, but maybe it can make it a little bit larger. And then also allowing upgrade status to run at PHPStan level two. Make that a flag because earlier somebody brought up that feature and I think that would be nice. Like upgrade status is a user interface for PHPStan plus more. Rector, my favorite tool. It's great for end users. I hope you all use it and love it because it's just bam gets your site ready without having to think.

For the most part it's really horrible. I say it rough, but honestly, it's really really horrible for contrib. And why? backwards compatibility. Rector is a one-way street. It comes in and says, I fix you, I fix you, I fix you, you're good to go. It's very opinionated in that fashion. And that's a good thing for the tool. But it would be great if it could provide backward compatibility to the fixes. And if we could put those behind a feature flag. So when you run it for your site, it doesn't add backwards compatibility because your site has one version of Drupal core. You're not running multiple, but if we had a flag that said, hey, this is for contrib, make sure the patch supports the previous versions, otherwise it's manual intervention. Maintainers get a patch, they can't accept it. They've got to go look up the old way, edit the patch, it's extra work and it'd be great to remove that extra work so everybody's a little bit happier. So I wrote a blog post about this. Oh wait, this doesn't have the blog post on it.

But I open an issue seeing if we could automate this. I spent about four hours on it and it is not going well, but I am not turned away from it. I still think it can be possible. It just requires a lot of trickery. And then the project update bot is, are most people familiar with what the project update bot is or have you heard of it before? OK, handful. OK, so I think I covered here, so the project update bot takes is an automated bot that goes for Drupal. org and takes patches generated to fix modules and distributes them to every module. So you'll see a lot of, it's like nine readiness Drupal ten readiness soon I hope we'll see Drupal 11 readiness and I created a little workflow that kind of walks through it and actually I forgot that the update bot is actually not much of the process, it just consumes an artifact and posts it. Earlier I brought up that Jenkins job that did the analysis and created an artifact. We'd have to tap and mix the logic like, hey, run it. It would go scan all the contrib from Drupal.org.

It then runs upgrade status to find out what the reports are and says, did this module have any errors reported? No, great It moves on. If yes, it has code that fixes info.yaml and composer.jason issues. It then runs Rector and when that's all done it collects the patches and puts that into the artifact. So there's an artifact that's available. If you want to go find your patch, it's really hard to go dig through like the tens of thousands of files, but your patch is there. The update bot is a tool that just downloads that and then creates issues or updates issues and puts those patches on Drupal.org for modules. So this has now been moved from Jenkins to a project on Drupal.org, a general project called Project Analysis by Bjorn. So that whole instability and night kicking Jenkins and hoping it works it's now on GitLab CI so anybody can contribute to this like a bunch of jobs are failing due to BC math for commerce so Drupal commerce was just crashing the ship. Well now anybody could have, like we did, we edited a Docker file and said add BC math extension.

Great, the community can now improve this. It's not locked away and managed just by the DA. So there's actually no difference to this workflow except for the fact that it's on GitLab. And I'm hoping that we can start to see improvements to this. This part, the update bot is closed source because it talks about how to automate going on drupal.org and uploading files. So the idea is let's not make that public. Yes, if you're bored enough you can figure it out, but let's not necessarily encourage that. If you're curious about the update bot and you're going to DrupalCon. Bjorn has a session called Project Update bot, the road to Drupal 11, where we're gonna figure out like the next steps. I won't be at DrupalCon because I have conflicts, but I will be excited to watch the video of this and it'll be really interesting to see how we can make life a lot easier. But the problem is this process is only as good as our tooling which we kind of we keep coming back to. Like the update bot can only deliver patches as well as we create or as well as the tooling provides.

So again, Rector needs to provide backwards compatibility for these patches to work at scale. Also back to the question can we automate JavaScript fixes? Could project analysis also run JS code shift to deliver patches for like jQuery once type of things? How amazing would that be If your patch fixes your info.yaml, your library.yaml, and then the javascript and it really is just like good to go. Though who knows what backwards compatibility with JavaScript looks like. That's a whole other thing. And then automating the dependency changes. I open an issue for this that if it detects it from upgrade status then it should generate that as a patch. But the main thing is we can just keep moving forward. And onwards to Drupal 11. I'm really looking forward to this next round. I kind of dreaded it when it was November. I was like, Man, we got to do this in a year and I can't but I'm feeling much more confident because we have better tooling, better processes. If you think about it, we didn't have to do this for Drupal eight 'cause that was like a hard fork from D seven to eight.

Drupal nine, eight to nine was our first rodeo, Drupal eight lived for a long time. This is only our second time doing it as a community and I think that's pretty good considering that no other community has this issue. Laravel doesn't have as many dependencies and it's kind of like a you snooze, you lose like whatever. Symfony is a framework and they make, they do more releases more often and they're minor versions of drop things. So we're unique and I think we're handling it the best we can. So thanks for coming. I hope this was informational on how we're hoping to improve the contrib experience 'cause if we make the contrib experience better, that means you when you do your client sites, your business sites. It makes your upgrade process even easier. So thanks for coming and then any questions?

SPEAKER:
How can, so project update bot is fantastic that they, do you foresee it being possible or beneficial to make it easier for contrib projects to run Rector much more regularly?

MATT GLAMAN:
Yes.

SPEAKER:
So we're not waiting until the point when we start the update bot for Drupal 11 and then we can get out of this.

MATT GLAMAN:
So I'll reiterate for the recording. So the question is, is there a way that modules could run Rector sooner and not need the update bot?

SPEAKER:
Yes, but I know any module could configure it all themselves, but I'm specifically curious if you see a benefit...

MATT GLAMAN:
Automated on Drupal 11, Yes.

SPEAKER:
In some way, yeah.

MATT GLAMAN:
So to automate it, and this is one reason I'm glad that project analysis isn't on Jenkins because, right Neil, are you helping with the Git Labs? You're doing the GitLab stuff and Brian together, right? It's not just one of you.

NEIL:
Ryan went to work for Linux Foundation. So it's just me.

MATT GLAMAN:
OK. Never mind, didn't know that. Alright. So the fact that project analysis is off, Jenkins and on GitLab means that Neil doesn't have to worry about tinkering with Jenkins. And we're working on getting to GitLab for everybody. So the main idea was there, then you can just focus on GitLab so everybody could do it, which means that you could have Rector run on Akron like Weekly. It says, hey, GitLab, GitLab CI, run this weekly run, Rector. If there's a patch add it as an artifact. So when the run fails, you can go with GitLab CI to that job you click download artifact, bam, you got a patch. I don't know about the whole automating it as a merge request. Maybe now it's more difficult 'cause we do issue forks and the whole bit and I don't know how GitLab CI on self-hosted handles secrets to be able to open your own merge request for your own repo. But once we move everything to GitLab CI that door is wide open that the update bot may not be needed because it's a GitLab CI job that again documentation and guidelines it's copy this YAML and go and to be fair I haven't looked a lot at the GitLab stuff so maybe there are ways to automate that, but I foresee it being maybe for Drupal 11, for 12 when we do 11 to 12 as the next one in four years, whatever it will be.

GitLab is just churning out patches for us. We don't need the update bot and we don't even need project analysis because it's all decentralized. Any other questions?

SPEAKER:
I was just gonna offer a suggestion with maintainers that have like a library dependency or something that needs to be regularly updated. If they make like a YouTube video of them going through the process and post that link then on their project page, then including the testing and everything, then somebody else could look at it and see if they could apply it and create an issue, and then test it. And even if they don't know how to fix the things, they could pair with the information and say, hey, I tested it, here's the results. I got things like that and take a light off the maintainer that way.

MATT GLAMAN:
Yeah. So the statement is about if we could get project maintainers to help detail updating those dependencies and the list and the steps to verify for like JavaScript library. So that way when it needs to be changed, somebody, anybody could go through and watch it. I would say like words over video 'cause I know I can't watch a video. I'm not able to...

SPEAKER:
Well then it's easy to do, while you are doing it

MATT GLAMAN:
Yeah, but it comes on to and like documentation is hard. Like just holding yourself accountable to write things. I'm bad at it. I'll admit it. Like I should do it way more and I don't. But we should do it more. Any other questions?

SPEAKER:
Have you looked at like other like WordPress or something like that that have a similar problem?

MATT GLAMAN:
The only thing I can say about WordPress is I created a plugin called Facebook Albums that got shut down because of Trademark in 2012. And people still email me 'cause it works on the latest WordPress.

SPEAKER:
Wow.

MATT GLAMAN:
So WordPress doesn't have this problem. You know, like I must not have used like PHP five stuff in there or whether these people are running PHP five, I don't know.

SPEAKER:
They're running PHP five. (LAUGHS)

MATT GLAMAN:
So yeah, sorry. The question, just to reiterate the way I said that is, I was asked if WordPress has the same issues and I...

SPEAKER:
Or like any other software...

MATT GLAMAN:
No because we're weird like we're a snowflake. And ae weird in a good way. Like I said, Laravel, it's all packages, everybody builds their own UI. So it's not like render or a deprecations or things like that. Like in Laravel, like you take the framework and then you build something custom every time. Symfony same way, maybe Symfony like the full CMF, like their full package, maybe. But they do that with like PHP unit bridge. Which is a big thing. So, but no, we're unique.

SPEAKER:
I work for an agency and we're trying to figure out how to think about major version upgrades in terms of how we build that to our clients in the future. So we have flat fees for regular quarter, we do it quarterly Drupal updates, and then emergency updates that we do for our clients. We, for Drupal eight to nine, we build that hourly 'cause that wasn't included in it. We're planning on doing that for nine to ten as well, though we expect that to be much smaller. Though for ten to 11, we're like, well, that seems like that's gonna be even smaller. And then 11 to 12, that could be even smaller than that. And it's, we're you know, we don't have any plans right now, but we're kind of just wondering like, you know, it almost doesn't seem fair. Like, you know, could this be something that is, could there be a point where like ten to 11 or 11 to 12 is as small as a routine?

MATT GLAMAN:
Yeah.

SPEAKER:
Composer Update.

MATT GLAMAN:
Yeah. So the question was about being in an agency. And before like eight to nine, it was well normally we do slotted like block hours. But this was we just had hourly time and materials because we don't know.

SPEAKER:
Yeah.

MATT GLAMAN:
Nine to ten. That way, but it looks a lot smaller and what we get insignificant. So it's a minor version. I mean that's what Driss says every time and I see them on the Driss and he'll be like It'll be the easiest upgrade ever. Rector is automated. (LAUGHS)

SPEAKER:
It's like, how do we communicate to clients? How do we know what to expect?

MATT GLAMAN:
Yeah, I know what I would do because it isn't a minor version because there's composer, right? There's info.yaml and composer constraints. So I would still just tell them like. It's not a month. It's almost like if you could say, look, we're gonna take one quarter, but it's not gonna be like a whole quarter of time, but we're gonna do it in Q3. Let's say, and that way we know everything is ready or Q4 because if that's a release. And just say we're gonna take a few hours a week and just kind of check on it. And our model is upgraded. Oh, it's more about finding your red flags of we can't get to Drupal ten because of this module and documenting that which I do have a tool that I didn't put in here because this isn't about like Drupal ten upgrade composer lenient package and it lets you bypass composer constraints.

SPEAKER:
Yeah, we just started using that.

MATT GLAMAN:
OK, great. Which credit to the symphony team. That package that lets you just install any Drupal module regardless of it's constraints. Was built out of talks with, I think his name is Nicholas from Symfony and I think somebody from that type or three. Another one, it was like a little roundtable at DrupalCon. Yeah, so I...

SPEAKER:
Still a lot of unknowns.

MATT GLAMAN:
A lot of unknowns. But it is getting easier and smaller that's what Driss wants though. He wants it to be like a minor bump and I think we're getting to that. But I would still just try to budget like a window of time because you need a check. You don't wanna check everything in one month because then you're gonna, oh, we got this. But if you can be prepared, you know we've got two months to kind of tap some people on the shoulders and that.

SPEAKER:
With regard, I don't know if there's a single right answer here, but I'm curious to your thoughts for contrib maintainers and how they should think about dropping support for unsupported versions of Drupal. So versions before the most recent. You noted that it's great to provide backwards compatibility and workarounds, but how do you think about striking the balance once it crosses out of those latest three, say like it's not worth it anymore or we get more benefit by dropping that support? What are your thoughts?

MATT GLAMAN:
Yeah, so the question is about when you drop the unsecured versions of, minor versions of Drupal core, I personally think you can just drop them as a patch release because they're insecure. Not like, oh 9.2 just became insecure I'm gonna drop it. It's like 9.1 down like fine, you really shouldn't be on 9.1. You could be nice and do a minor version for that just to help, You know. If you do the minor version, then composer might prevent it from being installed on, well actually, it always prevent it 'cause it does dependency resolution. It comes down to what makes you feel comfortable. But I would do it in a patch release because it's like it's insecure code. It's too past, and I guess I would do it as a patch version because I'm not gonna put bug fixes on that previous minor version no matter how many times people give me patches. So that's what, that's why semantic versioning is kind of a, is it a real thing because you have to stick to it. Like if you make a new major version, that means you're kind of committing to backporting patches to the previous minor.

So I know like at Drupal Commerce, what we did is let's say like 9.3 came out I think we dropped 9.1 and 9.0. We were just like, look, these are old. We'll support 9.2 still because not everybody jumped up. But like Composer update won't download the new version of Drupal Commerce because composer says it doesn't work.

SPEAKER:
So what you just said I think is more aggressive than I was even thinking. I don't see a lot of what you're talking about in the interim space. I don't see a lot of people dropping support for previous versions until they're forced to by some kind of deprecation. So you're suggesting not necessarily on day one, but you're saying even if I'm committing a bug fix that is unrelated to 9.1 support, you know, I'm not gonna, you know, I don't wanna support that at this point, it's insecure.

MATT GLAMAN:
I guess I'll refine that a little bit.

SPEAKER:
I like what you're saying by the way, it's just...

MATT GLAMAN:
Yeah, I'm just trying to remember our commerce one. I think it's when we worked with, we were creating like our own like plug-in form system. And then Tim Plunkett was doing Layout Builder and it was like, we needed some Drupal core. And I think in whatever eight dot version plugin forms came out and then after the next minor, we're like look, we don't want these like deprecation layers anymore, so we're gonna drop. We did something of that sort, so it's kind of like, yeah, if you don't need to drop it, don't but if there's that really cool thing because you're one of the bigger modules then make that call. Like, make your life easier as a maintainer, there doesn't need to be a bridge between maintainers making life easier for end users, but then also just making it easy to maintain software. There's a good balance in between and the big takeaway is be nice to the person on the other side of the screen because it's, we're all doing our best and trying hard. So yeah one more.

SPEAKER:
Keep in mind that it's nice to keep your Drupal project up to date, but you do have people that get a site that hasn't been maintained and so they've got to bring it up to par with all PHP version changes and everything else. The more you have to upgrade each module, if you have a lot of modules, it's a nightmare to keep on stepping through all that you need to do to get to that point. And if you can reduce the number of steps for a module that needs to be upgraded, it's simpler for that as well as the people migrating on new things.

MATT GLAMAN:
Yeah, and then the statement was keep yourself updated short of it. And I can say that as somebody who had an upgrade at Drupal site from 8.3 to 8.9 on Pantheon with lots of commits and lots of environment switching, and that's not a one-off. Like some people just don't pay for website maintenance until they have to. So there are lots of sites like that and that's where I wanna make life easier for the agency that gets that thrown at them. Sure, they could do time and hours, but as a developer, is that really how you wanna spend your time? No. So that's why I wanna make life happy for everybody. Alright. Well, thanks for coming. And it was great.

(APPLAUDS)