 Please start now. All right, so can you see my screen? If not, I'll zoom in a bit. That's the hell that is here. Yeah. So first of all, yes, I use light mode, like me. So I'm going to talk about annotations and plugins and some changes coming in that space. So if you've been doing development with Drupal 8, you've most likely come across annotations for plugins and I'm going to start with a bit of history. So originally we were using annotation reader from the doctrine annotations project and they had a simple annotation reader. And so what the simple annotation reader let you do was, here's an example of a search block from a contrary module and we've got just at block here. Now, this was something that we adopted early, early in Drupal 8 alphas for a developer experience. At the time, a lot of people were new to object-oriented programming, particularly things like namespaces. And so what has shown to be in hindsight, not the best decision, but we decided to allow the simple annotation reader, which lets you use block here without using the fully qualified class name. So what you're doing when you put in this block annotation here, it's actually a reference to this annotation block and the full namespace of that is Drupal core block annotation. So the full class name would be Drupal core block annotation block. But for developer convenience, we decided to go with a simple annotation reader, which lets you say just block. Now, you can probably reason that there's going to be some collisions if two modules have the same annotation name and seeing the sense in the matter, doctrine basically unsupported the simple annotation reader and we found ourselves, we got off the island, but we were kind of marooned on this simple annotation reader island. So what we did was we actually fought that into core. So in core, we have this simple annotation reader and you can see at the top here, this is a near copy of simple annotation reader. And yeah, we really want to get out of this and get away from this. And thankfully, with the release of PHP 8 along came a sort of native way of doing this, which is PHP attributes. And you've probably have seen that if you've used like symphony or any other projects that used to rely on this doctrine annotation reader that most of this stuff is now deprecated in favor of the native PHP feature. So in Drupal 10, we went with 8.1 as a minimum requirement and part of that was the plan that we've got here for these annotations to attributes between PHP 8 and PHP 8.1, there was an important change in attributes and that was for supporting nested attributes. So you'd be familiar with, for example, the entity type annotation, it's quite convoluted. There's a lot of keys and there's a lot of nested things in there and that sort of stuff wasn't supported with annotations in PHP 8. So both us and symphony six, we held off and made PHP 8.1 the minimum requirement. So that was kind of the first piece of this puzzle. With that in place in Drupal 10.2, we got our first conversion over for plugin managers and for the action and block plugins. So this is a contrary module that's still using the old block annotation. And this is a core module, well, it seemed to be a contrary module from forum that's using the new attribute. So these are actual PHP language features rather than magic things in the doc blocks at the top. And that means you get all of the things that you will expect from your IDE. So you can say derive, you get basically context hits about the things that you can do here. So if you've ever worked with an annotation before, you know that there's quite a lot of magic keys. It's very easy to get it wrong and get an error when you clear the cache. So this moves us to a nicer place where we can just use the native PHP feature and get all of those things free. So I don't know about you, but myself, I had live templates in PHP storm for these things because I was always making mistakes. So I could type, for example, and I block and it would give me like auto completion of this stuff. So I did make mistakes and I'll be looking forward to getting rid of that and just making use of these native attributes. So in 10.2, we've already converted block and the other plugin that we could go just action. So if I go to action base and I find you that it's a bad example. So here's a message action. So yeah, we've converted those two in triple 10.2. So if you're using triple 10.2, you can start making use of those. And then in 10.3, we've got a fair few more. So if I click through to this class, you can see that it extends from a base attribute called plugin. And then I can list all of the things that have already been converted in 10.3. So there's quite a lot. Most of the work still to go is around views and entity types, but we hope to have all of them finished by 10.3. So we've got a fair bit of time to talk here. So I might just talk about what you do if you are the maintainer of a module that has plugins and is already using an annotation. So the first thing you need to do is create a new attribute class. So we've been putting these in an attribute folder inside the module. So I might jump into a country module or sorry, a module instead of a core type. So let's go into rest, for example. So this is living in source attribute namespace, whereas the annotation was in source annotation. You create your class and you extend from the plugin attribute in core and you put this hash attribute attribute. So a bit of inception here about this attribute attribute tells PHP that this class can be used as an attribute and the attribute target class tells PHP that this attribute can be added as an attribute to a class. And I know that's a mouthful. And then all you have to do is have a constructor and in the constructor, you have basically the contract of the things that your attribute supports. And in most cases, this will be a direct mapping from the things that were in your annotation. So for example, the annotation for rest resource had ID label serialization class. So forth, and if we jump back to the new attribute, it's got the ID, the label, serialization class, and then the URI paths. Of note, here is this driver. This is something that all plugins will need to support so that we can use plugin drivers. I'm not going to go into detail for that here. But some of the nice things here is notice that we've got type hints. So before we had in the block one, for example, if I jump back to that search block, you see we're using this at translation annotation, but now with the replacement for these, we just use a class, new translatable markup. So again, we get all the benefits of the PHP language instead of magic stuff in a comment. So yeah, if you've done the, you've created this new attribute class for your module, the only other thing you need to do to convert this over is to change your plugin manager. So I'm just going to jump into the manager. And in the constructor for that, you have to pass in a, so the base signature of default plugin manager has changed. And now there's additional arguments that you can pass to that. And one of those is the attribute name. So this was the old annotation name and this is the new attribute class. And so the signature of the parent accepts both. So if you don't pass in, for example, this, I'll just comment that out. The parent will know that you're still using the old annotation approach. And if you do pass that in, then it'll know that you're using the new attribute approach. And we still have the BC layer for the old annotations. So that's how this module, this search block, it still works with the old approach that we expect by 10.3 will start emitting deprecation errors for that. So that if you are still using the old annotation, you'll get a warning that you need to update to the attribute. So that's kind of the conversion process if you were a module maintainer that has the plugin. The next thing to talk about is what's left for core. So I mentioned there's a few views plugins to go. There's quite a lot of plugins in views, a few migrate plugins. And it was also, I think, layout builder and the entity types. But the good news is, while we've been working on those conversions beyond Berala, who's from the Drupal 11 Redis team has created a Rector rule for this. So we hope that the project update bot that comes through and generates automatic formerly patches but now merge requests for contrary projects will come through and automatically make all these conversions for us. So that's a huge improvement. So with the work that's happening for the entity type conversion, at the same time, they're making use of those Rector rules and comparing what human generates versus what the automated stuff generates. So that's a huge, huge win. And that will mean any projects that are on Drupal, will be ready for Drupal 11 earlier. We expect, however, that we're gonna keep both of these around throughout Drupal 11. So we will have this deprecated in Drupal 10.3, the attribute approach, and most likely we'll keep it around in Drupal 11. So it'll still be deprecated then final removal in Drupal 12, just because this is such a large-ranging, large, a wide-ranging change and it's gonna have quite a lot of impact on both custom code and on contrary projects. I'm sure that nearly every custom client project you've built, at least one of these things, maybe a block, maybe a fieldful matter. So yeah, we're thinking that longer runway. And because we've got that fault version of doctrines, simplification reader, I mean, the maintenance is on us. We don't have to worry about the rug being pulled. It's kind of already gone. So yeah, I think that's everything I wanted to talk about. Does anyone got any questions? Unsilence. I'm assuming no questions then. Thanks a lot, Lee, for your presentation. No worries. I'll share links in the sidebar to the meta issue for the core conversions. If you're interested in getting your head around how the conversion works or how these work, I'd recommend picking one up. Yeah, you get both sides of the coin in that process. So you get to convert a plugin manager to the new system. You get to create a new accurate plugin and then you also go through core and find any plugins that were using the annotation and convert them to the attribute. So it does give you a really good branding on what this new change and what this new API sort of apply to. Perfect. Thank you. I'll stop the recording now.