 So anyway, welcome. If this isn't the talk you wanted to be at, too bad. You're stuck with me. Or you can leave. Let's see this. So hi, I'm Michelle. I design and build digital interfaces. Lots of other things about me. But I don't want to talk about me too much. I actually want to hear about all of you because I want to know who I'm talking to. So how many of you build themes? Or have built a theme, right? Cool. How many of you either work for yourself or run a small agency? Like, not a line, yep, nice, awesome. And how many of you, if you don't do those things, are thinking of doing those things? Excellent, so you're in a good place. I like to know who I'm talking to, right? How many of you have heard of a concept called the hero's journey? It's a literary concept, also known as the monomyth, which our hero embraces a disruption, faces challenges, and comes out transformed? So in the hero's journey, if you don't know about it, the protagonist has to leave their ordinary world to go into the special world for challenges and growth. And when they return to the ordinary world, they are changed. So what I'm going to do is I'm going to take all of you on a hero's journey today of transforming into a full-site editor. This will cover a lot in a short time, and I will not be able to teach you how to do everything, but I can give you a framework of how to tackle it from the beginning. So in the first stage of the journey, we meet our hero. And this is where we learn more about our protagonist, who, in this case, is us, the independent theme developer. So tell me if any of this sounds familiar. Many of us probably weren't necessarily developers before we came to WordPress. We have many different backgrounds. And we're probably wearing many hats, right? Maybe development, design, content, support, consulting. We need to worry about everything and get it all done. And maybe we have to support a family or have really interesting hobbies. Like, we're doing this for lots of reasons, and we're doing a lot of things. And we've also fine-tuned our workflows to suit our clients. We know our clients really well. We've figured out intake, build, training. We've kind of figured out our own suite of tools, right? Themes, plugins, et cetera. Maybe we have preferred custom field managers or page builders we like to use. There's definitely specific plugins or other tools that we use pretty frequently. We know exactly where to look for things. There's mature documentation around it, right? WordPress has been around for a while. We know all the languages that we're working with, maybe HTML and CSS, WordPress-flavored PHP, basic JavaScript or jQuery. We're really comfortable in our world. Things make sense. Things are working, right? We've been doing it. And then what happens is the call to adventure. And this is where the hero's normal life is disrupted and they are called to take a journey. In this case, it is the merge of the Gutenberg project into WordPress Core, and then again, with the release of full-site editing. We've had two calls to adventure so far. And the call to adventure is supposed to be appealing, right? There's something interesting about it. So why is this appealing as a service provider? Well, what's kind of cool, like, everything's accessible to the site editors, so there's less gatekeeping, there's less them coming to you all the time with small changes. There's a better user interface for managing long-form content. You can quickly build these really cool, big layouts. Talented clients can be empowered to make their own content layouts, right? And it's a lot closer to what you see as what you get. And as a developer, this is also kind of appealing because many layouts that used to take a really long time to have to custom build can now just be done really fast. Colors, typefaces, and other global styles are easily registered and available with the front end and back end. So again, doing stuff to keep people on brand and global styling within a JSON file is more closely aligned with other non-wordpress naming frameworks. So that's kind of cool. And this feels like an inevitable journey, right? Like, this is gonna happen. This is the way forward for WordPress, but it's still a really difficult choice for many of us who are used to living in our ordinary world. So the next phase is the refusal of the call. The hero is hesitant to begin the journey because they don't feel ready, they don't feel qualified, or they don't wanna leave their current life. And for us, there are also a lot of reasons to be resistant to this change. So why isn't this appealing as a service provider? Well, it was great that everything's accessible to the editors, but also everything's accessible to the editors, right? It's not locked down. People can maybe mess things up. Some interactions are still glitchy. They're not great. Inserting blocks can be kind of rough. I have a lot of opinions about the navigation block, being kind of glitchy. Some things like responsive and interactive features are still an afterthought. They're not quite where we want them to be. It sometimes feels still like beta software. There might be breaking changes, items moving around, and that means more client support requests. As a developer, there's also a lot of reasons why it's not very appealing. The documentation's kind of inconsistent. Like, how do I figure out what I'm doing? We're changing languages now. Instead of HTML, CSS, PHP, we're doing this weird markup and compiled JavaScript and JSON. This is all new. We have to learn and add new tooling, which is a whole thing in and of itself. Not all of the core functionality is available to us or in not in a way that we expect it to be. Our system of hooks and filters and everything are not as available to us as we're expecting them to be and it just doesn't feel as fully mature as classic WordPress is yet because it's not. And things keep just getting added. So how do I even keep up? I think that's one of the biggest resistances, especially those of us who either work for ourselves or run small businesses, is like, do we have the resources to keep up with all of this stuff? No one's paying us to learn all these new things. This is all time we have to spend. And especially for those of us like me, who came from a non-development background and were already self-taught, feeling like we have to learn something all over again is really scary. So in the hero's journey, what happens at this stage is the hero needs to meet a guide or mentor in order to get the confidence or resources to begin the journey. Maybe this talk is your catalyst. Maybe you've already seen some really great tutorials and resources out there, but the important thing is that the hero, who is us, needs to find support. And there's lots of great places out there to be able to find support. There's several different social or Slack communities you can be a member of. Again, there's lots of different tutorials and talks out there, whether through WordPress TV or through other platforms. And there's a lot of things that we can learn to do as independent theme developers and people who have clients. One of them is learning to manage expectations with our clients. Can we sell, update, or maintenance packages to help cover the time and costs for doing this stuff? Can we outsource or refer updates and maintenance to someone else if we don't want to keep maintaining that stuff? Can we take on projects that maybe push ourselves a little bit out of our comfort zone and pay us to learn some stuff? I usually try to do projects that give me like 20% things I don't know how to do yet and 80% things I do know how to do. It feels very comfortable. I can do that within the time. And also, remembering that you don't have to do all of this all at once. Again, this journey, which we're going to go on, you can take it at your own pace. So now that we've kind of refused the call to met our mentor, got some support. We feel ready to get started. So yes, I think we want to begin. And this next step in the hero's journey is known as crossing the threshold. This is where the hero decides to take the journey with the support of their mentor or their guide and with appropriate supplies like those snacks from the hike they embark. And for the theme developer, this will be your first foray into the block editor. Kind of just to see what new paradigms there are. And we can look at the interface with curiosity and the desire to learn. So we're going to look at it first as a power user. We're not going to build anything yet. And so what do we need to do that? We need a fresh install with the latest core theme. You can either set it up in your favorite local development environment or there's this thing called the WordPress Playground which is pretty cool where you can do it all within a browser and you can just kind of learn what there is. How many of you like have experience with the block editor so far using it or whatever? All right, great. I'm just going to go a quick overview for maybe some stuff you don't know, maybe some stuff you do. But the first thing we want to do is learn where everything is in the post editor, right? Because if we're going to be training our clients to use it and we're going to be building for it, we should be an expert at it ourselves. This is especially important if you're familiar more with classic WordPress or you're more familiar with maybe a specific page builder you've been using. Many of the classic editor pieces are still there. Like the content editor and all the page settings, they just look a little bit different. There's a bunch of new elements that have been added. So we have the block and pattern inserter, that's a little plus. We have our tools, which also used to exist, document overview, that one's fun. It's where you can get like a list of all the blocks that are on your page. The view and preview buttons we still have. Now we can kind of pick which view we want to have it in, mobile tablet desktop, preview it in a new window. Our settings live over here, so if you don't see a sidebar, that's the button you need to click to see your sidebar and then we have our screen options, which we used to have as a little tab and now they're in this little dot menu. So these things all still exist. In addition to the page settings, which we're used to seeing as part of classic WordPress, the block editor adds a whole bunch of block settings, which are contextual based on which block you have selected. Each block also has a toolbar that is either right above the block or docked on the top menu, depending on your global settings. You can choose whether you want to have it. So this one's right above the block, as you can see in the picture. But you can also move it so that it always shows up in the top bar depending on how you like to work. Many blocks also have all their more complex options in the block settings sidebar. This is an example right now for the cover block. So it's important to kind of study which settings tend to live in which spot. So here is the block settings, they live over here in the block toolbar, either lives there or on top of the content. And now we're also looking at the block pattern media insertor. This is the menu that contains all the blocks and patterns and stuff that you have available to us. And that lives in a lot of different places. It always lives in the upper left corner, lets you browse all the block patterns and media on your site. A small insertor also exists when you hover over the content. And you can also, if you have like a paragraph block selected, you can insert a block within your content by typing a forward slash and just showing a type. I use that one a lot, that's super fun, but there's several different ways that you can insert blocks while you're inside the editor. I mentioned before the list and outline view. I think this is an extremely useful part of the editor for both yourself and your clients. List view is a really useful way to see all your nested blocks and to select or move around specific blocks or multiple blocks. And I think this is getting even more useful as time goes on. Especially if you have a ton of blocks, like this isn't a very complicated example, but I have some where there's like 30 or so blocks on a really long piece of content. This is great. And then the outline view shows you some more interest information like your text hierarchy, how your headings are nested, what your word count is, et cetera. But it's also really cool that is going to be coming out in 6.4 is if you use a lot of group blocks, they're letting you give custom names to group blocks. And so now in your list view, you'll be able to see like here's all the custom names and that's just way more semantic than group, group, group, group, group, group. So I'm very excited about that. There's lots of other screen options but I wanted to specifically call out switching between the visual editor and the code editor. This might actually be your first time seeing block markup, which this is the exact same thing where if you're putting it in your theme, this is what it would look like. This is really helpful later when we're building and customizing templates and blocks because you can build it here and you can just see what all the markup's gonna look like. You can copy it right from here into your theme if you wanna build stuff in the visual editor, kind of fun. I also just wanna call out the concept of block locking which prevents movement or removal. This is something you can do in here and this is also something as a developer that you can do inside your theme. So again, when we're talking about not giving our clients all of the control that they possibly want, this is a great way to prevent them from doing that. So that was the post editor and now we're moving to the site editor because we're talking about full site editing. This is only accessible within full site editing themes so it has to be a theme that explicitly supports this and this is where you can actually create the theme itself. So you have the option to edit and create templates. So you can actually edit templates that are created by the theme in the editor and it saves the changes in the database and you actually have new changes to your theme. There's some new tools that came out in 6.3 that I can kind of show you right here. You can edit and create patterns in 6.3. These were changed reusable blocks were now called synced patterns and then unsynced patterns are patterns. Not confusing at all, it's totally fine. And then this is also where you can edit your global styles. So these are the things like your color, your typography, et cetera and they also moved navigation and pages over here in 6.3. So now we have the template editor. Template editor lets you see every template and also where it came from. So you can see like they could come from the theme, it could come from a plugin and customizations in the database. You can see one of these examples here was customized which means that I've done something to it that isn't part of the theme. You can also add new templates that don't exist that your theme didn't provide a template. You can create one right here. And you can also create custom templates that you can assign to individual pages. So that's like a classic WordPress thing that we're used to. Yes? If you wanted to ship this can you save as child? There is, so I'll talk about it a little bit later but yes, there's something called create block theme that makes it really easy to export all of your changes into either a child theme or a full theme or overwrite your, you know, there's lots of options for exporting this. You don't have to have it live in the database because we all know that version control and databases work together very, very well. If you've been watching block editor development for a while you might have seen the concept of reusable blocks which is where, you know, a set of blocks where when you change the content it updated everywhere on the site. Template parts and reusable blocks have now been merged into this concept of patterns that are either synced or unsynced. So a synced one is something where the content will change when you change the content and unsynced pattern is like you insert it and then it just becomes a set of blocks that you can keep using. But anyway, this is where patterns live here. And then again, like I said we have our global styles and variations. So this is color typography layout padding spacing, all the different things that apply that we will learn later live in theme.json but this is where they live as a visual thing. So I'm gonna go to our stats screen. Now I'm gonna show you some stats screens for each of these phases. So what are the benefits and obstacles now that we have kind of gone through this? Well, benefit is, you know, we get to understand the new interface from a client perspective which means we can offer better training, we can understand how their workflows are gonna change, we can answer their questions. As a developer, you know, we'll kind of know what's already available in core and plugins, et cetera, what things are missing and lacking. You know, not too many obstacles right now. So you can see we kind of have low stats on the change and time investment. It takes a little bit of time. You know, we had to go through all of that stuff and become an expert on it but we haven't really committed to doing anything yet. We're just playing around in a playground so that's not that bad. Next phase of the hero's journey. This is the test allies and enemies. This is where we kind of face all of the challenges and forge partnerships on the journey. This is where we have to actually start changing what we're doing to support the block editor. So now we're actually gonna start adapting our workflow. The most basic change that you can do without doing anything else in a traditional PHP theme is just adding these theme supports. This is, we're all used to doing this for lots of different things. This is not necessarily what I would recommend. This is the lowest, lowest possible thing you can do but what I actually would recommend you do is add a theme JSON file to your traditional theme. This actually replaces most of the add theme support stuff that I just mentioned on the previous slide. And these are the things that are found in a theme JSON file and the templates and template parts are only relevant once you get into full-time editing so we really only have to look at the settings and styles first. So again, like I said, these settings replace a lot of the stuff and add theme support and this is where you can kind of enable and disable different features. This is where you can set all your different presets. So again, color spacing, font sizing. You could also set a lot of block level controls for what you wanna have and this is also where you can set up your preset and custom variables and this is important to talk about when we're starting to move into embracing full-time editing because this is where some of the magic happens in terms of being able to interact with colors and styles and stuff in the editor and also in the theme. And again, like I said, I'm going to be going through all of this at a really high level. These slides will be available. There's a link to them so you can see them. So I understand that this is very fast and it's a lot to take in but I just want you to kind of go on this journey with me, it's super fun. So I wanna mention specifically theme JSON and how it's going to interact with your CSS. So if you're a theme developer, you probably have been writing some CSS, you have it, you know, it's already packaged up with your theme. The part of this, the part of thing you have to do in this part of your journey is change your CSS to support these variables that are being generated by theme JSON. It might feel like a lot of work at first, especially if you're more familiar with doing it kind of the traditional way but this really helps in the long run because what this does is as you change the stuff in your theme JSON, it will update what your CSS is doing. Theme JSON is generating some CSS for you and it's generating a whole bunch of variables. If you're using these as you keep evolving your theme, the theme JSON and your theme will kind of like work together really smoothly. So some of these other variables again are built into the settings and these will have this WP preset prefix. So they have this WP preset or custom and then what section it's in, like how nested it goes, the double hyphen, you're gonna get used to seeing that versus if you create your own custom variables which you can create whatever variables you want which is great because full site editing doesn't have presets for every single thing that we might have an opinion about. So then it would say WP custom, whatever nested thing, whatever nested thing has a very good explanation of that. But again, this means that it's really easy to make changes to your theme using the JSON instead of having to update CSS everywhere. And these are the default global styles and block styles. So you can set styles on a per block basis as opposed to just on a whole theme basis and you can interact with these styles in the editor as well as in the JSON. So I have a couple of resources. These are really great tutorials on converting classic themes to block themes. Again, all of these slides are gonna be available so feel free to take pictures if that's how you like to learn but also I have it all for you. These are both great if you want to go deeper into this process. Okay stats, where are we at? So there are a lot of benefits here. Well now we have opened up the block editor for our client and developer use so that's really great. We're able to provide some branding control within the theme styles so we can ship them something that matches all of their branding. We do have to work to CSS and add all the theme JSON so there is some time involved in that, right? So there's a time investment and we do have to make sure everything looks the same. That's a little bit of QA. But we don't have to change the rest of our functionality. We haven't touched any of the PHP. Still works exactly the same and we can also choose not to support certain elements like alignment or whatever. We don't need to have it full width support if that doesn't look good with our theme so we can really ship things that work. All right, next phase, approaching the innermost cave. So this is the phase where the hero is getting close to the ultimate test and so the trials are getting harder. We are going to start doing block editor development that doesn't involve JavaScript. So what do we have available to us here? First thing is block patterns. Patterns are preset groups of blocks. Now like I said, we can build those in the editor and save them in the editor. I showed you that interface but you can also build them in code. Core already comes with several. There's a few different ways of registering patterns but this is a great way to make the UI more useful for clients right away. Without ever having to build a custom block you can build some custom patterns. Like I don't know what's a common pattern. Three columns with some images and text in each column. Why don't you ship them that pattern? That sounds great. You can also like I remember I showed you that code view before, you can build the pattern in the editor and either save it or export it right out of the editor and include it in your theme. So again, we don't have to be writing anything yet. Another great one that I use all the time right now is block styles. So these are very simple to register. Basically what you're doing is creating some preset CSS for these blocks or JavaScript if you want to. This is basically just a little stand in for you can also like add a custom CSS class to a block manually but like why don't you just give them a button to click on and say like hey I want it to do this instead. Really simple. You can create lots of visual variants to existing blocks. So that's awesome. Block templates and block locking. So remember I brought that up earlier, locking blocks. You can create pre-populated templates per post type. So now instead of your clients opening up just a blank screen and being like what do I do? You know they can open up their post type and there's already a bunch of stuff on the page. That's really, really useful. And again, we are still not writing any kind of new kinds of code. This is all still in PHP. You can register it when you register the post type or you can register it as its own function. And you can also lock blocks within the code here similar to what we saw in the editor to prevent people from taking away things that they shouldn't be taking away. So again, like helping our clients be able to create new stuff. If you already use one of these tools there are a few different platforms that let you create custom blocks using PHP. So this is nice. I used the ACF blocks for a while. It's a great addition to your workflow being able to quickly create custom solutions without having to learn new stuff. So if you're already using one of these I would highly recommend checking it out. Downside as they can be a bit slower than native blocks just because they have to go through some extra stuff. If you have a lot of them on one page there might be some performance issues. But again, for smaller sites or one or two custom things this is really awesome for being at this point in your journey and being able to create some custom stuff. All right, stats. We're not changing much about our theme yet. We're just adding some stuff to it. And what's nice about this is it can be as much or as little as you want depending on your client needs. You can see there's a little bit of change, a little bit of time. We're providing some customization options for our client. We're being able to give our clients different controls and guided options. But again, a little bit of time to set up. We do have to learn a little bit of new stuff and we're kind of starting to look at this new markup syntax and playing around with that. All right, so now we hit the thing called the ordeal which is the hero's biggest challenge, right? We're fighting the dragon. And this is where we are building our first full site editing compatible theme. So the whole thing, changing it all, let's do it. The first obstacle is learning block grammar which is the thing that we have. There are many opinions about, yes. Block grammar is this kind of special JSON HTML comment thing that we have to write theme templates. We get to learn about things like self-closing ones like WP searches, self-closing, versus containing content. So this paragraph you can see contains some content. And again, they are written inside HTML comments. Again, this is where the code view I showed you earlier is very helpful because you can go see what everything looks like. I gave this talk at WordCamp US not too long ago and one of my complaints was that it's really hard to write this because there's no syntax highlighting. We're writing comments and so the whole thing is great. So my partner and I decided to solve that. So if you run VS Code, we put a VS Code extension for doing syntax highlighting. Yay! Which looks a lot better, you know, completes your JSON and stuff. So if you want to download that, if you use VS Code, go for it, it's a tool that we made available. Hopefully you like it. But anyway, so now we're writing this block grammar and we're writing block themes. So the biggest change is now we are writing HTML files instead of PHP files. We have a new folder structure. So we put our templates in a folder called templates. We put our template parts in a thing called parts. Themes also need a style.css and functions.php and that theme.json that you have already worked on. We need that too. Otherwise, templates follow a similar template hierarchy to classic themes. We kind of saw a lot of that earlier when we were looking at the editor. Parts, if you've been doing theme development, you're familiar with the concept of template parts, reusable things like headers, footers, comments, et cetera. And everything else is made of blocks. And I wanted to bring up again, you can build your own through writing it in a code editor. The syntax highlighting should help with that. Or you can build things directly within the editor and export them using something like create block theme. Yes. Yes. Yes, template file names are very similar to the old ones. So if you follow the template hierarchy before, you'll be able to write similar things. It would be like archive or specific type of archive, right? To learn more about that, here's some really great resources about templates and template parts that can go into more detail than I can do in this talk. There are still ways to use PHP templates within full-site editing themes. Sometimes full-site editing can't do every single thing that we want it to do yet. And so this is something where you can use them for more complex interfaces where maybe editing the theme template isn't necessary. So your clients will not be able to edit this template like they could in a full-site editing template. But you can mix block content and traditional PHP content. So again, this is really nice if you don't already have all the JavaScript skills to build a bunch of custom blocks to do everything. You can build a PHP template. These are not editable in the full-site editing editor. There are workarounds necessary. There's some weird stuff you have to do about where you're echoing out the content and how it loads assets. This article, again, full-siteediting.com, by the way, if you haven't been there is amazing. It's basically the only reason I can do my job and I very much appreciate it. So this article tells you about how to use PHP templates in block themes. So if you're getting frustrated because a block theme doesn't quite do what you need it to do, this might be a good workaround for you. All right, stats time. We're getting up there in terms of time investment, but of course, that makes sense. We're fighting the dragon. This is hard. This is one of the bosses that we have to beat. So it is a high level of time and investment to rebuild an existing theme as a full-site editing theme or to build a new theme from scratch if you don't want to rebuild your existing theme. This is probably the greatest deviation so far from what you've been doing as your previous workflow because we've changed languages at this point. We do have to learn a new syntax. We have to learn block markup, which again is kind of like a hybrid of comments in JSON. So not too bad, but is something that you have to learn. And there is a bit of trial and error when the markup is wrong because unfortunately what we get is a white screen. We don't really get useful error messages. Maybe you'll get a console error that might tell you something. So it's a little bit of a struggle. You can see the benefits are good. It only says one benefit. That's like a really good benefit. That's like a big benefit. The obstacles are hard, but I think doable, right? So at this point in the hero's journey, the hero sees the light at the end of the tunnel. We're getting the reward. We are now officially building things the new WordPress way. We are great. We are a full set editing developer, but there are still limits to what we can build and customize using the tools that we have learned so far. And the hero's journey isn't over yet. There's still several little bits left. So we are now at the road back. This is where the story is not over. There's more for the hero to face. To keep going on our journey, we must now face JavaScript. So here's some simple starts to getting into compiled JavaScript, right? This one's not even compiled JavaScript. So we can use JavaScript to register our block styles instead of PHP. You can still use them with PHP, but if I wanna start getting used to writing JavaScript, I can use JavaScript to register my block styles instead of PHP. We can also start creating block variations. I really love block variations as well. I think this is like a very powerful tool to customize core blocks in more ways than just visually with styles. Groups are a good example of a core block that has variations. You've seen them already. If you've ever used the editor, you can do a group, you can do a row, or you can do a stack. Those are all the same block. They're just variations on that block. I've really enjoyed using block variations to write custom query loop block variations because I think that's like a really powerful spot to put them. Maybe you can set different preset interblocks for them or you can pass them different parameters to order them maybe by metadata or by descending order, by title instead of the defaults. So just like a powerful way of extending this without having to fully write custom blocks. And these can also show up separately on the inserters. So you can see like my blog post cards and my blog post carousel. Those are custom query loop blocks that show up in the inserter as a block. But I didn't write a whole block. I'm just making a variation on the query loop. Probably the biggest obstacle here is dealing with transpiled JavaScript. So if you are not used to working with build tools, you have to work with build tools now, which becomes a large percentage of your life after this point. So everything can be written in standard JavaScript like ES5, but many things become a lot easier when you're writing in ES6 and JSX. There are like syntax extensions to JavaScript that are not currently readable in browsers, which means they need to be transpiled into regular JS for now, which means your project needs build tools. And learning how to set up and configure build tools is a whole talk in and of itself, maybe more than one talk. And there's many tutorials for this, but I will say that WordPress has a WP scripts package containing the tools that you specifically need to build, watch and lint for WordPress. This includes JavaScript as well as if you have any compiled CSS. So I like the WP scripts package, I use it. These tutorials will tell you a lot more than I'm going to tell you right now. But once you start interacting with WP scripts and you're doing transpiled JavaScript, you have a whole bunch more options when it comes to custom JavaScript code for UI, and you can interact with other pieces of WordPress JavaScript. This tutorial series, I loved it, it was really cool when it came out. It's a great example resource to get started with the build process and converting that to new UI elements. Like this example was like, what if I want to be able to pick emojis for my divider and I can provide this whole entire UI and it's not a custom block. It's just custom UI for blocks that already exist, so it's great. Stats. Okay, well, setting up new tooling can take a long time. Fortunately, there are plenty of tutorials and resources for it, although it will probably also take some trial and error. And the nice thing is once the tooling is set up, once you've gone through that whole process, you can use it again and again. So it's mostly an upfront investment, not too much troubleshooting after the fact. So many benefits. You are now able to provide so many custom things. It's amazing. And what you're doing is more seamlessly integrated within the UI. I especially recommend that last tutorial to show how they transformed from block styles to this custom selector UI to make it better for the client. Love it. You are gonna have to start getting familiar with the command line interface if you aren't already. I mean, as a person who came from a UX background, like I do not love command line interfaces, but I have learned some of it. Again, setting up build tools is a whole thing in and of itself, but I believe in you. I believe you can do it. I believe you can deal with package and dependency management. You won't lose too many afternoons to it. It'll be okay. But then the hero has to face their final battle. This is where they take everything they've learned and they faced their biggest challenge so far. In this case, that would be building custom blocks. And it is possible to do all of the other things on this list and never build a custom block. However, much like learning to build custom themes or plugins with classic WordPress, we probably have found ourselves here because the things other people had already created didn't quite match what we needed. They were like 90% good. We needed it to just be a little bit better. And this is why we probably have to maybe think about building a custom block. I wanna mention, again, this is multiple talks worth of talks that you could go see, but I wanted to just let you know that there's a couple different kinds of blocks that exist. Many of the blocks that you interact within the editor, the core editor, are static blocks, which means that all of the content and markup are created and saved to the post within the editor. These are blocks like your paragraph, your headings, groups, columns, images, et cetera. They often have many style and setting options and some can contain other blocks within them. But you can learn more at this article, but basically these are things that are saved to the post within the editor. On the other side are dynamic blocks. Dynamic blocks are often displaying content from other parts of the site or content that varies based on other conditions. Couple core blocks that are dynamic blocks are the site title because that's set somewhere else or the query loop, right? That's pulling in stuff from somewhere else. That's another post. These blocks render their content differently and they usually have server side functions that are associated with them, so there's PHP involved. They can also still have styles or other block settings within the editor that control what they look like and how the content is displayed. You can also have purely server side blocks so you don't interact with them at all in the editor. You just see them, you insert them, there they are and then they also render. Again, there's an entire, several talks you could give on how to build these, what these are, what this means, but just know that there is a difference between static and dynamic blocks. All right, and then the final stats, this is basically, if you're writing custom blocks, this is the biggest difference from what you've been doing all along, right? You're now actually writing React syntax if you don't know React yet. You're probably maybe working with APIs and other methods of fetching data and there's even less documentation available. As you get to this point, it's a little bit wild west because we're all creating it together, this is new. But again, build tools, pack into dependency management, everybody's favorite things, but the benefits are, we now have fully custom functionality, we have fully custom UI and we're doing things all the WordPress way. So the last phase is the return with the Elixir which is the triumphant homecoming for the hero who is now a changed person. In our case though, the change is not a full transformation, it's a larger suite of tools that you dispose of. Even when you get to this point of the hero's journey, it's still okay if you build a classic theme. There's good use cases for it. What if you're just managing a whole bunch of metadata? You wanna have things in structured content rather than inside the editor. I just built a classic theme for a major client because it made the most sense. You could still build a hybrid theme, right? You could build a theme that is like some PHP, some block editor stuff, whatever. Make sure to take advantage of as much as possible of full state editing, whatever makes sense. Like theme JSON, like styles, like patterns, like maybe variations. And have a good reason for it. Don't just do it because it's what you're comfortable with. Do it because like, well maybe the header needs to be a really complex mega menu and we can't do that with the navigation block because the navigation block is not very good. Or maybe there's something that I have to do that's really complex and has to interact with a bunch of stuff but I still want people to be able to edit some other things, right? So maybe you could do a PHP template within a full state editing theme. You can also build a custom unique solution that uses all of these tools that best fits your client's use case because you're the one that knows best. But now you have even more things that you can offer them. The most important thing to remember is that you can provide value to your clients during each of these steps of the journey. You don't have to finish the journey in order to be able to add value. The steps were presented in an order but you might have to go back and revisit or update some steps and I'm personally still on this journey, all right? I think I'm somewhere between step nine and step 12 depending on the day, right? Like I'm still doing this. I'm still working through this. I'm still learning and WordPress is still evolving and growing, right? So we're all gonna stay on this journey but you're gonna be a hero every step of the way. This is me, this is how you reach me. I can obviously take questions. That's the link where the slides are at so if you wanna take photos of that or also here but my head's a little bit in the way. And I have a few minutes for questions. Yes. Great presentation, thanks. So there's a lot of options that you just presented here in a lot of different ways. Like what's your philosophy on choosing the method and the tools and the toolbox to solve the problem based on like how do you rationalize scope of the project, the client and it's like, oh, I'm gonna do this with a custom pattern that's gonna be fixed so they can't mess it up, right? Versus go on and do, you know, custom PHP code. How do you like approach that? Sure. So to sum up that question was basically kind of what's my philosophy for deciding which solution and which of these tools to use for which client? So my personal philosophy has always been that I want to empower my clients to be great content producers. And so I always want to give my clients the most flexibility of doing their own content. Like I don't personally want to be a person that they have to call for every single change and I never have. So in the past what I would do before all this is I, like many of us, like I had a suite of like custom ACF template things that I would give to them to let them be able to build whatever they want. And now that it's the site editor, I want to give them as much like site editor control as I think they can handle. So I wanna maximize on that. It may not be the same for everyone. So again, some clients like giving them full site editing isn't correct because they don't need to be able to rebuild their header and footer. They just need to be able to change the menus. But I do try to give clients as much like within the content site editing as possible unless they absolutely need to have structured data and it has to be fields. You know, a client I worked on that's like doing a bunch of like video streaming for example, we absolutely just wanted to give them custom fields because we had metadata for like time running and you know, who's in the video and like what are the different tags and like that wouldn't make any sense in the editor. But most of my clients, it totally makes sense to give them editor access. But I lock down, you can only pick colors that are within your brand. You can't pick fonts because we've already picked the fonts for you. That kind of thing. Yep. Yes. If you decide to keep it simple and just go the classic route, how do you proceed then? What two ways do you use for that? Do you think running or things you just need or what do you need? Sure. So if I'm doing a classic theme, you know, what are my tools of choice? I mean that also kind of depends on the client. I mean, there are plugins that I use all the time like I have a preferred plugin for e-commerce, I have a preferred plugin for events, I have a preferred plugin for forms, et cetera. If they need those things, I wrote my own base theme a while ago and I've also written my own full set editing base theme. So I personally like have too many opinions for a theme framework, but there's nothing wrong with theme frameworks. I'm just stubborn. So I don't really like have a specific like you should use this, you should use this, you should use this. I've personally found a suite of tools that worked for me and I wrote my own theme. There are lots of theme frameworks out there. I will say I personally am not a page builder person. I know a lot of people that are and I understand why they exist, but that was never me. But again, with classic themes, I want to have a really good reason for why I'm not giving them the opportunity to build content in the editor. And usually that reason is that it's mostly structured data rather than long form content. Yes. I'd love to hear some of your thoughts on page builders. Because we're going to see why shouldn't full set editing presumably offer a lot of good place. So you're writing the hardest issue, working on the full set editing, the all set of classic theme background. What are your thoughts on is the current state of the page builders and what is the future of them, especially for some of the people? Sure. I feel like I always get this question. So the question is kind of like where do page builders fit into all this? And again, like full disclosure, like I said, I am not a person who uses page builders. However, I understand why they exist. And I think that they still have a reason to exist even with full set editing. I have always thought of page builders as like a user interface for people who have the same amount of opinions as me, but don't write code. So with a page builder, you can get very granular with like this thing has this padding and this spot and this in this spot and this margin in this spot. And there's like a lot of settings and they are great for people that wants to mess with a lot of settings. And I'm not saying that in like a bad way. Like there are, that is something that some people want. The block editor isn't ever going to be that, you know, we have some controls for margin and spacing and stuff like that, but it's never going to have the same amount of granular layout control that a page builder has, right? And so for people, I think who are no code or low code, but really want to get specific, I think page builders could lean into that market and continue to serve people even while the block editor is, you know, being a full site editor and letting you build everything. Yeah. How do you deal with the moving target problem? Because we've been dealing with block editing since like 1.5, 1.5, I think even before that. And I know there were issues, like I built the site in 5.5 and then 5.6, they changed all the underlying JavaScript and broke everything and didn't fix it until it went up. And so I had to keep this, you know, I couldn't even update WordPress for that problem. And it seems like they keep adding new stuff, but also changing the way that things work underneath. And so you're having to, you know, the maintenance. Yeah, so this is like the big question, right? Like how do we deal with the fact that this isn't established software, this is kind of like production level beta software. And I say that with love because I use it. And how do we deal with that? Because that's hard. And I think that is one of the biggest resistances for people that are in my position or your position where we are small and we have so many hours and, you know, if something breaks, it's on us. We don't have a whole team behind us. So what I have done is I have, when I built things, I tried to stick as close to core as possible, which doesn't guarantee things won't break because they have introduced their own breaking changes, but it has minimized the amount of things that have broken. If I wasn't building close to core, I was, when it first came out, I was using like ACF blocks for that stuff because they had a team that could fix their breaking changes and then my stuff wouldn't break. That being said, stuff that I did build for clients that's live now has broken in some ways because of just normal WordPress updates and I have a maintenance package, so at least I get paid for fixing it. And I told my clients when we were building it, this is new and cutting edge for WordPress. This is cool. You get some new features. The trade-off is that stuff might change. So managing expectations was the best way to do it. Yeah, managing expectations, not deviating too far from core, having to take the responsibility of reading all the release notes and seeing what's going to change. I mean, it is a big ask and I'm up here empathizing with all of you because I'm just saying look, there is no easy way to do it. We do have to put in work and that is hard and we're making like a really cool choice by doing it. But yeah, that's what I would say. Yes. So I have a different kind of question. I'm brand new to all of this. So I struggled a little bit. It looked like imposter syndrome. So when you built your first theme, what was like the time frame that you allowed yourself to, how long did it take you then versus what now, looking back, do you say, okay, that was a reasonable amount of time to develop this skill set. Sure. I mean, I think building my first theme, I didn't really quite like to sit down from scratch and build a first theme. Like I started like many people like breaking something that already existed to figure out how it worked, right? And this was like, goodness. I mean, I think 2011 maybe was when I first was like, I don't know what the loop is. What is happening? And I'm just a designer. Like what happens if I do this? Took me a long time to do it the first time because I was iterating over forever. And then eventually I said, forget it, I'm gonna do my own thing. And then now with full set editing, I mean, I understood all the underlying principles. So that was very helpful because I understood like, oh, what's the query and what's this? And like, what's the template hierarchy? And so then it was just a matter of learning a new language. But I think once you learn the concepts, like relearning it, I mean, what's nice for being new right now is you don't have to relearn all the stuff that we have been doing it for a while have to relearn because we all, you know, so that's like a glorious thing about being new right now is you can jump right into it and like do it. That's great. But we're done? Yeah.