 This guy goes into an interview for a bouncer. And the guy interviewing him sits him down and says, listen, we really need some tough guys. This is a rough place. We need tough guys who are willing to do tough things. What can you do to demonstrate how tough you are? And the guy says, well, here's a story for you. Last year I was out camping alone, middle of nowhere, asleep in my tent, a bear rips into my tent, rips my arm off, runs away with it. I track the bear down, beat him dead, take my arm back, sew it back on, and kept camping for a week. And the guy says, that is the craziest thing I've ever heard. You're hired. And he says, really? Great. So welcome to my talk. I will say as a general PSA, doing a talk like this is a great way to face your fear of public speaking. I would encourage everybody to do it. The topic of the day is Gutenberg for site developers. We saw a demonstration of Gutenberg a little bit in the keynote this morning. I'm going to talk a little bit about it from the angle of people who develop sites, freelancers, clients, or just setting up a site for yourself. There will be a little bit of code, but nothing too intimidating. So before I get into that, a little bit about myself. I am named Michael Dance. I live in DC. I took the train up last night. And I'm a WordPress developer at a marketing agency called Chief. So without further ado, we're all familiar with the old editor. It looks like this. It's very comfortable. It's like putting on a warm pair of socks. There's the title. There's a large WYSIWYG editor that you probably have to type things in and then save and then check the front end and see what went wrong and then type things in again and check the front end again. And then you add some code and the code gets stripped out and you play this little game. But eventually, you get the page you want. And you're happy with it for the most part. Another version of the normal way of doing things for people who are building large sites for clients or maybe very custom sites with custom post types and custom fields would be something like this, where instead of the WYSIWYG, you use a custom fields plugin like Advanced Custom Fields or CMB2. And you add a lot of custom fields. So in this example, it's just a first name, last name, description. You have some radio buttons because maybe you want people to choose between three options. And this is very attractive for developers because you can just hand this to a client and there's very little room to screw up. Just form field, field, field. They press publish. Everything comes out in exactly the location you want it to. They don't have to worry about design. You don't have to worry about letting them worry about design. So it's a pretty nice system. So obviously, Gutenberg's a little different from that. Gutenberg looks like this. This is very similar to the video you saw earlier. But if you weren't the keynote, you can add a title. Everything is block based. So you add content by adding blocks. The default blocks of paragraph block that you can also add headers, lists, images, et cetera. You can add list items here. Since they're blocks, everything can be moved around. You also get settings in the sidebar for changing the colors. A lot of bells and whistles for making paragraphs look different, choosing ugly color combinations. You can also delete blocks if you decide it's too ugly. You can even turn blocks into other blocks. Lots of toys to play around with. So as a developer, I see this. And that pit of anxiety in my stomach, the fear part of me, sees a big problem with this. And it's that clients, there are so many ways for clients to screw this up when we hand over our site. They need handholding. In case you can't read that, that's Homer staring at a computer that says to start, press any key. And he says, well, where's the any key? And I feel like all my clients have run into situations like that where I'm just like, no, that button right there. You want them to make pretty nice, normal-looking pages like this with a wide image and maybe some two different text styles. But something very minimalist and readable. And instead, they're given all these new tools and they build something like this, which is there's like a drop cap that doesn't make any sense. And they found this thing where they can put text over an image, so they just write a lot of text over an image. And this is what keeps me up at night. I'm scared of this happening. So the question becomes, how do you use Gutenberg in a way that is sensible, in a way that you can hand your clients and trust them not to immediately screw up their site? And how to make themes that support everything Gutenberg has to offer, but in a best practice kind of way. So in order to figure that out, we need to figure out what Gutenberg is good for and what it's not so good for. One thing it's good for is unstructured content. If you have pages that are not quite so rigid in their design, pages where you might add certain elements up here, you might want to move them around, that's what Gutenberg's good for. The idea of having blocks that you can add, move around, add some light design features, too. That's exactly what it's there for. Gutenberg is also great for long form articles, the pretty articles you see on Medium, the pretty articles that news outlets come out with sometimes where you have these big images, you scroll a lot, the text still looks good, you have pull quotes that look lovely. That's the kind of solution that's the kind of problem that Gutenberg is a solution for. Gutenberg's also good for media. In the classic editor, it's hard to handle media. Adding galleries, adding wide images, you have to create work rounds and insert short codes. And the Gutenberg interface has made a lot of really nice strides in avoiding all those sort of kludgy kind of interface issues. On the other side of the coin, Gutenberg is not the sun, the moon, and the stars. There are things that it's not so good for. It is good for unstructured content, but as a result, some heavily structured content can pose a problem for Gutenberg. What I'm talking about is if you have a website with a resource database or a staff BIOS page, or a movie library, something like that, where all the movie pages have a poster in one place, and a title in one place, and a synopsis in one place, and reviews underneath. And you have thousands of movies in this example. You wouldn't want to go into Gutenberg and try to recreate that layout for every single movie you add. It goes back to that picture of the custom fields. It would be much easier just to write in field, field, field, and make everything appear how you want it to. Because you want all of those thousands of pages to look exactly the same. So I would say Gutenberg's not so good for that situation. Gutenberg's also not good yet at layout building. I know there are grand plans in sort of phase two of the Gutenberg project, but right now Gutenberg is a fancy content editor more than it is a layout builder. If you have pages with sidebar and content areas, you can't really create that inside the Gutenberg interface itself. It does have a columns block, but that's best used for very simple sort of column layouts. If you try to add a lot of columns or if you try to fit too many blocks into the columns, you start to notice it gets really messy really quickly. So that's room that Gutenberg has to grow. And this last one is more of a philosophical issue. Gutenberg is not simple. It's intimidating at first if you're used to the classic editor. It provides a lot of tools, but as a trade-off for that, it can be hard to approach when you're just greeted with this blank screen and you're expected to know what blocks are, to know what options you have to be able to craft something that looks nice. So given what Gutenberg is good for, what it's not good for, the question becomes how do we integrate that into the sites we're building? So the options we have for using it or not are first of all, using the classic editor plugin. This is maintained by core developers. The idea is you install it, Gutenberg just goes away, you don't have to worry about Gutenberg ever again, and you can just go on your way. The nice thing about the classic editor plugin is that if Gutenberg is released this Thanksgiving, you can install classic editor plugin right now on any maintenance sites you have, and you don't have to worry about anyone freaking out over the holidays, so. Yeah, it's an issue. We also have custom fields. Custom fields still work. Gutenberg is not replacing custom fields. I suppose it can in certain circumstances, custom fields still work, whether you're using the classic editor or Gutenberg, advanced custom fields works with that still. Your meta boxes will appear beneath Gutenberg, or they can also be set to appear on the sidebar. So we still have those tools if we need them. And the most important for me is you can also remove Gutenberg on certain post types. So if you decide it doesn't make sense for the custom post type you're building, you can just turn it off and use custom fields instead, use something else instead. You have the freedom to be able to make that choice about your own content. And the way you do that is just this one line, remove post type support. The first parameter is the post type you're talking about. So in this example, just the post post type. The second parameter is just the word editor. That refers to Gutenberg. If you add that to your functions file, set it up, Gutenberg just disappears from the post edit screen. As a result, the classic editor doesn't come back. It's just nothing. It's just a title and a blank screen other than that. So you're expected to add custom fields to that screen yourself afterwards. That's how you do it for built in post types. When you're registering a new post type, you've probably been familiar with the register post type function. If you've dealt with that before. So that function accepts an argument called supports, which is just an array of features that you want that post type to support. By defaults, it accepts the title and the editor. So it shows you a title field in the editor. So if you just remove editor from that equation, then Gutenberg just goes away. There's also a, I forget the plugin name exactly, but there's a plugin called Gutenberg ramp up. Something like that, that gives you a user interface to turn it on and off for certain post types. So given these tools, let's come up with a plan for how we start working with Gutenberg. Site-wide, if you are running any maintenance sites right now that no one is paying you for additional features, they're just sort of humming along and the user likes the way they work and doesn't want you to do any additional work on them. I would say just install the classic editor plugin, save you and your clients a headache. They can continue working as they have been and maybe you can introduce the conversation whenever you want about them maybe upgrading to the new editor on your and their schedule. For new sites, unlike maintenance sites, I would say track Gutenberg, it's the future. It's about to be released. It's only gonna get better as time goes. So I would say definitely include it in new site builds with the caveat that you only use it on post types that make sense. So let's dig a little deeper into which post types make sense for Gutenberg and which don't. For posts, I'm gonna show just a really basic wireframe of a theoretical design. This is a post screen that's got a normal site header and menu at the top, but the post content itself is just a title. You got some big introductory text. You got a wide image. This theoretical layout is exactly what Gutenberg is trying to solve. It's exactly what Gutenberg is built for. All of these different paragraphs are blocks. The image is a block. You can move them around if you need to. It's very simple, very nice. So for posts, yeah, posts are designed to be used with Gutenberg. Pages, that's a more complicated question. Here's another wireframe. Let's say your designer gives you something that looks like this. The header has like a different background, couple color treatment on it. And it's sort of like this fancy landing page. So it's got some icons on it. It's got this big box that links to another page. And you're trying to think, all right, how would I create this in Gutenberg? It's a landing page, so it would be nice to be able to drag and drop different blocks. But at the same time, like there's no blocks that'll allow me to create some of these things easily. The background color on the header is kind of awkward because like, do I include the text directly underneath the title in Gutenberg, or do I keep those as a custom field? It creates a lot of questions in your head. And I can't answer those questions for you since we're talking about an entirely theoretical design here. So I would say maybe, possibly, you might need to use custom blocks. You might be scared of trying to figure out how to create custom blocks, or you might search the plugin directory for custom blocks that might suit your needs. So that's a maybe, that's a consider this. For custom post types, I was talking about a movie database example before. Here's a staff BIOS page. This is very similar to a page on a law firm website we did where you have the person's name, their title, short bio. The bio doesn't really need to include any pictures in it. You have a list of publications, a list of education credentials. There's 20, 30, 50 staff members on the websites. All these pages need to look the same. You don't want to have to recreate this layout in Gutenberg, and it would be difficult to do that with the sidebar anywhere. So this kind of example is where I would say, probably don't use Gutenberg, probably turn it off for this post type and use custom fields instead. Did you have a question? Share like custom page templates? Yeah, it's, I'm gonna talk a little bit about different classes and things you need to add to make sure that stuff in creating Gutenberg looks good on the front end. But in general, it does a relatively good job of respecting, on the front end, including just enough styles to respect the choices you make in Gutenberg. That's a big topic though. There are certain things it does better than others. Yes? And it might be similar to my property, though. When he gets updated, he says, my website will all get updated. I'm gonna manage WordPress posts. Will that affect my website at all? So, it will not. It's, none of your content will magically change or anything. It'll, it's, once you go into edit existing pages, once Gutenberg is turned on, it'll change the interface in which you have to edit the posts, so it might be unfamiliar to you at that point. But, you know, pages that already exist that you haven't, you haven't added it after the update, they won't, they'll continue working exactly the same as before. And how does it work for the same thing, but I don't know enough about the others? Yeah, so there are a lot of different page building plugins. A lot of them are popular, like Beaver Builder and a bunch of the different building plugins. Those are designed to really create layouts, create very complicated layouts in some cases. And the scope of Gutenberg right now is a little smaller than that. So I would say, if you're already using page builder plugins, it would probably be difficult to transition to Gutenberg just because you have less options right off the bat. But it depends on the situation. I feel better about it. Sure. So, now that we've talked about both types make sense, strengths and weaknesses, let's talk about making a theme actually ready for Gutenberg. This first tip goes back to the idea of making sure your clients don't make interfaces that are too ugly with Gutenberg. By default, in the Gutenberg paragraph block, it allows you to change the background color and change the color. And by default, it includes these various primary colors and basic colors. And it will warn you if the colors you choose creates a contrast issue, if you choose two light colors so that the paragraph isn't visible. But that's limited because you can't ignore it if you want to. And you can still choose ugly colors in general. So if the site has a brand guide or if it has a color palette, you can actually add that color palette to Gutenberg so that the only colors that are available to the user are ones that you know are gonna look good off the bat. So the way you do this is with the add theme support function, add theme support is also used to turn on things like featured images and a bunch of other features that the themes can turn on or off. So the first example is add theme support for editor dash color dash palette. And this basically just accepts an array of sub arrays that lists a bunch of colors. So the each color is given a name, a slug and a color value. The name is what appears when you hover over the color in Gutenberg. The slug is what creates the classes that get the CSS classes that get attached to the paragraph or the block. So in this example, if you have a color called light gray, if you set the text color to light gray, that paragraph is given a CSS class called has light gray color. If you set the background color to light gray, it's given a class called has light gray background color. And the color parameter is just the hexadecimal color code. Gutenberg also allows you to add a custom color. In addition to all the normal color default options they offer, there's a, the last option is just a rainbow where you click on it and it gives you this Photoshop style color picker where you can choose any color under the sun. And you can, you can turn that option off if you want to with the second example, add theme support, disable dash, custom dash colors. Yes, sure. So this stuff, this code you're seeing right now could go in a plug in. The easiest thing would be to put it in your functions.php file in your theme. So just to see the visual of that on the left is what Gutenberg shows by default. On the right is a custom color scheme. So it doesn't give you the option to add any color you want. It only gives you the option to show colors that you've already figured out. One tip is that it's in your color scheme. If you're doing this, it's good to include black and white no matter what, because sometimes you just need black and white to be available. If you create a dark background color, a lot of times you want to make your text white. So remember to include those. Just like colors can be customized, you can also customize the font size options that are available. So on paragraphs again as an example, you can change the font size and by default, it allows you to change the font size to small, regular, large, or extra large. And each of those values has an actual pixel size attached to it. So if you don't like the default size options, you can add your own. This works just like the color palette one. It's add theme support, editor dash font dash sizes. And it accepts an array of arrays that's specified the name, slug, and the pixel size of the font sizes you want available to users. One caveat here, and I'm not expecting you to actually copy down that link. Don't worry, I'll post this slide on Twitter. Themes are responsible for creating their own classes. So whereas the default color options and the default size options are given classes, CSS classes I'm talking about that actually make those colors work. When you use a custom color palette and custom font sizes, you actually have to add those CSS classes yourself to your theme. And you also have to make sure those work in the admin Gutenberg editor as well as the front end. So if you're trying to save some time, you might think, well, I've already added the color palette and PHP. I've already added the font sizes and PHP. Maybe I can just grab those values and auto-generate the CSS classes and yes, you can. I built a picture for that. That's in the gist link you see there. So after this presentation, my Twitter handle's just at Michael Dance. I'll post the link. You also want to turn on support for wide alignments, for galleries, images. By default, when you add images it'll allow it, Gutenberg lets you align center, left or right, but you can also align wide or align full. Align wide, breaks out of your content container to be bigger. Align full is meant to cover the entire browser with. So adding this line will add support for both of those. You do have to add some CSS to make that work and there are examples of CSS you can use to make the wide alignments work in the Gutenberg handbook on WordPress.org. So editor CSS, if you want the Gutenberg editor to look even more like your front end, incorporate the same fonts and styles. In my experience I've had to use both of these lines, so add editor style is what actually loads the file called editor-style.css in your theme and then adding theme support for editor styles, what that does, even though it looks a little redundant, is it what we call namespaces, the other styles you have in that file into the Gutenberg interface. So what that means in slightly more layman's terms is instead of having to override a bunch of styles with a bunch of very specific class names that already exist in the Gutenberg markup, this just makes it easier for your changes to actually show up inside the Gutenberg editor. So I just mentioned the handbook, here's a link to that. The documentation is not wonderful yet, it's, you know, Gutenberg hasn't even been officially released in WordPress core, but this particular page is good, it's been very valuable to me in terms of approaching building a theme. So one of the more advanced things, one of the more maybe experimental things that Gutenberg offers is also block templates, where if you don't like the idea of giving a, just blank canvas where people can add blocks wherever they want, you can actually pre-populate blocks onto certain post types and you can even prevent users from moving those blocks around. So what that looks like, when you're registering a post with a registered post type, this example just uses a post type called resource. There are two arguments you can add, one is called template, which just accepts an array that you're gonna look at on the next slide. One is called template lock. If you add template lock, then any of the blocks that you pre-populate, if you set template lock to all, then it will not let users move around, add or delete any of those blocks. If you set it to inserts, it will let users move around blocks that already show up, but it won't let them add any more. And if you just leave it out all together, then users can remove any of the blocks that show up. So here's what template, the array for the template actually looks like. This is just a PHP representation of Gutenberg blocks. Each block is an array. The first parameter in the first element in the array is the name of the block. So core slash heading, core slash paragraph. The second element in the array is just a list of attributes, each block accepts different attributes. So in this example, we're adding a heading. We're setting the heading to be called description. Underneath that, we're adding a paragraph. We're putting a placeholder in the paragraph that says enter this description. Then there's a separator. Then there's another heading called download. And then there's a file upload block. So in practice, if you actually call resource and add all this, it's gonna look like this. Where a user goes to a resource and everything's already laid out for them. And kind of a style similar to that you might be familiar with with custom blocks or custom fields. So they can add a title, they can add a description, they can add a file, they can publish. And it takes a lot of the guesswork out of creating their own Gutenberg blocks. Yes, this is just core stuff that would show up. You can still add custom fields to Gutenberg pages, but they'd appear below the whole interface. So considerations about custom blocks, block templates before you use them. Just remember that you can only create templates for the blocks that are available. And if you try to create complicated layouts, you'll find that there's basic blocks that you might be, you might still think in terms of custom fields, in terms of single line text fields that block doesn't really exist in Gutenberg. You only have the paragraph and heading blocks to work with. You can't add labels that users can't change. You can't sort of hard code anything if you're used to doing that. Nested blocks don't work very well when you use block templates by nested blocks. I mean stuff like columns where you can insert blocks inside other blocks. I've found that the template lock argument doesn't hold for columns. You can still add and remove blocks inside columns even if you have template lock turned on. But as a caveat to all of those caveats, I would say the template functionality has expansion plans. If you look in the documentation they're talking about, allowing users to create templates for individual custom page templates. So when you're creating a page, you can say this is a landing page and then it will show a list of blocks just for that type of page. So I would sort of keep an eye on this even if you don't find a usage for it right now. So final tips since I'm running out of time. For a project in Flux, source code will be way more helpful to you than documentation. You can find a lot of tutorials on Gutenberg out on the internet right now and a lot of them were written six months ago and a lot of changes have been made since then. A lot of things have been deprecated and added since then. The best way to actually get sort of a decent handle on Gutenberg is to look at the source code itself. It's all on GitHub. You can follow issues. You can look at components you don't understand. It's kind of intimidating since a lot of it is written in React and a lot of us are PHP developers. But the more you look at it, the more you understand. And it can answer questions that right now documentation can't. Sort of as a to be continued of this, I would say learn how to create custom blocks. So you can be empowered if the default blocks aren't cutting in for you, if you need to create a block for a call to action or a contact form or anything your site needs. I've started getting into this and once it sort of clicks how to create custom blocks, it can be very nice in terms of the user experience and in terms of just making you feel powerful. So maybe that'll be a future topic. I would also say expect things to take longer at first. This is the fact of life. This is complicated software. Some people are gonna be intimidated by it. Making sure themes account for the pull quote block, the different paragraph colors. It takes a little while to wrap your head around all this and I think you should embrace it, but also be realistic about the fact that the first few times you use Gutenberg, you're gonna be researching a lot of these questions, you're gonna be figuring things out on your own and things are gonna take a little longer. But I would say that as site developers, larger, small, the more we use Gutenberg, the more we can drive its evolution. We can figure out best practices right now for it. We can figure out pieces where it needs work. We can figure out pieces we like and the more we use it, the more we can be a part of that conversation. It's really a huge opportunity to help drive the evolution of Gutenberg and WordPress as a whole. So with that, does anyone have any questions? Yes. The categories for creating new blocks. Right, all that really does is when you add a new block, it controls where it's placed within that little pop-up window that shows up. Yes, in the center, up there. You, yeah. Well, that depends on how you do it. In general, all of it, pretty much. There are some major caveats to that though. There's something called server-side rendering where the output of the block can be created inside PHP. So if you're interested in that, just look up Gutenberg server-side rendering. If you're a fan of advanced custom fields, in the new pro version they have coming out, they also have a way to create custom blocks purely in PHP that avoids the React question in general. So if that sounds interesting, you should check that out too, in the front. In terms of taking an existing site that is going to be updated to do the work, we then have the option to pull out of the page or a post from the old website and now it's opening up the vault into Gutenberg. That's true. Yes, they've experimented with some different ways of doing this, so I'm not entirely sure, but there's a block called, there's like a classic editor block where if you open up an old post, that post will just show up inside a classic editor block inside of Gutenberg and then you can have the option of converting that to normal blocks. I believe it was, yes, restrict like which blocks show up. I have to believe the answer is yes, but I don't know how. That is a great question though, I'm gonna look that up. Yes, I experimented in a very limited way with that, mainly I just know that it's possible, but I think that is really useful because right now the blocks get stored in this big HTML content entry just like old content did. And obviously some fields you want inside certain layouts, you also want available as post meta so that you can control ordering posts by event date, stuff like that. So yes, you can create blocks where you save certain items within blocks, not only in the block, but also as post meta. Yes. Yeah, are we talking about like video embeds or? Right, so well, I guess it depends. So for things like video embeds and tweet embeds and a lot of the basic stuff, there are actually blocks for that where you can just add a YouTube URL when the video will show up as soon as you do. For stuff like more complicated situations, I know both the classic editor and Gutenberg can be a little iffy about data and stuff. When I'm in a situation like that, I usually just create a short code that users can add that the output of the short code itself is where all that code goes, just to make it a little easier. But again, it depends. Yes, red jacket. I would say the line I've heard from WordPress core is that it doesn't really require much effort to keep classic editor running. Gutenberg was basically built on top of that, but all the files that made the editor work, which is what the classic editor was, that's the technical name for it. All that files is still there. So the classic editor plugin, may need minor updates in the future just in terms of turning off certain Gutenberg features, but it's expected to be available for years to come. That's what I've heard. Yes, I believe that it's hard coded. There is a new feature in Gutenberg called, this might be slightly different, but there is a feature called reusable blocks where you can add blocks that appear across multiple posts and if you edit them in one place, they get edited everywhere. So that might be an alternate way of doing things, but yes, I do believe that changing HTML will only change it for new instances of the block. Yes, yes, it does. And it also has, even while you're editing a post, it has better undo, redo functionality as well. Yes, there aren't, you're sort of expected to do that yourself. There aren't like built-in options for, you know, I want a paragraph to look this way on mobile sizes and this way on large sizes. You're still expected to build all that logic in your style sheets in the back. That's a good question. That's a huge question. Yeah, I've been following the accessibility thing too. It seems like they're responding to it fairly well. Just I, you know, certainly haven't dug deep into this, but there is, you know, some basic accessibility features that you would expect like keyboard tabbing does work. But in terms of, you know, trusting your users to create, you know, semantic content, that's probably going to be the same struggle it was before. One of the nice features of Gutenberg is that if you add headings that are, if you jump from like an H2 to an H4, Gutenberg has a little table of contents feature that'll show you that you use the incorrect heading level. So that's a bonus. But in terms of, you know, making sure images have alt tags, that kind of thing, I think that's still something we'll have to deal with, with educating users to do that. Great. Well, thanks very much.