 If you have a site that does not do production with Gutenberg on it right now, raise your hand. All right, keep your hands raised. Lower your hand if you do not like it. All right. Some people like Gutenberg in here. That's a good thing. All right, so I'm going to be talking about Gutenberg. I'm going to be talking about the development aspect of it. If you are a user, if you are a blog writer, I love Gutenberg. I mean, from a user experience on creating content, I think it's a big step forward for WordPress. I think it's going to really revolutionize how we look at creating content. I think we're in a box before, right? The text editor box is all encompassing monstrosity as a monolithic thing that you can throw short codes into and things like that. I think Gutenberg is going to be a good step for that. My talks on Gutenberg about development side, probably about custom applications or custom development with it. I call it tail of love, hate, betrayal, and a mighty comeback and also case study. I'm going to start my talk by thanking you for being here. If you follow me on Twitter earlier today, I kind of want a little rant, and I'm not happy with how we'll don't come for second day. So I'm really happy you guys are here, not just on the second day of our word camp, but on the very last talk of the day. As a speaker, it's, I'm not going to lie, when I see that I'm on the last spot, I'm like, great, there's going to be like five people in the audience because there's going to be 10 people still left at work by the end of a Sunday. I really have you guys here, so thank you for being now, you guys are all my friends. About me, my name is Roy Siobhan. I'm a senior software engineer at the Walt Disney Company. I build websites for Disney, and as much as I said at the Pantheon booth, and as much as I wear Pantheon clothes, and as much as I love Pantheon, I actually don't work at Pantheon. And for your developer in the audience, there's two types of developers, those who get the joke with my name, and those who don't, and for those that don't, you're going to learn about it real quickly. A little bit more about me. My first install WordPress was a beta version. I was learning how to develop websites, and I learned about PHP include. I'm like, oh my god, this is going to revolutionize everything. I can now have one head or five. So I'm going to need to change it now by them. It's one file. That's amazing. And then my friend was like, you should check out this blog thing called WordPress. It looks pretty cool. And from then on, I've been contributing, working on, and just using WordPress in all sorts of forms. You can find me online pretty much anywhere, wordboy789. All right, what am I talking about? WordPress. If you're not here to talk about WordPress or listen about WordPress or you don't like WordPress, you're probably in the wrong place. I'm going to talk about WordPress. Gutenberg. Gutenberg is a new editor coming. I'm not going to go into too much detail about what Gutenberg is, but I'll be talking about it. I'll be talking about applications. So while you might be working on sites for small businesses and brochure or websites, we're going to be talking a little bit more about custom applications. So not necessarily apps for your phone, but not necessarily not apps for your phone. More robust websites that require a little more functionality and maybe a little more advanced coding. And finally, headless React. So I'll talk a little about what headless is if you don't know. But we're using React a lot nowadays. Gutenberg is React. So as we adopt more and more React, it's just going to be out there more. I'm not typically a React developer. I'm an Angular developer just because that's what I learned first. However, because of Gutenberg, I've really learned a lot more about React and how to use it. And I'm a fan now. I still tend to use Angular just because I know it. It's easy to get something running. But I tend to now use React more because it is not part of the WordPress ecosystem. That's a developer thing. You know, users don't really care that React's there or not. They didn't know what was there. It's just there for them. But as a developer, that's a really big step. Another big step for WordPress as we kind of make our way to Gutenberg. So I'm actually going to step back in time for a second. Here's 2014. I was standing either in this room or that room talking about WordPress as an application framework. I literally gave that talk here. And at the time, WPAPI or the WordPress REST API was in its infancy. It just started to come in to plug in Realm. I was playing around with some other options that were already out there. But I want to learn how to make JavaScript websites with Angular with WordPress PowerMap. Fun fact, if you go to a WordCamp website and throw a different year in the URL, it still lives. So there's my talk from 2014. WordPress as an application framework. This was on that line in my description using WordPress and WPAPI. What we remember is WPAPI and how we used to call it WPAPI. Yeah, pepper chargers and members. Let's talk about today. Basically, I'm going to give you the same exact talk I gave four years ago because I don't know how to be creative. But instead of WPAPI, I'm going to be talking about Gutenberg. It's pretty much the same exact talk just with a copy replace or a final replace. Let's start at the beginning. Some of you who didn't use, haven't used Gutenberg yet, right? Can you guys raise your hand? Who hasn't used Gutenberg yet? In development, in practice, whatever. You've seen it. You might have seen it on one of our presentations this weekend, but you don't actually have a site with it anywhere. So let me introduce you. It's Gutenberg. We have an affectionate name for Gutenberg. It's called Goots. If you follow the Goots on Twitter, it's actually a good place to get up-to-date information as well as satire remarks or sarcastic remarks about Gutenberg stuff. So while he's like the onion for Gutenberg, I would say. Not creating content but just commenting hilariously about it. And I always call it the Goots because Gutenberg is really long. I have to say it over and over again. It's really long. So Goots. I know all of you are going to ask me, do I know when it's coming? And the answer is no. I don't know. But the good thing is, it's going to come when it's ready. So I can't give you a date because I don't know a date. But I pretty much can guarantee that when it makes its way into core and core comes out, whether it's 5.0 or whatever it might be, it's going to be ready for it. Well, WordPress will be ready for it. And I don't know who will be ready for it. But it'll be ready. Here's where my rant starts. And this is where my love and hate part kind of come into play. So I already told you why I love it. There's a lot of cool things. It's a really good editor for people with right content. But as a developer, here's where my hate really kind of comes into play. This is what wall structure JSON data looks like. It's an object. You see all the data keys are there. Their values are there. So when you're using the REST API, let me see another, raise your hands. Who uses the REST API or knows about the REST API? You guys all come over here on this side of the room? Yeah. What was that? Was that planned? REST API. It's basically a way to get data from your WordPress site in JSON form, and you can use it pretty much anywhere. While WordPress democratizes content and creation of content, the REST API allows us to kind of democratize how we use the data. So if you have an application on your phone or somewhere else and you want your blog data, your site data to be there, you use the API. Go back to 2014. I'll tell you all about it. For every post via the REST API, you get a nice structure of data. You get an object-reached post, and you get an array of those posts. So it's really well structured. You can easily iterate through all of your posts. You can tell it, hey, I only want posts from one category, iterate through those. And you can do a lot with that. It is structured. It's an array. It's easy to use. This is Gutenberg. I bet this data looks amazing and super well structured, right? No. How many of you know what an HTML comment is? Literally making a comment in HTML. Yeah. Then you know what Gutenberg data looks like because that's all it is. If you look at it, you'll see there's an HTML comment that says WP paragraph. That's what we're just saying, hey, this is the start of the paragraph block. If you look at the next one, it's a cover image. There's some data there and another image. There's a cover image and an image. So when I show this to people and they don't know what the data looks like and they're like, wow, I can't believe the data looks like that. What do I end up getting back from them? Hi, Roy. What about the data via the REST API? It must be an array of data, right? There's blocks. The blocks are there. The blocks let themselves to be an array of data. Nope. Not an array of data. Have you ever looked at the database of said Gutenberg data? It's not that pretty either. So the screenshot up here, that's from SQL Pro. So if you don't use SQL Pro, it's a gooey for looking at my SQL, looking at your database. Every time I see these things, I'm like, why? Why is it so painful? And I'll tell you why. It needs to be backwards compatible. It's really what it comes down to. Backwards compatibility is both the greatest thing about WordPress at times, but also the band and mic systems at times. If you're running a WordPress site that's 3.9 or later, like newer, they say that your WordPress site should never break. But I also know WordPress runs 30% of the internet, so I also know that not having backwards compatibility is also not a good option. So here we have Gutenberg. Here we have the data that we can do nothing with because it's useless. So thank you. My name is Roy Siobhan. Any questions? Here, are there any questions up to this point in the top? I've shown you what Gutenberg looks like. I've shown you the data. Let's answer some questions up right up here in the front. Yeah. So I understand that the data is stored in the way that it is for backwards compatibility, but why was there no forward compatibility also included in the initial design and development of it? Like why important compatibility as opposed to backwards compatibility as in creating a method for structured data to access the rest of it? Yeah. That's an excellent question, just not for me. I'm a bad person. I really wish I had the time to contribute as much as other goals contribute. I just don't have the time, and that's really unfortunate. I wish that, yeah, someone in there was advocating for, hey, what's the future look like? What does this look like 10 years down the line? And not just that, when the REST API came, it was a huge deal for developers. We were like, yes, a REST API, that's a good thing. We can build cool things with REST APIs. Gutenberg is built with the REST API. It couldn't be there if it wasn't for the REST API, but users don't care about the REST API. 30% of the internet is running on WordPress. 29.9% doesn't care the REST API. It's just there. And it's a great tool for us developers. It's not a great tool for users. Gutenberg, on the other hand, is a user tool. So users are said to put it at the forefront, and that's fine because it is a user's tool. It is a conventional new convention of how to create content. Why we haven't thought about, hey, how does this work with the REST API? How do we make this better? I don't know. I'm sure there's GitHub issues for it. This is a conversation that we've been having ever since Gutenberg came out. Like, I think maybe like San Diego, last San Diego, I know I talked to a lot of developers about it. And it was just like, we all knew it was there. We kind of just let it go because we all have lives. We're all busy. We're all trying to make more assignments, right? We can't always contribute as much as we want to, but we all know it's there. But I will talk about how to get there shortly. Any other questions? That's for up to this point. No? All right. Thank you for asking that question because Gutenberg object plug-in. My shameless plug-in. So what I did was, after working on San Diego, I was talking to, I think Scott Wallinger, I think John was there, and we've just had a couple conversations, and I was like, you know what, this is BS. I want code and I want data. I think it's fantastic what Gutenberg does for the users. I don't like what it does for me because it does nothing. So what I did was I hijacked the save command and I said, when I save, when you save Gutenberg, I just want to gobble up that data. I don't want to talk too much about the plug-in. If you want to talk to me about it afterwards, if you want to find me on Twitter, I'm happy to talk about how it works. It's all open source. It's all my GitHub. If you find me on Twitter, I have links directly to it. You can just link there. But I was like, okay, this needs to happen. I need to be able to literally just iterate through blocks because it makes a lot more sense. Does anyone here use ACF flex content or like those live, those layouts? So one of the greatest things about ACF flex content was being able to go, hey, here's a new layout block with some data. And I'm going to create a partial, a template partial for just that one layout. And I'm like, great, Gutenberg's going to do exactly that except it's going to be built into core. And then that's all disabled. I'm like so close, so close. This is what the data looks like with my plug-in installed. On every single post returned, you get editor blocks. There's an array. And each block is there with the attributes of the data for that block. If you go to devgoots.url, it's also linked to my Twitter. There's a live site running right now. If you go there to the URL, it will take you to the welcome page because I only have one page on the site. It's the welcome page that's built in Gutenberg. And it'll take you there. You'll see all the data. You'll see the editor blocks are there. Not just that. I want you to try it out. So whether it's now, whether it's later, go to that URL slash admin, which will take you to WP Admin. If you're a security nut and you hate when people share passwords, I would look away at it right now. There's the username password for the author account. Feel free to create your own content and see what happens when you go to the REST API endpoint. If you don't know how to get to the REST API endpoint, it's the same exact URL. Slash wp dash JSON slash wp slash v2 slash post slash post ID. I'll leave that up. Take pictures. I didn't put the username password on my Twitter. I feel like that might be a little bit much. And if you're watching this on WordPress.tv, I don't know if it would work anymore. So I might go down. I don't even pan down. We're really happy with me for doing this. All right. So now that we have that data, how do you access it? Well, so there's two ways via the REST API. One is I just inject it into the regular post object. So every time you look, you get your post now, there's still going to be other content. It's still going to be backwards compatible because everyone needs to be backwards compatible. But there's also going to be that new block. Where does it get saved? During this whole process of thinking about things, I decided, well, what they should have done was what I just did, but create a new table on wp dash underscore post. So next to post content, you had another column, which was just that data. Backwards compatible, forwards compatible, all in the same place. But they didn't do that. So I just created a new table. So you'll get a new table in your database called goods arrays. And that's where all the data for each post will be stored. It only works one way. You can only store data from Gutenberg. I had a long conversation with a guy named Kevin Hoffman, who's a smart developer, and we decided, well, I decided that saving data to the Gutenberg of basic word Gutenberg stores its data was bad if you're not using Gutenberg. There's a whole bunch of other applications of that. Obviously you have to run through all the basic word pressed up every time you want to resave that data. So basically there's only one point of save and that's through Gutenberg. Makes it a lot easier that way. But all the data is there. So again, it adds Gutenberg data, just as it looks like this, to regular posts. As well as there's a new REST API and point I threw in just so I could look at something unique and isolate. But if you want to isolate just the Gutenberg data, you don't want the rest of your post content or you don't want the rest of your post data. You only want the Gutenberg data. You have a unique endpoint just for that. It comes in handy when you are only needing the content. Similar to like if you guys are familiar with Graph2L and you only want the content, well, I have that REST endpoint for that. For those people like ACF, I also threw in a PHP command. So we'll return an array of all those blocks, which again, so it's just been done out of the box, but it didn't. So just grabs the same data, returns an array, you for loop, while loop, whatever. You loop through that data and you have all the data from every single block. And break again. Do I have any questions up to this point? No? Good. So now that I've talked about why Gutenberg sucks and how I made a plugin to make it better, let's talk about a case study. As everyone's familiar with the company Airstream, they make trailers, campers, trailers, things like that. All right, cool. They have a cool little, like, their retro look company stainless steel rivets. Again, to you, at least, in one of them. So they're actually building a new site and Latlong is actually the digital agency that hired me to consult with them. So yeah, this is the case study. Latlong basically reached out to me, asked me if I knew anything about Gutenberg. And I said, yes. Then they asked me, hey, they told me there's a scenario. They wanted to build a headless react WooCommerce website. Let me let you sync that in a little bit. Headless react WooCommerce. And then throw Gutenberg on top. And I was like, you know what? I got just the thing for you. And I just built it. It's called this object plugin. And they hired me on spot. So what's the setup? Basically, we already talked about it. WordPress on the back end, WooCommerce on the back end, Gutenberg on the back end, a GraphQL layer. And then I had this react app. It's not launched yet. So I can't really share too much code. I will share some screenshots and I'll show you I'll share more about like the philosophical kind of look at how we took everything. But just keep in mind that the site was built for people who write content. And that's why they wanted Gutenberg. I recommend if you guys take clients, put Gutenberg on their sites, don't show them the regular editor, show them Gutenberg, let them learn Gutenberg first. So that's what we want to do with them. We knew that Gutenberg would be able to leverage Gutenberg much more than the regular content editor, the classic editor as it is. And so we were like, you know what, Gutenberg just makes more sense. So here's a cool screenshot. This is WooCommerce. That's WooCommerce. That's a helpless WooCommerce app. So that's what their dev site is for right now. And so I'm just going to run through all the steps. So why WordPress? I already talked about WordPress, you know, it was mainly for their content team. WordPress is a great CMS. Thanks to Jeremy Fremont from the last talks. Great slide. I wish I had just copied it. But hey, that's cool. WordPress is awesome. Hello, WordPress. I've been using WordPress for a long time. You guys are a little WordPress because you're here. So when someone says, why WordPress, I don't even know how to answer that anymore. Why? Why Headless? So performance, key factor there. When you have a headless app, you don't have to worry about the rest of WordPress. You don't have to load anything. You can do whatever you want with it. All you're doing is taking the data. It's a management. So when you have a site that's headless, you can really specify that people are working on it to only be experts in whatever that's built in. Separation of concerns. So if one team is actually writing in product data and blog posts and all that, you can have a separate team work independently on the front end. You don't even have developers working on the back end. So all they do is the WordPress site, which was my main role in this project. I was the WordPress guy. If they needed something on the front end, they came to me and said, hey, we're trying to get data for products. I was like, hang on a second. Do a poll. You've got the data now. I was the WordPress side of things. You can separate the concerns there. And that allows really experts to kind of show what they're experts at. The guys that are doing the React side while I dabble in it, they're far beyond my level of React. And that's amazing. And that's awesome. But I would just slow them down if I was on the React side. However, they would slow me down if they were doing WordPress stuff. Because every time they do anything with WordPress, I'm like, all right, I'll just clean up your code now. Thank you. Yeah, it's never fun. But I was the WordPress guy and it made things easy. And then finally connectivity. If you know about APIs, you know they're now kind of everywhere. And when you have a headless app, it allows you to actually connect to multiple APIs. So I'm saying WordPress, WooCommerce and all that. But let's say you have another API that does like analytics training, where you have another API that maybe pulls in data from somewhere else. Maybe you have a mix of products of WooCommerce and Amazon, right? With a headless app, you can actually grab all that data, put it together. And again, you're on that separate server for multiple, multiple reasons. It's just better. Not for everybody, not for every blog site. So don't get any crazy ideas that your blog about cats should be headless. Shouldn't be. Again, to you all. But it does come handy. All right, working with Gutenberg. Let me tell you, working with Gutenberg is so much fun because it is the best moving target. I love working on something and then having it break two weeks later because they push an update. It's just fantastic. I will give you a hint, though. This is something I learned pretty early on during the development of this project. And that is if you're going to be doing what I'm doing, first don't, stupid. But if you're going to anyway, what I did was actually turned off all the core blocks. And I said, I don't want to need your blockchain and create my own custom blocks. That's what we did. We created custom blocks. And I think the only block we have that's for is paragraph because we couldn't figure out how to get some of the keyboard shortcuts they hijack into that block. Because that's the main block that when you load a post, there's already four blocks ready to go for you to type into. A lot of that trickiness, we couldn't figure out how to mimic that of a block. So we just love the core paragraph block one. But every other block that's on there is a custom block. And it made my life so much better. Because as soon as we made that decision, I cared about Gutenberg updates, but I didn't care about the blocks themselves because the blocks themselves were basically just extra fluff that we weren't even using. Gutenberg and WooCommerce. Who here just absolutely loves working on templating WooCommerce sites? Yeah, so I thought no one. Because no one does. I will say that Gutenberg and WooCommerce fortunately don't play at all well together. It's amazing how much these two products don't work together. But that makes it more fun. So they do work together. Me too. It's kind of unfair. They do play together, like Tom and Jerry. There's a good example. They play together like Tom and Jerry, because sometimes it'll work and they're friends, and then most of the time they're not. But my favorite thing about the headless part though is there's no WooCommerce templates. Everything we did, including the cart, including the checkout, is all headless. It's all react. So all they're doing is raising WooCommerce on the back end for products, orders, payments, but pretty much everything else is its own reacting. Another cool thing that happened while I was working on WooCommerce in Gutenberg, this came out. And that's a changelog from WooCommerce. Yeah, that was a fun update. We were like, wait, what just happened to Gutenberg on all our products? And then I had to dig through the changelog files and I found this. Disabled Gutenberg editor on products. It's a tweak. Yeah, that's what it is. A tweak. Didn't see that one coming. No one told me it was coming. And you know what they did? They created a filter really far deep into the code with no documentation that allows you to turn it back on. So there was a fix. Took me a while to find it, but it does work. If you need my code for that, let me know. I can share it with you. You'll find it. There's people talking about it at this point, but yeah, finding that saved us a lot. So if you want to do Gutenberg and WooCommerce, you can just use that. All right. Let's talk about React a little bit. Has anyone here worked with React already? Cool. And full of you. I will say that there was a thread on Twitter talking about some tips and tricks for Gutenberg development. And one of the biggest things I took away from all of this experience was I kind of learned to react separately before Gutenberg, right? And Gutenberg has, well, they introduced a library that sits on top of React. So when you do something like, I think it's WP.element, that literally just creates a React component. So what I did was I just took the WP.element out of the equation and I just did React work so I could learn Gutenberg. I didn't want to learn Gutenberg's like arbitrary library just so I can learn how it works. And then I added a library afterwards. In my life, a lot easier. So if you're a fan of React and you already use React, try doing it that way. One of the coolest features that we put together for this project was React components are agnostic to where they live. So a React component can live anywhere you want it to. A single React component can both live on your front end and be user-facing as well as live inside Gutenberg. So you can have the same exact code base, both power your front end, your headless front end or whatever, as well as power Gutenberg. That's one code base. This is not a front-end editor. It's not a front-end editor, but it's not too far off. So like you see the similarities between these two components, they're three images, they all link to products. They're identical. That's because they have the same data. Whether you're viewing the site on the front end or you're viewing it via the Gutenberg editor, the same data is going to the same code. So why can't it look identical? I'm not saying that it's going to be a front-end editor soon, but you can kind of foreshadow what's going to happen that you Gutenberg feed three when you have that kind of power. So I think there's actually already front-end editors that people all put together, like mashed up together for Gutenberg. I've seen a couple examples, but I think this is where it's going to go, and that's going to be pretty cool. I know there's a lot of page folders that are already front-end editing, but this is, again, this is one code base. There's no extra code. We literally have a component library that sits outside of both WordPress and the headless. We made an end-cam package, and then every time we update a component, both sites just get an end-cam update, and they have the latest component. One of them takes Gutenberg settings, one of them reads Gutenberg data from API. I was my case study, and I want you to try it for yourself. So I already gave you the author for my dev account, but I want you to actually have your own version of it. So what I did was I went to Pantheon, and I created a custom upstream, and I'm not going to walk you through how to do this. Feel free to find me, because I have business cards from someone who might be able to help you. But what you can do is you can go to Pantheon and create a free dev account, 100% free. Create an organization, and then you can basically just say, hey, I have a custom upstream. Here's the URL to it, and when you install it, hey, I need to install a new site. It'll ask you which site you want to install. Do you want to install a WordPress site? Do you want to install a triple site? And you're like, no, I want to install Goose and Goose Object. That's my custom upstream. So that's going to give you everything you need to get up and running with everything I just built for our air stream. More or less. It's my plugin. It's Gutenberg. It's WordPress. Has anyone created content on that site? Has anyone actually managed to get on there? You did. Awesome. I'm going to go ahead and put it here. I can't see you. Can I just get Jason? I have to see you. Hold on. Entertain yourselves. All right, what we got here. We got a post titled New Goose, and here's the content. So let's zoom in for you guys. Again, someone created this post. This is the rendered content. This is what you would see on the front end, if you're viewing the site. And this is what Gutenberg saves. This is Gutenberg at its finest right there. Luckily we have my plugin installed, and then I can see, hey, there's some editor blocks. And I see that the first block is a core paragraph block. This is really important because we want to know not just the name of the block that we're working on, but the core allows you to know, okay, this is a core block. It's a namespace for that block. So if I wanted to create a partial or a template part, just for that one block, I now can. So Gutenberg is handy every day. That's awesome and terrifying, but it's like a tsunami. Yes, it is. Question is, will the rest of servers get wiped out? But as you can see, all the data is there, right? So someone created a list. There's all the list values. We know that if it's a list, there should be a URL, but here are all the LIs. And this is what Gutenberg saves. I'm not modifying anything. This is just what it saves. And instead of saving it like this, I'm like, hey, it should be a ring. And then there's a core embed with the YouTube video. Which is awesome. I'm pretty excited about this kind of stuff. That's it. Are there any other questions? Yeah. I have a question about caching. So most word for us is loop-conference sites. People put in all sorts of caching plugins to create. If you will, a lightweight, decoupled architecture of sort of a headless, if you will, like page caching, kind of buffering the PHP workers and database queries. What you're presenting here is a real decoupled application. The React front-end WordPress loop-back-end database. So I presume your front-end had to be really fast, really handle traffic spikes well, and you had to use cases for that. So what sort of caching is the other? Or how did you do caching? Did you still do like object caching? And the back-end system WordPress move? Is there special caching on this React app? Or how do you get that done? So since the project's still on the fly, we haven't had much of a caching, right? But I will say that there probably is going to be caching on the back-end just to catch the database. But what I didn't show you was the GraphQL layer. So the GraphQL layer also does has a caching to it. So when you ping the GraphQL layer, it's going to return the last version of the data. It does that through hash, basically, which creates a hash mark and then sees if the database has changed at all. Or it'll periodically update itself without you forcing it to. And then the front-end will just be completely cached, obviously. At the front-end, because it's headless, there is no PHP, right? So it's all HTML, JavaScript, CSS. That's all it's running. You can run that on, and you can CDM a crap out of those kind of files, right? So I'm not too worried about the performance because it's headless. There are issues, obviously, with issues when it comes to on-the-fly kind of data, right? So we're now working on the checkout aspect. There is no WooCommerce checkout. It is part of the React app. So they're going to ping me on the API side. I'm going to create a token, I'm going to send it back, and we're going to go through the transaction. And I'm still going to have to use WooCommerce for all that. But just via the API, I'm going to create an order. And I don't think there's going to be that much more caching to it. I don't think we'll actually need it. Once we hand it over to Airstream, they also have the text side that's going to probably look and make that any better than they think to. Question in the back. So the question was, if I used anything like out of the box to create my blocks? No, I have seen his code base. I looked at it to help myself learn a little bit about Gutenberg. If you want to learn more about it, I highly recommend looking at Zach Borden. He has some really good stuff out there for tutorials on how to get up and running with creating blocks. But once I looked at both of theirs, plus Josh Pollock has a few really good examples. I just kind of took all the best of it. And I put it together with just a core documentation that they released and created our own blocks that way. I didn't really kind of look at a mishmash of everything, I guess. Yeah? No, but if you want a great one, I'd be happy for you to create one on my behalf. Yeah. Yeah, so let me run through that really quick. So out of the box, you get all core endpoints, basically core blocks supported. Up to the last time I looked at Gutenberg, I looked at what core blocks are, right? If they add a new block, I'm probably not already have a score for it. What I did do was there's two main things you might want to look at. First is look at this thing. This is actually adding custom host type support. Out of the box, you only get post support for my plugin. We had an issue with Airstream where they have other post types, like products, and they have their own custom post type for the stories or blog posts. So I had to create that. I used a global define for that, just so it can be across all sites. That's kind of just how we did it. I might change that up later, but for right now, that's what it is. There are a lot of helper functions out. There's one for getting the array of data. The main part that I liked that I added in was this hook and JavaScript. So if you create a custom block and you're like, hey, it doesn't come out right in your editor, like in the API. It's basically WP Hooks add filter. It's clean data, and then the name of the block. So core paragraph. And then you just pass it back, call back, and that'll pass in the attribute data. And then you can do whatever you want with that data and then send it back. And that's what it'll sort of database. So what I did was I went through all the blocks that I have currently supported. Basically, all it is is block game. Every single one does. There's a pretty simple file. It's just which block am I supporting with this and what data needs to go back. You can just send back the same exact data if you want. And that's what it does by default. But for this one, I needed to render, you know, something to string it to render, I think because with this is a core button. I think there was another, like, react component built into the text. So rendering to string makes it a string, which I store the database. So by default, you get basically just a return of the attributes. But then you can hook in, create a filter, and then you can run any block. So what I did was WDS released that they were going to create. They have a plugin out with their own blocks. I said, hey, WDS, that's cool of you to create a plugin with extra blocks. So because they've open sourced their project, I was like, I'll add in that support into my plugin. So if you use WDS blocks, I support that. But it's pretty easy to add new block support and save the data or manipulate the data any way you want before it gets stored in the database. If you are going to use my plugin, please create issues on GitHub. You just go here and you go issues and then you create one. I had someone tell me a couple of days ago that the core heading stopped working. And that's because it was a moving target. So to create an issue, I looked at it. I realized what I needed to change. I changed it. I created a core request for myself and I merged it and it fixed everything for that block. So if you find all of it, obviously create issues. I'm happy to work with anyone that needs to use this for anything. Any other questions? Yeah. If you're using your plugin and there is a new block for changing a block on the core website, what would happen with your plugin when we get an error message? So by default, what it'll do is it'll try to save it anyway. And it'll run through all of the save functions. You might see an error in your console because it'll error out somewhere before it actually saves to the database. So it actually won't save any new data to the database if there's an error. But if it's more or less easy data like strings, maybe like integers, things like that, then it'll just save normal. A lot of the blocks I was looking at didn't really need much alterations because they're just like a string. So as my core filter just returns back whatever the set gets sent. And the only issue comes in play when it's like, okay, there's more data to this, right? So I had a problem with the core paragraph where drop cap is just boolean. You want to drop cap on this paragraph. That's easy. I can just return that back and it'll save the problem. But the content itself has all these sub-react components for when you bolt something or when you have an underline. So I had to turn that into a string first and then save it. But if you do have a block and it's a core block, credit issue, and I'll get on it. Just for my knowledge, you're calling it a web application, but is this just a website that's more indirect that it's cheap? What do you mean by a web application? It can be anything. So anytime you have, I'm not saying web applications in terms of like, yes, high UI or high functionality needs that are beyond a brochure or what do I say, beyond a, hey, here's what we do. Here's what, you know, about us. Here's my contact, right? That's your basic WordPress website. Get beyond that into realms of, hey, I need something really custom. That's when you start talking application realm, right? But it can be a phone application. I love AppPressure for what it is. It is a headless app that runs on people's phones. This can help you run your AppPressure better. If you wanted AppPressure supported, Gutenberg supported into your AppPressure, you'd do something like this and now you have Gutenberg data in AppPressure, on any phone app. So it's really anytime you're consuming data from WordPress, not within WordPress or, I mean, even within WordPress, but that's what I'm going after. Yeah. So a weird question. I found out today that Gutenberg is being supported through Google. Yeah. Does your plugin work on how you're seeing that since? Yeah, I know. It's definitely a WordPress plugin. But in theory, I mean, if you were to change where it goes into, it could work. I mean, you'd have to just change what initiates to save. So my initiation is, yeah, WP data subscribe, that's what initiates it. As soon as that triggers, everything else gets triggered. So find a way to replace that line with Drupal data subscribe and you're golden. I mean, the database part would also not work. So you'd have to print it out. Is Drupal going to have messed up data? No, no, no. So, wow, I hate, I don't want to say I hate to say this, but Drupal figured out the data problem a long time ago. And now that they have Gutenberg, they're going to be forced to be reckoned with when it comes to that kind of stuff, because they've already figured out the data problem. Yeah. Can you expand on that just a little bit, please? The data that I want, Drupal already had. Like, when I show this as a Drupal dev, they're like, that's nice. We had that, like, whatever, five years ago. Yeah. But yeah, the data has always been more well-structured on the Drupal side. The CMS part of Drupal has always lagged for me. Gutenberg now with Drupal. I might have to look into that. Any other questions? Is anyone going to install my plug-in? How many cells do you have right now? It's open source, it's not part of the orc, so I can't really count it. You know what really matters to me? Airstream. They're using my plug-in. No, I can't tell you, because I know the people who have thrown in issues, so they're probably using it on somewhere. But yeah, I don't have to count on active insults. You've been sharing this in Europe. Any WordCamps in Europe? I think that would be really interesting. No. If you're on WordTest.tv in Europe, plug-in, check it out. I mean, it's a pretty new project. I mean, I created it right after WordCamp San Diego when I was really annoyed about the whole thing, and then I've just been updating it. So I guess the initial comment right here is five months ago, that's when I first created it. I've been working on it ever since, yeah. Do you think this plug-in could get merged before in a structural way? Like, do you think that's a realistic probability? I haven't talked to anyone on the core side about this, so I don't know. Maybe not in the way I do it, because I'm kind of a coder that's like, I just need this done, and I'm going to do as elegantly as I can within just getting it done. Like, there's certain parameters there, right? Like, eventually I'm going to get to a point where my code's not the best code, but it works. So I don't know. They might have a better way of doing this, but I think I'd love to see conceptualities on like this getting merged to the core. I'd love to see, as she said, forward compatibility as opposed to just backwards. But if anyone who's watching is a core, I'm happy to work on this and get it mergeable. Any other questions? Yeah. What else would you like to do with this? Takeover the work. I don't know. I've only been a helpless fan. I love building stuff outside of the realm of the theme or plug-in, so I'm curious to see what Gutenberg does, and I just want to make sure that this is going to keep up with Gutenberg. In the future, I don't know. Maybe it'll power more things. If, as Gutenberg kind of itself grows into whatever final flow it's going to take, I hope that this thing kind of just tags along and is able to continuously be thinking about the future as opposed to always thinking back, I love that future compatibility. I'm going to use that from now on. Just calling it important that WorkCamp US mentioned how Gutenberg and VR will be together closer in the future than we think. Yeah. I don't know what I'm going to plan on doing this further, but for right now, as long as it supports the current iteration of Gutenberg, I'm not going to have to do that. Yeah. Can you talk about the decision of using GraphQL in the project? The main purpose of using GraphQL is when you're querying data. Like I told you, I have one RCA API in point that just adds Gutenberg data to your post, your regular post content, and then I have another API that you just want to Gutenberg data. So GraphQL allows you to say, hey, I want the latest post from this category, but within that post, all I need is the title and the content, or I need the title and the length. And then all you get back is just that data. So it's a little bit faster if it's cached properly, as well as the fact that you don't have to worry about it not being there, because GraphQL takes care of that concern. You're saying, hey, I need this, and in some form or another, you're going to get it back. So you're not saying, hey, I need a hyperlink, or I need a permalink. First, let me check if it's there. You can kind of assume it's going to be there. And so that's why we kind of went in that direction. On Saturday morning, Alex Vasquez challenged me to learn Gatsby, so I don't know if anyone's heard about Gatsby yet. I spent the day trying to learn it. It failed miserably. I couldn't get there. But my next iteration, I guess, would be learn Gatsby, get Gutenberg connected to Gatsby, and figure out what that looks like. That would be sort of like GraphQL, I think it's a performance front end, and then it handles back end. Are there any other questions? Cool. I'll let you guys go a little bit early, because we're all exhausted. You can find me pretty much anywhere online for Airboy 789. And if you haven't used Gutenberg yet, please go test. Test your site on something. If you don't know how to test a site, you don't have a place to test your site, go to Pantheon, set up a free account. They'll help you migrate your site to your dev site. And then you can just install Gutenberg, and then you'll see what happens to your site. I mean, in a lot of cases, nothing will happen, but in some cases, it'll all break. Figure out which one, what side of the equation you're on, and go from there. But test. Any time anyone has a concern about Gutenberg with me, I just say, hey, I know how to fix your problem. Test it. And that's really always the answer. Thank you.