 All right, well, thanks for coming today. We're doing a bit of a hallway hangout. We're going to just have a casual chat. And we've subtitled this one, Themer Goodies, which I love that. It's so much fun. There's some really cool stuff coming that will help users, but also potentially help workflows for Themers. Or a lot of it's already landed in Gutenberg. So super cool. But first, I think, Anne, you had an update about calls for testing and whatnot. Yeah, I wanted to show off, I was just trying to quietly paint up on my computer. I wanted to show off the current call for testing and just note it for you all. This is running, I think until February 1st. Yep, but it's kind of cool. It's going to go through some of the stuff that we're probably going to talk about today. So if you want to actually give feedback or play around with it, it's pretty awesome. And it also, I think sometimes people get nervous or don't realize that there's actually some instant test sites that you can create thanks to InstanceBP, which allows us to use this as private outreach program. Thank you to them. But yeah, you can just click this link and it'll launch a site that's set up for you to just walk through this test. So if that's been a barrier to entry for you, I always like to call that out. And yeah, these are some of the things that it goes through. We will not go through these now. I just wanted to mention the call for testing because it's a great way right before the 6.2 feature freeze on February 7th. This is a really high impact time to give feedback on these things because we are entering kind of the window before things get set for the release. I'll hand it back to you. All right, so a few of us put our heads together and collected some PRs that look pretty cool to talk about. So let's see, how do I want to do this? Maybe I'll share my screen and start from there. I'm probably gonna have to make my text bigger because this is on a giant display at like 4K. So there we go. So the first one is add pay styles to the block settings. So this is probably the one that I have, all of them that I know the least about. So does someone want to like explain what this is about and how it's gonna help themers? Maybe Justin? Yeah, you actually picked the only one I haven't read about yet. All right, maybe we'll pass it to Ann then. The very first one I'm reading about now. Yeah, I was about to say it's basically part of this wider suite of tools around sharing styles. So it basically just allows you to kind of have a way, in the same way we have like something where you can push the local changes to globally to the site. This is just kind of another neat way to copy and paste styles. So yeah, there's a paragraph. This is partially, I think if I'm not mistaken comes from some of what was done with the block, with the button block, where whenever you create a new button block it copied the styles over. It basically is allowing this to be more intentional. So let's say you're creating a heading and you really like the styles you put on that and you wanna apply it to a heading further down on the page. You could just use this to copy and paste. This is my understanding of the feature, but yeah, this video might be good to play just to show it off. Let me make sure that I've got my audio working correctly here because Zoom likes to make you work for your system audio. And then when I'm sharing my screen all of the controls get crazy. Eat that. I don't even know where they went. All right. We'll see what happens. We'll see if we, maybe there's no audio at all. It's just a screen capture. What to do about nothing. Okay. Okay. I actually got confused with the wording. So it's a lot more like apply styles. Like apply form, paste in apply formatting or something like that is I've seen that feature referred to that way or I don't know. Different tools do this and they all call it something different, but yeah, that's handy. I think that, I don't know. I'm thinking about what a themeer would do with this. Maybe not as much, but as far as user interface goes, I think this is a very helpful thing to have in the editor. I could see like using, like designing a complex like front page with similar like sections and like going through and let's say you want all your headers or all your groups on that front page or whatever, just with similar styles, you won't have to go back and input everything in the site editor or template editor. Just copy them over. I actually use that quite a lot. Like if you have multicolumns, like testimonials or these little like cards, I use that quite a lot to get that in patterns I'm building. So that looks handy. As somebody with mild tendonitis, like this saves a lot of clicking. Having to like- I could see that. Like if you do like complicated like typography settings from like all like everything and then you got to apply it to the next block. Yeah, so this is pretty cool. I also could see it as a precursor to before you want to apply something globally to the entire site. Like you're kind of just messing up the design and you're like, cool, yeah, paste that. Ooh, that was good. Okay, but I'm full with pushing it everywhere. Like I could see that also being something that's used. Yeah, patterns are a great example. That's a really great segue to this other one. I find it. I have all these tabs. Push, it's push local block styles to global block styles. So that's like an application of it. So it's not quite the same thing, but if you style your block in a post or in the editor to being able to say, oh, actually I want that to apply to this block all the time, being able to push those changes from there, I think is gonna, my first instinct is that it's going to remove some tension for site builders that might be doing this a lot. And then they go to their front, they go to like do it again later and they're like, but I already changed this, what happened? So being able to push that out to global styles and know that, oh, this isn't in a global style, it's just in this one block. I think that that distinction is helpful because that's been attention along the way that we have these interfaces that you don't always know exactly where that is being changed. So having those indicators of this is just in this block or this is global will be helpful, I think. Yeah, I like these features like this mostly because I think they lower the barrier for like non-developers to get into theme design just like a quality of life improvements you might call them. Yeah, I don't know that I would have to learn to code if we had all this stuff 15 years ago. Subtle but big impact. Yeah. Yeah. One of the things that this makes me think about though is that having used this a little bit, it becomes more obvious to me that right now there is no clear indication in either the list view or anywhere else in the editor of blocks where you have overwritten the global stalls because once you kind of experiment with some settings on a couple of blocks and then actually push one of them, that doesn't mean that it overrides or takes away those overrides that you have on all the other blocks. And right now similar to even in the screenshot you can see the published menu having that small blue or that small white dot indicating that there are some overrides or some unsafe things for the global stalls menu. Maybe there is something among those lines that could be added to the UI for blocks when they have stall overrides applied to them that aren't the global one. That is just coming to mind having used this a little bit that has not been reported in an issue or anywhere but it was just something that coming to mind playing with this. It actually brings up an interesting point because if you were to say a button, design a button, push it to global styles then you're on another button and you make some changes and push that to global styles. The original one because it has like the hard coded settings that you set won't change. So I think it's a cool feature. I think that the workflow, it's one of those things that is very powerful and making sure that the people that are using it know exactly what it's doing because if you don't know exactly what it's doing it can lead to some interesting situations which gets me to think like, I think that this workflow is fantastic. I'm always in a proponent of is there a way to turn it off in certain scenarios where having this functionality wouldn't be ideal for certain situations. I was scrolling through the PR and I'm not sure if that. I don't think there's a way to turn it off. I will open an issue right now to start that discussion if that's cool. Yeah. That is an interesting point. Yeah, having a supports and things Jason might be all that we need per block and interesting. I think it would be kind of interesting to see a comparison. I don't know like I have absolutely no idea how this would actually even flow but if you could compare like this is the set global settings and these are the block specific settings and somehow be able to see exactly which ones are what's coming from where, you know, we're so accustomed as at least me from the very beginning of my early web development days I was using Firebug back when Firefox was a thing and there were no inspector tools at that point. So that's kind of become standard at this point that we inspect the thing and figure out where all of the styles are coming from. At least that's what I do. And being able to see where our styles are coming from in the editor might be a really useful thing at some point in the future. But it seems like we're on a good path. At least the ideas are starting to come together and I imagine that we'll get some better implementations of them and expansion over time. And I think that this is a type of feature that's really, well, it's for everybody but I think it's really geared for people like building themes. Like I started to build themes in the editor. So kind of started with like a very stock based theme and then in the editor like set my styles like change layouts, do all the sorts of stuff. So I could see a workflow where you, a designer hops in the editor they build their themes, they experiment with global styles, push to global styles and then they use something like the create block theme plugin and just like export that and write that to the official themes, theme.json file. So definitely a lot of interesting applications of this. I have been actually doing just that as I will build, I'll work in the code a little bit. I've been live streaming this starter theme that I'm working on and it's slow when you live stream it once a week but that ability to push your local changes to the theme files I think is, you have to kind of trust that it's gonna do what it's supposed to do but it saves an awful lot of effort to not have to be going back and forth between the files and the editor all the time. Absolutely. All right. So any other comments about just noting that I open I just opened an issue. Also, I wanted to say that the phrasing is updated as of Gutenberg 15.0 which is released today. So it'll say apply globally instead of the push changes to global styles which is, I think that was just like a developer thing that was trying to get in place particularly we wanna call it styles and the interface. So now it's, I think just apply globally very simple. We got some nice editorial design out there but for now I opened an issue just around like being able to turn it off which I think tied in nicely with various like curating the editor experience stuff anyways. So feel free to chime in on that issue and it'll be included in the notes. Can I just, because of the wording, can I hop on just to, I recently switched to German language in the profile site editing and I was a bit shocked of the translation being used there. I was like, what is going on here? There were some translations that are just like from my perspective just completely wrong like someone didn't understand what they were translating and they're now in there. I was like, whoa, that's not a great. Yeah, so I think there should be like more documentation and feedback for translators too because there are like a lot of new things coming in and they literally don't know what they were doing like what these things are doing so they couldn't translate it properly. And yeah, it turned out like some, from my perspective, really huge mistakes were made there and now it's like hard turning back. They said like, what if someone like published a book already with these translations? So I think there has to be more and then I got feedback on Twitter like from Japanese community they said the same things happened. So I think there should be more documentation on what these things actually do. So there was an example that the appearance like font weight, font styles, italic and things like that were translated just to design because appearance in the menu like in the main menu is design in German and I was like, design that's just like wrong. It's like fun design. So it should be fun style. So it's like they can like, yeah, yeah, misunderstandings happened and I think it should be better documentation on. I just flagged some of that for the upcoming changes for training and docs teams for 6.2 and I'm gonna drop a note in polyglots just to get them on early heads up of like here some of the PRs are coming through like let's ask some questions because that's a good call out and I'd be happy to sit and I think most of us on here would be happy to sit and kind of give context and that stuff. Yeah, more context is needed I feel especially for like totally new concepts coming in and apply globally would, I mean, that's like I think it's easy to translate but it would be cool like for new concepts to be to be more explained. Did we have a glossary or did we at one point like a WordPress glossary just to cover like a lot of these terms? If not. There is, yeah, there's a glossary for the block header that has been updated for like the site or template parts styles like that kind of stuff. But like I think this granular decision making still is probably like someone would have to go into the docs like the user docs for that and kind of dig in and learn and probably use it themselves which is the same problem that the training team is running into the docs means running to get the marketing teams running into like this is all the same problem which is really tough to solve. And with this in particular, I'm not even sure whether it's an issue of not having the context somewhere in GitHub and all of that. I think that already exists. I think the issue with that in particular is that in PHP in the WordPress world there has been a lot of training over the years for everybody to have those really in-depth translator comments attached to any translatable string anywhere and at least from the limited inside I have into the good work code base. I don't think it happens as much and as deeply there and maybe that could be improved overall just having more of that context of what this concept is actually about in the translator comments because that is what you actually see when you try to translate something that is you don't see the poor request where the string was introduced you don't see all of the documentation about it you just see the string that needs to be translated and then the additional context that was provided in the translator comment. And so maybe I'm taking this conversation is just I wanna look at some of the translator comments in the code and see whether there even are any and kind of whether there is a larger issue with just adding the context in the code next to the strings where they're defined. Yeah, that's a good point. All right, so let's see. What else have we got that we can talk about here? Oh, I flagged up this custom CSS panel. So it's long been a request to be able to add custom CSS for block themes for full site editing in the site editor. So that's now available as a 14.8. Yeah, for theme authors, I think just supporting your users is like where this really comes in handy when you need to have a one-off block of CSS you need to add off. And the one issue I did see with it I don't know if it's changed or if it's been updated in 15.0 is I don't think there was a one-to-one match of like the options or whatever option was saved in the database with compared to the customizer. Yeah. That might be important like for themes that may be transitioning from classic to like a hybrid state to a full block or something. Users might wanna keep that same CSS they've added before. If I remember correctly, this has not been updated for 15.0 because I was just annoying Glenn about it who worked on this feature. And he actually updated the main issue which I'll drop. There's like a nice little list of tasks at the very end of the main part of this issue that goes through some of this stuff. And yeah, I think it's not yet been addressed but it's I think it's on the list because focus on this call give great feedback yourself included Justin around like some follow-up items. The red squiggly line in that box makes me really want there to be some kind of linting or auto-complete or something. But that's not really, I don't know if that's really necessary for this but the schemas have spoiled to me, I think. Yeah, I think that the big like from an adoption standpoint like if someone's taking a site that they had classic theme with using the customizer and they're moving to adopt a block theme like having that parity between the customizer, custom CSS pulled out, excuse me, pulled out automatically into this one I think would be great. Otherwise you might be losing some very specific important CSS that was added to the site. Yeah, sometimes I've seen a lot of times when I was building sites where or maintaining sites even more where the wall of CSS that would get put into that field and it would be for plugins, it would be for all kinds of things. So it's not only for the theme. Yeah, also the hot fixes that were put in there to fix random things. Oh yeah. A lot of which probably would not work well on the new theme anyway, but you have to stir it somewhere, right? Definitely. Yeah, I think it's great to, there've been many situations where I've had a client and I'm not around my dev environment or something and you know, you got emails as I need this fixed, you know, just log into their website, add a few lines of code and you know, then actually go back and fix it for real later, but just, yeah, quick fixes. I thought I saw a version of this where you could open up that box into something a little bigger. I know there's a drag handle, so you can make it taller, but that's always been a pain point for me is wrapped CSS is really hard to work with. Oh yeah. This little box is kind of, it's better than in the customizer already from what I can see in the screenshots, but I thought I saw one design or something where it opened up bigger. Maybe wrong about that. You could have like it open up in like a modal or something when you have full control. Especially when you get those sites that have tons and tons of custom CSS, it's really hard. I've always had to paste it out into a text editor so I could actually do something with it. Yeah, well, it's good stuff though. I think very, very frequently requested item. What do you guys think about? I think there was a conversation around per block, custom CSS. Yeah. I actually liked that idea better in the context of block theming. I mean, everything's a block. So having that selector and knowing that CSS only belongs to that block within the UI too. I do wonder how that would be managed. Like I might forget, I added something to the button block and it's overwriting some other setting or something. Yeah. I'd like to see how the experience of that works. But yeah, I think that would be great to have. Yeah, I worry about things being spread out so much across all of the different blocks I could get. And the other thing is if you put in this, I don't know how that it would actually work if it would only be applied to that selector, that that would be the way that it was output or if it would just be raw CSS. Because yeah, I could see you like, just start throwing CSS into a box and having it apply different places and no idea where it was. Yeah. That's my kind of concern. I feel like it might be a bit of a rather unintended consequences, but I'm not sure. I believe if I recall that particular issue correctly, the current thinking was that it should be kind of, it already has the selector auto populated and essentially works the same as the WP minus container and then a random number. So it literally only applies to that block and any descendants of that block. And I think especially in the world of block themes where there is no real semantic meaning to a group block, it could be literally anything on the side that is super powerful and I've been long. One of the things that I'm still looking for the most is at some point being able to change theme JSON properties on a template basis or on a template part basis to be able to have some more of that semantic of, hey, the post type archive for expose type should be red instead of green or something among those lines. And I think that is first. It's not the same thing, but it does give you some of the power because you can kind of on a larger level kind of scope it to only everything nested within that. So I think it is really cool how that is approached but yeah, it also can open a bunch of rabbit holes and a bunch of just things that may be messy to clean up. Yeah. For sure. For a feature parity to the customizer. Yeah, go ahead. Just to understand, so this would make it possible because I just had that yesterday. So like Nick said on a, so I could on a template just say, the header in this template will be the secondary background color instead of primary. Something like that. Because I run into that issue all the time. Like, okay, just on this template, I want my header a different color. How do I do that easily? It should be easy. Yeah, I think that it's a wish list item. It's not something that exists right now, but yes, that would be the main idea, I think is to be able to apply theme JSON settings and styles, more styles probably than settings to be at the template level or at the part level. Yeah, that would help a lot with actual building. And just the last month I've been like, because we relaunch our websites with block themes as like really digging more deeper than just theme building into what actually is needed. Like when you do it with your own site, I was like, okay, I need that. So I have like a long list now of, okay, we need, and that would be one of the things just. Yeah, one, like a funny example case of that, which could be settings to, well, I guess it's styles too, but it's specified and setting. If you have, let's say you have a font, like a website with two different fonts, like sans serif and serif, and you want serif fonts for like written text. But then that, if you apply that to like paragraph, it's gonna hit every paragraph. And so every time you put like a paragraph on a footer template part, you gotta like change it. And so like if you could, you know, scope that specifically to blog posts, you know, or something like that. So yeah, so often like magazines have that, like they have a heading like highlighted on their front page and then on the sub pages or like the single, like they have a different heading, like just the regular heading and not like the showcase front page heading. I've seen that a lot, that's the truth. Yeah. All right, we have a few more things. Oh, we'll see how far we get, but we're hoping to stop at 45 minutes today just to kind of respect everyone's time avoid getting too far into the trenches. So I'm gonna go ahead and move on to the next thing on the list, which is editing block style variations from global styles. This is another one that I don't have a lot of. Yeah. I can touch on this a bit or Justin, if you wanna jump in. Yeah, so essentially from what I understand, a theme or plugin, I guess, you could register a block style variations and those will be available to edits in the styles panel. Like if you click on a specific block and right now you can't create new block style variations. We have too many styles and variation like terms and by the way. So yeah, right now I guess a theme author could register a style and then a user could change it how they like. And I think this is also gonna run into, maybe it was Ellen asked the other day. I know a lot of people have asked about- Multiple. Multiple, yeah, multiple custom block style variations. So which we don't have, I don't think it's in the plan. Yeah, that's like, ah, why not? I don't think it's going anywhere, I think. I have reasons for not wanting it and then reasons for wanting it depending on the use case of an individual style. But yeah, this would be neat. I wanna see it get to the point where we can create style variations or block style variations from the UI and maybe even share them with other people. Yeah, that would be cool. This would be a new place. I think it depends hugely on how you interpret or use style variations like, is it like, I think depending also probably on the theme, is it more like a flexible like building theme where you can apply different styles or is it like a set theme where like everything is done for you? So I think that's a little bit of a thing that there's like a room for interpretation on like what style variations actually are how they use. So I was thinking of a more of a, like being components and I could apply multiple components on them. Like for instance, just, and then I was thinking maybe it's just a temporary issue because I was thinking about like animations for instance, for a block like or like a button having them the option to like CSS animation, wiggle or scale and do like both things together, stuff like that. But maybe it will be solved with having just settings for CSS animations, which would be even cooler to have like with shadows coming now in, we could add animations that just as a setting that would be amazing to have. So we maybe don't even need that. It was more like a workaround maybe from my thinking. You know, would style variations for me, at least like, I like to do the more complex things that it's not possible in the editor. Like I have like this, I wrote a tutorial a while back about like creating this like Polaroid, you know, design would like Scotch tape hanging it from the wall kind of design for images. And like, I couldn't see like applying multiple styles to that, you know, I think it would break it. So anything that's possible in the editor, I mostly don't use style variations for that. Just use the design tools. We got like things like animation and just more complex designs. It's not possible on the editor. I think block styles haven't been like really explored enough. True, feel the same. They're pretty powerful and like easy to use. And then from the design, I wish they wouldn't like be so like put into these two column boxes. I was like, oh, why don't we just have like a flex box and have them flexible in with because it's very annoying to find a name that fits into this little box. Yeah. Also for translations, I think it's just like, why is it? But that's another issue. I have a quick question. I'm just catching up on this reading through it quickly. This is still just applying these styles as a CSS class, right? It's not actually updating the attributes on the floor. Is that right? Okay. I believe at least the multiple global cells, the conversation that we had just now, this actual ticket, I'm not sure about that, but the discussion that we just had with multiple style variations, those style variations on blocks are still just class names. Yeah, that's what I thought, yeah. Because I think this is kind of interesting because my problem with block styles has always been if it's just like CSS class, right? And so to Justin's point, I've used them for like complicated things that you can't just simply do in the editor. But if you are applying things that are in the editor, color or whatever, in which it seems like here you're setting color, you're setting settings that you can also edit in the editor. The interplay here, I think it's kind of interesting. I'll need to play with this before I can speak knowledgeably about it. Yeah, I think I'm almost like talking myself into like during this conversation in my mind, I'm like, I don't know how useful this is now, or at least for my use cases that I have in mind. I would love it if it updated the attributes if you had like a predefined like colored border padding, whatever, and you clicked it and it just populated those attributes on the block. That'd be cool. Almost like a styles only pattern. Right, right. Inna could have extra stuff. You could still have the class and do things that are beyond. But I just, I don't like when personally when styles are being applied via a class that also can be applied in the editor by a user. Like there's some like dissonance there in my mind, but. Yeah, in 95% the cases where somebody tells me, hey, I want to create style variation for that. These days, the answer that I try and go with is instead of that creating an actual block variation because that allows you to actually change the attributes and the only issue is up until recently, we had no clear kind of the style, the block styles API, they have such a prominent nice easy to use place in the UI. They were even bigger than the art now in kind of since two versions or so, but they were so nice and visual and kind of just pleasant to use as a user who doesn't want to go into all the nitty gritty details and just click something and it applies. But with the variations, you can kind of, you can't do more than just one, you kind of, those are presets, but you then can adjust them and you can combine settings. It is a little more difficult to do that. And I think it could be easier to add some of those things and for needing to add custom class names, there still is room for improvement, but a lot of the use cases that I run into where block styles previously were kind of are the first thought block variations oftentimes ended up being the better solution. Yeah, I love block variations, it's so powerful. And I think you can kind of do that already, like you can put a transform in and say, well, transform it to this variation, which would kind of to your point, apply those attributes to what's already been added. With the group block, for example, we now have a really cool UI. The group block has this special UI to switch between the different variations of the row or the stack or those kinds of things. And that is just as visual, like the kind of styles that you could apply. It still isn't really possible to, or it is, but it's much harder to do that for kind of your own transforms. You have that dropdown break and switch between different variations, but it's not as visual and not as present in the UI as those style, as those block styles are. And block styles also are the easiest way for a developer to just quickly add something that takes two lines of code. You add a custom class and then you are in your old, familiar way of working of just adding CSS to it. So I think that is why it is prominent in the UI and it's super easy to add. And that is why I feel like sometimes it just gets overused because it's so simple and so nice to, so present. But with those transforms, that is super cool for variations. Nice. All right, we have three more. I'm going to try to move us along here. This title is not very good, but the basic just is that you can set blocks to be static and sticky position, which I think is going to be really cool for theme designers because being able to have a sticky header or a sticky sidebar or a sticky menu are pretty big requests from clients. So if we have a native way to do that, I think that's potentially going to solve a lot of pain for the folks that are trying to figure out how little custom CSS they can get away with. Yeah, I think also coupling this with like template locking would be a huge, so your client can't break the website. Do it with patterns. I think it'd be neat to have a pattern where you just like, yeah, you want to set the header, you can add it in. I will say right now there's some follow-up tasks that need to be done because currently, if you want to have like a sticky header, I will include this in the current call for testing, but had to pull it out because it was UX, it was just wonky. So there's some follow-up tasks there, but essentially you have to wrap it, like wrap it to the part in a group and then apply, have a group be sticky and that just makes no sense. So there was some follow-up work to refine that. I think in, not for 15.0, but for probably the next release and I'll drop a link to that issue if anyone wants to offer feedback there. And I'm glad that kind of came up because that has kind of long been an issue with Temple Parts for various things. And because of the sticky, it's putting more emphasis on it. So hopefully we can come up with a good solution there. Yeah, I thought it was broken. I straight up was like, oh, this feature's not working. I'm not going to include it. I don't understand. I can send a video and they're like, no, that's working as intended. And I was like, okay, well, that's busted. Like we can't unless we're solely relying on patterns to do this, which even then that feels very strange. When in doubt, wrapping a group. Very cool. All right, moving on global styles. Oh, this is a style book. So in a testing built right in two hour interface is pretty amazing. I think, you know, I think initial design, you're probably still going to be adding demo content and any in a testing content. But as far as like getting a quick idea of how a specific block is going to look in your theme or with a variation, I think it's going to be really helpful. So has anybody had a chance to play with this yet? I found it great. And it pulls in third party blocks, which is awesome. So there's a one minute video here. Let's see, sometimes these initial videos are not the most up to date, but... I really think it's cool. There are a couple of bugs with some of the style variations in 2023. The gradients, it causes some weird border control stuff that is being worked on, but otherwise it works really nicely. We've gotten some amazing feedback from just the outreach program in general of people being really excited about and it just solves kind of a couple of different problems. One is like, how do you know the changes you're making are happening everywhere? Like I think this communicates it really well. And then tied to that, it just allows you to see the changes you're making to blocks that may not be on the current template you're looking at. And I think eventually when this styles interface gets moved into the other sidebar or even communicate that better. So I'm very excited about this and this combined with the live previews when you're editing individual blocks, it's going to be huge. Yep, I agree. All right. Anyone know if anything else to add about that before we have one more issue and we were kind of at time. So we want to move on to this last one. Oh, importing widgets from the sidebars as we move away from sidebars and widget areas. Is it actually importing widgets or they're importing blocks? I know they're called widgets still, I think in the UI. I think it's mostly importing blocks. I'm assuming the legacy widget block works with it. But it actually does not. I actually have an issue for that last week. I was writing the next call for testing. Okay, so yeah, like it actually doesn't import widgets at all then. Yeah, the widget group block actually, sorry. But yeah, this is something that I think Mamadouka actually did a lot of work here and this is also part of the current call for testing because I think we need to find those common use cases and make sure it works with that or if it doesn't, I'm going to be really clear about it, how much of the gap it actually covers. You also do have to go through an import process. Like it doesn't automatically pull them in. So you have to know to like add a template part, you have to start new and then from there, you'll see the option to import in the sidebar. So it's a, they're steps and it's helpful but I definitely think more improvements can happen here. Well, that's George for working on this. This is a cheeky one. So hard, yeah, this is so hard. If you figure that probably like 80% or more of sidebars are still using legacy widgets. It's like, in all sorts of custom functionality and custom widgets and, you know. I kind of wonder how many people have, yeah, like there's like the custom PHP widget. Like that's just all like custom code or. Yeah, I ripped that plugin out any time I have a chance to work on someone's site. Any other database based PHP storage as well. Yeah, all right. Well, that was our last issue. So we can wrap up for today or if anyone else has anything else to share. So I think a lot of really great stuff that's moving in a good direction overall. It's definitely a marathon. I would have one like very unrelated question and I know it's like timing is out, but I just want to throw it in like, I've been thinking so much about we have templates, we have patterns, but I feel like more and more like we, we have like people started using page patterns, which feels just it's wrong, like, but there's no in between like the template is different. So like all the other like page builders and stuff, they promote page pages, like page templates and other like tools promote that. And it's like super cool to see for users, but in with the block editing, and I think we are missing something like that. Like page layouts because users, I think with just patterns, they're still like, they're still like, how does this work together? They're like, it's not enough. Like how do, where do we put that? Like especially for themes or like for someone who want to promote the like ready to use page layouts, where do I put it? How can I like promote it? You can tie the pattern to, is it the post content block maybe? Like in the block types, register when you register it. And like when some user adds a new page, like it'll pop up the pattern inserter and it'll show the templates you have, not templates patterns you have assigned for that page. Just for that page? Well, for building pages out. And there's also template types and link to in the chat. Yeah, I want to follow up with you on the DN conversations, it's like a great point. Yeah, Justin, sorry, that's exactly what I was about to say. Thank you. Yeah, I'd actually like to discuss like what we have now, like with you, Ellen, sometime like, I think that might, may work. But yeah, template types for patterns that is upcoming, we don't have a UI for that yet. I think that's a signing on the template level, right? And rather than on a page level. Okay, yeah, I will check that out more. I just like it should be so easy to just have like page examples and then like they can drop it in like bum, bum, bum. And then with like pages, like patterns, like multiple patterns in the patterns library is like cut off the previous cutoff. It's not like they can't really preview it. And I think that like something like that should be like the most easier thing, which I think still missing at the moment. Can I share, can I, I mean, while we have just a minute, can I just share my screen? To see if this is kind of what we're after. See, all right, so like, are you wanting to do, like go to add new page and then like there's a pattern that pops up. It would be cool if this, if I think more general, like so just have, for instance, a set of like five or 10, about page designs ready to go and then users can just choose like out of the 10, probably, so like patterns, but like bigger patterns. Do you mean including like things like headers and flutters and stuff like the components that are like site-wide like a template? Yeah, no, that's my, I don't think that should be included, but it would be cool to have it maybe in the preview. Maybe have the preview showing what like the general template you're going onto has as header and footer, but I think just like, yeah, 10, about pages, 10 landing page examples, contact pages, like maybe 10 is too much, but just like half this, like, because I just have this, just from my user experience, people have a problem, like hesitant to stack their patterns onto themselves. They're like, oh, this is design. I'm not touching that. I want a ready to go page layout. Then I feel comfortable to add my content. So just give them like more ready to use. Of course we can do that with like page patterns, but it just feels like wrong too. We've explored like, if you have like a page pattern, right, that's composed of like a bunch of individual patterns, those like a call to action, feature boxes or whatever, those can all be individual patterns as like component parts, but then they can be served in like a couple of different about pages, a couple of different landing pages. Yeah, we do that. And you also create page patterns for these. And then anything that's like a composition of individual component parts is served as a page pattern. So when they get that modal, it's not all the patterns, it's just the ones that are designated as like full page pattern. So I think that that modal could be improved. So you could imagine like a full pattern layout that said like about page, landing page, contact page, and you could like register a bunch of them in each category in a person. I want to contact page, click that and they see like five and they click one. Yeah, that's what I, that's what I mean. And then I kept the preview actually show the entire layout instead of having it cut off. So yeah, it works. We can do that. It's just like not visually working at the moment. There's also, I do want to bring in some of the conversations in the chat. There's conversations around like being able to shuffle through patterns and having it be more of like a building experience where maybe you went in the template and there's like the zoomed out view where you're able to see kind of like the different sections of your site. And I think for users, that'd be much easier. Like there's designs where you're literally clicking like a randomized button or you can flip through and see it so that you're not having to do that like stacking thing, but it's a bit more like modular in that way. And all of these designs are being solely worked on. I don't anticipate them at all for 6.2, especially that shuffling thing because that's wickedly blocked. There's a lot of issues for the phase two, dropping at phase two stuff that's been repeatedly blocked, but there's some neat stuff around like using that zoomed out view and having a way particularly with templates to start where you can kind of shuffle through different options. And if for it to feel less like I added a pattern now, if I want to get rid of it, I have to fully delete it and I have to select the parent block and then delete it from there. And like, oh, I thought I deleted it, but there's still a group block floating around in here. Like there is some like really painful experiences that need to be improved for sure. But yeah, that to me is like the foundation set right now. We have all the pieces. It's like, we just got to make it happen. Make it easier to like put them. Because I like, even like with blocks, I was like, blocks are so cool, but users are like, oh, that's too complicated. Like, I'm not going to like mess with blocks, like settings and stuff. And the same, even with patterns, like, like, oh my God. Okay, I have patterns, but how should that be a page? Like, no, no, I'm not a designer. I'm not doing that. So I want to give them examples. For like page patterns is a solution, but it's just like not visually showing up for them ready to. Yeah. And like Nick said, it would be cool to have like, okay, about pages and like have the, have it like more filterable. I think that's just like the easiest thing just missing at the moment to make it easier for, for users to get excited about having a block theme. Yeah. I think there's some design work on that modal, that page pattern modal could go a long way. Cause like Dan said, we have all the pieces. It's just presenting them in a bit more. And that's just the presentation. Yeah. Yeah, yeah. Or even a way to have a modal pop up after you create a new page, like one of the things I found really annoying is like, I was testing that and I was like, oh my God, go away. I don't want this referee. Yeah. It's like so annoying, but like to be able to invoke it, I think would be also me, obviously like you just inserting patterns from the inserter, but like, I think there's like a mode in which a user is thinking that they may not occur to them and like, but this ties into like pattern discoverability as well. Yeah. This is all cool stuff. Could I throw in a quick thought, quick question before you go. Yes, please. Sorry. Yeah. So my quick thought was, thank you to everyone. I've been following from afar for years. I appreciate all you do and all this work. So trying to get more involved and see how it goes. The quick question is how much view is put on to the dot com side as far as what they're doing. Meaning so like if you, if you pull up to your work, if you grab a WordPress app, sign up for a site, click create new site. The very first thing they do is give you those page articles. The link in bio page. Like that's, that's exactly the interface that you see. And that's what's used. So I'm just curious, like how much view is put on the work they're doing. If it any. What do you mean by view? Like, are we sharing designs or sharing insights? Like what do you, can you unpack? My brain is stuck. Yeah. Sorry. Yeah. Yeah. How much. A lot of the interface and a lot of the discussions I see in the dot org side seem to have been not solved, but. Yeah, like exactly like we were just talking right there with the page. Like if you pull up a dot com site and start a new one. Even though it's using the, you know, the backend is all exactly the same. It's actually a little more limiting because you're on the dot com site, but anyways, but that's what they give you the option for, you know, because everyone, you know, everyone on so, you know, the. Yeah. So I mean, I can tell you what's being built in core right now. And I want to give full disclosure for anyone on this call. I just know I work for automatic and part of my job is actually to help the company automatic adopt these things as well as the community. So I'm looking across both ecosystems, trying to see where the problems are. So what's being built in core is inherently more open ended whereas what you're seeing or fist.com is like a specific onboarding flow. And part of what has to be done is allow theme authors to do all kinds of path finding things while at the same time keeping the system open so that like someone on the enterprise side or agency side can also like hack it together and do what they want to do. So what you're describing is like, oh, this is solved. It's solved for a specific use case like Lincoln bio and newsletter stuff. Like all these are very specific use cases, but what you're seeing is application of what has been built in core. So you're seeing what that curated editor experience being done on where fist.com, which you'll see another host as well. It's not just unique for fist.com. Bluehost has some stuff there. But yeah, it's kind of working by design. So what you're describing is like, well, they've solved it. Yeah, but core can't solely just take that perspective and run with it. It has to remain open and it has to think about all the use cases and all the ways it's being applied. But at the same time, there are definitely always insights being pulled from everyone from like work is to calm giant, you know, that side would like, Hey, like recently jetpack, for example, was like, Hey, the default pattern selector of when you're opening up the query loop lock and you're seeing that big preview versus the grid option. Can we set that? Can we have control over what's the default? Because this is like really not cool when it just opens up this huge thing. And so that's like kind of the feedback that can be brought in is kind of those like settings and options to turn things on and off or change that versus like, we're going to build this specific path into core because that's just, we can't be that specific or nuanced. That's for building things so people can be specific and nuanced. Does that make sense? I know it's kind of like vague, but no, no. I make, yeah, that makes a ton of sense. And I, yeah, and I backtrack and apologize a little. Like, yeah, I didn't mean to intonate that. It was all, I just meant, I was just wondering, you like as far as us, you know, like you in Slack, like, do you look at that and then go, here's something that they did or is that just, is it kind of, like in keeping the separation, like even though, like we know that's there, but we kind of pretend it's not. So we're not muddling. Oregon calm. I think it's actually very much you'll see folks from WordPress.com who are working on this.com in GitHub regularly. We have a couple of teams who like live in between on the automatic side. So yeah, we definitely share stuff there and we need it from like all aspects from like, you know, Nick is from WP engine. It's like, yeah, tell us what you're seeing with agency folks. What are they wanting? What do they need? So yeah, there's definitely like some. Perfect. Yeah. And like from time to time, actually I'll try and everyone's wants someone to be like, because we're just calm having insights on this. Like how often does the replace flow use for simple parts can be full data for this.com. You know, so those discussions definitely happen. And get hub honestly, like out in the open. So it's, it's helpful. I wish I could pull up some quick examples, but yeah, that's definitely for sure happening. I think optional is the important word here too. Like some of the things like we don't want to force like there are so many different user cases for WordPress org. So I think optional it would be cool. We just like even harder probably to, to do like give options instead of like just, okay, we're going to do that. But that is, I think though, that is important to consider like there's like a wide use, use a case on that. So it's so tricky because I know for me, I'm like, yeah, we, I mean, like a theory, we could fix this, but like core has to be like, Oh no. Exactly. Yeah. So anything you do there's kind of a balance there. Yeah. It's very hard to find this balance. Yeah. Thank you. Thank you for your thoughts. And again, for what everyone here does, it's just, yeah, that was, I guess more of a, like a WordPress key question, like someone from the outside, you know, just like someone who just. So I love it. Appreciate it. All right. Well, thanks to everybody for coming today and really great conversation. Love this. Get a recap post up and published soon. I did not take notes while we were in the call, but I'm going to go back through the recording and, and pull it all out. So, um, yeah, thanks. Thanks again. And great, great conversations. Steven. Thanks everyone.