 I'm Kevin Killingsworth. I work with Automatic, specifically the WooCommerce team, and if you want to contact me, I'm CoderKevin pretty much everywhere, on Twitter, on GitHub, CoderKevin.com. That's enough about me. Let's talk about customization. Everybody here, a lot of people here, have heard about Gutenberg. You probably know that it is coming. We're targeting the WordPress team as targeting 5.0 for Gutenberg to be released into core. So far, I haven't seen any wailing and gnashing of teeth in here yet. This has been a controversial thing. Just like any big change in WordPress, there's always controversy and some fear, that sort of thing, and there are some things to think about, some things to look at, but I think there are a lot of benefits as well. Right now, in WordPress, if you want to customize your site, I'm guessing a lot of people here have some experience at different levels of customizing your WordPress site. So what do you have available to you right now? The first two easy ones are themes and plugins. Oops, that is not what I intended. There we go. There are themes and plugins. Those are easy. I'm going to pick a theme. This looks nice. I'll install that. Then there's the customization of those themes. There are plugins for things when you need more data and more features and stuff like that, and that's great too. I think I was just talking to somebody else. It seems like so many themes these days come with a bevy of plugins that they require and all of that stuff, too. So I guess there's that. But if you want to get any more down into the customization stuff, it's not long before you're down in this area. How much can you actually customize a site without knowing a bit of CSS? Yeah, not much. Yeah. So you get forced into that CSS stuff pretty quick. Has anybody experienced any fear of CSS? Like, oh my gosh, what do I do with the CSS stuff? I know I have, and I'm a developer. Yeah, definitely. It can be pretty scary, and then you tweak with it, and then scrolling. This thing pops out there and all the other stuff. So anyways, HTML and CSS. CSS is probably one of the first things that you'll end up touching in the customizer or elsewhere before you know it. You're writing a child theme and, you know, oh boy, right? Then you get down to the actual meat of the code and you're messing around with PHP and JavaScript itself. I mean, almost all, I mean, so many plugins out there do both, right? They have to have PHP and JavaScript because you have to have something for validation or, you know, maybe the more advanced ones are actually doing some API calls on there to speed up the interface, stuff like that. So this is a lot to keep track of. But some of this, actually, we can look at solving with Gutenberg. In fact, some of these reasons for this customization are the very reasons why Gutenberg has come into existence. Because it is really difficult to move stuff around where you want it and make it look the way you want it to without knowing CSS, right? That's one of the main focuses, one of the first ones. So right now, Gutenberg, the new editor, is actually available as a feature plugin. If you go on WordPress.org or just, you know, go to your plugins and add one, you can install the Gutenberg feature plugin and it will replace your editor with the Gutenberg editor. It actually does have a little extra link. You can go back to the classic editor if you want to and use that even on just while you're editing something. But even just downloading this and installing it and trying it out would definitely help out the people who are working on Gutenberg. If you run in any problems, WordPress.org forums or your friend, you know, let people know. Because, I mean, the WordPress team is looking at putting this in in 5.0. And so it's probably good to try it out, not on a production site, you know, try it out on something else and, you know, give it a try and see what happens. So there's still some growing pains that we're working through. But by and large, it's getting pretty exciting here. So as I mentioned, in 5.0, and there is currently a classic editor plugin for those who either have problems with the Gutenberg editor when it comes in in 5.0 or if you just don't want it, you can go back to the classic editor with that plugin. So let's get back to the actual editor and talk about that a little bit more. So use a quick little screenshot. So this is actually what the Gutenberg editor looks like. So when you edit a post, it is something very similar to this. So it looks a little bit different than the current editor, right? And so you've got your document. So if you can't see it here, but if you can click on that where it says document next to block, that actually gives you your familiar controls of publishing and making it private and, you know, that sort of stuff, you know, publicizing and all that. And but you've got a little tab here for the block. And so for each block, it actually comes up with a list of options that you can choose on here. So right there, you can actually choose not only can you choose the justification and all that sort of stuff on a paragraph, but you can choose the background color and the font and the font color and all of that sort of thing there as well. So it gives you a lot more options on these, but these controls are not right in your face all the time. In fact, if you click away from that paragraph block, the little things above it go away. The block thing on the right goes away. And so it kind of gets out of your way as you're typing and you're editing. So you hear, I think you probably heard me say block at least five to ten times already. And that's because, I mean, that is the basic part of, that's the most basic common part of Gutenberg is the Gutenberg blocks. There is currently an API to develop your own blocks so you can make them do whatever you want. We've got some different options I'll mention here in a minute about what you can do, but the most basic ones you can see here. So you've got your heading and your paragraph in your list. You can see there's one here, there's for ninja forms, gallery, other stuff like that. So when you, when you, you can make a plug-in that will install blocks that will be available in the editor for anyone. So let's try this out. So there's a really cool site here. So this is actually on the front end. Tom Norwell put this together and hacked it together. In fact, I'm not even exactly sure how he made it happen, but this is actually the front end of a WordPress site. But he got the editor here. And so you can see as I mouse over, I can see different parts, different blocks here. And I can just go ahead and edit, right? I can just type it in. Here's that link. I can add a new block here. I can also move blocks up and down. So I can put this up here. So we've got some different options here. If you look here, so this is expanding, but I can put it on the right side or left. And so this is just an example. These are all of the basic, the most basic blocks here. And the, and these will come with WordPress core, all of the basics. But the really exciting part is what blocks can, can the rest of us add? What can we all do with this? Right? Are we gonna have a Yoast block? Are we gonna have advanced custom fields block? Right? I can tell you they're already working on these as of right now. You know, WooCommerce block, right? You know, so one of the biggest things, one of the first things that we did is in WooCommerce, we have a product block. And so in here, if I want to go here, I can actually hit this plus button and I could type, you know, product. And I can actually find that block here and insert it. And I could select the product that I want. And then on that page, I'll actually show that product with a buy button or an add to cart button right there. So yeah, you can put things in columns, separators, all that stuff. Yes. Yes. That's exactly the way that would happen. Yeah. So WooCommerce, as a plugin, when it, when you install it and it activates, it will actually add hooks to install the, you know, the blocks that it has. Yeah. Yeah. So short codes. That's a, that's a direct analog between what we're trying to do here. Yeah, definitely. All right. So what's first on the list or first on the hit list, I guess, you know, what sort of things are we going to attack here? And it's actually really interesting, the WooCommerce one, because I haven't been working with the WooCommerce team, but it's really interesting what they've been doing because I've been following them. So short codes. So right now in WooCommerce, you can make a short code for a product, right? And it even has like a little short code builder thing, right? You know, which is pretty cool on some of those, they got little short code builders. Do you know what they did with the, so they actually made a Gutenberg block for this? And they basically made the Gutenberg block be the short code builder. So they just like switched it out and the short, and the Gutenberg block is now, it actually generates the short code. Now eventually, after Gutenberg is in core, they may change that and to where it's no longer a short code per se, it might be something different. But this is a way that the WooCommerce is gaining compatibility, backward compatibility, because it's still just the short code, the same short code that it's always been. So this is, this is something that if you have a plug-in that you have your own short code, this is something you can do right now. And whatever you're using for a short code builder, or even if you don't have one at all and you're just having people type it in, you can make a Gutenberg block that will output that short code. And that's already one step in the right direction. And the really cool part is, later on after Gutenberg is in core, you won't need that short code anymore. You could actually no longer generate the short code and you could just generate something else instead. And the block could be the same. Yes. So I don't have any experience of the visual composer plug-in, but the question was, how does Gutenberg compare with the visual composer? But I'm guessing it's a sort of page builder, rearrangeer sort of thing. I do know, from what I've seen and heard of podcasts and things, for instance, I think Beaver Builder is actually working with Gutenberg. They're integrating their stuff into Gutenberg. And so I would expect it's probably similar to that. I'm not sure where the overlap, I'm sure that there is some overlap between what Gutenberg does and what that does. But I'm guessing that there's enough unique functionality that they still do. And so maybe part of that they could use Gutenberg to take over some of the more basic stuff and then handle the rest. Yeah. So the question was, how do we deal with new projects that may want to use Gutenberg or the existing page builder? I would say talk to your page builder or look at some information, see if they've already posted something about them working with Gutenberg, because I know, like I said, Beaver Builder, they have. They've been very vocal, they've been very involved. And so check with them and say, Hey, what's your Gutenberg strategy? What should I do with that? I think that would probably be the best way forward. Yeah, yeah. A lot of that stuff should be compatible. But again, I would definitely test it. Gutenberg has been made with compatibility in mind as much as possible. But we do have a lot of legacy to deal with. And sometimes things are handled in ways that are not expected, right? And it's really difficult to sort of get a lasso around them and pull them all in. So, you know, if they're doing some stuff that's that's a little bit more out there, it can be really difficult to support. But yeah, I definitely if you depend heavily on, especially anything like a page builder or a theme that heavily modifies the content of your posts or you know, or anything like that or, you know, or plugins, you know, check and see what their what their Gutenberg strategy is, because I can tell you all of the major ones out there have been either they've come up with a strategy or they're working on it right now. We have another question. So, so yeah, short codes are the easiest one, I think that one's kind of the gimme. But then also meta boxes. Now, there has been some work in Gutenberg to actually render existing meta boxes. And it's I'll be honest, it's a little bit messy, but it's it's a little bit, it's a workaround, right? But a lot of what we have in meta boxes can be done with Gutenberg. Also, yes. So, meta boxes are, it's probably one of the easiest ways to add additional functionality to a certain post type. If you've seen like a little box on the right side of something of your editor, that has something different there. That's that's usually a meta box. Yeah. So then other than that is theme content. And actually, I have a good example for this. So I was doing some testing. Actually, this is one on at automatic, everybody in the company goes on a one week support rotation. And so this is when I was doing support for our customers for WooCommerce customers. And somebody had an issue with the store front theme, they wanted to so if the store front theme is the recommended theme for a WooCommerce site. But it also creates sort of a homepage with like a bunch of sections on the front of, you know, hey, these are new products, these are best selling products, etc. And they wanted to customize that part. And I hadn't done a lot with this plugin or with this theme, but I looked at it, you know, and I saw on the main index page, and I was like, okay, so I go to the index page, edit blank, right? And then I go to the customizer and I look around and the theme customizer, I don't see a single option for any of this stuff for these sections in there. Like, Oh, my gosh, this thing is like hard coded in there. And there's no way for me to get rid of it. Right. And so I actually told us, I replied back on on the support ticket. And I said, I'm sorry, I can't find a way to do this without, you know, doing some CSS to hide it or, you know, do whatever. And they weren't ready for that. And then one of my co workers said, Oh, you just install this other plugin, and then that gets rid of your and like, come on, you got to be kidding me, you can install a plugin to suppress another theme and it starts getting really messy. But imagine this. So what the storefront theme could be with Gutenberg is there's a concept called templates, and you can actually make a template for any page or any post type or something like that. And so imagine if you installed the storefront theme, and instead of hard coding these sections in that front page, if each section was a Gutenberg block, right, you know, this is your new purchases block, and maybe you have some little options on the right side and hey, display three items or five items or you know, whatever, right. And then that in the other sections are put in as Gutenberg blocks in a template for your index page, right. And so now you install that theme, it installs that template and it shows up on your page. And now if you go to edit your index pages, not blank anymore, you actually see those blocks, you can change them, change the order of them, move them around, delete them if you want. And if you want to put them back in, they're still there in the list of blocks, you can add them back in or you can put them on another page. So you know, these are the sorts of things that I'm talking about. These are the things that actually get me really excited about something like this because it's super frustrating to me when I install a theme, especially themes. And now I have this content and layout on my page that I have no control over whatsoever. It's really frustrating to me. And so this, I think Gutenberg has the possibility to bring that control back to the user, to the admin of that site in this way. So any questions or comments? Excited elation? All right. So yeah, the same thing with any other magic PHP, you know, that comes from plugins or themes or whatever. It's the same sort of thing. But yeah, the page templates are what we just talked about. So but if you, some of you may may already be thinking, okay, so where's this going? Right? Because this is just all the editor. Where else are we going to take this? How far are we going to take it? And you know, some of this stuff gets pretty interesting because you can implement custom plugin behavior in these blocks, right? And you can have it work together. The bottom item there I've got is a trading post meta for API calls. So for a lot of these things, so these do use front end code on the site. You're using JavaScript and it actually uses React on the back end, but we have our own API on top of it. And you can get data through API calls very easily, extremely easily on your Gutenberg controls and components. And where this gets really interesting is we can start to shift some of our code. Now, this is a little bit more technical here, but we can start dealing with our data through the API more so than directly through post meta calls on the server. And where this gets really interesting and really really exciting for me is number one, if you ever wanted to write a mobile app, you've already got an API for it, right? And you're using the data for that. If you wanted to change how you implement that API, you can do that now without breaking your meta boxes and your other stuff, right? You know, because these post meta meta boxes depend on post meta, you know, and they depend on the database structures in there most of the time. And, you know, you can decouple that. In WooCommerce, this is something that we've had to really work on. And this is a little bit more of an advanced example, so I'll keep it short. But in WooCommerce, we have situations, we have customers that are pulling in, you know, we have people who are using WooCommerce and they're taking in 50,000 orders a year, which is, you know, you got to store 50,000 orders in a year. It's not, it's in the realm of possibility. That's not unreasonable. But if you think about it, depending on what extensions for WooCommerce you have installed, I thought you could have up to about 20 post meta fields on each order. I've been told 50 post meta fields. Now, this is the technical part. Each one of those post meta fields is a row in a database. So if you have 50 times one order, that times 50,000, that is how many rows in that post meta table you have, and that's just for orders. And that really starts to slow down your performance on your, on your, on your site, on your database, on page loads and everything else, right? And so being able to decouple how you get that data and how it's stored becomes very important. And then we've taken steps, you know, through CRUD objects and stuff in WooCommerce, but where that ties back to this is the more you can use API calls for your data, the more options you have like this. So someday in the future, if you're hitting hard performance problems, you can change how that API endpoint is implemented and not call post meta, call something else, right? And that's okay, as long as you don't have other things depending on that post meta to be there, right? So that's, that's all for the technical stuff right now. And let's see. So a template editing and this goes to like theme editing and stuff. So the next target for Gutenberg is going to be the customizer. If you've been hearing about it, if you've been listening in, you probably heard some mentions of the customizer and that's the next spot in the next part. And that that can be really interesting because it'll allow exactly these sorts of things that I was just talking about, you know, with the with the storefront and the sections and all of that sort of thing, you know, so much of this can be using Gutenberg blocks in the customizer and you can be setting up those templates in that customizer. Yes. So the question I'm repeating for the camera here. So the question was, what about all of the CSS and that's generated from these Gutenberg blocks and how does that fit into the theme and the customizer? And so one thing that helps is each Gutenberg block or each thing that you write, it has two different operations for visibility. One is the edit function and then one is the save function, right? And so for the simplest example, we'll use like an anchor link, like a just a link on your page, right? So the anchor link, the edit might render a like a react text box thing that you can type into, right? And it might actually have some validation to make sure that it's a valid URL and stuff like that. And then it has a little button, right, you know, to hit save and then, you know, it's there. However, the save function of it is actually what is generated and saved to your post. And so the save would actually output an a href tag just like normal, right? And so as far as like a lot of these Gutenberg blocks, they actually have like an extra little class definition thing on that, on that on the far right, I don't think you can see it on an example that I showed. Let's see. So if I go here, yeah, I don't know if you can see this additional CSS class. And so if you did, if you were laying this stuff out and you wanted to do something special here, you could add the CSS class. However, when this renders, if it's a custom Gutenberg block, it's probably already putting out a CSS class for that type of block output. And then so that will play nicely with the theme or, you know, with whatever else manipulates that CSS class. There are some columns. It's kind of at the component level, though, because what I can do is I can add, I can actually add a text columns. Here we go. Right. And so I can actually, right. So and so this block itself will have. So most likely if you wanted to do something like this on your own, what you would do is your plug in would have some partnering CSS that it would in queue along with your Gutenberg block. Right. And so your Gutenberg block would define the class for this. And then your CSS would do whatever, whatever layout stuff you want to do to make those columns. Yeah, that's a good question. I mean, I think for each block, what it cares about is just its own block stuff. Right. And so any CSS that you write for that block is just going to be that. And it's going to say, Hey, for this block, here are my break points. Right. And, you know, and maybe even have that as an option, it could be possible as well. And so you have those break points for that. And then if you put that in a larger container that constrains it even more than you know, it's going to fire off its break points, just the same. How is this? I'm curious if you think that this is different than just like a normal. I mean, I think these things come up a lot in even just normal web application development. Yeah. Yeah. It's a tough. I think any time that you start dealing with several containers of components and CSS, it gets difficult no matter what, especially if, if you don't have just one piece of code to rule it all. And granted, the themes will help a bit. But I think what can really happen is we can start to push some of the individual post layout work down into the posts. And then we can start to let the themes worry about kind of the overall look and feel and sizing and that sort of thing. So, you know, the theme is not going to be concerned about, well, I have a really narrow column here. The theme is going to say I'm going to make sure that my posts have this much width, right, the whole thing. All right. So, customizing Gutenberg via themes. I think what's going to happen is a lot of these blocks do already have classes associated with them. And especially like the standard blocks, I could see themes hooking on to those CSS classes, right? So, if you have a paragraph, it's going to do this. And if you have a header, it's going to do that. But it's not so different from what themes have already been doing quite a bit. Maybe it actually gives it more options, right? Because I think we're going to have more CSS classes to hook things on to you with your theme. And perhaps being a little bit more discriminatory about them and being able to say it's only for paragraphs, right? Or it's only for these headers or it's only for this type of component on there. Or I could even see themes where maybe they allow you to put in your CSS class that this thing affects, right? And so you can type in your CSS class for only the paragraphs that you want styled a certain way on your components and then your theme will automatically grab that class. That's another option as well. I think there's a potential for a better cooperation between the editable content and the theme here. So does that answer your question? All right, good. Yes. I don't know. I don't know that there is one set. Yeah. Yeah. Oh, no, I think it I think it's going to be. Yeah. Yeah. Ooh, I'm glad you asked. So nested blocks. Actually, if you can see this right now. So here's an example. Columns right there, right? Yeah. And so it does say experimental. I have run into a couple little issues with it. This is definitely going to be the way that it's going to go. And actually, I'm super excited about this. So right now, when you look at a Gutenberg editor, it's handled as an array of blocks, right? Just a single from top to bottom, right? I see that changing as soon as we really start going nested on these blocks and a post block is going to be one block, right? A post block and you nest stuff inside it and it's going to be instead of being a single array, it's going to be more like a tree. I think you have to be careful with, you know, with what you're trying to go for, just like anything else. I mean, what's a grid layout but a table, right? So I mean, most grids don't look like a table because care is taken to not go overboard with them, right? Just because you have seven columns doesn't mean you're going to use them all. So, you know, I think the same sort of thing here. With anything else, it's going to take some design restraint and people who care. I guess the thing that I'm excited about is it gives people a chance who maybe don't know CSS to give it a try, you know, and start laying out and start playing with layout stuff here. I mean, it doesn't, it doesn't mean they're going to get it perfect. That's for sure. They're, they're going to be some, they're going to be some ugly WordPress sites out there. But I mean, there's some ugly WordPress sites out there right now. So, you can. Yeah. So you, right now, and actually right now, I believe it's supported and master in the Gutenberg right now. You can, through a plugin, define a custom post type. You can define a template for that custom post type. Super cool. If you haven't seen Matias Ventura's video at WordCamp US this last year in Nashville, he goes over it and he goes over, hey, I have a custom post type of book, you know, and it has a template with a picture and an ISBN, you know, number, place and, you know, all this other stuff that is very pertinent to books, right? And those are, you can walk that template down, you can make sure, you know, nothing else can be added or removed or you can just, you know, say, well, things can be moved around, but they have to stay there, stuff like that. I think we're going to see more and more of that. Any questions before we move on? That's a good question. I think it depends on the block. I mean, in general, there are different styles for the, I mean, it's different HTML output, right? For the, for the editable view and for the saved view. Those are two separate pieces of HTML. So I guess in general, it's not the same CSS running in both. However, care has been taken, as you can see, you know, a lot of these things look like they would look on the front page. So, and actually, when it comes to a customizer, that's probably going to be even more so. Questions anymore? Moving on. All right. So here's where it gets really interesting. So the future of WP Admin. So if we take this past potentially, I mean, we've got the editor now. We're talking about the customizer. As someone who has worked on a lot of WP Admin code for WooCommerce and other things, this is where I get pretty excited. But yeah, this is my speculation. So this is not authoritative. Although I have seen, like Matias put out a post and he already talked about some of the stuff too. So at the core of this, we've got our blocks, right? And we've got that today. But where else can we go with this? So we've got some UI elements already. We've got headers. We've got, you know, we've got columns. We've got images. We've got all this other stuff. Not only that, but we also have an editor for each of those, right? You know, we not only have an image that we can render on here, but if I click on this, I can actually change what that image is, right? I can turn it into a gallery. I can, you know, I can change what image I'm, you know, I can upload another image for that. So I have an image editor right here. How cool would it be if I could use this when I'm editing my product in WooCommerce and WP Admin? So not in the editor, right? Because there's a separate page for this. Or categories, right? You know, I mean, there are WP Admin pages that are not like the custom post type pages or anything like that. They're actually just straight up, we're making our own WP Admin page, right? How cool would it be to be able to incorporate some of this block functionality into there? So theme content, we've already talked about the customizer. I don't think anything definitive has come out of that just yet. But I think it's safe bet to say the customizer will see some more integration with Gutenberg. Probably not with the initial release, but it'll be out there. Rest API, just like we talked. I think there's a lot of power between the Gutenberg blocks and the API. Because the Gutenberg blocks give us a uniform way to talk about an image gallery or an image and where it should be on the page and how we show that. Or text, what color should it be, what font, all of that sort of stuff. We can edit all of those things. Kind of gives us a common language across a lot of different places. And then the rest API is just how we fulfill that on the back end. And we've already talked about the advantages of abstraction of that API. So there's some real advantages to us going and getting our data from the API rather than doing it in PHP code from a post-medical. The admin UI itself. So a couple months ago, just to try it out, I actually rendered a Gutenberg block on an admin page outside of the editor. There was no editor involved here whatsoever. And I got a list of categories from the API. Super easy, oh my gosh, it was so easy. And pulled that data in, rendered a bunch of rows for each, one row for each category. And it was super cool and it was just all on one admin page. And so that gets really interesting as if we can use these Gutenberg blocks to actually render admin UI. We could potentially make our lives a lot easier as plugin developers. So UI extensibility. So some of these components we've got within Gutenberg, they have a slot fill mechanism that is available to us. And so again, for example, on a product page, if I wanted an extra page for some custom fields in there, I could actually just render a slot component right there. And I register that and then something else can come by and say, hey, I've got custom fields for a product. And so they present those. And then when that plugin gets installed, now those fill in that slot. And the really cool part about it is the main product page code gets to decide where those show up, right? They get to decide how they are presented or at least contains them. And so I think that's really interesting as well. A little bit more, I think it's potentially a lot better for the user. Especially for WooCommerce, since we have so many extensions and we have plugins piled on top of plugins, right? You know, we've got the WooCommerce plugin and then we've got other plugins that extend that plugin. And I'm pretty, actually, I know, we already have plugins that extend that plugin which extends that plugin, right? We're going three levels deep on this stuff. And having a little bit of control on, you know, being able to lasso these things and say, okay, you're gonna exist in this little box, you're not gonna take over the whole page, I think is pretty helpful, especially for our users. The parts that I'm really excited about, so with Gutenberg users, so any blocks that you get installed, the users can use and they don't have to write code to do it, they don't have to write CSS, they just move them around, they tweak them, add them, however they want. They get to control the layout of their pages and their content, they get a higher degree of control of their site without having to write code and they get to tweak all those little display options and normally you would have to know CSS to do. Theme authors, so theme authors can get some benefits from here as well, so as a theme author, you can provide blocks that then the users can customize through the customizer or elsewhere. You can provide the default templates, those default templates for how things should look, you know, like the storefront index page, right? And the flexibility that you can provide because those users can go with the template that you gave them or they can completely revamp it or they could take parts of that template and implement them somewhere else. Yeah. Let's say if we're preserving a brand. Okay, yes, yeah, you can lock down a template. Right now the controls are not very fine grained, it's either you can't add and remove anything but you can still rearrange stuff or you can't do anything, you know, but I think we're looking at, we'll eventually make that a lot more fine grained of a control to where like, hey, these can't be moved but the rest can be moved or you know, stuff like that. But even right now those templates can be locked down. So if you're thinking about making a child theme for a site that's very specific for a brand and you want those templates in there, you can lock those down. And plugin authors, so obviously the first thing plugin authors will be doing is providing some blocks to be used, stuff that they may have hard coded in or done short codes or done meta boxes or you know, whatever they've done, you know, the magic PHP code that nobody can see that still renders stuff can now be in a block and people can choose to use it or not. And then yeah, plugins can use blocks from other plugins. So those plugins that extend other plugins, they can use blocks from those other plugins and their own stuff. And you can use the ones from the core set. In fact, you can even have some logic saying, well, if this is available use it, if it's not then don't. And then yeah, if you have your block and your API, it covers all of the use cases that you would need from a UI perspective in WP admin and then also on the front end. So, and that's it. So any more questions? Yes, yes. Yeah, it's gonna take, right, right. So at some point when people upgrade their site to 5.0, they will, at that point, see the Gutenberg editor instead of the classic editor. At that point, if they do not have the classic editor and plugin installed, you can install that now and then when 5.0 happens, nothing will happen. Years will be the same. This is why it's important, I think, to test things out, especially if you have a site with a theme that's doing a whole lot or if you have a lot of plugins, a lot going on, I think it would definitely be good to try it out. The Gutenberg team is still working through a lot of kinks right now and so they're iterating on this stuff right now. So you may find something and if you do, please report it. No, it'll just be the editor. Yeah, when you click edit post, if you edit the post, then it will just show the Gutenberg editor, yeah. Yeah, so I think what they've started doing is they actually, if you have a post that is edited before Gutenberg was installed on there, it actually stores the content in there, any classic block and it's treated a little bit differently than the rest of the blocks that are in there. So all of your existing posts, it'll say classic block and nothing else at first. So I think that's what I've been observing lately. It's until 5.0, yes, yeah. Yeah, 5.0 is it, yeah. I mean, from everything that I've been told, I mean, I'm not the authority on this. All right, I think we've got two more minutes. If you want your question on video, that was the time. So part of the automatic creed, which is kind of our motto, it's kind of our vision and what we live by, part of that says I will not just work on what's assigned to me and so this is me doing work on that's not just assigned to me. However, it's become more and more relevant to what we're trying to do in WooCommerce. I think very quite possibly we could end up using some of these Gutenberg blocks for our new admin UI that we're working on. Nothing definitive there though. I can't, you know, in fact, we don't even have a project kicked off on this but we're talking about it. Yes, certainly. Yeah, yeah, actually I think widgets would be another really good target for blocks. I mean, how great would it be if you just, if a widget was a block, right? And a nested block at that, right? And you could put other stuff in there and rearrange it and then save it and that's your widget. I don't think so. Now I think the very beginning, it's gonna replace some short codes, it's gonna do some of the editor stuff and that's probably step one. Oh no, I think the short codes themselves will be around. I think the short code builders will become blocks. That's where I think the best value is. Yeah, it is using React right now and so that would be my recommendation. You could probably shoehorn some other stuff in there but if you're looking to make a Gutenberg block, I think learning some React would definitely be good to do. So much of the boilerplate for React is already fixed in there for you. There's a Gutenberg examples repo that you can grab. If you just search for Gutenberg examples, it's in GitHub under the WordPress organization. Look at the Gutenberg examples and there's some really good examples there. It's not gonna be PHP calls. It's always gonna be JavaScript because it has to be run on the front end. There are other frameworks like Vue and some others that may be compatible with Gutenberg at some point but the team has settled on, I say I'm not on this team but the Gutenberg team has settled on React right now. So yeah, and that's like I've said, it's the path of lease resistance. Like I said, you might be able to shoehorn something else in there but especially when things are new, you wanna do it the way that it's recommended. So I think I'm up on time. If anybody has any questions, please come up and talk to me. I'll be around at the after party as well. Thank you.