 So that's right. Yeah It is yeah, so how long do you think you're gonna talk for? I mean, I was thinking at least leaving 10 minutes for questions. Okay. Yeah, I could go. Yeah, we're all good Yeah, I could talk again if nobody has questions people usually do. I'm sure they will yeah In theory we might we will get some online questions as well. See sometimes they pop up. Sometimes they don't all right Alrighty All right, thanks for coming to package manager powering automatic updates and project browser to Drupal's easy composer future So I am Ted Bowman, I'm a principal software. Maybe that's probably why you had the mic not pointed at me directly So I'm a principal software engineer at aquia at the Drupal acceleration team We work mostly on Drupal community projects and the tech lead of automatic updates initiative and a Co-maintenor of layout builder and settings tree in Drupal core. I'm Ted bow on Drupal Slack and our Drupal Drupal Slack and Twitter So yeah today we're talking about package manager, which is a mop an API module we're not particularly talking about automatic updates or Project browser, but it will tell you a lot about like system requirements and what's happening behind the scenes and how to customize Any module that or customize the experience of automatic updates and project browser So why are we interested in an easy composer future? so basically It concerns two initiatives Automatic updates and project browser so in Portland Drees sort of laid out this idea of ambitious site builder Sort of pivoting from an ambitious sites to site builders so a persona of somebody who wants to you know make an ambitious site through the browser Maybe a little maybe some coding some configuration But not but you know kind of focusing on what you can do as a site builder and the site builders kind of you has been a Sort of I think sort of a unique role in Drupal's sort of framework slash CMS chameleon that Drupal is and Also sort of focused on the composable core or composable Drupal The good news is that Drupal is already composable like you said earlier today It's just not as composable Depending on who you are. It's either more or less composable or the skills you have in you know anybody can Learn the skills to sort of do it from the command line and deal with composer directly But you know a lot of people have you know usually a site builder is not just a site builder. They're doing a whole lot of other things so It's not just like just learn composer and you won't have to deal with any of this It's like you're already learning probably not only Drupal site building But some hosting and just a bunch of other stuff that's not Drupal specific so automatic updates and project browser we're trying to empower the ambitious site builder and Move a lot of tasks. They're usually in the command line to the admin UI So they both need to execute composer commands for this so a brief introduction of automatic updates is That you know the current problem is that site maintenance is really high for a lot of sites and updates as part of that and a lot of sites just don't apply security updates We know that from usage statistics even after like really critical security updates They'll just be a you know month's lag before we get a critical mass of sites on on the latest security updates So in composers a pain point for many Drupal site builders and developers and then So Automatic updates its first sort of goal is to update Drupal core via composer We have an experimental module that does contrived modules and themes But the module really the automatic updates contrived module is really sort of a roadmap for core We're not really building features that We don't plan to be either in the core MVP or sort soon after We're doing the contrived version the experimental module and hopeful make it stable also because eventually we want not only core updates in core but also contrived And the target date like what we'd love to get it in is for 10-1, but probably an experimental stage We'll see there's a lot going on and Drupal core obviously outside of automatic updates to get out Drupal 10 so Could be 10-1 could be a little after This is just the form. It's just pretty generic You see your current version you see the next I guess in this case a patch version update Right now it doesn't support minor versions except if you set a config switch It'll show you the next minor so you can go from one minor to the other but We're trying to roll out features sort of in a more Not roll out everything all at once because there's a lot of problems that could even happen with just a patch release So we want to sort of get that as stable as possible that process and then add stuff like Minor updates so you can do minor updates now. It's just sort of more Potentially minor up anything that could happen in a minor update potentially could happen in a patch update But more likely there's going to be larger changes in and minor updates This is the experimental module You know updating your modules or themes just a reminder. It's experimental. So people are using it, but you know, it's It's not actually So I would say the experimental part of this is not necessarily that it's much more difficult to update Contribute core core contrived versus core. It's not the composer options very similar. It's just core is very The rules for what gets in a patch release what gets in a minor release and backwards in palability is very well Defined in core and a lot of people's our eyes are on it and depending on the contrived module or theme you have a Patch release could easily break backwards compatibility I'm sure there are modules out there that are very you know, very careful back backwards compatibility and then there's probably some that aren't and There's no way for the automatic update module to say well and potentially we do scan your code, but There's not an easy way for us to tell okay This module is probably safe to update a patch version because it's not likely to break anything and this module X is in module Y is not so I would say the experimental part of it a lot of it is It's just seeing what happens when you update different contrived and Probably a lot of the same problems That you would see through just regular straight composer updates you would see through this UI We are doing things like security checking on the updates. We're not That part's not experimental. We're not saying okay. We'll just let you update to anything. We don't care We're definitely checking security and that it's supported and stuff like that But we're not scanning the code to say, okay, did they break backwards compatibility? Project browser so right now like searching for new modules requires leaving your Drupal site and it's When you go to Drupal.org you're not necessarily going to see Modules or themes that are that are compatible with your site So doing it via the UI is going to allow you to search modules That are compatible for your site and again This is also a composer being a pain point is a sort of one of the commonalities between automatic updates and project browser So we covered that so right now the project browser module just currently displays The composer command you copy it into command line and then you install the module that way. We're working right now To have that be automatic via composer and that's sort of where package manager comes in so this is the UI for browsing So so they share the problem of you know Composer being a pain point for a lot of people So they both need to execute composer commands and they both need to do it in a standard way meaning like if you update via automatic updates You uninstall the module there really should be no sort of tell that you used automatic updates Or if you install a module via a project browser You should be able to completely uninstall it and it's just a standard like as you if you had Installed it via the command line with composer and it also needs to be able to do do their composer operations safely So that's where package manager comes in It's an API only Drupal module right now. It's within the automatic updates Contrib module and that's solely because we started working on this functionality and automatic updates first If project browser had started working at first They probably would have we would have you know worked on it in the project browser repository It's nothing specific to automatic updates, but we did There was some validation that was only in automatic updates But now that we have a second use case project browsers like oh we need that kind of validation too So we moved some stuff into project browser That was only an automatic updates before so I'll try to comment on those things this week go by Package manager doesn't really It can update any composer project. That's not how Automatic updates and package manager are using it But it doesn't like check to see okay You're trying to install or update something that is a Drupal project You just send it a package name and a version that you want But it does have Drupal specific security checks So How it works right now is we have automatic updates and we have a sub module called package manager Which this presentation is about and then package manager calls this outside PHP library that Was also made by the initiative called composer stager And then project browser right now has to be dependent on automatic updates just because the sub module lives within the repo So let's look at composer stager. So this is a PHP library. It's not Drupal specific It really doesn't have any knowledge of Drupal And it runs operations in a staged copy So the goal is to basically be able to safely perform composer operations in a live site Technically doesn't have to be a website could be anything with at least downtime as possible So it copies all of the composer manage code And you sort of tell it what is not composer managed into a copy and performs the Composer operations there and then merges this site the changes back into the site So it has a phase called begin where it takes the active site and it copies over into a staged copy And it has some because it has no Drupal knowledge composer stager itself wouldn't know it'd be like Oh, don't move the site files or whatever over there or don't move my sequel database my sequel a database that's in there Then in the stage copy it runs one or more composer commands there and then on commit it Takes a stage copy and moves the files over it comes with two copiers one is a rsync runner Where it would only move the change files and then there's because our sink is probably not available on a lot of environments There's sort of a dumb php copy that just sort of copies everything over right now by default automatic updates is using the sort of dumb php copier and that's mostly because Drupal CI couldn't run we didn't have Drupal CI didn't have our sink for us to test on Once we move to git lab we'll be able to have our sink and we can have the default copy or be It'd be the rsync runner. It just seemed not prudent to have the default sort of copy or be something that we're not currently testing Even though our sink is obviously well tested itself and then the final stage is you clean the op you clean the The stage copy just by deleting it There is a separate library it used to be the same one in composer stager But now it's a separate library to make the main library simpler that runs that has a Compose a symphony console command that you can actually run this from the command line Okay, so that's composer stager You know basically copies does composer operations copies back not Drupal aware So if we look at package managers and API only Drupal module It performs the staged updates via composer. I guess state operations really in operations and It it doesn't really have an opinion on Whether you can update something inside Drupal outside Drupal. You just send it a package name and So the automatic updates example This is the update process video So you have your site here. It's on 931 and Then you're you're currently you have visitors going to your site and we make a staged copy of Your current code base excluding things that you tell us we don't need and To copy over like your sites well automatic updates would tell package manager like hey I don't need sites default files And then in that stage copy we run composer update to 9 312 We briefly put your site in a maintenance mode and then we copy I Think I'm not We copy this over so now your site's running 9 312 and then we take your site out of maintenance mode And then we delete the stage copy. So there is a brief time where Part of the reason of using composer stagers you don't want to want to check certain things in that staged copy So we don't want to run the composer command directly on your site. So if something is wrong or something Something happens in that come during the composer command that we didn't expect then we don't actually have to run the update So like a direct API usage of package manager. It really doesn't care You know what you're updating it could be Drupal core could be anything and then also there's no like version restrictions on like say if you want to update from Version one to to version nine. It doesn't care So with automatic updates in particular, we have a lot of rules about like what you can update from and what you can update to We don't support dev version as the target or the The the version you're coming from so we're doing a lot of safety checks But compote but patch manager itself is sort of not opinionated on that So so what else is package manager do for you basically like why not just use composer stage or directly? So there's a lot of good things inside a package manager One is the idea of path exclusions. So we'll get into events later, but basically you can tell package manager like when you're What automatic updates does is say hey, don't or actually I guess this is in package manager itself It says don't copy over sites default files or wherever your public and private files are Don't copy dot get directories if you find them Don't copy the SQLite database file So it has because it's composer stage is not Drupal aware, but package manager is it can know certain things that aren't basically composer Managed and we want to copy. Oh, we want to exclude anything that We can That when we have the stage copy the composer command would still run correctly. So we can't necessarily exclude say Any of your code or anything that composer knows about we can't exclude but anything that composer wouldn't care about we can exclude Just to make the file copying take less As certain safeguards like enforcing HTTPS for composer and Drupal or update XML fetching So you could set composer to not Require HTTPS to get its package information But we just like do some of those checks like insure it does that we check the composer patches library to make sure There's an option to I forget what the default is but basically you can have it still succeed if the patch fails And so we obviously don't want that in a situation where the user would think that everything see seated so we make sure that the composer operation won't succeed if the patch doesn't fail and we Another check is like make sure that there's no pending database updates because if you're either installing or updating anything new You probably don't want to have pending updates sitting there It prevents simultaneous operation so the idea that if you had the begin stage of package manager and You left it sitting out there. You didn't finish your either project install or your update and then for some reason somebody went to the command line and Ran another composer command We will check that on commit and say actually, you know Is your is the is the active site in the same state? It was when we first started this because the last commit stage is not really composer aware It ran the composer command in the staged copy, but then it's just doing a file transfer of okay Here's what's changed and let me add it to the site So if you had changed if you would actually run a composer command during that time Obviously, you could lead to a lot of problems So it also prevents operations where it doesn't allow like automatic updates to be in the middle of one operation Then project browser to come in and be in the middle of another operation So basically what we call a stage in package manager. The only one stage can be active at a time This is currently a work in progress, but in automatic updates We check everything that's changed against update XML, which is going to tell us whether it's secure or published and supported We're moving this into package manager because Even though project browser sort of has their own way of figuring out if something is secure To offer to the user whether they should install it or not You never know like basically project browser has to consider that they're not just installing a module They may be installing module X and module Y is being updated and module Z is being added because you know like you don't know Even if the module X only has one dependency, you don't know how many dependencies Its dependency has and if it's going to require any other updates. So we basically Package a manager just scans and says okay any Drupal projects that we could get XML for Have their versions changed or are there any new ones if there are then we go out to Drupal.org and say Make sure these releases are secure and if it's not then we stop the process from happening This is just an example of update XML from Drupal.org and one of the things they would tell you is if a particular release is secure or not Yeah, so this is a work in process. It's currently in automatic updates But because project browser basically needs the same thing. We're just moving it down into the API module We This is also Part of this is done. The second port is I think is either done or Will be done the next couple days Basically, we do a lot of work to try to prevent conflicts with non-composer code. So Some sites could still have modules that aren't managed by composer and they may be in a custom folder. They may not be in a custom folder so Basically after you do a composer operation. We make sure there's no duplicate Info files after the operation that weren't there before I mean you may have duplicate info files for some reason But if we cause that in package manager, then that probably means that either a dependency was installed That wasn't there before as far as composer knows, but it was actually there in your Drupal site And then we also prevent you from overriding any directory that if you install a Package that is new according to composer. We can't have it wipe out an active directory so that that would either indicate that there was a package there or Drupal project there that composer didn't know about or say you have a a a Modules slash contribs last notes folder where you keep all your notes And then you install the web form notes module and then it had a dependency on the notes module Which then goes in modules can trip notes and wipes out your notes folder. So We're not particularly like scanning because Drupal has a different idea of like what Drupal's idea of what projects it has has In some sense no relationship to what composer thinks it has So we have to do a bit of work to say okay if you're not fully managed by composer We have to avoid you we can't we're not trying to solve those problems for you But we are trying to stop the operations if that happens And what that would mean in and say in automatic updates is you would just get to the update continue screen And we would check these things for you to be like sorry You can't proceed because you have you had see tools as it get clone And we stage see tools in a different directory and if we move those in you would now have two versions of see tools Or you had see tools in the correct location sites can trip But it wasn't managed by composer and so composer thought see tools was new So we can't be sure that you have you would have the same version of see tools We also do some stuff to prevent edge cases like Actually most of the time you would think my some module on Drupal dot org equals to Drupal slash some module But actually it could be some module to Drupal slash literally anything It's the packages on Drupal dot org usually prevents this But I think it's because of modules being split out that we can never guarantee That this is always going to be the case so we have to always check against this So we do some checking to see and why this is really important is for checking the update XML We need to make sure that we're getting the right project Basically if we had a package called Drupal literally anything we can't necessarily check literally anything's update XML We have to sort of do a transfer to see okay What is the real project that the thing that composer thinks it installed? What is the real Drupal project for that? It's not like very common at all But these are the kind of things that like if you could figure this out you could use this to attack Something by making it think it had the wrong update Making you think you had the right up update XML when you didn't The life cycle for for the update process is this is similar to what we talked about For composer stager just slightly different named The life cycle events is basically This is is how we do all the validation, but this is really a custom module would really want to tap into this We have a pre and post for every event Stage in the process and all the pre events can stop the next process from happening So on pre-apply we would check something like was there another composer operation that we didn't know about in the active site So an example of that would be the idea of like preventing this situation here is On pre-create we would store a hash of the active composer lock And then on every time you did try to require something or apply the update we check Okay, is the stored active lock that we had is it the same as the actual active lock now? And if it's not that means some other composer operation happened that we don't know about So it needs a writable file system Because you're updating code so a lot of hosting this is not going to work on directly And it's it's targeted somewhat to the long tail sites or in the composer in the project manager project browser Use case you might be an often you're just installing the modules locally so you have a writable system there so I think automatic updates and Project browser have sort of different concerns about the writable file system Project browser if you're using it to site build and install modules the writable file system is probably a given because you're you're local But automatic updates that's more of a concern If you want to apply the updates directly You can do this stuff in local environments. It's not version control aware though you could write a control module that does Using the admit system does commit afterwards Yeah, so a possible contrived solution to this problem would be it using Pre-apply and post-apply to either like tag the current code and commit it afterwards I think it was deemed at a scope for core is because a lot of people use get differently So I imagine they'll be contrived solutions Yeah, we'll see that's sort of one of the most common questions we get And right now it does not work with multi site Basically It's very hard like right now. We didn't write a locking system. That would be across sites We prevent a lot of things from happening during the apply phase Basically the last point where we're copying all the code over We prevent you from uninstalling modules I forget what are the things we prevent but basically and you can't say just you can't get rid of an update That is in progress in the apply stage So to support multi sites We really have to know across all of your sites is anybody performing operations And because you're using the same code base and same like json api Composer json and composer lock on your multi sites It's really difficult to have multiple op. Well, you shouldn't have multiple operations going on in the same ones so You know, there's possible ways to get around this, you know You could have settings and settings dot php or sites dot php that says okay There's only this one site can perform operations via package manager You could allow it in local development only basically We haven't had enough Yeah, there hasn't I mean there's been some Most of the people who've wanted this feature sort of want it locally They want to be able to do operations locally even when their sites dot php says it's a multi site because if you're local You know, you're not a multi site or you know that other sites aren't operating at the same time Or in a case where you have a pretty small multi site And you know the people who manage all maybe the same people manage all the sites You know when you can do an operation, you know when the other sites are should be down or could be put into maintenance mode Whereas if you have a hundred sites and you're updating corn For through one of the sites, but it's updating everybody's code all of those sites really should be in maintenance mode at the same time So using it in production versus development environment So the pros for using it in development environment is Obviously for automatic updates if you want to keep your site secure Then you need to on an ongoing basis without you having to be there. It needs to be in production Cons is, you know, there's not it's not version control friendly unless you use write custom code Potentially contrib will solve this It needs a writable file system, which is incompatible with a lot of hosting and The staged update even though it's in a staged copy and we can check things like okay are your versions of particular modules secure Right now, we don't have a process for bootstrapping your whole site and testing stuff potentially you it would be possible But for a lot of sites that would be very difficult Because you'd have to copy a very large database over you can't really point in most cases you probably can't point to the real database and just say bootstrap with with this code because There's not a guarantee that that that just bootstrapping it won't write something to the to the database And if then if you decide not to update you've already bootstrap the site on the new version of Drupal which could make changes that are Drupal doesn't downgrade. Well, basically it's the problem. So I Suppose there could be you know, you could there could be some contrib that could actually run tests in that stage environment But right now we're not running PHP unit tests or anything in that environment Use in development So project browser use cases probably more suited for using put package manager in development It would save site builders from having to deal with Composite directly They would still have to use version control in the same way they're using now unless it can trip comes up with a solution for that And you can fully test your changes You could like at Akubu we have this cloud ID ease which or I think that's the name Anyways, you can spin up an environment that is writable. So potentially you could do You could use project browser or automatic updates in there to update via form and then move the code over in the same way You would usually do All right, so let's look in under the hood So the main thing that does operations in package manager is called a stage and Automatic updates provides a class called updater which extends stage and project browser is Will soon have something called installer that also extends stage and you could have say your own module Have a class called remover which just is to remove packages and extend stage Generally any time that you wanted to use package manager API to provide your own types of operations You would want to extend the stage class This is the simplest example of using the stage And this is this is actually from our test code is we have the stage class Instance from package manager. We call create which copies all the Composer managed code over to the stage environment Then we call require and we tell it, you know what we want to require and then we call stage apply And that moves it back over so this used to be kind of exactly how it worked It's a little more complex now because when we were testing the update from either 9 3 to 9 4 9 4 to 9 5 They changed the location of the database drivers And we thought we had or something to do with the database drivers changed either 9 3 to 9 4 9 4 to 9 5 And we thought we had sort of cleared out all the caches we could possibly do and I think we had But that caused a failure after the update so The more realish example of what happens is this top part is the same where you do create require and then apply But we have a post-apply event. If you remember the events earlier Where did I get to the events? Yeah events Yes, we have a post-apply event and then post destroy and actually pre destroy so Pre-apply happens and then all the code is moved over and then all the other events You can't really do them in the same web request because there's no guarantee That whatever you updated didn't change like every file in Drupal I mean potentially it's not going to change every file in Drupal, but it could change any file in Drupal And so you're basically Not guaranteed about which versions of those files you would get because of the PHP class loader You may get the previous versions of those in the same web request if they've already been loaded If they haven't been loaded you would get the new versions so you're kind of an indeterminate state of like mishmash of What classes you would load in PHP? so How we're currently getting around that is This is the test example But the up the regular updater and automatic updates does something similar is after apply we immediately reroute you to another send a redirect and Then we Finish in another web request and what we're doing here is after we get at the top part during create we save the ID so for Always you pretty much have to be doing the very last step in another request So you save the ID and you can only Claim the stage which we're doing the first here if you have that ID and if you're the same session that Started it we do a lot of checks to make sure that if you somehow break the lock of we have a message a Method to destroy an existing stage that you could never destroy an existing stage and then have another one come in and somehow accidentally take it over and So you claim the stage and then you do post-apply which fires the post-apply event which a lot of times clears cash But also could be anything in the future say if there was actually and a security update to the update system itself We have to be sure that we've loaded all the new classes there and then we destroy the stage so basically After we apply we basically try to get out of the current web request as soon as possible in the cron Updater which cron updates and automatic updates are currently turned off because of the DA is still working on the sort of package signing that needs to happen on the server, but once cron updates Are finished we actually will do another request to do post-apply stuff because that's the only way we can guarantee that The new update is loaded A quick example of a module. This is called the Ted boat module preventer silly custom module so Basically, if you're familiar with the event system in Drupal how you would customize the pack any package manager process is By doing an event subscriber and listening to one of our events and this is most of the code here is We're going to have the event which knows about the stage And then it we're going to get the active composer and the stage composer And we have a utility function says give me everything in the stage that was not in the active And then we're just going to loop through all the packages and see if they start with Ted bow slash And if they do then we're going to add an error so you can't go through this operation so To do a lot of this stuff about validation You don't really know how to have to know how the whole system works You just have to know which events to listen to and then how to get The packages that are say in stage and inactive and sort of compare like is there something you want to prevent there How you would target a particular use case of package manager is in this case when I listen to the event The first thing I do is I check if the stage is an instance of our updater if it's not then I return So a lot of our listeners and automatic updates. We only care about affecting automatic updates use of package manager So this would be the same for project browser We would check of the stage as an instance of the project browser installer That is why I said that technically you don't have to extend the stage But you almost always should extend the stage so that you can target just your operations Okay, I think we're about Over 15 minutes less than 15 minutes. Okay. All right questions Who has a question? Yeah, I just had a couple quick questions So eventually this is planned to be moved into core, right? Yeah, okay So that the whole point of it being inside of the automatic updates module Yeah, it'll eventually not matter that's temporary like so the plan is now Automatic updates would get into core first and package manager would get in as this as its separate module there then But if for some reason we got delayed in automatic updates something was more tricky than we thought and project browser got in first We would probably move we move package manager and project browser in so it doesn't have to be automatic updates It moves in first it just whichever moves in first package manager has has to be there to support it Gotcha, and then other question. Does it run update HP when it does it's updates? So right now when you go through the form you get routed to update dot PHP and told to do it on Cron update we do a test. So we have all the cron Update stuff finished. We just have a feature flag turning it off But the logic in the cron one we actually checked to see if there's any staged updates in your staged Site, and we don't we would probably catch some that aren't there. We're very paranoid about checking it But if we find a potential update that needs to a DB update that needs to happen We prevent it on cron because cron that could always like hose your site completely So somebody as of now really somebody needs to be there during To run database updates. So if we detect that it will happen. We don't allow you to do that during cron Gotcha. Thank you. Yeah Can I just ask a quick online question before I go back to the group and that is just a guy called Jaws has asked How does this play with other? Different composer frameworks like the core composer scaffold of particularly he's asked about Cameron Egan's patches Yeah, so the composer patches thing right now The only validation we have is if you have it We make sure that you have the setting that the composer operation will fail if the patch doesn't apply Cleanly so you can't have the patches in there do our composer operation. They don't They don't succeed and then we don't know about it So basically, you know, we don't fix your patches or anything if they don't apply But right now if they cleanly apply then we'll go forward. Okay, so whatever composer file it will try and run it basically It does I mean it just does a composer update require doesn't necessarily know about composer packages Yeah patches except for to check for that one setting. Okay Who has a question? Yeah So I had the similar question about the patches because right now when you do composer update manually And if a modular core has a patch which is now being merged into the core And then you apply why a composer manually it updates everything even though it gives you an error that the patch cannot be applied But it has already updated So what if if the same thing happens with automatic updates? I mean though that particular issue which has been used as a patch is already applied to the So if your patch doesn't apply cleanly then the composer operation We do in the stage copy of a site would fail because of the setting we check in composer patches So if it doesn't apply anymore Then the composer operation in the staged environment would not succeed and then we wouldn't we couldn't proceed with the update anymore Since we're never doing the composer operation directly in your active site I mean you're not gonna you won't be able to update, but also you won't apply it You know, you won't apply an update where you think you have a patch, but you no longer do So we don't we don't help you out with the patch situation Except for to prevent it from proceeding if it doesn't work You have to figure that situation out yourself. Yeah, at least for the MVP. Yeah Hi, I Think I know the answer to this but it follows to say if you have composer or scripts Those are just gonna run as they normally would and would you know anything there if those thrown air Are you able to to catch that and? Right now we Don't we're not We catch it in the sense that we tell you hey the worst composer that we're not smart about like we just show You whatever composer would show you and prevent the update Yeah, so anything any composer plug-ins or scripts that would run on And like a post update command They will be run because composer just knows it's a regular command And if they caused that operation to fail then you would basically be told during the stage that hey, sorry It didn't work Any more questions. Yeah So you said that the prevents copying the sequel Sequel like database. Yeah, but then how does it check that there is no pending or the pending updates in there? How we do it now is we look at the install dot install and dot update PHP files The files that could have it if they are not exactly the same as it. Oh, so before We do the update before a crate We check to see if there's any Pending that haven't been applied to the active site and then in stage We compare for all the modules that are currently enabled All the dot install and all the dot post update files if they are not exactly the same Then we say there's a potential update. So we're not gonna apply that could be just a comment It doesn't touch the database. Yeah, okay, so there could be a comment that changed and there's not really one So we're definitely gonna have some false positives, but hopefully we won't have any false negatives Okay Like so in In an update that is through the browser. Yeah You make another request, but the crown updater is gonna spin off a new PHP process or right now. It's gonna make another request Like a web. Yeah, but we're probably that is probably not the solution we're gonna go with finally because The first version of this module which was not composer Where they actually did it via a console command? So we're gonna have to look for a better solution for that, but right now. It's another web request But that could be a problem if You have restrictions about outbound requests. Yeah, okay And right now we do it in the batch process There's not a good way for the batch processor in the form to tell this needs to be a new request Except if you sleep for one second, it will automatically do it So if anybody who knows the batch process really well to there. Yeah, there doesn't seem to be a way So it'll probably be a core a Core request to change that Actually, I have time that we can do one more question. Can we do one more question or is that okay with you? Yeah, and also find me in the contribution room tomorrow and Friday I would love to people test this or people who want to contribute or ping me on Drupal slacker if you've seen me in the halls Hi So the reason I'm very interested in this module is because like we mentioned yesterday We have I have an agency that runs 600 websites and every month this the maintenance takes a very large amount of time So you you mentioned that you're not going to do database updates So is there going to be an option for us to risk it and have it run it? because For us that have like, you know regular backups and we're willing to to go back to a previous version Because it's still not going to be automatic if we have to go to every site and do the database. Yeah So I think in that case you would have to like extend our cron updater And I'm not positive we didn't make that final. So you would have to do some work So for something like that you would either have to remove our validator that says and all the validators at service That says don't allow this during cron update. You could just remove it at that point It wouldn't run the database updates, but you could have run them yourselves and post-apply But you're doing something we don't recommend But it's possible like it's all services and event listeners and stuff so you can really customize it in ways by removing certain validators and Doing other stuff during events So you could do it would require custom code But not very much custom code, but dangerous custom All right, sadly we're out of time, but thank you very much Ted. Thank you