28: Writing Block Themes with Justin Tadlock

Transcript

Cory (00:00:14): Welcome back to In The Loop, a WordPress agency podcast by Blackbird Digital. I'm Cory Hughart, and in this episode, I'm joined by Justin Tadlock of Automattic. We talk about his series of articles on the WordPress developer blog about adding custom controls to core blocks, theme scaffolding, and workflow scripts. If you have questions about WordPress website development, contributing, or anything else web related that you'd like to hear us discuss, send an email to [email protected]. You can also find us on Instagram, Threads, Twitter, and TikTok as InTheLoop_WP, and we're on LinkedIn too. Blackbird Digital is a web and app development agency that specializes in WordPress, creating onscreen experiences that connect, teach, communicate, and inspire. Visit blackbird.digital for more information. Enjoy the show. Cory (00:01:18): Hello, folks. We're back. I'm back from recently attending WordCamp US for the first time. Met a lot of great people for the first time as well. So hello, if you're listening. I also managed to contract COVID while I was there after managing to avoid it this whole time. But I am feeling better. And just in time to talk to today's guest, Justin Tadlock. Welcome, Justin. Justin (00:01:46): Hi, Cory. How are you today? Cory (00:01:49): <Laugh>Ah, doing, doing well. Glad that I have my voice. I heard that you had recent trouble with losing your voice as well, so hopefully we get through this. Justin (00:01:59): Yeah, just a bit. Allergies and so on. Cory (00:02:02): Okay. So you know, before we get into, so I invited you on actually after you were on Ryan's (Welcher) you know, Thursday stream that he does over on Twitch. Mostly because that was a chance for me to, you know, directly ask you, "Hey, hey, can you be on the podcast?" but also because and I don't know if it had come out yet at the time, I don't remember exactly, but you did a recent set of posts on the WordPress developer blog about doing some, like customization stuff of core blocks in themes, and we're definitely gonna get to that. But that's kind of, you know, setting the stage here. We're gonna talk about, you know, theme development block stuff. But before we get into that, you have a very long and storied history with WordPress just in general. So could you- this might be difficult, <laugh>, but could you give us a sort of brief kind of timeline of like your involvement with WordPress and where it started and where you've ended up? Justin (00:03:19): Oh, yes. So brief is gonna be tough <laugh> but I've been around web development for 20 years now. I started in my first year of college just learning how to build like some basic webpages, not really websites, so it was like shout outs to my friends and things like that. Eventually that kind of progressed into me wanting to write a blog, I didn't know it was called a blog at the time, but, you know, just wanted to write and share my thoughts with the world, or, you know, the two people who may have actually read my website, back then. I eventually, like two years later, I think I moved to WordPress. Justin (00:04:06): It wasn't that I wanted to be a developer or anything, I just wanted to be a writer. My goal, and still is a big goal of mine, is to be a novelist. And don't ask me to share anything I've written, it's horrible. <Laugh>, that's kind of, yeah. That, that's kind of the driving force, like behind, like me learning WordPress. And WordPress was not that great in 2005. It was better than a lot of other things. You didn't just have all these awesome plugins, awesome themes. Like if you wanted to do something to your website that was different, you had to learn how to code. One thing led to another and I'm, you know, a WordPress theme developer, plugin developer, mainly because I wanted to fix things on my own website. I think it was two years later, I launched themehybrid.com. It was one of the earliest like kind of theme and plugin shops. And I ran that for 11 years before moving over to the WordPress Tavern. Of course, now about two and a half years after that, I moved over to Automattic, which is where I'm at now. That's about the briefest. I can make it <laugh> Cory (00:05:19): <Laugh>. Very well done, <laugh>. So and I don't want to dwell too much on, you know, your time at the Tavern, but obviously a lot of folks know you from that time, and your just excellent articles, body of work there, honestly. Particularly the, you know, the technical aspects of certain things and keeping them understandable, you know, brief, not too long-winded, et cetera. So I think if I'm looking at this right, you were basically writing for the Tavern during this period of time that a lot of us were experiencing the transition to Gutenberg, and a lot of your time spent writing at the Tavern seems to have been kind of covering a lot of Gutenberg based stuff. Right? And actually, like, I don't know, the first season mostly of this podcast actually, we did a series of episodes kind of talking about our experience as an agency transitioning to, you know, using the block editor. Right? So I'm just curious if you had been working at all with Gutenberg, the block editor, et cetera, before you started writing at the Tavern, or if you were sort of learning on the job at the time, like so many of us were. Justin (00:06:50): I would say it's a bit of both. I mean, I was an early adopter of Gutenberg the plugin before it was ever, you know, in WordPress. I had built the final theme I built at my previous business was, it wasn't a block theme because we didn't have the concept of block themes yet, but it was, you know, a block a theme that supported the block editor. And so I had a lot of experience, or at least a lot of frustration, <laugh> with the block editor at that time. And but that, you know, a few months later, the opportunity for the Tavern job popped up. And I actually asked if I could work part-time originally, but there was a full-time opening, so I kind of wanted, the developer part of me wanted to kind of see like this whole Gutenberg thing through and at least do it through my business. Justin (00:07:50): But I had to make a make a decision there. Do I go full-time to this new job? And well, it just made sense for me personally, it just made sense to make the move, and then I learned Gutenberg right along with everyone else. I do feel like I missed out on a lot from a developer perspective because I wasn't able, the only development I was able to do was on my own, 'cause the job was writing, right, about these things. And then the last year, I've had to do a lot of catch up. I may have known like these things at a surface level, but not as deeply as I would have if I was a developer the entire time. Cory (00:08:35): Bu t you also worked on, you know, redeveloping the Tavern site as well while you were there. Justin (00:08:40): Yeah. I did that, I did the first redesign. There's a lot of people who loved it, and a lot of people who hated it <laugh>. But Cory (00:08:50): Can't please everyone. Justin (00:08:51): Yeah. We we had to, wanted to get away from the old wood grain look. But we had another team come in and do the second design on top of the block editor, a full block—it now runs a block theme. It was actually one of the first kind of big sites that was running like a real block theme. And here we are in, you know, beta for a year or so. So exciting times and lots of frustration there too, because there's always problems, but I feel like a lot of those issues got reported back upstream to like the core, you know, developers and many of 'em are fixed now. Cory (00:09:32): Nice. So you now work for Automattic <laugh>? Maybe, this is just me and I find myself very naive often just in the WordPress space, and I mostly get to know people through this podcast. I'm very introverted. Like I mentioned the WordCamp US just a couple, just a week or two ago was my first WordCamp ever at all. And it was great. Very overwhelming, et cetera. But anyways, so the point is <laugh>, I don't really know what goes on behind the scenes at Automattic, honestly. Maybe some people do, maybe some don't, whatever. But what, what exactly, what is your role? What is your, like prime directive working for Automattic? Justin (00:10:23): Okay, so I could tell you about like our division and then my team a little bit. So technically I'm on the Automattic's Five for the Future. You know, Matt's (Mullenweg) really big on, you know, everybody giving back 5% of resources time you know, financial, whatever it may be. And Automattic is very much in line with that. I think our division is probably a little over 200 people that work specifically on WordPress.org. Like either documentation, code, you know, you name it. So, and my team is within that division is we're actually called Bifrost named after the Bifrost bridge. If you're familiar at all with like- Cory (00:11:12): Norse mythology and Heimdall. Yes. Justin (00:11:14): Yeah, yeah, yeah. So it's kind like the bridge between, you know, the core developers and like the extender community. So technically my job title is "Developer Relations Advocate". I don't know what that means all the time. <Laugh>, sometimes it's documentation. Sometimes it's, you know, bug fixes. Sometimes it's doing calls like this. And just generally helping out the wider developer community at, you know, any point. So that's what we're here for. If you have questions or just want to like throw feedback our way and make sure it gets pointed to the right people. So we jump around a lot. Cory (00:12:00): <Laugh>. Okay. Makes sense why it feels a bit enigmatic, but also necessary. So as part of that I assume you wrote that series of articles that I mentioned previously. I don't know if you're calling it the "Beyond Block Styles" series, but that's kind of what I have it as here. I'm gonna put a link to all three of those articles in the description of this. But and I have some very specific questions about it. But the reason I'm most interested in this series of articles, well, it's a, it's a little maybe selfish, honestly. You know, as an agency developer, I've run across this situation often where you know, we want to use core blocks as often as possible because it's what's already there. We don't want to confuse the clients with a bunch of different blocks that are all image blocks, you know say, that sort of thing, and which one do they use, and et cetera, et cetera. Cory (00:13:11): And, you know, so back, even in the early days, I wanna say 2020-ish at least you know, having to add custom controls to a core block and have those controls show up, not just in the effects of those controls show up, not just on the front end, but also in the editor, because that's kind of the whole point of the editor, right? Is to see what you're making and have it be pretty much exactly the same or as close as possible to what's on the front end. So but before I go on and on, can you just give us another <laugh> brief overview of what those, you know, articles? There's three of them, so what each of them kind of covers? Justin (00:14:02): Yeah! So first I'll say that this, actually, this is part of, like the work our team was doing. So in this quarter it was all about extending blocks. And this was kind of my contribution to like, here's how to extend blocks in some way. This series was three posts was primarily about teaching developers or specifically theme developers, how to extend a block with a custom control. It can be anything. I chose like an emoji icon picker. Just mostly because it was fun. And, there are more practical use cases, like text-shadows, just missing CSS features that you might wanna have as part of the design tools for a block. So that was like the, like where I started with that idea. Like, I want to teach how to extend, but first I have to go back to the beginning. You have to teach how to use the wp-scripts package. Right? Right. Because nobody knows how to do that in themes, Cory (00:15:01): <Laugh>. Justin (00:15:02): And, and then there's like a second post that like, okay, here's like, oh, let me take a step farther back, <laugh> here's how you do block styles. Like, here's how I came to this idea. And I've actually, like, I think the first code I wrote for all this was all the way back in May. And we didn't publish until like, sometime in July <laugh>. I think a lot of people don't see, like what goes on behind the scenes sometimes, like all the testing, Cory (00:15:30): How much it takes, yea. Justin (00:15:31): And just, yeah. And then like, feedback from teammates and or people on the developer blog. The review process. It's a lot. But I think we came, like, I don't wanna, like, I don't really take credit for the entire series because we had, you know, great feedback from everybody, people testing it. Especially if I can name drop Mary Baum who was the copy editor on all three. Gosh, I don't know that I would've gotten through it without like her feedback, 'cause it was quite a long series. There's a lot to it. And but I'm glad it's out. And I've actually had a conversation with someone this morning who had run into an issue where they were using this process to build their own, you know, extension to a block. And it was a real simple fix. It was just a mistake with the class system. Yeah. I'm getting feedback on it a lot. Cory (00:16:25): Yeah, that part is tricky, isn't it? Justin (00:16:26): Yeah. I basically wanna open theme authors up to like: here, try these new things. Like think outside the box a little bit. You don't necessarily have to follow everything I'm doing here. Just explore, have fun with it. Cory (00:16:41): So what I'm understanding then is that you wanted to write an article about: here's how to make custom controls for a block. But you realized that in order to get there, there was all these other steps along the way and you wanted to show off some other stuff as well. Like the block style system. Which makes a lot of sense if, if you wanna customize a block, that probably should be your first kind of go-to thing, unless it's more complicated than that, as you showed with, you know, just the amount of styles that you had to add just to have a whole bunch of emojis to pick from was just too much. So you go into a custom control where instead of having all those styles, you can just do the picker, grab the one, it applies, and then, you know, very specifically it uses the block's className attribute. So you very specifically went in that direction with this. Did you start off with that in mind when you wanted to make a custom control that it should use the className attribute? Or was that something that you had to discover while trying to figure out, okay, how do we customize a block? Justin (00:18:00): Okay. I knew that ahead of time, mainly because I wanted something that I knew would pass the theme review guidelines for dot-org. Justin (00:18:11): Custom attributes, that's kind of a gray area, and I didn't really want to put something out there. And then somebody put it in their theme , and then they get rejected when it gets submitted. So, but I know, like, you know, block styles, they're just classes. So why can't we just kind of recreate some of that under the hood stuff to just use classes? If I'm doing this for a client, I'm probably not even putting it in a theme. I'm probably putting it in a custom plugin. And I'm probably doing custom attributes. Yeah, the className decision was entirely based on, I wouldn't say entirely based on the theme review guidelines, but based on like, my beliefs about how themes should like- how to handle those things, 'cause people change themes, right. And at least with the class, the class is kind of always there, right? And, you know, even if you change themes in the future, you could still add CSS attached to that class. Cory (00:19:17): It's a really great insight. Yeah. Justin (00:19:20): I co-wrote almost all of the current guidelines back when I was on the theme review team. So I kind of <laugh> like I knew all that going into this. Cory (00:19:32): Yeah. So in, you know, in, I don't wanna call it, you know, my world, but whatever that is, you know, in the agency space where we're working mostly with custom builds for, you know, business clients, there's a lot more gray area maybe because we don't particularly attempt to abide by those theme review guidelines. Maybe some, maybe some do maybe that's a best practice and I should be considering that. But most of the time, you know, we're doing a lot of things in themes that are looked, or frowned upon, let's say <laugh>, such as, you know, even custom blocks inside of themes. But we'll talk about that later. But anyways <laugh>, yeah. When I was reading, so the, the selfish part that I was alluding to is that when I was struggling with this sort of stuff early on, and I believe that there were some changes to some, the JavaScript hooks that allow you to do this, Cory (00:20:39): So it was in the early days of like 2020, it was a changing landscape and it was difficult. But after that, it was kind of solidified. And there are ways to alter, you know, the actual like block's markup, or I should say the blocks wrapper attributes, right? So not so much still at the time anyways, you can't really reach into a block and alter its markup. That's all kind of set in stone for the most part. But you certainly can affect the main outer wrapper, the div, or whatever it is that the block is. And so while I was reading your series of articles, well, first of all, gosh, I keep forgetting this point, <laugh>, I wanted to write a blog post about this process that I had to go through. Cory (00:21:36): Obviously, you beat me to the punch here, and it's much better. And you know, more, you know, there you had a lot more eyes on it, certainly, but also, like, it's better for WordPress and the WordPress developer blog to approach it in the way that you did with the classNames, which I didn't, I didn't really even consider at the time because I was in this mindset of, I don't remember what kind of blocks I was trying to alter or customizations I was trying to make at the time, but I needed more than just classes. And I think, you know, some of the examples that I could give are like, you know, if you have some sort of JavaScript library that's using data attributes, say to apply, you know, animations or something like that to stuff, or if you're using some kind of slider library that needs, you know again, data attributes, I keep coming back to data attributes, especially because as I was, you know, looking at this cool, like emoji picker that you created, I had this thought that like, okay, we have, you know, we have this CSS function, this attr() function, right? Cory (00:22:47): That can reach into an attribute and grab its contents and actually display it right as like a pseudo element or something like that. So I could envision a way to extend this even further that's not, not as sanctioned, I suppose, by this idea of theme review process or, or that sort of thing. But I could see a system where you could create a, an emoji picker that is kind of future proof, right? That has every emoji available to your system. And putting, just putting that emoji as text into a data attribute on the block. And with CSS, you could very easily just pull that emoji in, right? But like you mentioned in your post, which was a big point of it, you know, if you do that and you change themes or, you know, remove plugin if you've done it in a plugin or whatever, the block itself no longer validates as what is expected for that output to look like. And you have to like, you know, please, please fix this block. You have to click on the thing and hopefully it recovers it or whatever. So, I don't know, what do you think of that approach? Is there a worthwhile trade-off in some contexts for, you know, the possibility of a block just breaking? Or do you think that maybe it's, you're better off just kind of doing, going the custom block route? Justin (00:24:22): My philosophy is, in a theme, I don't want anything to ever break if somebody changes themes, I have a different philosophy with plugins. I feel like once you kind of decide on a plugin, especially one that's going to affect your content in some way, then you're kind of stuck with that plugin as a user. And I know it's maybe not all users are aware that you might have to fix things later. I do think as the developer, it's your responsibility to make users aware, if they may be breaking changes after they're deactivated. Like if I wanted to do something that wasn't class-based, I would definitely do it within a plugin. And I'm very much okay with just altering core blocks to do that. Justin (00:25:17): Yeah, I would have no problem. That's the direction I would take. Especially if it's like, you know, like just say the icon picker, for example. It's just adding that to the separator block something that simple. I don't think you need an entirely new block to do it. It doesn't make sense to me. It's just more noise in the user interface when you'd have that. Right? And even if they deactivated that plugin, there's still, you know, leftover block markup. So why not leave the leftover, you know, markup with the core blocks? Cory (00:25:51): Makes sense. New Speaker (00:25:52): Hopefully that kind of helps explain a little bit of my thinking. Cory (00:25:55): It does, yeah. It does. Yeah, another thing I was thinking about with this whole idea of data attributes is the upcoming Interactivity API, which makes use of data attributes. And, you know, I was kind of like, you know, I was, I was thinking about the data attributes thing and the classNames thing, and like, oh, well, the className stuff is, built in. And it doesn't matter what you have in there. You know, the block validation process will grab those and okay, these are these are the classNames or whatever. You know, I wonder if there's ever, you know, maybe room or interest in having a similar system for data attributes, because they are used in so many, like third-party, I don't know, libraries, right? Like, you know, if data attributes were kind of a first class citizen, just like the className attribute is for, for a block but <laugh>, I could see that there could be interference there with this Interactivity, API and so maybe that's, maybe that's a bit of a pipe dream, I dunno. Justin (00:27:12): Well, I think the Interactivity API is probably namespaced. So that would be, shouldn't be a problem. It should be like data-wp-something, like the different attributes that are added. But I, yeah, I would like to see some exploration around like, what could core do to make that really simple for block developers or just plugin developers to like, just kind of hook into it and, you know, easily add their own attributes. And maybe there is something within the Interactivity API to kind of facilitate that at some point. Admittedly I'm a little behind on the Interactivity API code at the moment. Cory (00:27:56): I haven't used it much either at all. I haven't checked it out. All I know is that it uses data attributes. Justin (00:28:01): Yeah, I was really up to date there for a bit. And like early this year my team had a session where we all learned, and then everything changed <laugh> like two months later. It was like nothing, like all the code we'd written, none of it worked anymore. So I had a session where I've went over like more like the foundational, like ideas behind some of it. A lot of it just kind of went over my head because I've been super theme focused here lately. And I haven't had as much time to dive into that as I would like. Cory (00:28:43): That's fair. That's fair. No, I, <laugh> this is not a pop quiz about the Interactivity API, don't worry. I'm, yeah, I'm very interested to see where it goes, but I like to be, I like to be aware of things coming down the pipeline, but I don't like to be too aware because like you said, in the beginning, things change quite a bit. So I am kind of waiting for a release candidate kind of state before I try to play with it at all. Justin (00:29:14): Yeah. I will say I think it's not gonna come out in the next WordPress release as far as I know. I think it's gonna the Interactivity API will be the following release before it's a public API I believe. So 6.5. Hopefully. Cory (00:29:31): I look forward to it. <Laugh>. So getting back to you know, so we kind of went through to, that's basically like the third article in the series, right? The kind of big conclusion of how to add, you know, custom controls to a core block and affect it with className and style it however you want. The, the very first article I wanna get back to that because it is about adding the wp-scripts package to a theme. And the funny thing about that is that it feels like it shouldn't be difficult, but as you, you know, cover in that post, you actually have to do a bunch of stuff to make it kind of work with the theme, 'cause it's, even though it's wp-scripts, it's maybe kind of misnamed, honestly, in my opinion, because it seems like it was built very specifically to deal with building custom block plugins. So one of the things I think that you had to do was alter the Webpack <laugh>. You had to alter the Webpack configuration just to deal with like how it handles. Well, maybe you can tell me about that part. Actually, <laugh>, Justin (00:31:02): There's quite a bit you actually don't have to alter. I've worked with theme authors a long enough time to know that everybody, all of them have their own like folder organizational system. And I do too. So like, I just wanted to go ahead and showcase that you can use the default "src" and "build" folders with the script and not have to change some of that. So you do still need to work with Webpack a little bit to like, add your entry points, like for your style sheets and, and specific JavaScript files. I believe Cory (00:31:44): There's that part where you have to like, add an additional NPM package in order to like stop it from outputting, like JavaScript files for all your CSS or something like that, right? Justin (00:31:59): Yeah. Oh, yes. That's right. Cory (00:32:01): That's like, kind of like what Webpack is kind of for, is like JavaScript apps essentially. And Webpack is kind of like focused on: well, you have a JavaScript app and everything is JavaScript-based, and all your entry points are JavaScript. And like the style stuff is just added on top <laugh>, but as themes, right? We need, you know, like CSS is a crucial part of what at least I'm doing with themes and should be crucial in general. Like, that's kind of what a theme is, is styling. So yeah, that's always bugged me a bit, but, you know, but you, but your article is very clear on the, the very minimal steps on what you have to do to make it work. Justin (00:32:48): Yeah. one of the things I've worked with for the past several years is Laravel Mix, a package that does like most of the legwork of Webpack for you. It's great for like, you know, designers doing like theme work but it's also overkill for a lot of projects. So I kind of wanted to bring like all the good things that I liked about that, and like, can I do this just with the wp-scripts package , and it turns out like I can, there's a couple of, I mean, in my own work, I have a couple of other things like packages that I'm using, but it's mostly just like what's in the in the article there. Cory (00:33:35): At at Blackbird we, you know, of course we're an agency and we do custom theme development. So of course we have, you know, a themes scaffold, quite a big and complex one that's still, you know, that's still in this sort of hybrid theme kind of area. That's the last transition that we need to make, and I need to spend some time on a proper scaffold for for block-based themes which you actually have from what I can tell you have a custom block theme scaffold called First Draft. And I'll put a link to the GitHub repository in the in the description. But can you tell us about, about this First Draft theme scaffold? Justin (00:34:25): This kind of started as a project that, like- I'm the primary like theme developer on our team, I think most of our team leans a bit more toward block development. And I realized, like, I haven't built like an actual block theme, like a big block theme. And like, I've built like a one page theme and I said: well, let me build a starting point and like, try to keep this as simple as possible for beginners primarily. But I also wanted it to be useful for like, more advanced folks. And so I started working on this, this theme to try to cover this whole wide range of people. And then Ryan Welcher and maybe you've seen that episode on his podcast or on his stream, basically <laugh>, you know, he's really advanced developer, but, you know, didn't have like, the tools that he needed. Justin (00:35:26): Like, I want the build scripts, right? You know, everything else. And I realized at that point I was kind of missing probably a huge segment of the community that, you know, such a theme would be helpful for like a starter theme. And so I just kind of set that to the side for a bit and started working on my own theme and just throwing every idea in there that I could. And I plan on taking that, what I learned from that process back into the starter theme, hopefully some time in the next quarter and maybe do like a 1.0 release. I don't know what it's gonna look like when that happens, but we'll see. Cory (00:36:08): Like you kind of mentioned there, one of the decisions that you made, you know, that part of the readme talks about is that there is no JavaScript workflow kind of very, almost purposefully, but it sounds like maybe you feel now that it's a necessary part of a theme or no? Justin (00:36:36): I don't think it's necessary. But I think there's two very distinct audiences, and maybe there needs to be two versions or two separate you know, starter themes or scaffolds to work from. I still want to cover like the- lemme back up. Like, when I first started learning theme development, there was no build process. There's no Sass and no Webpack, <laugh>, NPM, you know, and I remember, you know, I'm so fond of those days, like I could just open a file and what I edited in that file would show up on my website. You know, most of the time it was broken <laugh>. But, you know, you got like that <laugh>, you know, you got that feedback like from the browser you're working in, you didn't, it wasn't really complicated. And themes are headed that direction to be simpler where you pretty much can almost built a theme entirely in the visual editor. Justin (00:37:36): So like, the idea for this theme is a little bit: what's that next step for somebody who's getting out of the visual editor, wants to touch a little code, but maybe doesn't know, like, you know, they haven't touched a command line interface ever in their life or know what GitHub is, or, you know, version control or anything like that. So I want to like, cover that set of users primarily. And that's why the deliberate decision, at least to start with, to not have a build process, but we definitely need something that's a bit more, that's got all the fun tools and, you know, goodies in it too. So I don't know what that's going to look like in the coming months. It's a project that I probably won't touch for at least another month and a half, and then I'll start thinking about it again. Cory (00:38:36): Yeah. Sorry, I'm not trying to rush you or anything <laugh>, but it is, that is an interesting idea, is to have you know, two kind of different starting points because yeah, like, like you said, you can just look at like the core themes, for instance, which are, you know, eschewing that kind of stuff and just sticking very, you know, to either very little or no, no actual, like enqueued CSS at all, and just, you know, utilizing theme.json, which we haven't really talked about today, but, well, I don't know if I wanna get into it, but it's kind of a huge point of contention for a lot of folks too, doing custom theme work: is our profession, our, you know, our primary focus kind of falling outta fashion in favor of just being able to do everything in the editor, and do you even, you know, we talked about this a little bit on the podcast a while ago. Like, do you even need a theme anymore or can you start with some sort of blank canvas theme and do everything you need with, you know, global styles in the site editor? Maybe? For a lot of folks, and maybe that's a good thing. Justin (00:39:50): I can answer that question. Cory (00:39:52): Good! Tell us, <laugh>. Justin (00:39:53): Yeah, I can answer: yes, you can build a decent theme or, you know, web design with the editor and never touch code or just within theme.json, but if you want to do something that's pretty great, like that's well designed, you're still in CSS, you're still in the code right now. There's just no getting around that. Cory (00:40:18): Can't get rid of us <laugh> that easily. Justin (00:40:23): Yeah. No, I mean, there's just so many things that theme.json and the visual, or just the template editor and so on that have really, you just can't do it yet. And the design tools are becoming better and better, but I haven't worked on a project yet where I haven't had to touch code. But I'm also probably trying to do some more advanced things than somebody who's just, you know, dipping their toes into the pool or whatever for the first time. Cory (00:40:53): Right. Well, I mean, that's kind of the space that I live in. That's the space that I think a lot of the audience may be who's listening lives in where we are, you know, in this agency space where we're very explicitly getting paid to do the work that, you know, people either don't have time with, don't know how to deal with, don't want to, don't wanna touch it. Just please make the website look like this <laugh> and it's our job to then, you know, go in and figure that out. And oftentimes it's, you know, due to the fact that there is no tool to just kind of click some buttons and make it happen. You do need to touch code. And, you know, we're seeing a lot less of those instances these days with Gutenberg and the block editor, but at the same time, things are getting more complicated with what you can do. And there's still room for us. There's always gonna be room for like, custom stuff, fixing things that don't work the way that people want them to, all that sort of stuff. Cory (00:41:58): So, the other theme, I think you mentioned in passing here, I believe it's the one you're talking about is the x3p0-ideas theme. Is that the one? Justin (00:42:11): Yes. yeah, that's the one I was talking about. Cory (00:42:14): What is x3p0? What does that mean to you? Justin (00:42:18): Okay, yeah. So there's a little bit of a story behind that. I'll keep it short. <Laugh> So this goes all the way back to pre-Tavern. I was working, still running Theme Hybrid. And the final theme I made was called Exhale that was the name of it. It was a commercial theme. And so version 1.0 was a you know, block supported theme. And then there was like 2.0 that I don't know that I ever released 2.0. Anyways, 3.0 <laugh>, and this is where X 3 point 0 comes from, 3.0 was supposed to be a- Cory (00:43:02): Oh: X 3 point 0. Justin (00:43:04): Like, I mean, I was just searching, I was trying to think of a name for like, I was at kind of the time when I came up with the name, the business was over. I was working at WP Tavern, and I wanted to just build something that was separate from like, my own personal profile, something that was separate from the old Theme Hybrid and like just a block playground for me. So I just kept playing around with the names. And that was it just came off, built off my last theme, and I was gonna make that version 3.0, the 3.0 of the theme, and I never did. So this ideas theme actually is really a continuation of that original project. Cory (00:43:48): So, as I understand it, this is just where you put every idea you have, in, related to theme development, and you just kind of work through it in this one kind of project. Is that, is that fair to say? Justin (00:44:03): Yeah. Because like when I'm writing the Beyond Block Styles series, I need something that's real that I can test these ideas out in. I mean there are several other examples I mentioned, text-shadow, I think there's like a color variation control. I don't even know what's all in there. And I haven't touched it in a couple of months. Cory (00:44:32): I will link to it so people can check it out. Justin (00:44:36): I go through like periods where I'm like super motivated because a lot of this is just, this is outside of my primary work. It's just something I'm doing for fun. Now, I do use it for ideas for my work I do in the daytime. But yeah, I do get burned out on it a little bit. Like I might work in the evenings on it for a couple of months, and then I'm like: I don't care about theme development <laugh>, you know, for a little while. But yeah, I mean, it's mainly where I just like to test out ideas and hopefully, like, I'll actually complete this theme and like, put it on WordPress.org and let other people test it and use it. Cory (00:45:19): Nice. Nice. So this one uses the @wordpress/scripts package and the, the workflow, 'cause obviously you're doing a lot more advanced stuff here, but it's not really a starter theme. Of course, this is an actual fully fledged kind of theme with a bunch of different ideas and custom, you know, design concepts and all that sort of stuff. One thing that I noticed about this theme is that you know, it uses what some might consider in the WordPress space anyways, as "advanced PHP". I'm using air quotes here. You know, it utilizes things like namespaces, but also classes, interfaces, et cetera, things like that. So, somebody I met at at WordCamp US recently told me that they "don't take shortcuts", and this kind of reminded me of that. So I wanted to ask you about, you know, what are the benefits of architecting a theme this way versus just like plain functions, WordPress hooks, that sort of thing. Justin (00:46:35): Yeah. I know you said, you know, you used air quotes for advanced because I don't feel like some of this is advanced. This is like 10 years old PHP like outside of the WordPress community. Why I kind of use classes interfaces, traits, and like newer PHP features; It's just because I do other work in my spare time, and I don't like kind of mentally switching like back and forth to like, oh, let me use like, just plain functions. I like to, like whatever stage I am in my career professionally, like, or, you know, knowledge level, I like to just kind of do all projects in that way. Five years from now, it may look completely different than, you know, what it does today. Cory (00:47:21): Five years from now, WordPress will support a different PHP version and we can, you know, include more fun stuff. <Laugh>. Justin (00:47:29): Yeah. Oh, I was so happy to see that we're at least up to version 7.4 with the WordPress 6.3 release. Because I've, like, I've long ago dropped like the PHP 5.6 that WordPress was still supporting, and I wish we were on like, at least 8.0, 8.1 . But I know that's not reality, right? So I do try to scale some things back. There's not a whole lot. I think there's just a few features that I use that's not available in 7.4, but I do try to kind of stick with at least, you know, so people can, who are on that version can at least use my plugins or themes. Cory (00:48:14): Something else that I noticed actually in the other theme, the First Draft theme, but I assume this applies to the X3P0 as well. You mentioned in the readme for that other one that it is "highly opinionated in certain matters such as naming schemes", and this is, you know, this is a matter close to my heart as well as a fellow scaffolder. Can you talk a little bit about your naming scheme choices and how you apply those in, in either of those? Justin (00:48:47): Yeah. I can tell you I've already changed my opinion <laugh> since <laugh> since I first added it, it may be opinionated but I don't know, I don't like people, I don't like developers naming their red color "red" or <laugh>, you know their background color "background" when it could very well change in a style variation or it could change in a child theme. Or it can change when you change to, to a new theme. I don't necessarily say I have the correct system of naming things, but I do think agencies, or particularly, this leans more toward theme shops and people who, like companies that put out multiple themes, at least keep it consistent across your themes so that your users or maybe even customers, if you're selling your themes can switch to like, you know, your theme two years from now that you uses the same you know, slugs when they name things. So like, they just transfer. I did model a lot of my naming schemes off of Tailwind which is something I do love to a degree. I like a lot about Tailwind, but I hate a lot about it too. So love-hate relationship, I guess. Cory (00:50:17): I hear that a lot. Justin (00:50:18): So it's modeled off of that. But since I've been working on my own theme, I realized like I had make some decisions that altered from like what I thought was the right way for me to do this. And I think I've borrowed some things from Bootstrap, like naming scheme wise that made sense for that theme. I think with colors anyway, so I mean I think it's just about individual developers doing it. Yeah. Cory (00:50:45): You like the kind of Bootstrap approach to like- let's just stick to colors, for instance. So colors slug naming or whatever, like primary, secondary, tertiary, that kind of approach? Justin (00:51:00): Yeah. I'm not very familiar with Bootstrap. I think there's at least one version there where they use like this color naming scheme where it's like muted, subtle, emphasis, and that made sense in my mind. Like I needed like about five colors, and I do like the one through like 900, like from light to dark. But if you are designing something that might have like a dark color scheme, and then you're kind of flipping that around a bit. So the muted and I don't even know the names of all of 'em right now, muted, emphasis. I kind of got to that point mentally because I actually have three child themes I've built for the ideas theme, and those are not public at the moment. So I took like this project, I made the theme and I said, well, let me go explore making child themes or style variations and pretend like I'm somebody else who's extending this theme further. So I realized there were some issues that I was running into. Cory (00:52:09): Yeah, I think I'm ready to start, like, at least the third scaffold for, you know, WordPress sites that I have built here at Blackbird. I think our first scaffold was Bootstrap-based at the time, I wasn't particularly fond of, you know, using Bootstrap for everything, but I had to work with other developers, right. So, and that was kind of something we agreed on, but then Gutenberg showed up <laugh>, and at a certain point it just wasn't feasible anymore to kind of make Gutenberg in the way that it wanted to handle theme colors and that sort of stuff and, and the classes and all that sort of stuff that it wanted to use and have this whole other system of Bootstrap in there just kind of messing things up. So that was the that was part of the reason why we switched. Cory (00:53:08): We're not using any, you know, CSS frameworks or anything at the moment. Honestly I haven't even really looked into Tailwind. I can see the advantages, especially in a team setting. And I think that utility class stuff was probably the best part of Bootstrap. But I do wonder, you know, how you deal with the fact that, you know, for the most part, like you're dealing with core blocks and stuff like that, that just, that don't- I mean, sure, you could go in there and add custom classes to it, but I assume that you probably have a different system for applying, you know, particular classes that you wanna apply, or styles, I should say, to core blocks that aren't class-based. Justin (00:53:56): Yeah, I'm not I don't actually use any framework in particular as far as CSS goes, but I do like to borrow concepts and naming schemes and, and things from a wide variety and then just build my own thing on top of that. So like, I like all the block styles, or like is-style-custom-name in WordPress. So you can't just like transfer those one-to-one easily. Yeah. So, I mean, I just try to take those concepts and build them into WordPress in a way that makes sense. The reason I'm not a big fan of like, some of these utility frameworks. Like, I don't like all utility classes. I think they're helpful, but I'm I much rather like the BEM system of like naming like components and <laugh>. Yeah. So that that's a good balance. Yeah, that's a good balance for me. I like that. I use that like for my personal websites that's really what I do. And with utility classes sprinkled in. Cory (00:55:10): Yeah. I know that there have been evolutions of the BEM kinda concepts like Cube CSS and that sort of thing, but honestly, I've been <laugh> BEM CSS: it's like a comforting warm blanket at this point, especially with like particular, you know, Sass nesting kind of approaches. It's definitely my favorite way to do CSS. And it works. I mean, it's already basically the way that core is doing classes, classNames, essentially you know, with naming pieces of, you know, a block that are inside of that block with the class name, the full class name, underscore underscore, whatever that piece is. So it fits really well within the WordPress ecosystem and, and Gutenberg blocks. But we are like getting close to the end, and there's more to talk about. So I wanted to quickly talk about the newest effort that you are undertaking, which is the overhaul of the theme developer handbook. Can you tell us about that process, what that's been like, and how much work is still left to do <laugh>? Justin (00:56:31): Yeah. So the theme developer handbook is out of date. There are parts of it that are not out of date, but it's all mixed together, block themes and classic themes stuff together. And as most people should know by now, block themes are the future of WordPress. So I put up a proposal to outline a new handbook that is block themes, that that's block-first. Yeah. And classic themes will still exist in this handbook. But like the documentation is going to be, you know, almost the entirety of the chapters are going to be focused on block themes. And how is that going? That is going slowly. Actually starting next week I will be doing a full month of focus on the theme handbook. So no developer blog articles from me for at least another month after this week. Justin (00:57:35): And I probably won't be doing- I won't do the Hallway Hangouts this month, which is one of the things I do. I'm basically just going to be a hermit <laugh> and working on getting at least like a couple of the bigger chapters finished like the theme.json chapter, which I've almost finished drafting that. And probably like some template stuff and maybe some other block theme features, and hopefully kind of get those actually published. There's some things we can't publish until everything else is written, just because the way they're referenced with, you know, lots of links. I would like to ask anybody who's listening, please join <laugh> and, you know, write. At the moment there's been one other person who's written or at least started drafting one of the articles. We do have a couple of people who have reviewed. So thank you to everybody who's has been involved with it so far. But you know, the fact the more people we have, the faster we can actually get a handbook updated. Cory (00:58:54): I will link to, I'll make sure that I have the right link. But it's, it looks to be kind of an issue on GitHub that's just kind of a huge, like, overview; giant long checklist with lots of things to do that links to each like, individual piece of this that you were working on. So yeah, jump in, check it out. Get involved. Good stuff. I'm gonna be, I'm gonna be giving this a careful look as well. I'm, I'm very excited about the, about changing the theme handbook to be, you know, block theme focus. That might be controversial. I know. But we're getting past- are we getting past the, you know, Gutenberg is controversial thing? I don't know. I hope so. <Laugh>, Justin (00:59:47): I think we are. I think we are at this point. I had the same exact thing. Wh en I proposed this, I was like, this is going to be the most controversial thing I've ever posted on, like it was on the, it was on the Make Themes blog. Like I put this out there, you know, for the community to give feedback, and nobody said a word about it. Nobody <laugh> like, okay. And we had two meetings about that outline and what this was, and nobody complained about that. One thing I've, you know, I was so worried that would get shot down by the community <laugh>. And it was like crickets when I asked about it. So I think we are past-I mean, you're still, you're going to have the people who still don't like the block editor and the progress that we're making. Justin (01:00:45): But there were always people, there were people who didn't like the Customizer when it came out. There were people who didn't like the nav menu system 10 years ago when it came out. There were people who didn't like the MP6 project, which is if you don't, that was the redesign of the admin from like the very old school. But, you know, we have to make progress. WordPress has to stay current with modern software. Because WordPress before 5.0 was not current with what you're, you know, seeing coming out out of the rest of the developer community. And we don't need to lose- we all want our jobs <laugh> at the end of the day. Right. And we don't wanna lose like the users and the community by staying in the past. Now whether the block editor that we have now was the best thing we could have built, I don't know, but this is going pretty well, I think. Cory (01:01:54): Alright, well we will look forward to that for sure. And maybe some folks will check it out and get involved. I have a bit of a parting shot to <laugh> to throw at you before we go, I was checking out your blog at justintadlock.com. I'll put a link to that. And on the about page, it says that it is built with a custom [CMS]. And you mentioned earlier that early on, obviously your blog was custom built. Is it WordPress now and you just need to maybe update the about page? Or is it still a custom CMS? Justin (01:02:37): It is a custom CMS at the moment. Cory (01:02:40): Caught you red handed! Justin (01:02:42): <Laugh> Yeah, well, I've actually got an open GitHub repository that I can share with the code behind all that. A lot of people asked because it was when I switched back from WordPress to something custom, it was right before Gutenberg, like the WordPress 5.0 release, you know, so a bunch of people asked like: oh, you're doing this 'cause you hate, you know, Gutenberg. I'm like, no, I just I felt like WordPress at the time was not advancing with PHP and I felt like my development skills with PHP were lagging. And I wanted a challenge. There was no challenge for me, at least PHP-wise in the WordPress space, I felt like, and it was just like a really educational thing to like dive deeply into some of the subjects that I wasn't familiar with. Justin (01:03:45): Like URL routing. I had no idea like, how, how did that, how does that work? Because WordPress's system was, don't look at the rewrite rules, <laugh> system there in WordPress. But I just wanted to learn some of these things and I wanted to do it with some modern PHP. And I just kind of played around and one weekend I built a blogging system. Now it doesn't have an admin interface or anything like that. I still have to like, just upload my markdown files to the server, you know. So I built like, the main thing I built in a weekend and I was like, that's really cool, and like, I'm gonna turn my website into this, you know, like a week after that. And I've just had fun working on it as a side project, and I still love WordPress. I just don't necessarily need it. Like, I can always change my blog at any point. I mean, I'm a developer. I mean, it's not hard to do some of those things for me. Cory (01:04:50): I can get behind that. I get a lot of, not a lot, but occasionally I'll get an email from somebody who's found my website and I just, I actually just recently updated it from not, you know, touching it for like, six years to actually have a blog component. So I'm hoping to write some more articles that are WordPress-oriented. You know, I have one, I have one article about, you know, using variable fonts with theme.json. But but anyways I have people that email me and say like, Hey, I like your site and ask me a question about it, or whatever. And they're new developers and, you know, maybe they'll ask me something like, you know, what are some good resources or, or whatever. Cory (01:05:46): And at this point in my career you know, so much has changed in just this whole landscape of how you make websites that I oftentimes don't really know what to tell them other than like, pick a thing that you wanna make and just go through the process of making it <laugh>. Because that's how I've always done things throughout my entire career. I need to, I need to do a thing, I need to solve a problem, figure out how to solve it. And, you know, looking at books or whatever, you know, has never really clicked with me in particular. I don't know. So maybe for some folks that works, but yeah, jump in, create a whole new CMS. Why not? You know, maybe you can bring that experience back into WordPress if you are like, like Justin is very passionate about the WordPress project itself. So- Justin (01:06:41): I would just say quickly, I do not learn from books on programming either, even though I've published two of them. Yeah, I do agree <laugh> just go build something and if you don't, nobody knows how to do it to start with. Google's your friend <laugh> and, you know, search and break things a lot. That's what coding is about: breaking things until it's no longer broken. <Laugh>. Cory (01:07:11): Fantastic. Fantastic parting words. Thank you very much Justin. I really appreciate your time that you've given me. I know that you're a very, very busy person and you got a lot of work ahead of you. So good luck in that endeavor and I wish you well. Justin (01:07:30): Alright. Thank you for having me on. Cory (01:07:36): That's all for this episode. Thank you, Justin, for taking the time not only to talk to me today, but for your long history of writing excellent articles about how to do the things that I've built my career on, as well as sticking around to chat with me about gardening after the recording. Follow Justin on Twitter at @justintadlock and on wordpress.org as @greenshady. Check the episode description for links to things we mentioned in the show, in particular, the theme handbook overhaul issue on GitHub to get involved. As always, don't forget to send your questions, thoughts, and fan mail to [email protected]. You can also find us on Instagram, Threads, Twitter, and TikTok as InTheLoop_WP, and search for us on LinkedIn too. If you're interested in having a WordPress website custom built, or you want to join a team that does that, head over to our site at blackbird.digital and drop us a line. Thanks for listening to In The Loop. See you next time.