 Thank you for that wonderful introduction and good morning everybody. I mentioned this at the very beginning, but if anybody is not interested in Gutenberg development, this is not where you want to be. I would recommend going next door because Brigitte is going to do a very awesome job talking about WordPress for nonprofits, which has lots of good things in there that aren't just for nonprofit people. But we're going to talk about an intro to Gutenberg development. How many people have not yet looked at Gutenberg? Nice, about half of you. Sweet. Well, if my clicker works, that would be amazing. Pause for technical difficulties. Yeah, how about that? There we go. All right, so this is what Gutenberg looks like. It's from a distance. If you close one eye and squint with the other, almost exactly like what the WordPress editor looks like right now. You can see a title up at the beginning. You can see some content below that, a bunch of boxes off on the right hand side for controlling the publishing schedule. But if you actually look closely, it's very, very different because everything that goes into the content editor now is a block. The block is the smallest unit of measure for working with a piece of content in WordPress using the Gutenberg editor. And everything is a block. Paragraph is a block. And image is a block. And embedded tweet is a block. And you can manipulate the blocks, change them from one thing to another, and compose some very nice layouts very quickly without having to mess with HTML or short codes or meta boxes and just wondering how it's going to look on the other end. It's pretty cool. So I'm going to skip talking about who I am because we already did that. But in case you were wondering, I run WP Sessions where I help people be empowered by WordPress. I'm going to mention this right now. I have a bunch of stickers up here that I always forget to talk about if I just leave until the end. If you want a sticker, I have a ton. Come and take one or two or three. I won't mind. But today we're going to talk about a bunch of different things to build your first block. So Kellen is going to present how to actually make your block. And I get the easy job of just telling you a bunch of vocabulary and things that are going to be useful to you as you go about creating your own blocks, which means that he gets to answer all of the hard questions. And I just get to say whatever I want and move along. So we're going to talk about some of the JavaScript libraries that get included with Gutenberg. We're going to talk about how to interact with and access those libraries so you can actually use them in what you're building. And we're going to talk about the core function that you actually care about, which is register block type. This is the magic function that actually allows you to make a brand new block of your very own in Gutenberg for whatever purpose. So if, for example, you were building a contact form plug-in, you might have a block that represents a contact form somewhere in your piece of content. We'll talk about some of the types of blocks and some of the different, the anatomy of a block, more or less, and then some other features that you're probably going to care about and want to use as you're building your blocks. Before I go any further, can you hear me all the way in the back? Is this good? Should I be a little louder? Little louder? How's this? Better? So let's talk about some of the JavaScript libraries that get included with WordPress, rather, with Gutenberg for you to use in WordPress for building your blocks. The first one is wp.element. And this is a very thin wrapper for React, basically. Gutenberg, on its deep underbelly, is powered by React, if you didn't know that. And the core team went about creating a few abstractions to that so that if for any reason they need to switch away from using React, I don't know, for instance, Facebook introduces a new licensing policy that's hostile to open source, which wouldn't happen again, probably. They could completely gut React from the experience, bring in something else, whether it's Vue or even vanilla JavaScript, and everybody's blocks will continue to work just fine because they were built on top of wp.element rather than whatever the underlying React methods were. WP blocks includes tons of components for building your blocks, for things like alignment controls and inspector controls, which we'll see a little bit more about later. WP components are other generic components that you can use for creating rich text fields and buttons and things like that so you can very quickly build an interface that looks like everything else without having to code up every single aspect of that interface by hand. WP I18n, this is huge. Internationalization and localization has been something you've been able to do with JavaScript and WordPress for a long time, but not in JavaScript. So if you wanted to have an internationalized text string that showed up for like show more, show less on this button that was driven by JavaScript, you had to pass that through via PHP using WP localized script. Now you can just write your text strings in your JavaScript and they will be localized just like everywhere else throughout WordPress, which is really good for internationalizing all of your plugins. There's WP.data, which provides a bunch of Redux state management and then tons of other packages. Basically any React package that exists or any other package that exists via NPM, you can pull in and use for your blocks, which is pretty cool. So let's take a quick look at what's in store for us on GitHub. So if you go to github.com slash WordPress slash Gutenberg, I'm also going to pause here to mention that all of the resources that I mentioned here are all linked in these slides and my slides are all available at wpsessions.com slash WCDET and that'll be on the screen at the end. So you'll be able to get all of this. So if you miss something, don't worry, it'll be there for you. Anyway, at github.com slash WordPress slash Gutenberg, we've got the actual plugin repository where it's being actively developed right now and you can dig into each of these. So if we were to click on, for example, the blocks directory to see all of the blocks that Gutenberg ships with, we would not see any of the blocks that Gutenberg ships with because these are the components that you'd be using to make your blocks. As I mentioned, autocomplete, editing controls, color palette, things like that that you'll probably use in your block but these are not the blocks themselves. What you're actually looking for is the core hyphen blocks directory. This has the audio block, the button block, the gallery block, all of the different blocks that exist in the core Gutenberg editor as you're dropping in to make your content are all defined here in the core blocks directory. So if we were to look at the code block, for instance, here we see the index.js which is the JavaScript that defines and powers how this block works. We see it's style sheet and we have a directory for tests for testing it. There's really good test coverage across all of Gutenberg, which I like a lot. And then if we were to go in deeper and look at the code that runs this block and click on index.js, we would see nothing yet because I'm getting ahead of ourselves. So we'll come back and talk about some of the code in a little bit. The important thing is there are tons of JavaScript libraries that are now part of Gutenberg that will eventually be part of Core that make the development experience so much simpler. Has anybody ever made a widget, for instance, in WordPress or added your own meta box for controlling metadata or your own settings page? You have to roll all of your own UI and build all of your own stuff and thankfully the core team thought through that and provided so many handy tools for us. So how do we get access to those? How do we work with those? Well, all of the JavaScript libraries that I just mentioned are attached to a global object in JavaScript called WP. So you get WP.element, WP.block, WP.i18n. Or if you wanna go back even further, it's window.wp.whatever script that you're trying to access in JavaScript. And you can check all of this out in your browser right now if you've got Gutenberg installed. So if you open up an editor page with Gutenberg loaded and you open up your web inspector tool and you type wp.element or wp.blocks and hit enter, you'll see all of the stuff that's in there or if you need to hit .wp. And so here I have a nice little, here, let's make it for real. I'm gonna type wp.element and look at all of the stuff that's stuffed in wp.element. And then if we check out wp.blocks, like there are tons of handy things that we can just start using. And it's just all waiting for you to use for free, which is awesome. But it gets really laborious to access them. So if you wanna use them in your code, not just fiddling around in the browser, you make your plugin, you register it and queue all of the assets that you need for doing your own stuff and then in your JavaScript, you'll reference wp.element and then maybe wp.element.createelement, which is a function that will generate HTML for you. So you can say I want an h1 tag. So you say I need an h1, it's gonna have these attributes and this is going to be the content of that h1, like hello world or I need a paragraph tag or I need six paragraph tags. There's this handy dandy createelement function that exists for you. You're probably not going to use it too much if you're writing in ES6 and beyond and using JSX syntax, which Kellan is going to show off, because you can just start writing HTML in your JavaScript and it goes really fast. But for everybody else, there's this handy createelement function and so on. But you're gonna wanna rename these libraries because typing wp.element.createelement, every time you wanna use that function, it's just too much work. I'm lazy. I don't wanna type that many characters. Forget about it. And so JavaScript makes it really easy to alias what you're working with. So in ES5 and older syntax, you might say var createelement equals wp.element.createelement. Or in ES6 and beyond, you might extract that method. So you'll say const createelement and I'm going to pull that from the wp.element's object. And in both cases, what you end up with is a variable named createelement that you can just use as a function. So at the bottom, I can write createelement, feed it the first parameter, which is the tag that I'm creating. The second parameter is an object of all of the different attributes that I'm going to use on that tag. And then the final parameter is what do I want to put inside that tag? So this example would create an h1 tag that says hello world. And so you can do this for all of the different libraries, right? You wanna use something from the blocks library. You can say var whatever equals wp.blocks.whatever the thing is. And now you just type your nice short variable the whole way through. Anybody who's been doing anything with JavaScript for any amount of time knows this and I just wasted your time. Sorry for anybody who's new. Ta-da, you can shorten what you're typing. And so register block type, as I mentioned, is the function that you're going to be carrying about the most because this is the one that actually lets you register your block for use in Gutenberg. And I just said that. It has a few basic settings, right? You have to give your block a name and this has to be a namespaced name so we don't have collisions, right? Your contact form block is not going to collide with my contact form block because mine has a namespace of risen and yours has a namespace of whatever before that. And so that's like the ID if you're registering a widget. You give it a title, you give it an icon, you give it a category and this is one of the ways that can look in JavaScript so you give it a name. In this case, this is the core slash code block that I was referencing earlier. It's got a title, which is just code. It's got an icon which uses the dash icons library that's included in WordPress core so you get all of those for free so it's using the editor code icon and it's in the formatting category. And so then on the front end where you're looking at what you're making here inside of Gutenberg we have the formatting category and inside that category we have our code block which has the icon and the title that we specified. You don't see the name anywhere that's just the internal ID for referencing it in all the different places. And then it also has edit and save settings so these are responsible for managing the editor experience and managing what gets saved when the post is saved. And by default all of your block contents get saved to the post content using a mixture of HTML comments and actual HTML which I remember as Gutenberg was first coming into being a lot of people were like, oh no this is gonna ruin all of our structured data. What about all these things that were conveniently put into meta boxes because this was structured data that we needed to have in one certain format. Good news, you can save your data wherever you want. By default it stuffs it in the post content but you could say I wanna save this to post meta. I wanna save this to a custom table. Forget you WordPress, I have my own way of doing things. I'm gonna save the data here. But by default it goes into the post content nice and simple. And so this is the edit and save method for that same code block that we looked at before so the edit method is returning a plain text editor and it's got a placeholder, it's got a label, it's got values and stuff for what this block actually holds and then on save it's just saving out the compiled HTML. So in this case in your content editor you'll have a pre tag followed by a code tag followed by whatever content you put into the block and then it closes both of those tags. And again on the front end in the editor this is the experience you get if we flip back so we created a plain text input that's one of the components that you get for free courtesy of all the libraries which looks like this and you just start typing in plain text and then when you save it the HTML it generates is exactly what we wrote here but it'll also do some handy things like injecting class names based on the block that created that element. So you can easily style things without having to manually type in I want the class name to equal this because you'd have to do that for every single block and it'd be monotonous and WordPress just does it. Easy. There's a few other things for you for free that are kind of handy that Kellen can talk about maybe. But then the most important part of your block are the attributes because the attributes are your variables. These are, if we're thinking about a meta box this is your post meta that you're working with. This is where you're saving the data and all of the different configurable aspects of your block. So in a paragraph your attribute would be the content. What's the content that goes into this paragraph? And so here we have an attribute that's just some editable content. On the block quote block we have one attribute that's the quote, a second attribute that is the attribution for that quote. Attribute attribute. Can I say attribute 10 more times? Nothing confusing there. And so attributes have a bunch of properties. They have a type. They have a default value if you want. They have a source. Where is this data coming from? They have a selector so not only what's the source how do I select that source? And then sources may require other levels of specificity which we'll get into in just a couple of slides here. So attribute types, string, number, object, array or any other react prop type. For the most part you're probably gonna be working with strings and arrays. But you're explicitly saying this is what kind of data that is stored in this attribute. And then sources might be text. So if your source is a plain text editor or rather your block is a plain text editor your source is the text that's inside of that HTML element. It might be the full HTML markup. Maybe it's just one of the attributes of that HTML markup. I'm going to pause because this is very confusing. We're talking about attributes of Gutenberg and one of the properties of your attribute can be attribute or sorry one of your sources can be attribute which means that one of the other properties can also be attribute, attribute, attribute, attribute. We'll look at an example of this in just a second. I think, let me jump ahead. Yeah, I do, okay. So it could be an HTML attribute is the source for this data. It could be children. So like all of the paragraph tags that are a child of this div are what I'm working with. Right, if you have a multi-paragraph editor you want all of the paragraphs. So you're saying, give me this div but I want all of the children that are inside of that div to work with for my data. Or you can write a query that's pulling multiple things for you at once. So you have an attribute that has a couple of properties and so it's just this nested in another level deeper. And then meta as in post meta. You can pull this data from meta and the Gutenberg handbook which is linked at the bottom of the slide and again at the end of the slide deck goes into great detail about all of these sources and how to use each one. And I think Kellen is going to show off a little bit about the sources in his examples. And so then we have additional properties for defining how to get the data out of your source. So I already mentioned selector. That's the element or class name or ID. So I want every div that has a class of alert block. That's my selector and then inside of that I want all of the children. So my type is going to be an array because I'm going to have an array of child elements that exist inside of this alert block that I created which are ultimately going to be paragraph tags. And so if you specified your source is attribute then you also specify an attribute property that might be href. Maybe your block creates a link and so ultimately it's just writing a single anchor tag to the content area where you have an href, a title, maybe some other interesting information. And so when somebody comes back to edit the URL for that link, you need to pull that URL out of the anchor tag. So your source is going to be an attribute and then the attribute property is going to be href. Dragon with me? It's really muddy until you actually start writing it. And then if your source was meta then you also have to define a meta property that is the name of the key that you're working with. So my source is meta and then the meta key that I want is alert block content for instance if that's what I was saving to post meta and so on. There are a few other additional properties depending on what you're trying to use for selecting your stuff. So I've got a few examples that I pulled from Core. So we've got a message attribute its source is text, the type is string and the selector is Gutendev notice. So you can imagine this is, this one's actually not from Core, sorry. This one has a div of Gutendev notice and the content of that is just the text and it's just going to be a string. This one is from Core. And so we've got three different attributes. We have a URL, we have alt text and we have a caption. The URL is a string, its source is an attribute, the selector is the image tag and the attribute that we're pulling this data from is the source attribute on the image. Similarly for the alt attribute we're pulling the alt attribute and for the caption attribute we're pulling an array of children found inside of the fig caption element. So fig caption could have a bunch of paragraphs. We want all of those. So we want every child element inside of the fig caption give me that whole array and that's what I'm working with for the caption data. And so here are all of those settings together. We talked about all of these except for keywords, supports and transforms. So name, description, icon category that's how you're seeing to select the block in the editor. Keywords allows you to specify up to three additional text strings for finding this. Cause there's a type ahead, a look ahead search so you can just start typing to filter the blocks. Thankfully the people who designed this limited it to three so all of the plugin authors who are now adding tons of blocks to their plugins aren't just stuffing tons of keywords into their blocks that it always shows up no matter what you type. So you can have three other things that describe your blocks so that people can find it very easily by typing it. So for Web Dev Studios that just released their own cool block library you can type WDS and see all of the blocks that are available from their plugin for instance even if WDS wasn't in the title of the block. Supports is for defining additional things that your block supports. Right now it's mostly for defining things that it doesn't support like I don't want to support the raw HTML editor for my block. So inside of the supports property I say HTML false so you cannot edit this block via HTML. In the future you'll be explicitly saying yes I do support these things. Just like you can say my post type supports a title, an editor, all of these other things. Now your block can support these additional features. And then transforms is a really cool thing that we're not really going to cover this morning but I want to mention because it's possible to change from one block type to another block type and core does this a lot. If you have say three paragraph blocks and you want to make it a bulleted list you select those just like you would any normal text but there's three separate blocks and you say I want to make this a bulleted list and Gutenberg will change them from three separate blocks to one block that's now a bulleted list with each of those paragraphs as a list item. And conversely you could go from it being a bulleted list to paragraphs and it does precisely the opposite. It explodes the list into multiple paragraph blocks. And so in this you can define how those transforms work because it's all structured data. You're just working with objects in JavaScript. So you can say I want to take this object and make it into this other object. So pass this data to here, pass this other data to there and it does voodoo magic and today you have a different block on the other end. So types of blocks. We have static blocks which are not editable at all. You drop the block in, it does whatever it's doing you have no control over it. Contact form would be a good example of this right? You're not really going to edit the contact form. You just want to put it on the page except most contact form blocks are going to be editable if you're thinking like gravity forms, then you form whatever because you have to select which form you want to show. But you get the idea. You're dropping something in, you can't change it at all. An ad block might be a good example for content creators, right? They've got ads, they just need to drop an ad block in and move on. They have no control over what the ad is. They just need to say I need an ad to show here. Editable on the other hand you can now configure the content. So you've got some editable text like the paragraph block that ships with core and then dynamic where you're saving only your settings because the content itself is dynamic and changing. So if you're pulling the latest posts from the REST API, for instance, you don't want to save those five links in the content editor because tomorrow they should be different. So you just want to say, I want the five most recent posts go and fetch them on page load. And so Gutenberg makes that very easy. You save the attribute data. You don't save any HTML. And then when it renders on the fly, maybe you have server side rendering that builds out what you need, just like you would traditionally with a widget or how you handle meta boxes and ta-da. Here's the final finished version in almost real time for what you need on this page. And we have a few other features that I'm gonna sprint through. You can have the unselected versus the selected state of a block which looks like this. Unselected, it just looks like what it should look like on the front end. And then you click on it and now you see all of the editor controls. The goal of Gutenberg, I probably should have mentioned this at the beginning for anybody who's unclear, is to give you an actual what you see is what you get experience rather than what you see is WTF which is most of what happens when you're working with a WYSIWYG editor. Gutenberg gets really close to giving you a true experience. But you have to hide the editor controls while still making it possible for people to edit things. So in the selected state, they appear. We've got a formatting toolbar which looks like this. So you click in to start editing the text and then the familiar formatting toolbar that you might recognize from TinyMCE pops up and now you can control all of your text formatting. And then there's also inspector controls. So if you click on a block and you look at the advanced settings on the right hand side of the screen rather than seeing the normal publish information for your post, now you can see additional controls just for this one block. You can stuff all kinds of great things in there where somebody might need to control something but there's no good visual way to present that in the layout. You throw them in the inspector controls, everything's fine. So there's a lot of stuff that I just blasted through and Kellen's going to help get you even more lost right after this. But just in case you want some guide posts I have a few additional resources for you. The official Gutenberg handbook is pretty good at describing a lot of the basics. That's at wordpress.org slash Gutenberg slash handbook. There's an even more comprehensive learn Gutenberg handbook that's coming and I know it's coming because I helped write a couple of the chapters but it's not published yet. I think that one's going to land at learn.wordpress.org when it's finally all done that goes into really, really deep details about all the different things. There's a fantastic companion article that my friends at Reactive Studios wrote that talk about all of the different attributes settings because the official handbook is really wimpy when it talks about all the different cool things you can do with your block attributes and then Jay at Reactive goes into great detail about like what if you have this real world scenario? Well this is the kind of attribute you would use and how you would select it. And then if you want the full experience if you liked my slide deck you should thank my friend Zach Gordon because I stole most of it from him. And if I sound smart, it's because I took his Gutenberg development course. I reached out to him, he set up a coupon so if you go to Gutenberg.courses and pick his development course you can take 30% off so it makes it 55 bucks which is a steal. I think it's like 10 or 12 hours of content. Maybe it's less than that, maybe it's eight. I know, it's perfectly succinct and it covers everything. You can just jump right in the middle like how do I make a block? And he walks you through the whole thing, beginning to end, tucks through all the awesome stuff. Very, very good course. If you wanna just dip your toes in the water and get your feet wet, he came to my site, WP Sessions and gave an intro to Gutenberg development course which is somewhere between what I'm presenting and what Kellen is presenting to give you just a little bit more of a picture about what's going on. And that's only 10 bucks? I don't remember what my own stuff costs but it's at WP Sessions.com. If you want everything for this weekend, thanks to me speaking here, you can get everything I offer. I have 92 hours of sessions of other awesome smart people coming to present. You can get the whole thing for 149 bucks and all of that is linked with the slides at WP Sessions.com slash WCDET. Just like the event hashtag. So, thank you. I almost forgot. I am organizing a virtual conference called Word Sesh which has happened a bunch of years in the past that's happening in July. If you like everything that's going on here today, you're probably also going to like that because you can do the same stuff that's going on here but from your home in your pajamas. So you check that out. That's it. I'm going to take a couple of questions while Kellan gets set up but I would suggest that you save most of your questions for him because we'll have a nice big long question period at the end. So does anybody have like some low level easy questions that I can answer right now? Dave. What if I use Divvy? What if you use Divvy? I'm sorry. I'm going to need your diva, no. You'll probably be okay. So there's been a lot of speculation of what happens to all of these layout editors in the world of Gutenberg. Most of them have already started and if they're not they're way behind the eight ball at this point. They've already started working on integration with Gutenberg. So the way you're doing things now will probably still be the way you'll do them in the future but then as they get more integrated with Gutenberg it'll be more like working in Gutenberg and the stuff that you're pulling from Divvy or other page builders will likely just be blocks in Gutenberg. So it'll be the, you'll have the Gutenberg experience essentially but all of the stuff that you liked from whatever your layout builder was. Cool. Any other quick and easy questions? What's the meaning of life? Why is the sky blue? Why are we here? No?