 So it's probably about time, huh? Yay, okay. Hello. Good morning Drupalcon Thank you for coming to listen to my entirely uncaffeinated self Rambalon about automatic updates for an hour, which by the way is almost in Drupal core as you can see from the title I was talking to my friend Paige the other night. She asked me if I knew the game two truths and a lie and I have two truths and a lie here are the truths There is a module called automatic updates, which we wrote it does automatically update Drupal core the lies that it's in core We thought it might be in core when we submitted the session, but that hasn't happened yet for reasons. I will explain So let's get into it Little about me. My name is Adam Glovis Honick. I go by Fena Proxima on Drupal.org and Underons I'm a staff software engineer at the Drupal acceleration team at Acquia, which does a lot of really good core work I got a pretty long history working on core. I'm a co-maintainer of the media system I used to be a maintainer of the migration system and officially I still am but I don't even think I know how that system works anymore I also maintain the lightning distribution for Acquia may it rest in peace and I have a co-presenter whom I will delegate to if I just Forget what I'm talking about Alright, I'm Ted bowman. I'm Ted bow on Drupal.org Principal software engineer also at the Acquia's Drupal acceleration team The tech lead of automatic updates initiative Co-maintenor of lay output on setting tray module and yeah, that's it generally a smart program or two And that is my dog. Yeah, the dog in my picture by the way, not my dog my house She's total sweetie, but well that I didn't say anything you just filled in the blanks so Before I get into kind of the nitty-gritty, I want to do a little bit of philosophizing here about why we need automatic updates in core The biggest and most important reason is because you know as we all know Drupal's update process is painful and cumbersome It has been for very long time and when you're releasing security updates that you really want people to get on to as quickly as possible That's not really good So our main goal is to keep as many Drupal sites as possible as secure as possible as quickly as possible as easily as possible and The flip side of that is that we need to make composer as easy and painless as possible Composer not being always the most friendly piece of software that has ever been written But this is the way we assemble Drupal code bases now it is how we've done it since Drupal 8 So we have to try to take the pain out of it if we can So this is why we need automatic updates and this is what has guided what we've built But It's not the what we have built is not necessarily meant for every single use case under the Sun The people we think will get the most value out of automatic updates as we've created it Are those who don't have you know Don't have the time or the budget or whatever to do Drupal's complicated update process You don't know you don't want to hire developers to just update a site Thank you this open if you're a technical person who is responsible for hosting many Drupal sites Unless you've got really good scripting foo That's going to be a colossal pain in the ass keeping them all up to date as quickly as possible So we hope that this that what we've built will provide value for you If you're just somebody who doesn't have access to the command line on your host or would prefer to avoid it And if you're trying to avoid using composer at the command line, I don't blame you this is for you and You know ultimately it's really built for anybody who finds for whatever reason that you cannot do security updates for Drupal in a Timely in a timely way, and that's who it's that's who it's really meant for It's not as much meant for those with you know complicated Sites with development teams of several people who you know when every change needs a pull request and review from a bunch of people And you put it through a continuous integration pipeline, and there's a complicated deployment I'm not saying there's no value in automatic updates if this is you. I'm just saying it's not The main thing we were thinking about building this. This is for what we call long tail sites Which I don't know what that means, but I think it just means the people from the previous slide So Thank You Peter for the much much better definition that I had So with all that in mind what exactly is automatic updates? What if we built here? Well, we built two modules in a library and this slide vaguely resembles a pyramid because that's Effectively how it's built there's this library that has nothing to do with Drupal that we made called composer stager That's it's on the bottom. I'm not going to really talk about that because it's you know, it's technical It's really under the hood Then there's two Drupal modules one of which is called package manager and then on top of that is built automatic updates So from the top down I'll get into that First the automatic updates module This is a module that provides a user interface and tooling for updating Drupal core only It is not concerned with updating contributed modules or themes It replaces the core update UI which has existed for a while It's meant for updating modules and themes, but it doesn't it doesn't really work I don't know if it's worked for a long time because it's not composer aware It kind of expects you to upload a tar ball, which is just not how we do things anymore modules have composer dependencies So automatic updates replaces that UI with a new one that is meant just for updating core it is capable of doing updates in the background and It's also built on top of package manager, which is which is what it uses to do the to do the plumbing basically So to give justice to the plumbing Package manager is another Drupal module that is included with it's currently included with automatic updates It'll be its own module in core package manager has no user interface at all it is strictly an API module and what its purpose is is to manage the existence of temporary copies of the Drupal site which we call stages and The temporary copies of the site those are what get updated before it's all copied back into your live site It does all that using composer stager under the hood to do the heavy lifting This this API is also used by project browser Because that's how it installs modules. It makes a temporary copy installs the module over there Then brings it in and that's all mediated by package manager so a little bit about how it works not going to get too deep into the weeds about it, but How it works? This is really how package manager works is any given update has four phases Which we collectively call the life cycle of the update the first and this they happen in this order The first phase is called the create phase and that's where we make a temporary copy of the entire Drupal site Which we call the stage That temporary copy does not create it doesn't copy Like uploaded vials Doesn't deal with the database it ignores site settings a bunch of other stuff. It's not really a usable copy of the site It's just containing the code of the Drupal site so core vendor dependencies Modules and modules and themes So that's the create phase in the require phase. We run composer commands on that copy most of the time We run composer require which is why we call it the require phase in theory You could run any composer commands, but that's about the require phase is about doing composer stuff to the to the stage Then the apply phase which is the most sensitive the phase that is I don't want to scare you the most sensitive to failure Which is why there's a warning The apply phase is where we take all the changes that have happened over in the stage and we copy them back into the live site And then the final phase the fourth phase is the destroy phase where we just delete the stage because Changes have been copied to the live site. We don't really need the stage anymore So this is how it always works create require apply destroy, which is almost crud crad Which I don't know if that's useful at all Additionally at every step of this Process, there's a ton of validation that we do because we're always trying to make sure that everything looks good on The live site that there's no unexpected changes that have happened that things that we don't expect to update are not going to accidentally be updated So we're doing a ton of validation just to make sure we don't break your site A lot of validation bordering on paranoia, but you know when it comes to breaking sites, I think paranoia is good and this every every phase of the stage also has Events dispatch there's an event dispatch before a phase begins and there's an event dispatch after the phase begins and those events are We use them. You're they're also meant for you to hook into to do custom things if you need to So it's very it's somewhat extensible But this is basically how it works. That is the 30,000 foot view of it So before I move on I just want to recap everything That's pretty much all the theory of this thing our goals in automatic updates are to keep Drupal secure and Do so by making composer as easy as we can make it the most useful There we think the most useful case is for sites that just don't have the resources to do Drupal's Painful update process every time a security update comes out, but presumably you would like to be secure most I think people like to be And we do this with two modules automatic updates which is meant for updating cores strictly and It is built on top of package manager, which does the grunt work and heavy lifting on that Package manager has four phases of an update create require apply destroy That is how it works so In order to do automatic updates A bunch of things have to be right. You have to be set up correctly There is a very long list of things that have to be correct Most of them are not that important and a lot of them are edge cases and things We're just checking like in case in case but there are some things that are very important And these are the ones that sort of leap to mind for me The most important thing is that's a code of Drupal core and of modules and vendor dependencies has to be writable by either the web server or the terminal depending on configuration and That's you know just kind of par for the course because this is a system where Drupal literally rewrites itself So has to be writable has to be able to write itself That's not a thing we check very deeply we sort of checked certain critical points in the file system to make sure that you know You have right permission Because if we tried to check every single file in a Drupal site, it would just take forever So that's one thing that's a very that's probably the most important thing Another super important thing is that composer as I said we call composer commands on the stage So the composer executable has to be somewhere that we can find it. It has to be runnable by PHP You have to have a valid Composer dot Jason in your project, you know, you have to have a properly set up composer project You can't have any unsupported composer plugins installed and I want to explain that because it sounds draconian on its face But the thing about composer plugins is composer has its own plugin ecosystem and the plugins can do basically anything They want they can change the file system in completely unpredictable ways, which to us unpredictability is a bad thing and That sounds like sites gonna break so for us what we do out of the box is we have a list of plugins for composer that we know are safe Stuff like the there's a patcher plugin that is I think fairly widely used You know core has plugins to like scaffold files into Into the Drupal site and there's a few others as well So we have a list of known safe plugins are like, okay These ones can run and if you have any plugins installed that aren't in that list We will basically say no. I'm sorry. You can't do this that being said if you are a savvy user and you know What plugins you have and you're like shut up automatic updates. This is safe It is possible to configure this to allow plugins that you want but by default are Our impulses to be more careful and more conservative about that Another thing that is must be correct. You can't be in a multi site to use package manager The reason you cannot be in a multi site is because when you update core or modules for that matter You know caches need to be cleared roots have to be rebuilt Probably database updates after run update dot php And there's no mechanism in core right now to sort of centrally coordinate that across a multi site I'm pretty sure that there are systems out there which can do it But there's not one in core that we know of anyway So for that reason because it would be complicated and there's no way in core to do it We don't let you use package manager in a site right now One other thing with that is we stop you from like uninstalling modules while an updates going on and in the future We'll probably stop you from doing other things while an update is going on So it would be very hard to stop those other sites from uninstalling modules at the same time and multi site by definition They're using the same code base so Yeah, right now. It's not we stop it from being used Yeah, or you know, the only thing worse than breaking one site is breaking many sites and a multi site at the same time Also composer needs to be secure to use Package manager by which I mean it needs to be using HTTPS and TLS to download stuff from the internet Which to be clear it will do by default it is so unless you've specifically turned off HTTPS for some reason Which why would you do it? But even unless you've done that you're okay here. There's other conditions There's a lot of them. These are the most important ones The good news is you do not have to remember all of this crap because if there are problems detected The UI will tell you that there are problems And it'll do that on the status report as you can see here It'll also do this like on just the admin screen before you try to update if it finds a problem And if it does find problems, it won't let you update the button that says update will just not be there So we're we're pretty strict about enforcing these generally So that's sort of that's all the caveats and stuff The way this actually works is there's two ways to do a Drupal core update on attended updates and unattended updates Attended updates are real easy. You go to you know admin reports updates and If there's an update available, it'll tell you can read the release notes if you want But then you just push the button And a batch job begins and you wait and then there's a confirmation screen before we apply the Apply the update to the live site We recommend you back up. I will be repeating this point and Then you hit the button again another batch job begins and when that's finished Ideally you see update complete and you're on the latest core. Isn't that magical? I Hold for applause So That's an attended update We call it an attended update because you are actually sitting there and you're actually clicking the buttons And if something breaks and goes wrong you are in a position to react to that problem right then and there Attended updates are more permissive than unattended updates in the sense of they'll let you update From say Drupal 10.0 point something to Drupal 10.1 they'll let you update across minors that are reasoning there is that you know Updating across minor versions of core is a little bit more disruptive more things could go wrong and If you're actually sitting there, you will catch those problems. And so we'll let you get away with more stuff The other way is unattended updates These are the ones that happen while you sleep The goal is to set it and forget it basically They sit and run in the background and these are more tightly scoped They can update you either to security releases, which is the default or all patch releases What I mean by that is like if you're on Drupal 10 point 0.3 or something and 10 point 0.4 comes out But it's not a security release. It'll just be ignored But if 10 point 0.5 comes out and it is a security release will update you to that because we want to keep you secure Or you can say no, no, no, that's okay Just go to all patch releases and then it'll update to all patch releases unattended updates will never ever update you to Across minor versions of core it will not go from 10.0 to 10.1 or any other minor jump like that because of the potential for breakage Unattended updates if a problem is detected that will that could break updates like oh suddenly some file That became not writable and we need to write to it it'll email you about that So you should never wake up with a broken site You might wake up with complaints about not being able to update but that's better than a broken site And there's two ways to run unattended updates Which I will go into one of them is run by a drush command Which you could set up in cron tab and the other way is by a web request, you know to like slash system slash cron So Let me talk about both of those ways Setting up unattended updates by a drush. We wrote this command drush auto update It's that's literally what it does you run drush auto update if there's an update. It does it all in one shot and It is running at the command line So because of that there's a security advantage here Which is that the web server does not need to be able to write to the Drupal code base and that's pretty good. Hey That's pretty good thing because I mean the web server's job is to talk to the entire world and do whatever the world Wants so kind of better to run things as a separate user on the terminal in the background This is the main advantage of doing it by a drush There's also the fact that commands command line commands don't necessarily aren't necessarily as prone to timeouts The con is that it's a little harder to set up. You got to go to cron tab You know and say hey you got to run drush auto update, you know on some schedule And it would look the command would look something like that So that's running them by a drush running them via the web unattended updates the setup is a little bit easier Cores documentation Suggests setting up a thing in cron tab that you know pings the system cron root Every so often which will run cron. That's how you would trigger automatic updates that way the downsides being that The web server sorry the web server needs to be able to write to the to the file system Just a little bit risky from a security standpoint You know web web requests can time out more easily, so that's a little bit that can be a problem unattended updates also do not work with automated cron right now for boring technical reasons But they don't work with automated cron. So if you're relying on automated cron to do cron stuff You're gonna need to set up Probably pinging system cron in cron tab rather than do that And that is one of the things we'll warn you about in the UI We'll tell you like hey you have automated cron and you have automatic updates on That's and we guide you how to do it the other way So those are the two ways of running automatic updates unattended by a drush unattended by the web or you know just sit at the UI and do an attended updates nice and easy so That's how you use it What could go wrong? Famous last words for sure A lot of things could go wrong But a lot of them we a lot of those problems we will try to detect ahead of time So, you know, I don't want you to be scared of this as I say it does work pretty well Some of the stuff that's probably most likely to go wrong file permissions are the reason that I brought them up first on the other slide They can be a little tricky they can be unpredictable as I said We're not scanning every single level if you have a hundred modules installed in 500,000 files in your Drupal site It would take eons to scan every single one of them and make sure they were all writable And even if we did that, you know while we are working on an update over in the stage somewhere file could Permissions could get changed on something so they're not necessarily predictable They're a little bit tricky if something like that changes and we can't write to can't write to a file that we need to That'll break an update Certain operations particularly the create and apply phases of an update where we're just copying a ton of files back and forth those could time out Simlinks used to be more of a pain point than they are now. It's it used to be That if you had any sim links in your code base at all, we would just detect it and say nope no automatic updates for you That's improved significantly. It's now that you can use sim links now just not all sim links under all circumstances Certain kinds of things like sim links on Windows. I'm sorry Windows users Hard links are not allowed absolute links pointing elsewhere that are that's not inside Drupal those aren't allowed But we're more we're a little bit more smart about this now So these are some of the things that could go wrong there could also just be a random sad You know, I don't know. Maybe maybe the server gets struck by lightning or is stomped upon by Godzilla I don't know But That is why you always back up You should be doing this anyway. This is good life advice back up back up back up the good news about problems going wrong during updates is that If something goes wrong over in the stage Who cares? It's a temporary copy of the site. It's not accessible. It is completely separate from the live site So problems in the stage don't affect the live site at all Good, this is true for every phase in an update except for the apply phase The apply phase as I mentioned before is the most failure sensitive because that is the phase where we are literally just copying all the Stuff from the stage back into the live site So if something goes wrong in the middle of that What you're gonna end up with is a live site where some of the files are the old version of Drupal and some of the Files are the new version of Drupal and that's just not gonna fly There's no way right now to recover from that scenario except to have backups Which is why you have to have backups so have backups if that happens that is what that's the only failure We consider it to be a catastrophic failure. You will get an email says hey No, the update failed to apply in the middle of it. You need to restore from backup But the good news is that we have had people testing automatic updates for a while to some extent and we've never seen this reported So I think that generally it's going to be fine But back up because it is a smart thing to do so To recap all this a lot of things have to be right for automatic updates to work properly and especially file system permissions and We check those things It's the good news Attended updates are done in the UI. They're very easy. They're two clicks. If all goes well It's done unattended updates are done while you sleep and they can be run either by the terminal on a drush command or By the web if something goes wrong in the stage your site is completely safe and will be totally unaffected except during the apply phase where if it breaks while copying files from the stage to the live site You are definitely going to want to restore from backup restore your code and you know Just to be safe your database also from backup. So back up before updating. That's the last time I'll say it So getting towards the end here. This is a short session, but honestly, fine I Want to talk a little bit about what automatic updates doesn't do either yet or at all Rollbacks so rolling back an update is not something supported by automatic updates This is not something that has ever really been supported by Drupal when you run update dot PHP There's no way to control Z that You know, it's a one-way street updates in Drupal. So we don't support rolling back updates because Drupal doesn't really support that We don't have built-in support for git or version control Mostly because there's a lot of different ways to use git There's many different workflows trying to support that would introduce a lot of complexity for us for maybe dubious benefit and The truth is as I mentioned package manager has event hooks it fires events at many different points and you can hook into those and Therefore if you really want to have some sort of integration with git or a version control system That's something you can do with custom code. So it's not built into automatic updates There's no built-in a B testing You can't you know create the stage and then do the update in that and then go see it before you apply The reason is because the stage is as I mentioned not a it's not a bootable copy of the site It sits in a temp directory somewhere. All it has is code. It doesn't have your settings. It doesn't have your database It doesn't have your uploaded files So it's probably a thing you could custom code in some way if you really wanted to but in that case you might already be kind of very well into the enterprise space and I Don't know how much value you're getting out of automatic updates at that point anyway So this is just not this is just another complicated thing that we don't support out of the box But if you are determined, I'm sure you could do it in some way automatic updates will also Probably never do major core upgrades. It will not bring you from Drupal 10 to Drupal 11 because Major versions of core break backwards compatibility. That's what they do. That's their kind of their point So we can't just update you to Drupal 11 while you sleep because backwards compatibility breaks virtually guarantee your site will be broken in the morning So not a thing that we will do at least not for the foreseeable future And I wanted to devote a whole slide to this about automatic updates not updating contrib projects because this is a Thing that is clearly a useful feature So we wrote a module for it called automatic updates extensions, which is included currently with automatic updates It's going to not be in core at least not for now But it will be in contrib you can use it if you're feeling very confident about it It's still experimental the reason automatic updates extensions is not part of cores not part of our of our MVP in core Is because backwards compatibility and contrib projects is really if the core has really strict standards About what can change in any given release and how it can change? And those are very carefully enforced by the core committers for the very reason that they don't want to break sites Contrib bless its heart can do absolutely anything it wants. There are no rules Which is a good thing, but it's dangerous when you're talking about automatic updates So because contrib themes contrib modules can break anything whenever they want if they want to It's not something that we necessarily want to support automatically that being said we do If you want to use it install automatic updates extensions you go to the modules page and there's an update tab Which will show you a list of modules that you can update and it works basically the same way as Automatic updates for core. So the main difference is we don't support unattended updates right now for contrib and So basically, I mean we're not It is probably as safe as running composer for say right because we do check things that say you wouldn't run in a regular Direct composer command. So if you want to especially use it locally, you know, if you're if you're updating modules locally It's you know perfectly safe to use as far as like you should be you'll be sitting in front of it And you'll be able to see the changes to your site, but it's not It's not part of core MVP. So we didn't build it into the main thing But yeah, still experimental, but we definitely want people testing it out to see, you know How can we get it to the non-experimental phase and honestly? It's a hell of a lot better than like having to sit there and battle composer at the command line to like figure out why your modules won't update So yeah, that is a thing that maybe eventually we'll do it in core, but I don't want to promise anything I think that would be really cool if we did But speaking of core So I started this whole thing by saying we are not in core yet In automatic updates, but let me talk about what it's going to take to get there There's a few things one we have to do some infrastructure work on Drupal org itself Automatic updates and really package manager uses something called the update framework, which has the very convenient acronym of tough Its job is to prevent Supply side attacks many different kinds of supply side attacks And it's not specifically meant for it's not a Drupal specific thing But the idea here is if somebody set up a man in the middle attack on packages dot Drupal org So it could send out malware to every site every Drupal site that was using this well That would be bad. So tough prevents that and we've been working on this While working on the automatic updates module and it's going really well But there are infrastructure changes needed on Drupal org to support this properly Which we are working on and the Drupal Association also. I want to just thank them Because they've been working tirelessly on it as well along with I think consensus enterprises and tag one possibly others So this is something that we need to have in place kind of before we can get our Reviews and so I say something about tough. So the update framework stuff that we're implementing It's basically going above and beyond what composer now offers you so basically it's not like We're introducing new security risks in the sense that we're offering to do updates in the background And we're providing a UI. So if you give somebody access who you don't trust to your website They can now update Drupal, but we're not introducing any new composer oriented security risks that we now have to Implement the update framework is basically because we're trying to do this for the whole Drupal ecosystem or anybody who wants to use it We want to go above and beyond what you now would have if you went through composer through the command line It's not necessarily that what we're doing is more risky than composer itself It's just we want to be more secure Because you won't be watching your site when it happens and when a critical security comes out update comes out and eventually We want, you know a lot of Drupal sites to use this then a lot will update, you know within a few hours So that's obviously a very tempting attack You know attack surface if you are malicious to go after the Drupal community So the idea is we want to be even more secure as secure as we can possibly be and so the update framework is I think was made by the Cloud native Foundation and it's used to update car software. It's basically a protocol of how you do it. So we're Don't think that because we're doing this all this stuff on Drupal.org. It's because We're doing more risky operations It's just it's a bigger target. So we want to be even more secure Fix the internet basically So After we have that once we have tough support out on Drupal.org We need to have review from the security team as I said Drupal rewrites itself with automatic updates. So This is pretty security sensitive. So we need full review from the security team. And then after that We need regular core committer review, which is a very Very deep and very long process. What doesn't have to be very long, but it's definitely deep. They read every line So these are things that we also need before we can get into core Another thing we need I Think is battle testing. We need real-world testing. We're ready for this now We just tagged an alpha of automatic updates three in contrived and If you if this is inspiring to you if this is super useful to you We would love for you to help us battle test it This is absolutely the best way to help this initiative and to help this project right now We're gonna have a boss in the contribution room Immediately after this so if you want help set like setting this up or you have questions, maybe you think this could be useful Come bother us. That's what we're there for So when we have all this kind of stuff I think I think the road to core is clear and Hopefully will be in 10.2. Maybe 10.3 somewhere in 10 definitely would like to be in Drupal 10 and With that in mind, that's everything I got Got our boss in a few moments slides There's where the module is if you want it any questions Yeah, so it does have a I mean basically the problem of autumn of updating your site if you are able to do it in different environments is Not the same as if you don't have multiple environments and you have to do it in the same space I mean, it's it's similar, but like what you need to do in the background is not the same So I'll quit does have a system for like, you know providing Security updates to clients, but it is not exactly this system and We've talked to them about like integrations, but it's not Even though it seems like it's the same it's like The same general problem space, but it's just the restraint This is really focused on the restraint of you have a life site that you want to update to directly So a couple things that we you could do if you have continuous integration to use this is our drush command Presumably you could spin up You could have something that makes an environment every once in a while spins up this command And it will change files like the composer JSON file You could see if it changed the it will basically look out and see if it their security updates Let's see if it's like to the policy that you chose like security not security updates and At that point you could use your Continuous integration pipeline to basically send it out to your clients or ever say hey We have an environment that applied an update and depending on you know what the client wants to do either will look at it Or just directly push it over so you could use that part I mean what we would get you is you don't have to write The logic for like parsing the update feed from triple dot org to figure out if something is an update Pals is updated or not The other thing that we get you is potentially we look at the code base and say okay Is there probably a database update that's going to apply and if there is that's not something that we do? Automatically and that's probably something that no site really wants to do automatically and have nobody look at it So that kind of stuff you could use in that sort of continuous integration environment You wouldn't have to write that yourself so it could be that you know You could send the client potentially at that point like oh there was an update and It didn't have a security. It didn't have a database update So it was it's able to apply able to be like either reviewed or push automatically So could you could use that tool right now? It's a drush command eventually with this court It'll probably be a symphony console command, but it's not going to be something like out of the box This initiative is just going to take care of everything for you also because there's just so many ways that You know people want to do their continuous integration, which is not like something core is aware of so yeah But I think the console command could be something that people could use For the record the question was is there a plan to support, you know more complex And the thing that actually Peter pushed us to do this is Probably not that tier because aquee doesn't support this and a lot of hosting a lot of like specific Drupal hosting doesn't support this is the The drush command and eventually is a symphony console command does allow you to have your site right protected From the web server you just run that command as a different user who has higher privileges say like every hour every three hours or whatever So that is one thing that now I think we're covering a larger Base of sites that we used to not cover because we used to say okay Your site just has to be writable from the web server, which was you know, it's a It's a balancing act of security if you never apply security updates And then we say okay to use our stuff you have to be writable then it's like okay Well now you have security updates, but you're writable, so you have to choose what's more valuable But if you're willing now to go through the You know one time step of setting up that drush command then you can have sort of both worlds of like a Protected file system by your web server, but something that also gets automatically updated MVP Yeah, and we've talked about it Yeah, so have we explored the idea of basically having some way for contrib modules to say I am auto updates compatible because I'm following Simvormers for more strictly. I won't break things. I won't break BC and patch releases basically Yeah, we've talked about it It I think we obviously would need Drupal.org infrastructure changes probably to so right now. I think that's Not possible because I mean basically we don't want to take the Drupal association away from the work to getting the update framework Done, so it's something we've talked about. It's just a matter of it would also So for the core update testing for the testing that we're going to set up is related If you're interested in the boff is we're working on cron updates for for contrib unattended updates and We want to test that with people who are opting in who know the risks and Basically because we want to look at like the future of like how we could do this So if you're interested in well, this all sounds great, but it's only useful if I can update contrib Automatically then come talk to us because you'd have to get set up with this first And then we've when we finished the unattended updates for contrib That we're going to test in experimental way with like a small group of users Then we can see like how it works what problems come up and then we can get a better idea of like, okay Do we want this in core eventually how you know, what are the pain points people have? Is it really what people expect if it happens? So there's yeah, there's a lot of ways you could potentially even like opt-in individual releases. This is automatic up This is unattended safe or something but sort of down the line, but Interested in like how we could make that work So one thing I was interested in trying to work on at this Drupal con is actually like can we like people who Rely would rely on us for backups not our module, but Drupal like I want my site to back itself up I don't want to do it. There is the backup and write migrate module. I'm not I don't know the current status of it It does say it's 10 compatible But they could Potentially pretty easily Like hook into our event system and say we're going to do the database and I know it supports database updates I think it supports code updates, but I'm not sure if the Drupal 10 version does But potentially there could be an integration module there probably not on RSA, but maybe on their side That would do that for them and basically We would do it like in the pre-apply phase so right before applying to the site and one thing with the advantage of that is You can write in the event system that we have you have valid in all the pre events There's validation So basically they could write something do the backup and if the backup doesn't work say an error like don't do this update because obviously It doesn't help you if you say okay right before I'm going to try to do the backup But then it didn't work and then you update anyways So they could actually stop the backup based on at the update based on whether the backup actually worked or not No question for the record. Yeah, is there a way to use the event hooks to back up your site beforehand? Yeah, and code wise you could do whatever you want But I think but I don't know is backup and migrate still a thing as far as like a people use it for And anyways, it's a module is out there. I think it has a lot of usage. So it could definitely custom-coded it Yeah, all else fails Yep, so Update so yeah, so he asked whether we up we run update hooks So basically Drupal updates schema or database updates under under certain circumstances Usually happens in minor releases, but sometimes it does happen in patch releases Right now. There's not a good way For like a hook update to tell you like oh, I'm doing something very minor. It's probably fine, you know run it unscended That is another thing we're also talking about like can we figure out a way to somehow annotate or somehow let us know like this Does something very minor Right now if it's in If it's unattended we look at the stage and we look at the active site and say hey Are there any database updates that are going to run and we err on the side of predicting that there will be updates even if we get it wrong as opposed to airing on the side that well, maybe we'll miss some but we'll get most of them or whatever so So basically we look at the stage and unattended and say actually their database updates We're not going to run this and we'll email you to say hey, we can't do this update automatically But if we don't find that we'll do it so if you're doing it via the form We will take you to update PHP Afterwards if you're not familiar the hook up the update hooks are basically if you go to update dot PHP It says hey, there's some pending updates. That's what we don't run if it's unattended Most patch releases do not try to do this do not provide that so most of them will apply I think most security releases definitely don't have them Yeah, so security releases if you're not sure they are always solely focused on like the one security thing They're trying to fix so it's not like they're going to roll a bunch of other things in that need of database updates So most patch releases should be fine in the unattended Even more security releases should be fine in the unattended But we do check to see okay Did they for some reason need to do a database update and in that case we'll email you and say hey, sorry We can't run this please go to the forum and run it the buff is yeah in the sprint room Which is 408 so basically go up the escalator that way like go across you could either go across that courtyard Go up the escalator and it'll be running to write But there's a sign says general contribution. I think Monday morning. It should be pretty empty I'm guessing not everybody's full into sprint mode yet. So I didn't see where the buffs were to sign up earlier. So this will actually give us more time to do We're not time limited to be like, okay, we're done. We use somebody else's taking our tables. So if you're interested Other questions. Yeah Yeah, so yeah, we the the question was if you're using the patching Plug-in for composer what happens if like, you know, you have a patch applied to core and then it gets fixed in the next release You know what will happen there? What will happen there is we as part of our support we have very explicit support for the patcher and One of the things we do is we make sure that if you have the patcher installed It will composer will freak out if a patch doesn't apply composer will exit. There's a flag for that so If you suddenly update to a version of core that has that patch committed to it The patch should fail to apply and composer will have an error and the update will stop So we're checking for that. We want to make sure that that Doesn't that there's no conflict there And we don't like we don't assume like oh the patch didn't apply. It's definitely fixed Let's just go on basically if the patch doesn't apply We we figure we can't do the update because we don't actually know if the patch fails that it's because it was applied or just that Code changed now the patch doesn't apply. So if the patch doesn't apply, then we say sorry, we can't do the update And then we email you so basically we veer on the side of like not doing the update if we're not sure We don't be like, ah, it's probably fine. Let's do the update and we'll email them afterwards or whatever Update to try not to update anything goes wrong at all. I mean we're risk averse for now but yeah Composer patches That's one of the composer plugins that we support Because we know how it works and we've talked to the maintainer and Yeah, we'll tell you if that setting is not on that to fail if If the patch doesn't apply and then we try to go actually we don't try to buy it The composer plugin itself tries to apply the patch and it will tell composer like a some, you know Something didn't go right. So and we'll stop the update process Oh, it does as long as you're sitting there making it do it you have to push the button. Yeah Because the idea with minor updates of Drupal core course, you should really be looking at your site and seeing if everything's okay There's nothing technical that would stop us besides they usually always have database updates There's nothing technical that would stop us from updating you via minor But it's probably just not safe like you should look at the site and be like, yeah, it's fine Also because minors aren't like a surprise It's not like you're gonna wake up one morning and there's a new minor and you're not on it You'll sort of know ahead of time like security. There's security updates also not a surprise and that we know the window But there's a lot more of them and you don't know if there is going to be one So the idea is you shouldn't have to sit there on Wednesday and be like her every it's every few Wednesdays And security standpoint, too. It's like if you're on the previous minor Those are almost those are still security support So if the security if you're if 10-1 is the latest minor you're on 10-0 and a security fix comes out on 10-1 It's almost certainly gonna be back ported to 10-0 unless it unless it just doesn't apply to 10.0 So you'll still be secured either way Yeah, right now triple-core itself I think is going to warn you if you're going out of security coverage And I think it warns you actually if you're on the if you're on your status report If you're not on the latest minor that you only have six months or so to get on to the next one so if you're on presumably with the two versions the two minor version support of security updates is You should be able to run the unattended updates for a year And have it automatically update and then you know every year you would have to go from like 10-1 to 10-3 But That probably you know There'll probably be some in there the patch relates that might have database updates So what you're not it's not guaranteed that you won't have to go to the forum before then But the combination of triple-core is new like security policy of not new now But for a while of supporting two minors at a time and us supporting all patch releases should get you a ways Without having to go to the forum press the button That's time So I release you all yeah anybody wants to come up