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


Hi guys, we're Famicide in Kenya because people are having so many conversations about it. People are saying it's been caused by a certain community. What is the main cause of Famicide in Kenya? I think the main cause of Famicide in Kenya is basically just how society raises men to think that they have autonomy over women's bodies.  It's because we excuse what the perpetrator is doing.    It's not because she was on the streets at 3 a.m. A man can walk outside here during darkness and feel absolutely nothing. But as a woman, you can't. And what we are trying to say is we need to make society as safe for women as it is for men. So that I don't feel like I will be targeted just because I'm a woman, just because a man thinks that I am weaker. Just because a man thinks that, oh, I can do what I want with her body. That's what we are saying absolutely no to.  That is not reason for you to kill me. What do you think should be done now? I think, one, the courts and the police need to have extremely stringent measures for what they do with men who kill women or who abuse women in any way.  That is an offense that should be life imprisonment or the death penalty, even if you ask me. We also need the government to speak out actively. I am really looking forward to seeing which Kenyan leaders are here around us to be able to protest and show us that they are part of this struggle. Because the reality is that a lot of people, especially men, don't think that they are affected by the issue because maybe their mom or their sister or daughter has not been affected, has not been killed.  And I hope that it doesn't happen to any of us, but we need to realize that the loss of one woman is a horrible thing for the entire country. I would love to see the president saying something about it. I would love to see the first lady saying something. Sarkaja saying something.  That's what I want to see. Let me introduce us all. My name is Murugi Muni. I am a content creator and entrepreneur, a podcaster and a woman. Yes, so I've seen it today. Maybe you can tell us through what is happening to them. Why are you here today? So today we are on the streets of Nairobi, marching against femicide, which is the intentional killing of women simply because they are women, not for any other reason, just because they are women. And that is the reason for them to target us. So we are here to protest that and to make sure that the government and the institutions responsible for stopping and ending this happening do what they need to do. I mean, the highlights of femicide in Kenya because people are having so many conversations about it. People are saying it's been caused by a certain community. What is the main cause of femicide in Kenya? I think the main cause of femicide in Kenya is basically just how society raises men to think that they have autonomy over women's bodies. Such that when a woman gets harmed, it's because of al-Qa'an avahi. It's because we excuse what the perpetrator is doing.    It's not because she was on the streets at 3 a.m. A man can walk outside here during darkness and feel absolutely nothing, but as a woman, you can't. And what we are trying to say is we need to make society safe and safe for women as it is for men so that I don't feel like I will be targeted just because I'm a woman, just because a man thinks that I am weaker, just because a man thinks that, oh, I can do what I want with her body. That's what we are saying absolutely no to.  That is not reason for you to kill me. What do you think should be done now? I think, one, the courts and the police need to have extremely stringent measures for what they do with men who kill women or who abuse women in any way.  That is an offense that should be life imprisonment or the death penalty even if you ask me. We also need the government to speak out actively. I am really looking forward to seeing which Kenyan leaders are here around us to be able to protest and show us that they are part of this struggle. Because the reality is that a lot of people, especially men, don't think that they are affected by the issue because maybe their mom or their sister or daughter has not been affected, has not been killed, but you're all affected because every woman is a person just like you. And I hope that it doesn't happen to any of us, but we need to realize that the loss of one woman is a horrible thing for the entire country. I would love to see the president saying something about it.  That's what I want to see. Just to mention, I've seen Nairobi women representative Aisap Asari is here. You are fantastic. Good. What do you think of the picture? Do you think of yourself? Murugi, as a girl, mom, probably we have seen some of the cases where men are taking advantage of ladies' economic situations, maybe to exploit them and to perpetuate this act. Maybe what advice can you give to the young girls who are in university and who are just coming up? So I would definitely say that because of the current climate, we do need to be careful.  But more than that, I want to tell the men that it doesn't matter. Atakama o meninu lia pomebe ngapi. Atakama, you have bought me food for a month. Even if you have done what that does not give any man a right to touch me how he wants to do with me what he wants, it doesn't matter whether you have a million and I have two bob. That is not in any way a, you know, it doesn't give you a free pass for a woman's body. And I need more men to acknowledge what their fellow men are doing. In fact, I need more men to tell fellow men who they see speaking a certain way about a woman. If you start seeing a guy who's just like, ah, this is a femicide thing, she was talking about in a very light way, that in itself is a red flag because the reality is that economic empowerment or not, even a very rich woman will be killed and raped, even high in her house.  So either way, is it really about the money? You know, is it really about the money? We've also seen many of the cases related to foreigners and we have so many cases of maybe foreigners taking advantage of ladies. Maybe what advice or what can you comment about that? I would say that for me, okay, maybe I don't know and sell the statistics, but what I do know is that the majority of women who are raped, abused or killed, it's by people who they know. People who are their husbands, their ex-husbands, their boyfriends, their ex-boyfriends, there are people who are close to them. Whether it's a foreigner, whether it's an imzungu, whether it's somebody from your village, whether it's somebody who you met in Taoh, it really is not about who the kind of person is. The reality is that society protects men. Society raises up men to believe that no matter where you are or who you are, you have power over a woman and that's what we are trying to change. It's so unfortunate that a lot of these women are being taken advantage of by people who are closest to them. It shows you we are not safe anywhere. Whether you have money, you don't have money, you can be killed. Whether you are on the streets, whether you're in your house, whether you're in the village, whether you're in the city, you be at risk. And so women everywhere need to stand up. Men everywhere need to stand up and say that this is the end of the killing of women in Kenya. All right, maybe what next after this? Because now if the government wants to speak about this, if the government wants to address this, what is next step, you guys, or plan to take? My God, I have absolutely no idea. No idea at all. In fact, the people I've come with are telling them, after today, I'm out to Anzekfanya, march every weekend. Should we start marching every weekend? Should we speak out about it? Because the reality is, right now we are marching because nine cases of femmicide were reported in January. But the reality is, I'm sure there are hundreds more out there. People in the village, who maybe the media has not reported about. People somewhere in the slums, who maybe they just died, their bodies were just thrown. So nine are the only ones that we know. But we need to be actively speaking out against it. What I would like is to see people not lose the fire. I don't want the fire to end after this. We need to see more women continuing to speak about this on our platforms. We want to see policy reform. I want to see policy reform that gives extremely stringent punishments for men who are found raping or abusing or killing women. We need to see women actively protected. We need to see men, especially, coming out speaking to their fellow men in terms of events, policy forums, advocacy forums, activism, so that people can see that it's not just a one-time thing. It's not just that, oh, we're throwing our little tantrums to Mema Lisa, when they're home. It needs to be, this is serious and it's something we need to keep talking about. Thank you so much for your time. Thank you. Nice to see you. Thank you. Nice to see you guys here, covering this. Great time. Mm-hmm. Let's go, let's go. Let's go, let's go. Let's go.


Hello and welcome to the Grand Line Review, your source for everything One Piece. And today we have a review of a chapter short to go down in the history books, being 792. I am Odin, and I was born to boil. And it is with a heavy heart that this week marks the time to say goodbye to one Kozuki Odin, a legendary figure synonymous with the very fabric of One Piece, even though we're only just now discovering his story. This chapter was pretty much everything I expected after last week, which is in no way a criticism by the way. It just felt like the time for a nice dramatic ending, and Odin delivered exactly that, which will leave a series defining impression on me. And I have to say the panel most burnt into my mind at the moment, was one of the more understated ones actually. But I guess it's technically the very last shot we get of Odin, and his lifeless body is sinking into the oil, and there's just this incredibly satisfied and almost menacing smile, as if Odin knew exactly what would happen from here on out, and that Orochi and Kaido were the epitome of screwed. So despite not being a D, Odin passed on with the trademark will of D smile, and honestly I'd say he's owned it. Also just as a side note, I think the cover and colour spread of Weekly Shonen Jump is a bit on the nose, because it features Luffy holding some cup noodles, which is a tie-in with the Hungry Days commercial series that features One Piece characters in a slice of life school setting, and these commercials are all phenomenal, go and look them up if you haven't seen them. However I do find it quite funny that you know, in a chapter featuring someone boiling to death, the cover of Weekly Shonen Jump is adorned by a boiling noodle type of food. Hmm, not only that though this conspiracy goes far far deeper, and thanks to Ettenboy on Twitter for pointing this out, but apparently chapter 972, which officially came out on February 22nd in Japan, was released on Odin Day. That's right, Odin Day. And I mean, the sheer amount of planning that that would have taken Oda, to ensure that Odin met his demise on this very release date is just, ugh. So in any case, there's lots of boiling and Odin references at play here today. Although in the end, Odin does not die as a result of the boiling oil, and he is instead shot by Kaido, which is kind of a sigh of relief I guess, because for a while there, it really was looking like the legend of Kozuki Odin would be put to an end by Orochi, which would just be, ugh. So even though Kaido very much did the pirate thing and went back on his word, it still does carry a nice degree of respect, having been killed by such a profound figure, rather than a slimy little bowl of pure, scummy stuff. Something I very much did appreciate though, is that Odin was smart enough to realize that Kaido and Orochi were going to go back on their word in advance, even after Odin did the impossible by lasting an hour in the pot. Which means I guess he finally learned something from his five-year dancing experience. However, what I don't understand though, is that this was Odin's absolute victory. This stunt, combined with some well-timed words from Shinobu, seems to have changed public opinion at large, and all of a sudden it would seem that everybody loves Odin again. So it does make me wonder why in the modern day, the Kozuki clan are still so hated by the residents of Wano. I mean Orochi's propaganda probably has a lot to do with it, in regards to the younger generations, but I can't imagine anyone who was alive during this time flipping on the Kozuki clan after this. So it might just be one of those one-piece things where secretly every citizen of Wano still harbors an incredible amount of love and respect for the Kozuki clan, but they've all been collectively acting, so as not to incur the wrath of Orochi, and just waiting for the right time to reveal their loyalty. But other than Odin's death itself, the most touching part of the chapter for me was seeing that montage of all the vassals running away, and each having their own one or two-panel flashback of when they first met Odin. Which is very powerful because we got to experience these moments firsthand, and the kind of quirky joy I felt when they first happened is juxtaposed very, very strongly, against the sense of sadness and despair being felt by each of them at the moment. It really is a great couple of pages, although I do have one worry after reading this, which is that this material seems like prime anime extension stuff. The Wano incarnation of the one-piece anime certainly not above needing to pad out episodes, and I suspect that when we do eventually get to this section in like a year from now, each of these small one to two-panel flashbacks are going to be heavily extended, like a minute long or something each. In fact, this entire section could be a whole episode. Back to manga thoughts, though, this section once again highlighted a curious feeling, which is the overall importance of Denjirou. Because this is not a straight-up montage, it's actually broken up, because we get to see Kinemon and Denjirou's moments first, and then there's like a badass interlude from Odin, and then the rest of the vassals are showcased. So it's just one of those things where it really does emphasize Denjirou's overall importance here, which was something I noted when he was first introduced alongside Kinemon. These two were the OG Odin followers, and so that's why it makes a lot of sense for Kinemon to be acting as the de facto leader of the vassals, and I guess the allied forces are large as a result. But it feels like when Denjirou returns in whatever form, then he could take that role alongside Kinemon. Something else that caught my eye though, just before the whole tragic Odin death thing, is a super small panel of Kaido holding the gun up at Odin, and stating, I'm sorry about what happened with the old hag, I had her killed. Which I'm assuming is referring to Kurozumi Higurashi, aka the past user of the Mani Mani no Mi. But this section was just strange, because it's very much like a one-panel story all on its own, because there's absolutely no build up to such a revelation, and Odin barely acknowledges Kaido's words afterwards.  And to be perfectly honest, it is not a satisfying end to the Higurashi character at all. Like, she was the main driving force behind Orochi's rise to scummy power, as well as in my mind, the exclusive reason behind how Kaido was even able to defeat Odin in the first place. So to hear in this tiny disjointed panel that, oh, she's dead now because Kaido's inconsistent morality deemed it necessary to have her killed at some stage offscreen, it's just kind of meh. Especially because Higurashi had a nice layer of mystery surrounding her, in regards to the Mani Mani no Mi. You know, from the moment she was introduced every single manga reader, immediately knew that she was going to die. And it left a nice lingering question of how and when. It was almost something to look forward to in a twisted sort of way, but mostly to further connect the dots of this world. So unsatisfying is the word I'm going to use for what happened, in regards to this during the chapter. Which is a shame because everything else is so super solid. Now in defensive order, this could also be done on purpose, because it is clear at this stage that this flashback is made to focus on Odin, and there is a lot going on in the background that we just don't get to see at the moment, in regards to characters like Kaido and Toki and many more probably. Which I would say is the correct decision to make, because Odin's story is big enough as it is, and those factors would probably just attract from telling his individual tale. So I submit that perhaps in the future, we'll get a much more satisfying scene during say a Kaido flashback, whereby he is enraged after battle and orders the death of Higurashi. So that might be a thing, and we also need to deal with the user of the Bari Bari no Mi as well. So there's definite hope because we have a surprising amount of unfinished business in past Wano, much much more than I thought we would after a four month flashback. Moving to the last two pages now, this was some pretty stunning stuff as well, featuring Toki reading Odin's words as well as several flashbacks of the man himself, mirroring the situation with the vassals. Very sad stuff to see but also incredibly interesting, because the thing that happens here is Odin actually tells Toki the time frame, which she will eventually come to use in her prophecy. So due to her time-travelling powers, I guess I always assumed that she would be the one to know about future events, and in a way was almost acting like the mastermind behind planning the downfall of Orochi and Kaido by sending various people into the future and selectively keeping a few here. But no, none of that though. Odin knows all of this, somehow. Most likely as a result of landing on Muftail, which once again begs the question, exactly what the hell it was that the Roger Pirates found there. To think that Odin would come away from that experience with such an accurate time frame regarding the return of Joyboy, just complicates exactly what was on that island, like was it some kind of ancient prophecy engraved in stone or poneglyph, and a hilarious prophecy of that, or what? Who knows, in any case I think it's a slight shame because it removes some of the mystery behind Toki, who up until now has been very much portrayed as another legendary figure, but currently she looks more like a side story utility that was conveniently in place for Odin to make use of. But with that said, from here we do have a couple of options. Given the way the chapter ends with the statement, the story hurtles towards the present day. I would say that implies that we're done here for now, and it's time to go back to modern events, which is interesting because this story is in no way finished. We still have the ransacking of Odin's castle and Toki's actions to see, which could very much be what next week's chapter focuses on in some way shape or form. And it doesn't necessarily have to be another full chapter flashback either, it could be one of those situations where Odin spends a page, or two quickly skipping through those events, which we already know the technical implementation of, and then jumping back into modern day. I'm really hoping not though, because my ideal scenario would be to cut the flashback off right here and now, and then have a separate Toki flashback later to focus on this figure, who is quite possibly the only individual we have ever met to have lived in the void century. There's just far too much potential to leave her hanging here. Plus, any further flashback action right now would probably start to get a bit fatiguing, because fun fact, this is by far the longest flashback ever featured in One Piece, and I mean, we're currently on chapter 13 now, which is more than twice as much as the Trafalgar lore flashback, which I remember feeling like that took forever to read back in the day weekly. However, with that said, this experience to me has been completely different. This is probably the first flashback in the series that has truly captivated and engrossed me into it, rather than me always having that nagging thought of modern events in the background. And for an example of that, my first experience of reading a flashback weekly was Robbins on any slobby, and it was a very good story, very tragic, very substantive, but my god, I just wanted to get back into that CP9 action, and I find myself similar in most flashbacks, but not this one though. And regardless of whether or not the flashback ends at this point, which I think it will, we do know that this is the end of Odin, and he has been nothing short of a pleasure to follow for the last few months. He just represents such a grand journey, and through that, he is now carrying the immediate future of this series on his shoulders, in a similar manner to that of which, that he was holding up the vassals, whilst boiling in the pot. So in his own words, Odin's soul most certainly lives on, and I really look forward to rereading the series with the understanding of the context of his existence. Like going back on arcs like Punk Hazard, I'm very unlikely to view Kineman as that simple comic relief samurai, or Khandro and Dressrosa or Raizo and Zo. When these characters come up again during yet another inevitable reread, they will carry with them the emotional resonance of the last two chapters specifically, and that is going to be one hell of a unique experience. So look ahead Odin, 20 years into the future, as your samurai continue to do you proud, and eventually open the borders of Wano. But that pretty much has it for chapter 972. If you enjoyed this video and the content this channel produced in general, then please do consider donating to the Grand Line Review Patreon, because the support of all of your amazing people is what continues to make this channel possible. And if you'd like to see more videos like this but applied to other anime among series, then please do feel free to check out my second channel New World Review for all of your wider needs. And if you'd like to join the fun at any time, then please do head over to my Discord server where a wide array of shenanigans takes place on a daily basis. And finally, please do comment with your thoughts on the chapter. This has been the Grand Line Review, and I'll see you next time.