 All right. I think we can start now. So, good morning, everybody. This is a state of Drupal 10 or getting ready for Drupal 10. This is Matt Glamin. And I am Gabor Hoici. Both of us happened to work at AQUIA now when we submitted the session. Not both of us worked at AQUIA yet. But now both of us work at AQUIA. We tried both of our computers and neither worked. So, this is off of the conference venue computer now. But it should work. So, hi. Drupal 10. I don't know if you know, but Drupal 10 had three possible release dates. One of them was on June 15th and then August 17th and then December 14th. We defined these, I think, last year, maybe a year ago, something like that. And the thinking was that we want to have Drupal 10 out soon enough for everybody to update to, but we also want to make sure that we do all the things that we need to make Drupal 10 available. So, we defined these dates based on whether the beta requirements will be done on time for March 18th and May 13th and September 9th. And although it's not yet May 13th, we now know that things will not be ready by May 13th based on the trajectory that we are going through. So, the release date of Drupal 10 is going to be the last option of the three that we defined last year. So, it's going to be December 14th later this year. And that also means that there's going to be a Drupal 9.5 alongside Drupal 10 at the end of the year. So, we're going to have a 9.4 in June in the original window, the earliest window that was for Drupal 10. And we're going to have a Drupal 9.5 alongside Drupal 10 in December. That also means that Drupal 9 support will end roughly a year after Drupal 10's release because we need to stop Drupal 9 support due to Symphony being going unsupported, Symphony 4 going unsupported that we use in Drupal 9 and also CK Editor 4 going unsupported in Drupal 9. So, there are two major dependencies that will go unsupported and Drupal community does not want to fork Symphony and CK Editor and maintain it for ourselves. That would not be fun. So, we need to stop supporting Drupal 9 towards the end of next year. So, that's why we're releasing Drupal 10 this year. And then we'll go on with Drupal 10. And as you will see on the next slide, Drupal 10 is based on Symphony 6 and is also based on CK Editor 5. So, theoretically it could be supported until like 2027 or something on Symphony 6, but there may be probably other dependencies that will stop us from doing that. So, I don't know how long Drupal 10 line is going to go there. We'll see. An interesting fact is that Drupal 7 will be supported longer than Drupal 8 and it will be supported longer than Drupal 9. So, all the marketing that we did to update to Drupal 8 and Drupal 9 from Drupal 7, I think it was worth it, but we're still going to support Drupal 7 more. Realistically, the support for contributed projects from Drupal 7 is a hit and miss now. So, I would encourage you to start looking at upgrading to Drupal 9 and then eventually Drupal 10. And so, one thing that we will have is we will have the migration path from Drupal 7 and even Drupal 6, I believe, in Drupal 10. So, if you have a Drupal 6 site, the migration path from Drupal 6 is included in Drupal 10. That's quite unprecedented, I think, in the history of Drupal. So, after our session, the Dries node will go into a lot of the details about what's in Drupal 10. So, this is our one slide about what's in Drupal 10, the major points. So, Drupal 10 is now at Alpha 3. We'll release further alphas and then when the beta requirements are done, we'll release the beta, which will be API complete. And so far in the alphas, we managed to get in Symphony 6 in place of Symphony 4. This will be updated to Symphony 6 one in May and will be updated to Symphony 6 two in November before release. That's the expectation. And the trick there is that we would not normally be able to release Drupal 10 on Symphony 6 because Symphony only supports their minor releases for six months and they only support their LTS release for long enough for Drupal. But we made a special agreement with the Symphony team that we have Drupal core committers sitting on the Symphony security team that can make special Symphony releases available for things when it affects our project. They can backport the security fixes to otherwise unsupported Symphony 6 minor releases. So, that's why we can release on Symphony 6 even though it's not long-term support and even though they would not normally support long enough for when Drupal wants to be supported. Cic editor 5 replaces Cic editor 4. So, that means that Cic editor 4 is moving into contrib. It's going to be a contributed project. And Cic editor 5 is going to be the editor in Drupal 10. If you're interested in this, there's a session, I think, at 1 p.m. from Cic source. And they're also in the expo hall. You should talk to them. It's really cool. Cic editor 5 has a lot of cool features. So, you should talk to them about that. Claro will be stable and will be the default in Drupal 10 while 7 moves to contrib. So, this is a pattern. When we get something new in, we move the old thing out to contrib. So, if you rely on 7, you have a custom admin theme based on 7 or just like 7, it's going to be a contributed project. Same thing for... So, Claro is the admin theme in Drupal Core. Same thing for Oliveiro is a new frontend theme in Drupal Core. So, that's already stable. I'm going to be the default in Drupal 10. And Bartik will move to contrib. It's been a long while. It's been a time. There's also a bunch of other modules that we are moving to contrib. Forum tracker, aggregator, caller, HAL, RDF. And we'll probably move more later on in Drupal 11. But for Drupal 10, the plan is to remove these ones. Why are we removing them? They are mostly single-use modules that don't have an ecosystem in contrib. They don't have further modules that depend on them. Most of them are not very well maintained in core. So, like, caller module could do a lot of good things if they would get some love from maintainers in contrib, for example. There's better solutions for aggregator in contrib. So, we don't need to, like, compete with better solutions in contrib. We don't need to have the core solution that's inferior to something better in contrib. Yeah, and we can reduce the maintenance burden in core and set these free and have them better maintained in contrib. They will move to contrib as they are in core. So, if you want to use them as they were in core, you can use that branch. And then the maintainers that we recruit for them, we ask them to release new branches with new features so you don't need to adapt the new features if you don't want to. There's also no support for Internet Explorer in Drupal 10. None of the Internet Explorer is anymore. So, that sets us up for a lot of good front-end things. Olivero is happily adopting a lot of modern approaches, for example, now that we don't support Internet Explorer. Drupal 10 has a minimum requirement of php8.1, which may be sound a bit high, but it will not be high in December by the time it's going to be adopted and PHP 7 is on its way out, so it will not be supported much longer. So, you need to look into updating to php8.1. And the database requirements will be largely unchanged. We already made the major database requirement changes in Drupal 9 to require JSON support in databases, and we do not yet use JSON support in databases to have, like, deeply look into JSON data structures in Drupal Core, but we hope to use it sometimes so we keep the same requirements in Drupal 10 for our databases. And so, as I said, this is how we built Drupal Core, is we basically add the new things into Drupal Core, like the Clio theme, like a new API, like new modules, et cetera, and then we deprecate the old things, like Bartik, like things, ways to do things. And then the change in Drupal 10 is basically removed the deprecated API. So, the way we built Drupal 10 as much as possible is to put everything into Drupal 9, all the features, all the new APIs, everything put into Drupal 9, and mark the things that we'll remove so that you know that this is not going to be available in Drupal 10 anymore. And so, this is what we do on the theme level, on the module level, we do it on the API level, we do it for routes, we do it for a bunch of things. And so, this is how we help you go through this transition. And then the rest of the session will be about going through this transition. And I will hand this over to Matt here. All right, hi everybody. So, we're going to talk about how are things deprecated in this process. So, when we go through, when there's like code methods that are deprecated to class, we use PHP docs and do an at deprecated tag and then give a message. There's actually a standard message that gets flagged by PHP CS. And there's also a runtime error that gets triggered. So, if you go to your database logs, you'll see the error logged in. So, if a code is called, it will say, blah, blah, blah, it's deprecated with the same kind of message. And it's important that we have these two layers, the static analysis tools, can catch PHP doc. But you're just running it and you're going through the site and you're just finding out, you can look at your logs and see that you are actually triggering deprecated code. There are services deprecations, and this was added in nine dot, in the nine dot era. So, if a service is fetched, it will log an error. Whenever that service is retrieved, it says, hey, the service is deprecated, use this instead. And that also has its own standard formatted message. Libraries can now be deprecated as Drupal core moves away from having heavy reliance on jQuery. Now, the jQuery libraries have been marked as deprecated. And as we go through, well, wouldn't these trigger, do a trigger error, correct when I load it? Yeah, do a trigger error and we'll go through later on on how we can actually find these without relying on looking at your logs. And modules and themes can also be deprecated now, such as aggregator, HAL, RDF. So, there's a new lifecycle key that's for deprecated, and this is also used for experimental modules, too. So, it helps explain their lifecycle in the experimental process. And then the lifecycle link, so you can go find and read more about why is this in beta deprecated, alpha, et cetera. And the cool part is, if you go to the modules list, as you see in the bottom right, it actually has a link of that lifecycle status and can bring you to that node. The biggest thing of all is all the change records. So, every deprecation, in fact, any major change gets a change record, but it's important to check this out for deprecation notices. They're published at Drupal.org slash list dash change, hyphen changes dash Drupal, or follow the Drupal 8 changes bot on Twitter and get announcements as one of the people who maintains a lot of the upgrade tooling. I monitor this a lot. It's also good to help you plan for your next sprints. So, if you watch this, that we can put in your backlog. So, in your sprint in three weeks that kicks off, you have it ready to go. So, that's how things are deprecated. Now, let's talk about how we find this deprecated code besides just relying on our database logs every time things run. So, first we have PHP stand and PHP stand Drupal. I'm also wearing my PHP stand shirt today. PHP stand stands for PHP static analysis tool. It scans and analyzes your code. Write PHP is a scripted language. It doesn't compile until the web server runs the request. And it's compiled on command. So, PHP stand allows running your code that way to do static analysis without actually running it. PHP stand Drupal is an extension I maintain that makes PHP stand how to auto load Drupal code. Because we don't dump our classes to Composer. We have dynamic namespaces because we have extensions that can be uninstalled and installed. So, it also provides some very Drupal-specific extensions. One to highlight here is if you do a lot of entity queries, before you by default were in to entity access. But in Drupal 10, you must explicitly opt in or opt out of entity access. That's not a deprecation. That's a policy change. So, there's a rule in PHP stand Drupal that works for about two-thirds of the code that we can read. That says, hey, you have an entity query that does not do entity access checks. It does not specify it. So, those are things that aren't quite deprecations but has specific rules that we tell PHP stand to understand how to read the code. And then there's Drupal check, which I think people probably are more familiar with the name of over PHP stand. Drupal was created for Drupalcon Seattle as a much easier way to configure PHP stand. It's a lot easier to configure PHP stand now, but Drupal check is basically a install and run. No configuration required defines all the dependencies. When you run Drupal check, it actually generates a configuration on the fly, uses that and you're good to go. So, you don't have to maintain anything in that regard. It runs PHP stand without any static analysis except for deprecation rules. It's the one thing about it. Upgrade status. Yeah. And then there's the UI, sort of the UI on top of Drupal check, let's say, is Upgrade status and then it does a bunch of more things. So, what Upgrade status does in its core is it runs PHP stand Drupal with the same configuration that Drupal check would run and it collects all the deprecation issues and it runs them on your project to where on your site. So, it runs them for your projects and then it identifies for each project the next step that you should take. It knows about automated fix coverage for your project. So, we'll talk about that a bit later how we automate the fixes. But Upgrade status will let you know if there's automated fixes available for those errors. If all of them are automated, it tells you to just run the tool and then fix it. It also tells you to manually do. It will tell you if you're not using certain projects on your site to uninstall them and just get rid of them instead of keeping them around. It will tell you if there's updates available from Drupal.org that are compatible with the next major version of Drupal in this case Drupal 10. And to tell you to update it will link you to the issues on Drupal.org for updating it to the next major version. So, it facilitates collaboration in the community with the project list of where you are. It also checks for a bunch of things on top of Drupal Check. So, it has a lot of stateful things like checking routes in Drupal or checking your tweak templates that would not be statically checkable with PHP 10 Drupal. So, we'll add those on top of the results from PHP 10 Drupal. And then it has an environment check. So, it checks all of the requirements of the next major version if your current developer environment meets that if it has the right PHP version the right database version if your settings file includes deprecated keys a bunch of these things it will go through and report them so you can fix them and get ready and then it has this pie chart at the end how complete you are with your process and it will congratulate you at the end if you succeeded. So, this is very visual. It's also integrated in Drush so you can run it in your CI system it will fail your CI if there's problems. It has like an XML report that you can put into fancy other display tools so it has a bunch of these nice solutions. So, that's upgrade status. The fun one PHP 8.1 compatibility so I don't know how many people are running Drupal 9 on 8.0 but if you do the breaking changes from 8.0 it's not that bad, there's just a few. So, one of the best ways to do this is I know most projects now have some kind of continuous integration built in set up another workflow that uses PHP 8.0 and run Drupal check PHP stand the Drush command for upgrade status in your CI and see if it explodes that's the easiest way to go for it PHP stand does have a way to set the target level with the PHP version and you can set it to 80 100 which is 8.1 but I spent about a month and a half contributing to PHP stand to try to make it be self-aware of breaking changes in PHP 8 when running on 7 it's hard so you can set that up and try to run it, it will catch some things especially native PHP functions that have signature changes it will catch that but also PHP stand at about level 2 to 6 so if doing it in Drupal check won't necessarily do a lot so one of the best ways to do it is to just get a PHP 8.0 environment and run it I just opened an issue for myself to add a flag on Drupal check to say with PHP 8.0 and it will set that flag to at least try to do something so that's one note on PHP 8.0 compatibility do it in your local, do it in CI see what happens the easiest brush, brute force tracking deprecations so we have all of these tools and we always wanted to know okay so how does Drupal do how does the Drupal ecosystem do in this sense so the Drupal association is running upgrade status on all of the contributed projects thousands of contributed projects every week once a week, it runs on all of them and then it has a incomprehensible zip file of data that nobody would be able to read and so we take that incomprehensible zip file of data and then make a beautiful colorful dashboard out of it that we put it on dev.aquia.com so that takes the data from the Drupal association and digests it so that's on dev.aquia.com Drupal 10 slash deprecation status and it gives you a run down of the general status of the contributed projects we discontinued running this for Drupal 8 to 9 because the Drupal 8 releases that are not yet Drupal 9 compatible were marked unsupported so there's no point in running it anymore there so we have it from Drupal 9 to 10 now and if you've seen this tool before there's a lot of good new things here that you should check out because we've improved a lot of things based on stuff that we learned before so one new thing is that we have next step suggestions for projects here which are very similar to upgrade status so we tell you if we have pre-scanning errors and like there's a machine name problem with you or a malformed info file or a PHP fatal error that we can't run upgrade status on your project then we categorize these and we tell you you need to fix them and we have help text for each next step as to what you should do to fix this in your project and then we are tracking when you need to fix deprecation errors when we find them the automated tools rector or you need to do manual fixes as well and one shortcoming that we had before is once you fixed all of your problems we considered you done but now we don't consider you done at this point because we track your release status for projects as well because having no deprecated code in your project doesn't really help if it's a dev project and people building sites can't use your project yet because it's a dev release so we are trying to encourage the contributed projects to make tag releases available and then improve the stability of releases as well so we suggest these next steps with clear instructions and we track stability beyond zero deprecation errors each project page has a landing page now on the site with the list of the errors, the next step and explanation of the next step so that's the instructions on what to do fixed info files and then there's a UI to filter the errors and then look for how widely this error applies to other projects like how easy it's likely going to be for you to fix it and we also have maintainer search now that was a popular request that people wanted to look at their projects and the status of their projects so they can just search for the maintainer name now and look at the projects for themselves we also do finer segmentation of errors now so one of the things that happens in Drupal 10 is that most of the deprecated errors found in 7000 contributed projects are coming from Drupal 8 to 10 deprecations so these are the bright yellow ones were already deprecated in Drupal 8 so if you don't care about supporting Drupal 8 then half of all of the deprecated API instances that we find in all of the contributed projects on Drupal.org can already be fixed without any incompatibility problems with Drupal 9 and then the other half is Drupal 9 deprecated APIs. We are also tracking third party projects so we have separate tracking for twig API, symphony APIs, guzzle APIs etc and we also know which of the errors have automated fix coverage so this this half of all of the errors is Drupal APIs that are covered by automated fixes and this is the Drupal APIs that are not covered by automated fixes so we are way better in covering the API changes with automated fixes thanks to a lot of funding from Palantir.net and the work of this gentleman that basically built most of it single handedly. So we have this finer segmentation of errors as well there and then the next up is how do we fix them automatically. Now this is the fun part and there is going to be a part where you look at this and I know some eyes are going to glaze over because I did the first time I started working on this. So fixing deprecations automatically Rector has now become a household name. Think of it as a way to automatically upgrade and refactor your code. Drupal Rector is a repository of Rector rules so let's first differentiate PHP stand is a static analysis tool. It reads your codes and reports back problems. Rector you write rules and say this is a problem fix it. So it's reactionary. PHP stand is for discovery. Rector is for reactionary fixes. So that way you don't have to do it manually. So it is great. So the rules target specific nodes in an abstract syntax tree. Now you don't need to know what an abstract syntax tree is. Think of it, you write code, it gets turned into a tree of objects that can be traversed and we can say hey this is a function this is a method. Oh this is the method that I need to fix. Here's the replacement tree syntax. So if you want to write rules here's a quick example that it will go through or just ping me in Drupal Slack and we can hack on it together. So let's take the first example is file create URL was deprecated and it's to be replaced with Drupal with actually not this exact code file URL generator service and invoke the generate absolute string method. But the simplest way to replace it without trying to do dependency injection for you is Drupal service. All right, so this is a rule that was written in over the fall ish time. So the target we say get node, Rector says what node types do you attach to and here we say function calls which also means that every single time Rector finds a function call on your code it's like okay do you work or do you want to go to town and fix this? So in the rule we have to say is this the right one we want to modify because I've written bad logic and next thing you know I rewrote everything in the code base. So don't do it in production please. And then this is the fun mess with it. So the top line is just an assertion for PHP storm so I know it says yes I know we have a function call and another method we said I will only receive a method call. And the first thing that it has to do is it gets the name from the node which is a function call which the name will be file create URL. If it's not file create URL bail out we don't want to modify it and then all of this right here so I'm kind of blocking it is saying to create a static call to the fully qualified name of Drupal and we're calling the service method and passing it a string argument of file URL generator that creates the Drupal service call and then method name is generate absolute string and then we return a method call node. It's one of you look at it and it's like but once you start going through it it's really repetitive we have a lot of base classes that makes a lot of this easier but I didn't want to show a simple base class I want to try this as the simplest straightforward example but there are things that we have a lot of helpers for to help automate next is project update bot which ties into Rector. Yeah so one more thing about Rector is this is how you write Rector rules we have a lot of the Rector rules written now so you very likely don't need to write your Rector rules but if you find areas where something is not doesn't have an automated fix it would really welcome you to help out with writing the Rector rules but you most likely don't need to write much Rector rules at this point so next up is project update bot so the project update bot runs as part of the same job that generates the status results that I've shown before and this runs where after the upgrade status step is run it checks if the errors that upgrade status found are fixable with Rector and if they are then it also runs Rector and generates the patch from Rector for the project and then it posts the patch in the issue queue of the project as a project update bot user so it's automatically posted in the issue queue and then it will post updated patches later on with updated Rectored codebase if there is more fixes available so this is basically automating all the tools that we have running upgrade status on your project running Rector on your project posting it in your queue maintainers only need to look at this patch and understand if it works for them and commit them and fix it up and then make the release we have not updated the project update bot yet to Drupal 9 to 10 so this used to run very happily Drupal 8 to 9 we need a little bit of work to update this to 9 to 10 to make it work again and then we'll kick it off again and we'll run on contributed projects but this will help with getting all of these contributed projects ready it still needs humans to review the patches and to make the releases so that may sound trivial but you need humans to review them but it's a thing that we need to be aware of so because of all of these things that we do then some of these projects will have their releases available that are Drupal 10 compatible and so you can use them with Composer on your Drupal sites but not all of the projects will be Drupal 10 compatible in time for Drupal 10 so that's just the effect of life so we have some solutions for that as well so we for Drupal 8 to 9 we built the lenient Composer facade because there's this problem that thousands of these projects need very simple changes but you need the humans to be involved to commit the change and make the release and I think it's great that a lot of people contribute projects on Drupal.org because we have all that open source code base that people can use and it's also fine that people stop supporting their projects they move on but unfortunately there's a lot of these projects because they stop being supported they don't get to be updated so we built this lenient Composer facade to allow site assemblers if you're assembling your site in Composer to ignore the core requirement in these projects so if a project does not get updated to Drupal 9 in this case or Drupal 10 in the future then you would be able to require it with Composer even though normally it would not be possible to require it with Composer so that was the idea behind the lenient Composer facade. This was the other thing that's not yet updated to Drupal 10 so this was a solution for Drupal 8 to 9 and yesterday we had a discussion with the maintainer of Composer itself and with Ryan from the DEA and other people how do we do this in Drupal 9 to 10 because there's a bunch of technical problems with that process if we apply the same solution and the solution that we came up with is to build a Composer plugin that we put into core so that you can require Composer projects ignoring the core requirement and that would allow to distribute this to people building their sites instead of it being a central service that has some potential technical problems so that's likely how we're going to update the lenient Composer facade is we discontinue the lenient Composer facade and we write a Composer plugin instead that allows you to require projects where the humans did not make the compatible release yet so that's a good step for building your site now you have the codebase but it's still not compatible with Drupal 10 so that's where Composer patches comes in that you can apply the patch from the project update bot or the humans wrote in the issue queue and you can make the project compatible with Drupal 10 on your site so this is a process that is not ideal but it's the best that we could do on the way from Drupal 8 to 9 and we'll apply the same from Drupal 9 to 10 yeah so the question was this allows you to install if the dependency was declared in the Composer JSON file yes this allows you to install dependencies that are not yet compatible with your major version of Drupal but it was only for 8 to 9 so we will discontinue this for 9 to 10 and we'll have a Composer plugin that we didn't build because we just had the discussion yesterday about this but now that the Drupal 10 releases in December we have time to build it and put it in core to support the similar workflow with a Composer plugin on your Drupal site yes yes so once you install it you can patch it that's what you said so this is for getting it with Composer because if it's not yet compatible with your Drupal then Composer will refuse to download it so this is to make a Composer to not refuse to download it and then once you have it downloaded with Composer then you still have to patch the info file at least and then some other things possibly this project is for applying patches to things that you got with Composer so you can apply the patch from the project update bot or from humans in the issue queue that has not yet been committed to the project with Composer patches so these two solutions are for projects where the humans are not making the releases yet or will not make the releases so that's how you get your project in and yeah so I know offhandedly that might seem very convoluted but realize this is not an us problem this is a problem in every ecosystem that has upgrades I don't know if anybody was tracking package updates for PHP 8.1 but there's a scary a lot of Twitter theory about oh it doesn't support 8.1 yet is it locked to PHP 8.0 and dependencies on dependencies that would be patched for 8.0 and a lot of times people are then forking on GitHub and pointing their Composer and same with symphony and symphony bundles so it might seem like there's a lot of work going on here but this tool is like a shortcut from you having to point to a custom repository and forking it and maintaining it in your Composer so no like this isn't just a Drupal problem this is just a software problem period and this is I think this is actually like the best approach that we as Drupalists can approach this from yeah if you look at the readiness data of Contrib around half of Contrib is the bright yellow that only needs an info file fix so around half of Contrib Drupal 9 Contrib only needs an info file fix which means that if the humans are not making the fix and not making the releases then you will need to use this Composer solution and patch the project but they are projects that only need this one line fix to be able to be used so that there's another option of taking over those projects so if you want to be co-maintenors slash maintainers of projects that would also solve the problem but it's needs even more humans so if you want to get involved we have a lot of select channels for the things that we talked about so we have the D10 readiness select channel for all the Contrib tools and the core work that we are working on there's a dedicated channel for PHP 10 for the low level building PHP 10 itself if you're using PHP 10 for Drupal 10 readiness there would be D10 readiness there's the Rector channel for working on the Rector fixes and whatever problems you have with running them there's the Admin UI channel for Claro, the Oliveiro channel for Oliveiro and the CQTDR5 channel for CQTDR5 there's a meeting in the D10 readiness channel every Monday at 11am pacific about Drupal 10 readiness we talked about the tools we talked about core progress we celebrate our progress and we discuss blockers and you can also meet us here at the contribution rooms and there's a bunch of buffs later today about these other things that happen in core that we would love to see you at with this we have 14 minutes for questions if you have any could I show you an example of finding the deprecation status by maintainer yes this is not my computer so I would not be able to do any CLI but web browsers are easy so here's the deprecation status dashboard live and so you want to look at my projects I'm not going to do the accent here so we're going to look at Drizzi's projects why not this is the example so here's Drizzi's projects he owns OG for example he's the OG maintainer of OG I don't know so this is his projects and then you can see the next step is to run Rector to fix some errors and you can look at this next step and here it explains that 920 projects need to run Rector and here's the description of where to get Rector and what to run and all the projects that need to run it so this is how you look for maintainers sure yeah I know next question is there another library that's going to replace jQuery yes and no so jQuery UI was documented to be emeritus which is basically end of life and so we worked a lot on replacing jQuery UI components with other things and we replaced some of them but not all of them and by the time we replaced half of the jQuery UI components then jQuery UI decided not to be emeritus anymore and they released this update and now they have security support so we were like okay that's good but you don't need to replace everything because if they are emeritus and they don't release security fixes anymore if jQuery itself gets updated they become incompatible and that's a whole mess for Drupal Core to update all of your JavaScript overnight in a security release that would be a problem so now they support it again so we stopped replacing the components we would still ideally want to replace them but we stopped halfway because the way that we do the replacements to do these deprecations and a new API and have backwards compatibility it's a lot of additional work for core developers to do this for the benefit of side owners having an easy upgrade path it's a lot more work so we stopped halfway and we're not going to replace jQuery UI we're not going to replace jQuery we may introduce new frameworks so project browser is being proposed for core and the prototype that we have right now is using Svelte.js and we don't know if we're going to add Svelte the prototype with Svelte.js into core or not but that's an option that's on the table so that's a possibility we may use other frameworks in core without dropping jQuery UI or jQuery first next question alright well if there's no more questions then thank you for coming it's been fun see you around