 Thanks for coming. I won't take it offense that people chose to stay at the trees note instead of getting here right on time I'm just kidding Yeah, I hope I didn't set up too much expectation for humor as far as with the video, you know It's easier to plan out ahead of time So, yeah, this is getting ready for automatic updates in Drupal core I'm Ted bowman a principal software engineer at the Drupal acceleration team at aquia One of the tech leads on automatic updates initiative and a layout builder and settings tray co-maintainer So automatic updates why did people most people came from the trees note? I just because I know we covered some of it in there Anybody not see the trees note Okay All right, so why is automatic updates important? So the overall maintenance of Drupal sites is high Of course, this is not going to solve that problem, but you know like completely but you know chipping away at that problem and a lot of sites don't apply security updates on time even Massively like the you know critical of critical security updates. It's usually, you know, like three weeks I think was like the quickest we have we got You know 80% of sites to use that and you know the exploit was probably like in one week so Yeah, it's I think we can just infer by that by for a lot of people that yet keeping up with security updates Especially is too hard And also composer has been a pain point for a lot of Drupal site builders and developers So I'm gonna go through a couple definitions Because oftentimes when I say automatic updates and then I show a form where somebody presses a button They say well, that's not automatic and I say, you know your dishwashers automatic, but you do have to press a button to start it So So manual update I'm considering you go to the terminal you run composer update. That's manual Even if you wrote a script to do that, I would still consider it manual Attended updates is basically you go to a form and you press a button and you update something Unattended update happens on Cron. You're not actually there And you could be asleep while this is happening. It's undetended Patch version update. So this is like going from nine three Ten to nine three eleven. These are mostly bug fixes. Usually I think usually are always no new features and Historically, or we try to be the lowest least disruptive on this type of update Security update does usually happen in a patch update, but Usually in a security window window, not always. So you kind of know they're coming up And then it usually contains only the security fix. We don't like oh, we're gonna do a security fix And then let's throw a bunch of other stuff in it also. So Disruptive could be but also try to make it as least disruptive as possible by not putting a lot of other features in that security release Minor version update going from anything in nine three to anything in nine four And these are unscheduled six months releases and the Drupal project has a pretty good track record of Keeping on that schedule This does contain new features can be definitely can be more disruptive as far as like the history of Drupal eight and Drupal nine Then patch updates, but again try to keep it least disruptive as possible and then major version updates from Say nine anything in the nine to the ten up to to Drupal ten These are disruptive They remove deprecated API as we do try to make again try to make the process as simple as possible But for now, we're not even really talking about this as in scope for the automatic updates module It's not really a limitation of the tech. It's more a limitation of like the policy of like Yeah, things could go very bad If you if we get it wrong So current status we're beta testing the contrib module. We've had beta testers come through Drupal con It's gone pretty well at two thirty. I'm doing a buff and then after that I'll be in the In the contrib space or the contribution room, but two thirty. There's a buff We're gonna try to get as many people going starting as possible We have a script starting from nothing or you can try it on your existing site. So If you can get to the terminal on your site, then we can probably test this if you're going to the first time Contribution area and this is something that you'd like to contribute to as far as testing They will set you up with like Git pod So you don't necessarily if you don't know how to get to the terminal right now They can help you set up environment where you could test this and If you're watching this later There is on the project page. There's a link to the instructions to beta test So as long as we're beta testing that link will be there and I'm sure I'll remove it. It's the day. We're not so for sure Okay, so let's look at the features. So again patch version updates is the thing we're going to support right out of the box and So this is again going say from something in nine three to nine four and So nine three One in this case to nine three twelve So an example of minor version support like what you would basically be able to get away with without doing any kind of manual update is nine to zero came out in June 2021 or Yeah, and then nine three was released in December and then the next June nine four was released And then nine to support in so that would be like at that point You would need to do a manual update if we only support patch versions updates So of course if you wanted to get to nine three before that you would have to do manual But if you're okay with the bug and security fix or maybe it's just security fixes for a year Then you could stay on the nine two branch and we would Automatically update you So let's look at the update process. I am not going to play the video that we played For the Dries note, but generally you're shown a form You select to update it downloads the update. What's happening actually is that, you know, it's copying your site everything In your code base that we think is sort of composer Managed and we exclude a bunch of stuff like your public files and your private files because again that could be You know huge to copy over and composer doesn't care about those if you're using like a SQL like database we skip that and there's an extension system where you can exclude other stuff that we don't know about that Is not considered your code base. So once that's copied over Behind the scenes we run composer on it and we say get to your next version You're shown the update form. You can cancel or continue By default it's going to put your site in the maintenance mode unless you uncheck that We really recommend you do it in maintenance mode because Somebody's hitting your site while you're updating. There's not much we can do in a single environment from making that work well so You put the site in maintenance mode and it copies the staged update back to your site and Then you know you go to your page and see you updated to whatever the latest version is Okay, so we're going to look at some actual behind-the-scenes footage of like how that works Okay, so you have a Drupal 9 3 11 site and you have visitors coming to your site and then We make a copy of 9 3 11 your code base and we put it in a temporary spot and then composer comes down and we ask composer to update it to 9 3 12 and Then we put your site in maintenance mode very briefly We copy it back over now your main site is on 9 3 12 what we call your active site and Then we take your site out of maintenance mode and then we destroy this staged update because you don't need it any longer So at that point we'll talk about sort of the limitations of this system later But your site has been updated via composer so your composer Json your composer lock has been updated I guess your composer Yeah, your composer Json in this case would be updated So unattended updates you can either select to do all supported patch updates meaning like Everything that comes out. We would update when Cron when Cron detects it or Only security updates if you do only security updates and it's your responsibility to go to the form To make sure that you're ready for that security update. We're not going to jump you may Cron is intended for one patch release at a time So if you leave it on it will for all supported updates It will keep you up to date if you fall behind because you're only doing security updates Basically when a window is coming up Earlier in the week you should probably go to the form update to the latest minor or the latest patch version And then you'd be ready for that security update. We do have a warning system to say hey, you know, you're falling behind You know if a patch if a security comes out right now you would not be ready This currently is functional, but disabled because We are working on and the DA working on this thing called the update framework, which is a way to sign packages it's a cloud it's a sort of widely used framework for securing update systems and it's used by The best example is there's like a automotive Linux that uses this framework So not the exact code, but it's basically a protocol that you implement that protects you against a bunch of different types of attacks So automotive Linux uses this to update, you know cars over over the air But you know, we wrote the functionality into the module. It's working. We tested it and then we disabled it until On Drupal.org. They're implementing the server side because it needs a server side to get the signed packages and the information about the releases So that's in beta testing now on Drupal.org We wrote a composer plug-in that goes on the client side that basically interrupts any Requests to get things that are in the Drupal namespace and says, okay, I need to make sure this is signed correctly I need to make sure that there's not say like a freeze attack basically somebody trying to convince you that there's not an update So I don't know there's like five major types of Security tax that it protects against and if all that is good, then it downloads a directory to like Directory so it's not it is through composer, but composer has sort of an API for you to Check the updates after it's Before and after to say, okay, I need to make sure this is valid through my signing system So it provides update readiness checks and these are basically periodically checking to say hey If an update comes tomorrow, are you going to be able to apply it? So you don't want to be surprised on that kind of thing so This is an example of the status report on the status report This is one where you haven't run the current database updates needed from however you updated last time whether it was automatic or manually So this one's you're like, hey, we're not going to attempt to update unless you do this So there's a bunch of stuff like Well, we're getting at the limitations of the system But it basically checks the limitations of the system and make sure that you fit them And if you have permissions to do updates, it really annoys you and says well It annoys you on every admin page if you're not up to date and you have cron updates enabled Because basically you're telling us if you have cron updates enabled that hey I want this to be responsible for my security updates and If we know that you are not in a current state will work We want to let you know that that is the case so not every obviously not every site or every admin would see this but people with permissions would because We don't want to give you a false secure since the security that when a security update comes that you would be able to Apply it. So this is sort of to make sure Once you're set up, this should not happen really you should not see these areas But if something happens, you need to get out of compliance with this system, we're definitely gonna let you know So there's also another part where we have modules and theme updates and like I said in the trees note This is a sort of still under development. It does work, but we're still working on the validation System for this so we'll go in later about how the validation system works under the hood But basically we're writing the individual validators now to make sure that this is completely secure but Basically, it works right now if if you didn't try to hack it, but we're trying to protect it against if you tried to hack it So yeah, basically shows you a list of all your modules and themes to update So let's go into the limitations and requirements of the system so You need a writable file system So if you're gonna update your code base that means writing to the file system So there's really no way to get around That limitation Obviously, this is gonna make it not work on some, you know Drupal specific hosting In particular host like production hostings. They protect it for good reasons against it being writable. So Using this in production will maybe target the long tail sites without full-time devs and maybe that are running on lower fire hosting or say like a VPS something where they can sort of where the either the hosting provider makes it writable or they're setting up something that they make it writable So possible workarounds to make it work to use the module even though you're in a production non writable system is you know, you could use it in as a sort of composer replacement locally and Basically replace the part where you would usually go to the command line via going to the browser And then deploy as you usually would You could do it in custom writable update environments. So basically if you have a right protected hosting hosting a lot of Some hosting providers that have that right protected will actually have different environments that have different settings And so you could host you could and it's often used for like merge requests, right? So you have a merge request that you might want to review That is not your production site. So it's maybe not locked down as much So you could run an update there and then merge in the same way you would do a merge request Update event subscribers that we have that we'll go into later. You could actually make the code base to very temporarily writable This is theoretical. I don't know. There's no host since the module is new There's nobody's actually doing this yet, but theoretically that would be possible Or you could rely on the cron updater and have the cron updated or run as a privilege user That actually does have access to write to the file system Composer to is a requirement. There are a lot of improvements for memory usage in Composer to so basically It would allow it allows the up the composer operations to happen in one web request And also with the memory limitation settle that sort of a more broad range of hosting has You know technically it probably would be possible in Composer one for some hosting provider environments But you don't really want to get this wrong. So I mean Composer to is I don't know when Composer ones out of support, but Composer choose been out for a while And also it has API changes that make it easier for us to verify packages Through the the signing that I was talking about earlier. You probably could do it in Composer one But the APIs are just better in Composer to to do it Limitation it's not get or version control aware. So it's not going to commit code After the update so you have to take this into effect. Obviously, this is going to affect a lot of people do it on Production not everybody not everybody follows strict version cool control requirements But you know get is really inversion control is really developer dependent I'm sure there'll be contrib stuff that will start to take this into account Like I said, we do have an event system that somebody could write a get integration for this But yeah, but out of the box, it's not in scope for the module right now it doesn't support multi-site and the reason is Say if you did enable this on production, you don't really there's not a good locking system in Drupal to lock basically on multiple sites in one code base so We locked down updates so multiple users can't try to update Drupal at one time But if you have a multi-site that's much trickier to do because people could be on different databases and we can't say hey Somebody on site X is trying to update on site Y. You cannot Obviously if we're running this locally If you're using it as a local development tool to get around using composer That's really not a concern because you know other people aren't hitting sites So we'll probably put an override in settings dot PHP. We really can't put the override I think through the UI because then that defeats the purpose if you can turn it on on one site Through the UI and other sites don't know about it then you're kind of yeah kind of eats a purpose Limitations so right now database updates are not supported through the UI Sorry, not through the Through unattended cron updates because basically database updates can go very badly And if you're not around there to see that it went badly then then it's worse. So basically We detect in the staged environment we look and say okay Is there likely a database update because predicting database updates without bootstrapping Drupal is a little bit Difficult so we kind of veer on the side of like we could have some false positives where we thought there was gonna be a database update On your site and there's not but I'm pretty sure the system We have is will be very very low possibility that we're gonna do a false negative where we say okay cool There's no database update. Let's run this during cron So in that case you would just need to go to the form for that particular one security updates are less likely to have database updates though that they're not I don't think that's Policy that they wouldn't But they're less likely to And in the future if this is in Drupal 10 that would I think would be a factor in pushing out a security update if we know If we know it'll work via cron so people automatically updated to it if we don't put any kind of database update into it Then we would you know, I think people would try very hard to make security updates work that way So let's talk about using this in a production environment versus development environment So pros of using a production environment is it's that you know very simple way to keep your site up to date Cons obviously what we talked about it's not version control aware Needs a fightable right a writable file system and the stage update can't be completely bootstrapped so you can't actually go Browsing through your site and say okay everything looks good on this new version So this is something if you're using a hosting environment where you have multiple environments, obviously you can do an update in In another environment test it out So you could put you could potentially like I said use it that way But it'd be your responsibility from getting it from one environment to the other Development environment Pros is you don't have to deal with composer directly and once project browser is in then also for installing modules You won't have to use it directly and If you're using development environment, you can easily do whatever you do now to get your update in diversion control and You can fully test the update in the local environment so Using a development environment could be like a local host on your laptop or it could be Something that you have a special environment. That's not production Okay, so Let's look at getting Likely core roadmap, so this is not certain, but this is sort of what I Would like and then we've talked with the release managers as far as like how this might get into Drupal core So not certain but I think likely So each sort of step on how we get into the core depends on probably how the previous step went Obviously if we do patch releases and it's something I don't know it's not gonna be horrible But if something horrible happened, we're not gonna do minor releases right after that minor updates. So And I think all of this depends on the beta testing now And when the the stable module is contrib getting people to use it in contrib first Because auto updates is not something you want to test out in Drupal core first like ship it out to hundreds of thousands in site and say Okay, now we're gonna auto update also the way that Drupal's Experimental module system works or policy works is that it's harder to update something It's harder to test an updater using the experimental module process because if the experimental module in core is Alpha level stability. We actually take it out of the releases. You can still test it if you get clone But you can't test an updater real this kind of updater in a git clone. It has to be through a composer project so So first step would be patch level core updates. So basically the main functionality of the contrib module right now and again, that would get you one year with Without needing to do a manual update if you're okay with not being on the latest minor and this would be attended or unattended updates And this would of course depend on us getting the update framework integration done on Drupal.org After that probably minor core updates. I Think probably we should do minor core updates first via the form minor core updates are I think almost always going to have some sort of schema update or database update so unless we figure out that problem of running those updates via Cron then this is probably only gonna be on the form so but you know if you're doing if we support minor updates via the form That does give you potentially theoretically multiple years of without having to do a full update So it once we get minor updates in hopefully sometime in Drupal 10, then you won't have to do a manual update until Drupal 11 and then I think That I would hope we could get module in theme updates into Drupal core and really like Technically, it's not any harder really. I mean it's probably a little bit harder because you have to do with conflicts between contrib modules but It's really the more of the case that core is very careful about backwards Compatibility breaks about what goes in a patch release and what goes in a minor release and what goes in a major release There is not an ecosystem-wide policy In contrib to say, okay, we're all definitely not remove any API in a patch release I mean, I'm sure most people try not to but I'm sure people do sometimes so contrib updates can probably be even on a Patch release version update. You can't be sure that it won't be more disruptive so Well, the contrib module will support it and we'll test it out. We'll see how it goes. Maybe it's maybe I'm being Maybe I'm more worried than I need to be about how contrib module Theme and and module updates will be but I think we want to be very careful about putting that into core And it may need some sort of like policy change like maybe a release would opt-in to okay Yes, this is something that I'm saying is safe to automatically update even even during cron or something like that Because I think most people who are making releases now to a module. They they're not thinking Okay, somebody is just going to this is just going to apply and if nobody's ever gonna see it But that or not I can see it till you wake up in the morning, right? so if Drupal core has automatic updates in for itself, then obviously we're thinking about that when we release a patch version That is this something that could run during our cron update or not be disruptive So we'll have to see how that goes. I'm I Think it would be great to have this because basically then all your updating For for people who don't like to use composer directly can be done without using composer directly So let's take a look under the hood and basically this sort of section is okay If you're a developer and you want to figure out like how to integrate into this new system. This is what we're going into now So this is on three levels automatic updates package manager and composer stager And eventually this will be the top part will be split between automatic updates and project browser We'll both be using this lower level package manager and composer stager Project browser is not doing that yet and eventually any contrib module that wants to leverage our composer API or our API for making composer operations could do that So let's go back to the three Sort of level here and let's talk about composer stager. This is a PHP library It's not Drupal specific and it basically is job is to run composer operations in a staged copy of your code base It's not, you know necessarily a site. It's any composer project This is probably the least likely thing you would have to deal with as a developer It either uses a custom file copy or to do the file copying back and forth or it uses our sync if you have that on your system So then the next level up. Let's look at package manager This is an API Drupal only module meaning like no UI and it performs staged composer updates and but it can update any composer package It's not limited to updating Drupal modules or themes or Drupal core itself so if we look at the Sort of screen of what we showed the update looking like before for For automatic updates basically you kind of swap out the thing you're updating Instead of Drupal core you're updating any composer package as far as package manager is concerned and then also the version constraints package manager doesn't have the idea of like, okay, I'm going to restrict you to patch or Or minor or major updates all that policy stuff is in automatic updates and eventually Project browser would have its own policy. So it also doesn't do any checking of Automatic updates is the part that actually checks the update XML on Drupal.org and says, okay, is this a secure supported release? package manager think of just a generic Updater, but with this staged ability and the ability to do certain checks before it actually applies it So the update lifecycle according to package manager is create creates that staged copy require This can be multiple operations for Drupal core. We're saying, you know require Drupal core and a couple other Like the scaffold and a couple of things that come with Drupal core Apply is to apply those changes back to your site and then destroy is destroy the database destroy the copied code base And then during that lifecycle, we have events that are fired off before and after each event and All of the pre-events can flag errors to stop the operation. So I'll give some examples So we have a pending updates validator Inside package manager that says it listens to the pre-create event and says, you know If you have any pending database updates, then I am going to say you can't start an update So it listens to pre-create it flags an error if it finds any pending updates So this would be anybody who's using package manager. We put this restriction on it for now We have one called the lock file validator and this listens to pre-create and it stores a hash of the active Composer lock. So basically it looks at your site now It says, let me store the status of your current composer lock and then on the pre-require and Pre-apply events it'll check that hash and says okay has this lock file changed at all So the active lock file and it basically the idea is you don't want to stage a composer operation Then somebody else to the command line run another composer operation and now now you're going to copy your stage Code base back to your active when it doesn't know that something has changed. So basically it locks down your site From it locks down. It doesn't prevent you from doing other composer operations safe from the command line But if you choose to do that, it won't allow you to apply that update Because basically at that point we don't we don't know what you just did So just this is an example of how a custom module could listen to multiple events to implement more complex logic So package manager provides safeguards so any module that uses package manager directly Either automatic updates or project browser or your custom module We prevent conflicting operations basically there can only be one package manager operation going on at a time So we have an ownership idea of once you start an update your session or user owns that and you have to claim it on every Request so that nobody else can say okay. I'm going to start Automatic updates can't start updating Drupal core and then project browser says well somebody else on project browser Who doesn't know you're updating Drupal core can start to? Update can start to install modules and then somehow we try to resolve that together So any module that uses package manager will sort of automatically get into that and not have to think about it at all Just basically claim it try to claim the update stage And it'll tell you whether it's available or not And it also checks all the basic requirements. So the idea is you could write You could write it it's not too Hard to write PHP library that does this composer operations But package manager hopefully being a common API will be able to make a bunch of different modules that want to use This not conflict with each other So the events that we went over is sort of allow having custom logic And sort of a custom experience so you could tap into these events to make your own restrictions For automatic updates say or project browser So this is a example module. I'm going to go through called peak time update preventer In the basic idea here is that we want to prevent any package manager operation. So that would include automatic updates or Installing modules during one of our peak times if say we're an e-commerce site And we know we're having a big sale or it's a event website and while the event is going on We don't want somebody updating it. So all we have to do is Set a dependency on package manager and then we're going to create a file called peak time validator And this is just a service. Let me see if I get to the service file. I guess I didn't include the service file But it's a service file. It's an event subscriber And the meat of it is basically we tell it which events who want to subscribe subscribe to and this is pre-create or Pre-apply because it could be we don't want them to start. So that's pre-create. So we're going to start We're going to check peak time at start But also maybe you started an update and you waited six hours and you're oh now I'm going to apply it We want to check it apply. So we listen to pre-create and pre-apply and all we do is we call a function Is peak time? That's our custom code. You can see what it is here So it always may or may not be peak time. You never know But we call peak time if it returns true then we just add an error and say sorry, it's peak time You cannot update so basically You know, it's pretty simple code to sort of customize the update experience to what you need and Then we are going to look at the Ted bow module preventer. So this is another Custom module. So this is a little more complex, but we actually only listen to one event which is the Pre-apply event. So basically right before you try to apply the update. We're going to check some stuff So we have some helper classes. So first what we're going to do is we're going to get the stage So the stage is the thing that's doing the updater doing the updates and then we're going to get the active Composer so what's on your currently running site and then the staged composer and We're going to compare those by calling get packages not in the active. So say, okay You know, tell me all the packages that are about to be applied that I did not have before and then we just loop through them and The logic basically on the bottom there where you're looking through is just This is from the composer API. It has an object for like getting information about packages And we're going to see if any of the packages start with Ted bow slash and if they do We're not going to allow you to them install because we don't trust the developer or something like that so basically you know it's our our API stuff or helper modules is the getting the active composer and the comparing Comparing what's in one and what's not in the other but The other once you get the packages. This is composers API. So this is not something that we wrote. This is something that's you know Been around for a while So basically you have information about your composer in active and staged So you can really sort of find grain. We actually in the core update The automatic updates we actually do this type of comparison to make sure that Somehow inadvertently when you're updating core a Contrib module or theme didn't get updated along the process because we don't support that right now and we show you an error So but you could check any sort of they're also one of the examples I was going to put up but it's a little more complex is there's a number of PHP libraries that help you check security releases in any PHP project and You could check that to basically say okay did I act any of my vendor stuff that I updated not the Drupal stuff But any vendor stuff it are there known security risks in that So automatic updates as far as the API level it really just provides the readiness check event and Which we're talking about the warnings to make sure that you're gonna be ready to update Automatic updates can be customized a lot, but really you're just using the package manager API To customize the automatic updates experience and how you do that is basically when you respond to any vent event This is the pre-create event. You just say hey get me the stage Which is the thing that's doing the updating and then you check to see what class it is in this case the updated class Is the one that we have from Drupal core This is targeting project browser So you check okay, I want certain logic if we're using project browser Important note. This is not real yet. There's not an actual project browser installer, but you know there will be one day So before we get to questions just want to remind you about the beta testing 2 30 p.m. Is a bop and you know come through basically we have a script That can go through and do the basic Drupal core updates But if you have more if you have more time we can go through and do like test out the extension updating We can test more stuff like switching to our sync on your system to see how that works And then also get involved if you want to get involved with the project We have a slack which is pound auto updates on Drupal slack You can ping me there and we have issues in the queue if anybody's interested, but so now let's go with questions I'm gonna take a couple minutes later because we got trees bump me a little bit. So yes Yeah, so right now that's a Yeah, so I think the question was Contrib that is not enabled as far as Drupal is concerned but is on the yeah So basically we're leveraging the update module to determine whether stuff is secure or not And so basically the update module itself and core has a setting that says check for only installed or check for For things that are in my code base So if you have that turned on to check for stuff that's in your code base, then then we'll yeah, we'll let you update it The droop for checking if there's an update it relies on Drupal's XML because not package manager But automatic updates does because composer doesn't know about security Or unsupported as far as Drupal projects are concerned. Yeah Yeah, so you could so the question was can you tap in for like CI to actually run testing or something like that? so Once the update is applied. No, there's not a rollback feature, but in the staged version you could potentially write something that and that Does a pre-apply? listens to pre-apply and actually does whatever you want so running tests you could do in that case and you could You could can't you could destroy the stage first and if your tests don't Don't complete or aren't don't pass But after it's applied. No, there's not a rollback system after you apply the update so the The the actual database updates run after you apply because yeah, we don't We don't know how large a Drupal database is so like copying it over and saying okay Let's run the database updates first Though that being said if you know how big your database is or if you want to make a contrib module that does copy it over and bootstrap It should be possible though. You would also have to be responsible for moving any stuff That's not Consider that we don't consider your code base So if you need public files or private files over there, you'd be responsible for making sure they're not excluded There's an API for adding exclusions so So yeah, so theoretically you could do that, but that would definitely be custom code You could so so basically summarize you could run tests and then you could what was the other Thing that I just Roll back You can't roll back after it's applied, but you can you can cancel basically. Yeah, there's just to destroy the stage Yeah, the questions. Yeah Yeah moving. Yeah, yeah Yeah, so you can do that you can actually access composer stage or Directly via PHP or I think it comes with the symphony console tool though if you're on the terminal the whole staging is not as I Don't know it's not as convenient. I mean doesn't give you as much features or not a use for it as much. I guess Yeah Yeah, yeah, so the question was will it be updating composer lock or he's just confirming that it would and yeah It will be so it basically it is doing a composer require update on your code base So it is as if you did it in the as far as you know, if you looked and get and did a you know get diff Whatever if you you know if you commit everything or if you just commit the composer files if you would you would see the same thing So usually yeah, so config files if they changed So my understanding is is like an update The like usually a module would use the update hooks I think to ensure that goes correctly So we would detect that During we have it we would detect that if it's a cron update and say actually we're not gonna allow you to do that during Cron so unattended because we don't there's not a system right now to say like this is Probably safe, you know, this probably is not a long-running operation. There's nothing that would tell us that on the API level so Through the form Right now if you went through the form and did the update or it's a okay We've detected that in the stage copy. It would say we've detected updates Just be aware you're gonna have to we're gonna reroute you to the update page the database update to trigger it So at that point you could be like yeah, it's not a good time for me to do that and back out In cron we will detect it and just say you have to do it via the form right now, we don't have the notification, but There before stable there would be like an email notification that says hey, we tried to update via cron, but we detected Configure update config schema changes or database update changes. You'll have to do this via the form Does that answer question If you're going through environments, right from Yeah, this won't deal with that because it's presuming you're in one environment Yeah Yeah, yeah, oh if the patch fails like through the Sea Wiggins patch composer plug-in So right now, I think we have a detection in there We have a validator that just checks. I'm not sure if it's committed Committed yet that basically makes sure that you have the setting in that plug-in to say fail There's a setting for that composer plug-in that says fail if a patch doesn't apply So it doesn't silently just like say cool you updated So I think the only integration we have right now I'm not positive that we committed that change is that we just say you have to have that setting to say that it fails and then basically We don't need to do any extra logic if the composer operation would fail itself and would let you know yeah Yeah So right now we kind of feed you the composer information directly We have a lot of verbose error messages if it's not directly from composer, but The problem is right now that I'm aware of like I think require an update You can't do dash dash format JSON, which would be great if you could it would be much easier for the parse So we're gonna definitely file an issue with the composer to see if it is possible to make those operations work with that format Because then we could actually give you more useful information right now We besides showing you it and knowing at what point in the process it happened. There's not much we can tell you Yeah Other questions Yeah Yeah, so if the versions pinned our updater will actually pen it to a different version at least core if you have something I mean we're do we do all with the with all dependencies And that we flag that so that would bump the dependencies. I'm pretty sure But say if it I'm trying to think when in case wouldn't it wouldn't work So right now the way that it works and we'd sort of got Feedback from the composer initiative is we pen to exact versions And that's I think the nature of like The updater itself, you know needing you know, we're telling you through the UI. This is the exact version We're going through we're not you know, we're not we're not acceptable in a range So we do pen to exact versions so as long as like There's like three lines in the code where this actually happened so it's pretty easy to see like oh, this is the composer operation that happens, but it's like a We had to do a composer up require and then it with no updates and then it then an update So but we there was some bug in composer. It could be fixed right now in certain cases, but It will pin you to whatever version that that it's saying it's updating you to for Drupal core But that also could be changed if if It could be changed it's a little harder to change it You could by writing your own updater, which is not that hard But also if we get feedback as far as like the preferred way to do it. We definitely looking for more input Any other questions The actual updater itself There is Now it's we make it whatever Drupal nines PHP version is The core version would we would tie to obviously to what Drupal core is right now Yeah, right now. We're just looking at the current supported versions of Drupal 9 I forget what it is 7 3 and and making it compatible with that But that will bump like he said for Drupal 10 it'll be 8.1 I think yeah Anything else? Thanks for coming. So boff testing 230. Thanks