Democratizing the Theme Directory: Building Block-Ready Themes with WP Rig & AI | Rob Ruiz

everyone doing today? Thanks for hanging in there with me all the way to the end of day two. I guess this is um yeah, we're going to be talking about uh some theme development stuff, building themes, how can we build them faster and easier and more automated. Um, I did build a cool guide that, uh, if you want, you can use to help you get up and going. If you're going to actually build a theme during this workshop, you can go to wprig.io. Uh, and there should be a learn v3 link in the main navigation up there. just click on learn v3 and there's a nice like interactive onboarding guide there uh that you can use to essentially get all the prerequisites installed before you can actually properly use the tool because it is a tool that leverages composer and node or bun and some other things under the hood and so uh you will need to have some of that installed. Um, it is also a Git repo. So, this is an open source framework. It's on GitHub. And so, you'll need Git installed in order to clone the repo down to your local environment. And then, of course, speaking of local environments, you'll have to have some kind of local environment system. Uh, something like WordPress Studio or local WP will work great. And uh yeah, you just want to clone that into your themes directory and you know, clone WP rig in your themes directory. And again, that guide on the first page will help you uh get there essentially. Uh I'm going to assume that some people still need to do that step. And so while anybody who's following along is getting their local environment set up to kind of spin up a a theme, uh I'll talk a little bit about myself and WP Rig and just give people a quick primer on kind of what it is. Uh so yeah, again, my name is Rob Ruis. I'm the lead maintainer for WP Rig. Um I've been doing WordPress development for quite some time now. I recently got my certification through WordPress VIP. So I'm now an advanced WordPress developer according to automatic along with some other anthropic certifications. And uh yeah, so just never stop learning basically. Uh a quick thanks and disclaimer uh before we carry on. There are two other somewhat uh heavily maintaining you know other maintainers that that have contributed a fair amount over the past few years. So thank you to Janac and Carl Brewbaker uh for for your contributions to WP Rig. Um and then just something I want to make sure everybody keeps in mind. There's not a ton of people contributing to this project right now. It's not as popular as some other theme development frameworks. So, uh, that's part of the reason why I'm here today is just to raise awareness about WP rig. Um, and hopefully get some more contributors and users. Uh, and so just know this is mostly like a solo passion project. If you look at the change log, it's like my name all over it like quite a bit. Um, so all that to say there may be bugs, you may find things. If you find issues, please report them in the issues area on GitHub so that we can I can get those prioritized and uh and fixed. Yeah. So, here's a little road map of what we're going to be going through today. um going to go through kind of like setup and just highle architectural concepts and then we'll get into some various use cases for WP rig and kind of how you would approach each one of those use cases and how WP rig tends to well is designed to change how it behaves based on these different use cases and of course we'll do some Q&A at the Um, I will say if anybody has questions throughout this process, don't be afraid to to raise your hand, come to the mic and ask. Uh, this isn't going to be like a formal wait until the end thing. If you're trying to get up and going and you hit a blocker or something like that, you you want some help getting through it, please, uh, raise your hand. Um, or if you have a question about anything I'm talking about at the time, feel free to ask. Um, so we do have a a theme dilemma currently that WP Rig has been trying to solve. Um, and the dilemma is there's just various um, paradigms I guess uh, around theme development. Uh, I'm not sure how many people know this, but it is actually the theme that determines whether or not you are using uh the full site editor or the site editor in WordPress today. The theme determines that. So, if you're not using a theme that supports that, then you don't get the site editor. Um, so classic themes have the classic menu manager uh and customizer and some other uh features that are built into like kind of classic WordPress and then if you build a blockbased theme or a universal theme that unlocks the the site editor. Um, and so it's it's just a very interesting thing that I think uh a lot of people are not aware of. And there's how how you approach theme development is very much dictated by which paradigm you're targeting essentially. So it does help to know whether or not it's going to be a blockbased theme or not when you set out to actually build your custom theme. And this is going to be a big question that that I get asked a lot. So I'll just answer it right up front right now. you you can build any type of theme with WP rig even though WP rig was created before block themes were ever a thing it has been updated over the years and so uh it it actually provides you a it prompts you when you're running the initial command to initialize it uh what type of theme you want to build and then it will set itself up accordingly. Um so I I think everybody's noticed the trend this year. It's a lot of talking about AI and we're going to talk about AI a lot during this session and a lot of things that I've added over the past couple years to WP rig have been preparing and uh accommodating the changes that have occurred because of AI. Um, and so what's interesting is if you've done any amount of vibe coding, you've probably noticed that when you spin up any project with AI, if it's not done within a framework, your results are going to vary dramatically. And so kind of the mentality here is if you build your theme within a theme development framework and you use AI to do it in theory the likelihood of hallucinations or drift or just it creating weird things in theory again in theory should go down. Uh, now it does depend on what model you're using and what agent you're using and how you're prompting and the amount of contacts you build up before you have it try to oneshot something or whatever. Um, you know, the idea here is that doing creating a theme within the bounds of a framework like WP rig should yield better results than than not. Um, and so WPR provides a fair number of opinions and assertions and uh just general guidelines that help steer your agent in the right direction. It also has uh a model context protocol server built into it. So WP rig has a build server built into it. So it's had a server for a while. And so the idea here was sensor is already a server running. Why not spin up a little MCP server and this MCP server is very lightweight and simple. Its only responsibility is to check the documentation that lives on wprig.io. And that way we can make sure that the context that the agent is getting is always staying up to date with the documentation that we have on wprig.io. Um, it makes it a little easier uh to make sure as we're adding more features and updating things, you know, we're making sure we put documentation up there for humans to read, but then it's nice to, you know, two birds, one stone. Make sure you make sure the the agent is also aware of that documentation as well and has, you know, good access to it. Um, so it it is also really nice when you work on a team to be able to share skills. I don't know if anybody else has been works on a team that heavily utilizes AI, but it's a very common thing for people to like kind of build their own library of skills and share them with each other and stuff. And so, uh, that's definitely something that you get from WP Rig is it's open source. So, there's an open source set of skills in there. Um, and the way it leverages skills is very unique. So, I would recommend anybody that's done any amount of skill writing or engineering, go ahead and take a look at kind of how we've done it in WP rig. The approach is very progressive and the idea is your main claude or agent.m MD should be very very lightweight 50 to 100 lines um and then all other context should be built up via skills and other markdown files as needed depending on the task that the agent is setting out on. So it used to be slower to build themes with WP rig. Uh we used to use something called Gulp back in the day. Uh in version three we've thrown all that out and we've rebuilt it from scratch to try and get something that's a little closer to Vit. I don't know if anybody's used Vit here to build anything. Um but Vit is the fastest build system uh in existence as far as I'm aware right now. uh although bun is quickly knocking on that door and uh and so what we've created here is something similar to vit but not exactly beat. Uh but the goal here is to make it as vit like as possible. So we now get subsecond builds. So what this means is as a theme developer, as you're editing your code, it's constantly rebuilding the code and transpiling it into minified versions real time in fractions of a second. Uh what's nice is that makes it able to keep up with the agent. Agents write code extremely quickly. And so if you have the dev server enabled and you have browser sync set up and you're watching your browser, it is possible for you to literally sit there and watch AI like build your theme for you and the page will just automatically re-update as your agent writes new code into your files for your theme. uh we follow a very modular object-oriented approach in WP rig. Um all of the functionality are in what we call components or PHP components not like front-end visual components. And so what this does is it provides a few benefits. First and foremost, having a single responsibility is not only good for uh developer practice, but it's also really good for agents. Agents are very easy to understand this components for this, that components for that. The documentation within those files are isolated to just those files and you get a lot less hallucination as a result of that. Uh so and we'll talk a little bit. This unlocks another superpower that we'll get into a little later, but that also means that you can kind of uh add and remove functionality uh to and from your theme extremely easily. So the idea here is keep everything as modular as possible, as light as possible, and as modern as possible so that we can keep things moving in the correct direction and make sure the AI knows how to use it properly. Uh, another big thing we want to make sure we're doing at WPV rig rig is we want to make sure that performance is top of mind. So, and and not just performance of the build system, but also the performance of the theme that you're building. So, we're constantly looking for new features and new ways that we can um improve the speed of your theme because believe it or not, one of the primary uh contributors to sluggishness on a WordPress site is the theme that you're using. Um, how many people here uh have built or are currently using for their own site um a website with kind of like a multi-purpose theme or whatever, right? Like how many people? A few hands. Yeah, everybody's aware of the multi-purpose theme. And so while while that's handy when you're building a site to be able to just use the same theme for 10, 15, 20 sites, uh that does come with a certain amount of overhead. And so it's nice to be able to build a theme that doesn't have all of that weight to it. And you can make much more lightweight single-purpose themes with WP Break. Yeah, >> this is probably a longer conversation, but are you doing your critical CSS extraction server side or client side? >> Uh, it's a good question. The feature built into WP rig is not meant to replace something like Perf matters if that's what you're thinking about. Um, so there's only so much that you can do from the theme level. So no server side stuff is built in here because that would be the responsibility of something like a plugin. That's very plug-in territory. This is more like making sure that whatever scripts or styles are specific to your theme that those are being in line responsibly and being or if you organize them properly. Like say you have a CSS file for your header and your navigation and stuff that's obviously going to be at the top of your page. This helps to get those scripts and styles into the browser as fast as possible. >> Okay. So you're basically analyzing a properly broken out block CSS structure rather than running the DOM and figuring out what's used where. >> Correct. Yeah, this is Yeah, it's it to to get the perfect situation, you would want to pair it with something like a Perf Matters or Flying Scripts or whatever your solution is there. Yeah. So, uh a new thing we recently added was uh a dev toolbar. uh developer experience is very much at the front of WP Rig. Uh something I noticed when I first took this project over back in uh 2021, I guess 2020, something like that, uh was that the developer experience was not quite there. And so I I'm constantly trying to find ways to make the developer experience a little better and provide tools that make developers job a little bit easier. So we recently added a front-end dev toolbar. If you get a local theme up and going, if you get WP rig, kind of like the baseline starter point for it, if you get that up and running right now, you'll notice that there is a WP rigde dev toolbar at the bottom. And what that toolbar contains is a few to few tools that make your job a little bit easier. Um there is now automatic um WCAG uh accessibility detection built in locally. Uh and this is a tool that only exists while you're developing. So this does not get bundled and shipped with your theme when you're ready to actually like deploy your theme. This only exists on your computer where you're building so that you can identify like contrast problems early and address them. Um, there's some other tools in there too. There is a tool where you can click and drag and I'll I'll demonstrate that a little bit later. Um, it will help you identify certain elements on the page so you can easily tell an agent what needs to be fixed and and so on and so forth. This is just more about that as well. Uh, it it does actually build a prompt for you. So when you click on an element on the page, it will figure out all of the necessary context to provide to the agent and allow you to add additional context as well and build a prompt for you that you could just copy paste and give to the agent. So you can tell it, hey, something's wrong with the header or the navigation or whatever and just click on it, add the context, pass it to your agent, and hopefully your agent is able to figure it out and fix it easier. Another big thing we wanted to add and I guess I guess I'll preface this quickly with a problem that I identified which is that it's really easy to make a theme. It's not easy to make a theme that works 100% of the time. And uh if you've ever tried to make a theme for like the WordPress.org or theme directory like a free theme or um if you're working on a big agency theme that you know highv value client type situation and you're constantly making changes to it or whatever you want to be able to um ship and deploy with confidence in either situation. Nobody wants to create a theme and submit it to the theme review team and have it come back with a bunch of issues. And so I have added many layers to WP rig to help catch issues in your code early before you deploy so that your CI/CD pipeline can throw an error or that you can just catch these problems manually on your own before you deploy them or submit them for review. We do have uh a spec.md file that gets built up by your agent over time automatically. As a matter of fact, every time you ask the agent to create you a new feature in WP rig, it will automatically author a new spec.md file. Uh, and then it has these playright tests built into it that allow it to test what it builds based off of that spec and go back and fix anything that it catches. And you can kind of create type of a kind of like Ralph loop type development experience uh with WP rig right out of the box. Cool. So here are the three um types of scenarios that we're going to kind of paint here. Uh I'm going to start with the second one on this slide. Uh I just forgot to like change this slide. I decided to change the order in which I'm doing this. But we are going to start with a more of an agency type approach here. I'm basically going to show you how quick and easy it is to get up and running with like a classic or yeah, a classic uh WP rig theme, which is what it was originally designed for. And then we'll get into uh like what you know how we would use it to create a blockbased theme. If you're a solo contributor, you want to submit it to the theme directory or uh a a new feature we've added recently is that you can now use WP rig to author child themes too. So, we're going to go over the child theme scenario. If you have an parent theme that you rely on heavily for whatever reason, maybe it's, you know, something like Ali or maybe it's the 2025 theme or whatever, um, you can use WP rig to author a child theme to override certain aspects of that theme. So, it should be a lot easier for agencies to build custom themes. Um, I would say probably like three or four years ago, it didn't make as much sense for people to build their own themes from scratch. And it made more sense to just spend money on a paid theme and just get up and going as fast as possible. But with AI, the build [clears throat] versus buy has changed dramatically. And I would argue that now uh the situation is inverted and many people are still unaware that that inversion inversion has occurred. Uh I would say with probably like 20 to $30 worth of tokens, you can easily create a theme for any website build situation that will perform even better than some big expensive multi-purpose theme. and do exactly what you needed to do. Now, it's not going to be a theme that you can necessarily use on like a thousand different websites right out of the gate for 20 or 30 bucks, but it's certainly a theme that you'll be able to iterate on over time and you could in theory turn it into your own custom multi-purpose theme that belongs to you. So, no need to worry about licensing. Somebody else didn't make it. Uh, it gets updated when you want it to be updated and you can do whatever you want with that theme. You can use it on a client website. You can put it up for sale. You can share it with the world for free. It's up to you. So, that's the nice thing about agencies building themes is that they can create their own library of themes and use it on all their clients websites without having to worry about how many licenses do we have for this theme or whatever. Um, so we really want to make sure that we're respecting the design teams. uh wishes. When we're thinking about an agency scenario, a lot of times people have a design that they're trying to implement by way of a theme. Uh so some things that you might want to think about while you're thinking about, hey, we're going to build our own theme from scratch is, you know, how do we get the design system in our theme to match the design system in Figma? or how do we make sure that we can have multiple developers working on the same theme at the same time or how can we make sure that none of those developers cause any issues or add any regression or issues into our theme. WP Rig kind of helps you take care of all of those things. Now, so at the heart of WP Rig and what kind of happens behind the scenes when you first run rig init um is there's a config.json file and that's kind of like the memory for your theme development project. It remembers what the name of your theme is going to be, uh all of the details that are going to get added to the style.css CSS file and all kinds of other stuff too like what your local development environment URL is and port numbers and there's all kinds of stuff in there. Uh so just you can look at the defa there's a defaultconfig.json file. Um but the config.json file is the main file that it uses. You can also override that with a local.config.json JSON. Um, in in a team-like scenario of different people are using different local development environments and different URLs, they can override the config.json with the with the local one. And then if if an agency has a lot of like strict guidelines or uh opinions about how code should be written uh what's good PHP tabs versus spaces things like that uh the PHPCS configuration is completely configurable and so any dev any senior dev can change those guidelines to meet whatever they think are the best um I guess criteria for good code, but by default it follows um the WPCS standards. I don't know if anybody's familiar with that, but there is a library or a project that's maintained called WPCS. It's basically a configuration rule set for PHPCS, and that essentially automatically checks your codebase for bad coding practices and with PHP CBF allows you to automatically fix those. Um, and so all of that is built into, well, it's not only built into WP rig so that devs can change those things. It's also there are skills. So you can now unleash your agent on that task as well. And you can say, "Hey, agent, check check all my stuff. I'm done. I'm done adding this feature to the theme. Run all the checks. Make sure everything passes. And anything that doesn't pass, fix it. We also re uh we also created a open component registry uh very very recently actually. So this is a open GitHub repository. It's completely open source and the idea here is that WP rig now gives you the ability to pull in PHP components at will. So, if you want to add a feature to your theme uh that maybe doesn't make sense for every theme, but does make sense for this theme specifically, um you can create your own component and contribute it to the open component registry if you want other people to then go use that component. So, a good example might be like a mega menu component or um maybe it's like a dark mode component. There's four or five uh components in the open component registry right now. You can find that registry on GitHub. Uh you could just Google it and see those five components. One of them is like a hero interactive hero component some other stuff. So um yeah and then agencies can also this logic is built into the framework. If an agency wants to have their own private component registry that other people don't have access to but they want to have so that various members of the team can share components between projects that ability is also baked in as well. Uh the dev toolbar gives you ability to uh purge transients. Uh so if you're doing any kind of like WordPress level caching using transients uh that's built into the toolbar as well. Uh uh and I'll there's there's a few features here. We'll get to the demo here shortly. But um one cool thing that that's there now that I don't I haven't seen anywhere else is like the ability to lock your mobile navigation. So right now if you're building like a blockbased theme and you want like to inspect your mobile nav so you have to open it first. If you try to like click on the dev tools while that thing is open it autom there's like code built into core WordPress that like tells it hey when they click away from this nav like close a nav that makes uh the development experience a little bit tricky. So, we added a feature in here that allows you to hit like a little key key combination while you click on the navigation, it will lock it. Um, and that also only happens in the development experience. There's also a playright or several playright scripts built in that like very strictly and strategically test your mobile navigation for you. Uh, so uh well, not just mobile, also desktop navigation. And there's also a mode for you to watch it. So it'll like slow itself down and allow you to watch the AI, oh, not the AI, the playwright script automatically go through and test your navigation for you. And that's just one of many ET playright scripts that are built into WP Rig. There's also a Lighthouse performance script and various other things in there. You could take screenshots with it, too, to give your AI agent some visual feedback on what it's doing while it's coding. And yeah, let's do let's do a hands-on walk through. So, let's see. How do I want to do this? I have already before this all started um set up a local development environment running on WordPress Studio. And this is a brand new local site. And I'm just going to show you how quick and easy it is to get up and running with WP Rigg in a scenario like this. Um, think this one's going to work anymore. So, let's just go here. Open terminal. And I'll put it in presentation mode here soon. But the problem is in presentation mode, it only shows the code. And we need to be able to see the terminal. So, just pay attention down here. And we'll clone WP rig. And I got to figure out what screen I got to be on. I'm just going to the GitHub repo for WP Rigg and I'm just copying the URL. The Wi-Fi here is not the fastest, so bear with me. CD into WP rig. Um, so some of the instructions you'll find say MPM everywhere. If you're using bun, you don't have to type npm. I recommend everybody start switching over to bun. If you don't have bun installed, install bun. Um, but you can every every time you see the word mpm on any of the documentation, just know that you can use bun instead of uh mpm. So, I'm going to use bun because it's faster. And then this is going to install all of our node and composer dependencies for WP rig to make sure it can do all the things it needs to do. And just like that, it's done. So now I just need to give it the URL to my local environment. So in this case, I'm using WordPress Studio. So we're going to pull up WordPress Studio. And I'm just going to click open site, which I kind of don't need to do, but I'm going to anyway. And then I'm going to paste this in here. And then if you follow the example, it shows you there it says don't put the HTTPS. You don't have to. Just need the URL. This is just so that browser sync works. If you don't care about browser sync, you don't even have to do that. And then I usually just click yes through all those things. And again, in this situation, we're just going to do a classic theme. And that's it. And so we've now like already installed WP rig. It's like ready to go. So before we like look at it and test it, uh we'll want to build it first. Uh so now you get to see how quickly it builds. This is just a one-off build. This is not starting the dev server. I'll show you that in a second, too. It's done. So, we can now go to the local development environment. And I don't even know if this is the right one actually. Hold on. Think I meant to go to this one. Yeah, this is the one we want. And then I'm going to go back here and just click on admin. And of course, we'll need to go find our theme. So, we're just looking for WP rig in this situation. WP rig is what your local theme is always going to be called. So, like you can consider WP rig like your source theme. When you run the bundle command, it will actually create a whole new version. So, it'll create a whole new theme in your themes directory. And that theme will be named whatever you set in the config file and not just named like that in here in the WordPress admin. It will white label all of the code in the entire codebase. So anybody reading through your code for this theme, if they're reading the bundled code, they will have no way of knowing that you even use WP rig to create it in the first place. So now we can go test this out. And here we are. This is like default standard WP rig. Uh this is like a starting point. Consider this like a blank slate. And it's only dark like this because out of the box WP Rig supports light mode dark mode detection using the prefers color scheme uh CSS feature in our toolbar down here that we just recently added. We can see we've got some stuff being caught. Although none of it's critical. It's all just warnings. And then we do have a tool down here to change how we're viewing it. And notice that the ally stuff that's getting caught has now changed because I've changed to light mode instead of dark mode. So, it's now catching a whole bunch of stuff that we didn't catch in dark mode on light mode. We could also change the light mode, dark mode of the toolbar itself, too, if we want separately. And if you don't like this toolbar, you can disable it in the config.json file and never see it again. Or you can also just close it. And then you'll keep this little bubble down here. And you can just reopen it whenever you want. And it's just there. And we can use our AI selector tool to go around and select anything we want. Whoops. What is that? A little bug just happened. Uh oh. The live demo curse strikes again. There we go. I'm gonna change to this because that's my faves. Okay. And then notice how all the details about what I just clicked on are all in here. I can add additional context. Like this looks bad. Fix it. I don't know. And then we can just copy this whole agent. It like added that for us. And we can just copy this and paste it into our agent and it will just fix whatever and it will contain all of this context automatically. So that's pretty cool. We can also see like what template files are being used to construct this page. Uh and then we can also like I said earlier purge this cache. And this is just default WP rig. Now, if you're doing this locally, if you're following along, you probably don't have these menu items up here, and your website probably isn't set up to run like a regular marketing site does, where the homepage is set to a page called home, and the blog page is set to a page called blog. And something worth pointing out here is that WP rig does come with some WP CLI commands built in. So if you're using the WP CLI, you can just use WP space rig space setup. And all of this is in the documentation, by the way, on wprig.io. and it will automatically set up your local environment to not only change those settings so that your homepage is home and your blog page is blog and all this stuff, but it also automatically installs a whole bunch of plugins for you. It's a curated set of plugins that we have decided, I guess I have decided are handy plugins to have while developing a theme. So something like Faker press to add fake content to any of your pages or the accessibility checker plugin or any of these other query monitor all that stuff. It's all just helpful tools to have while you're developing a theme. And like I said, dev setup installs that automatically. Another WP CLI command that was used to create this situation that you're seeing right now. I didn't run it. I ran it ahead of time before this presentation um is a command called uh fake menu items. And so you can just run wp space rig space fake underscore menu items. And then what that will do is automatically create a whole bunch of fake menu items for you. So why would you want fake menu items? Well, so you can test your navigation. Um, and there's some arguments you can pass with it and change the depth of it. So, it creates sub menus within sub menus within sub menus and all this stuff. And so, yeah, just again focusing on the developer experience, making sure you can easily kind of get up and running with a theme, at least a basic version of the theme. And then at this point, you can do all kinds of other fun stuff like add micro animations to your sub menus or box shadows or change the mobile navigation. So we can like look at that real quick. Like out of the box, let me refresh the page so we don't get that little outline. Out of the box, your mobile navigation is just this, which is nothing very fancy. But if you wanted to make it more fancy, you can kind of go to town here from here. Again, this is just a starting point. Remember, WP rig is a starter theme. Um, so just it tries not to add too many opinions, but also give you a good working out of the box situation. So, if you did all the steps that I just did and you were just trying to make a very very very basic theme, in theory right now, you would already have your own theme. It wouldn't be a very unique theme, but it would be a theme nonetheless. And so, uh, at this point, if we wanted to, we could say, hey, we're we're done with our theme. We're going to call this theme like I don't know the basic theme or something. And we could just uh release the theme as is right now. And so in order to do that, we could just go in here and we could just say, well, you know what I'm going to do first? We're going to let's go into the config just so you all can see the renaming stuff here. So, I'm just going to call this word campus US 2026 demo. And then obviously, we will want to rename all this, too. Uh, I'm not going to get too crazy with it. And then, of course, you'd want to change all this to like your name and the repo where you're storing it at and your own website and your own description. And I'm just going to leave the name space as is. I don't feel like messing with that right now. Okay. And you can see kind of what's in here in this config.json we were talking about there earlier. I will switch it to presentation mode for this so everybody can see a little easier. Sorry. And um and this kind of helps you understand like how it's kind of all set up. So like here we tell it what our local environment admin and password is which is always this illustrious. And then we've got our local host configuration that we gave it when we started. And there's all kinds of other stuff in here. Um just so you're aware what all there's other settings you can make it not do some of this stuff. Okay. And then now that we've changed the name, we can go ahead and just say bun run bundle. And it broke. Not quite sure why it doesn't like what I named that. Let's fix that. Not quite sure why it doesn't like that. Okay. Okay. And just like that, we've created a new theme that's called Work Camp US 2026 demo. And nowhere in this theme is it going to say WP rig. Well, except for the name space that we didn't change, but if we had changed that, it wouldn't say that. So, yeah, basic classic theme, the most simple use case for WP rig. Um, and obviously this bundle command if you're using this like in a CI/CD pipeline situation. So say you have a repo and you want every time you merge to the main branch you want to deploy this to somewhere uh you would make this bundle part of your YAML file essentially. So you would just tell it pull the repo down, run mpm run bundle, whatever artifact is generated from that bundle, then upload it and decompress it. Um, it does not it doesn't only like make the regular directory too by the way. It also automatically creates a zip file. So that zip file is what you would want to deploy. Any questions on that before we go on to like the next like use case looking into block based use case and all that. All righty. We'll just keep on keeping on here. Um there are some things that I was going to demonstrate in here. I don't know that we have time for all this. Um, but I'll share a link at the end of this presentation to this slideshow. And if you all want to use this slideshow as like I don't know a little objective guide to try and see if you can build these things in WPreak uh yeah you can go ahead and use this slide I guess to do that. So, another thing I was thinking about, I remember I saw in a talk like two or three years ago, um, Matt Mullenwig said he wanted more block themes created and added to the WordPress.org theme directory. And he's expecting this to grow. And I believe that there is a large number of people out there, especially creative people, that now that they have AI, would want to whip up a little theme and throw it out there. And so we should encourage that behavior so that we can get a wider variety of blockbased themes on the theme directory. And so in theory, we could use WP rig to help us get there. And so we're going to talk a little bit about that. So the scenario is we have a solo contributor. It's just one person. They have an idea for a theme and they want to not only create this theme to have all the features that they want, but they also want to make sure that this theme meets 100% of all of the WordPress core standards and does not get rejected by the the theme review team when they submit it. And we want to make sure access accessibility is there out of the box. So how does WP RIG help us get there? Well, I showed you the the ally toolbar down there. That is one of many things. Um but there's a lot more there that we could go into detail about. Uh something to point out here is that when we build a blockbased theme with WP rig, it does automatically change how WP rig is set up. So you get a theme.json added, you get a templates directory added. Um it does remove some stuff like some classic paradigm stuff. It'll get rid of it and it will add whatever it needs to make it a blockbased theme essentially. forgot to take this slide out because I didn't think container queries were all that cool. Um, yeah, after the fact I was like, why container queries? But I will take this opportunity to go off script a little bit here from the slide and just mention that WP rig does have a concept built into it um called custom media queries. And so you can think of this as like CSS variables for your media queries. [snorts] So why don't I just let's just demonst it. So in the assets folder is where all of our CSS and all of our JavaScript is organized. And so there's a source directory in CSS and WP rig doesn't read any of the CSS files. Well, let me rephrase that. WordPress doesn't read any of the CSS files that are in the source directory. WordPress is only pointed at all of the min.css files that are in the CSS directory. And so these are only for development purposes. And if we go to this file called custom media, you'll be presented with kind of the defaults for these custom media queries. And so what these are are named namespaces for you to set break points that you can use throughout all of your CSS. So why would you want to do something like this? Well, if you're setting your breakpoints with magic numbers all over your code and you decide later on down the line, oh, we need to have eight main menu items in the navigation and not six. Well, but I also don't want the main navigation items to like bump down to the second line. Now, you need to change your mobile breakpoint because you have to make it break to mobile sooner essentially. So you want your hamburger menu to come up sooner and you want your one column situation to come up sooner and all that stuff. And so here we can just edit one file to make that change as opposed to not using this approach and having to go through all of your CSS files and change all of your numbers in all of your files. So while that's not container queries necessarily, uh it is a very nice feature of WP rig and it's not something that you get out of the box with any other framework as far as I'm aware. Uh I've this has actually saved me so much time in the past. So, if you're building a blockbased theme, you may want to build some custom blocks. And while it is best practice to create all of your blocks as plugins, there are some unique scenarios where it does make sense to have blocks built into your theme and have theme level blocks. Now, before I continue, I will say that if you have blocks built into your theme and you try to submit that theme to the WordPress.org theme directory, your theme will get rejected because themes are not supposed to have blocks because that's plug-in territory. So, when would you want to have blocks in your in your theme? If you're creating a theme you're not submitting to the WordPress.org theme directory, then you can put as many blocks in there as you want. And so there is a whole block building system uh that is similar to and actually inspired by the create block package um that will allow you to build blocks in WP rig using the built-in WP rig build system which as we've seen already is extremely fast and it is actually faster than using the standard create block package as it exists today. Now, maybe they'll upgrade it in the future and it'll run on faster tech in the future, but as of right now, your blocks will build faster in WP rig if you author them in there. Um, now you may run into a situation where later you want your block that's built into your theme to not be specific to your theme and say, "Well, I want to use it somewhere else without this theme." In WP rig exists a script and a command that will extract the block from your theme and turn it into a plugin for you. That also solves the problem for the WordPress.org theme directory. So you build your blocks and wpig, you run this one command before you submit it to the theme directory and then I don't know, you submit a plugin I guess at the same time too. whatever's clever. Um, but yeah, there's all these commands like scaffold a new block and uh remove blocks, build your blocks. Actually, your blocks get build automatically by the build system if you're running the the dev server. And also, if you try to bundle for the WordPress.org theme directory, which there's a command specifically for that. It will fail if you have blocks in there and tell you, hey, you need to take these blocks out before you try to submit this. Essentially, there's a script built into WP rig to manually convert your theme to an entirely blockbased theme. So currently, as of right now, as of today, until some future version comes out, um when you start a new project and you tell it you want it to be block based or or universal, it actually just makes it universal every single time. Um but you can run this command right here and that will strip all of the menu features and customizer and all that stuff to make it truly block based. There's accessibility checks built into the AI check system. So, this would be important to run if you're building a theme for the WordPress.org theme directory. And again, just a reminder, all these tools that we're talking about right now, they're all what's handy if somebody wanted to just go create a theme for the theme directory all willy-nilly. We already talked about the browser inspector. This is this is overkill. All right, so I was going to do a handon walk or hands-on walk through here and actually do kind of what I just did, which is like build one from scratch, but I don't think we have time for all of that. So, I will show you something that I just built literally like I don't know. I guess I've been up here talking for like 45 minutes. So, it was about an hour and a half ago. I just built it out there with Gemini real quick. And that's actually what I accidentally showed everybody earlier, which is this. And keep in mind, this is like two prompts. Like not a lot of time was spent on this. It took probably about 15 to 20 minutes total to create some theme that I used Stitch for. So I had Stitch create a knockoff Word Camp US 2026 website and then I pumped it through here and tried to see how good it would do at blockbased and not great but um it would not take long to clean this up. So, it's a very short amount of time and we've already got colors, font usage, and other stuff in here. The only reason this like section down here is so narrow is because it's not set to full width in the in Gutenberg. Uh, as a matter of fact, from personal experience, I'll say when you are building a blockbased theme, one thing that is a little bit jarring at first is you'd be surprised how many things you have to go into Gutenberg or the site editor to change to get them the way you want them to be. And so, for that reason, AI is not very good at setting all that stuff up for you. Now, I will say if you're using WordPress Studio and if you've installed the WordPress Studio CLI, it is a lot better at automatically injecting WordPress content into your development WordPress site. So, just a quick little aside, if you're not aware of those tools and you've been trying to use AI to like generate content in WordPress, WordPress studio with studio CLI and if you have the right skills set up is very very handy. Uh, WP rig has a script built into it that automatically reads all of the schema of all of the blocks in the core files. and then uses that schema to provide better guidance and guardrails to the agent to make sure it writes all of your Gutenberg content appropriately and so you don't get any block validation errors and all that stuff. It works pretty well. 100% of the content you're seeing here is editable in Gutenberg. And as you can see, there are some validation errors. And this is the type of stuff that I'm talking about. So the idea is, can we get it to not do this? This is something I've been trying for months to figure out how to get it to not do this perfectly. Um, I don't know if anybody else out there has tips on how to get there, please reach out. because I'd love to know. Cool. Cool. So, let's go over the parent theme situation real quick. Uh, we got about 30 minutes left. I do want to leave some time for questions. Uh, before I go into the child theme situation, though, I do want to ask, are there any questions about anything that I just went through? I kind of covered a lot in terms of blockbased and WP rig and AI and all that. Again, that thing took me 20 minutes to build and probably about $8 worth of tokens. So, yeah. All right. I'll cover the parent theme use case real quick and then I will once again open up to questions. I do welcome questions, conversation, so please uh please feel free. So, here's the scenario. Um, you know, we've got a situation where we want to keep a parent theme and, uh, we don't we don't want to create a whole new parent theme. We just want a child theme to override the parent theme. You can use WP rig to do that. There is a child defy script built into WP rig. So when you do all the things that we did earlier, uh, which is like create a classic theme or whatever quick little exercise I went through, you can just go into your command line and just type mpm or bun run childify and then it will ask you some questions. So, it'll ask you what the parent theme name is and all this stuff and uh it will automatically change itself to a child theme situation and uh and create that relationship between itself and the parent theme. And of course, that relationship would carry over to the theme that you bundle. Why would you want to do this? Anybody who's created a child theme that has a significant amount of CSS or JavaScript in it knows it's very nice to have a build process built in that minifies your CSS, that minifies your JavaScript. Maybe you want to write in TypeScript and you want that converted to JavaScript, all that good stuff. There's no reason to scaffold that from scratch anymore. You can just use WP rig to build your child theme on and then you don't have to worry about any of that. So there are some commands that you do have to specify the use usage of bun. Uh something I will point out right now is that in the future, I don't know when in the future, but sometime in the future we will end up deprecating mpm. So probably like version four or something. It will just be all bun. So there will be no mpm. Everything will just be bun. We'll use bun for everything. And we may even take ES build out and replace it with all custom bun scripts uh to make it even faster. So just something to point out there. We do have a recctor PHP added. For those that don't know what recctor PHP is, it's basically a composer tool that allows you to identify outdated PHP and like convert it to new better PHP. Um that's built in. And not only is that built in, you can also run composer fix and it will automatically fix everything it catches in these checks. Uh some small things I'll point out real quick. If anybody's aware of what HMR is, hot module reloading, that feature is built into WP rig. It is not the default dev server browser sync situation yet. Uh, I wanted to give people time to like transition to that. And I wanted to make sure that the HMR system worked very well before I made it the default thing. So, you can try it now in WP rig. You just have to run a very specific command to start that up. Uh, that command is devodern. I think if you look in package JSON, you can find it in there. And there's also documentation on wprig.io that tells you that. And then I'm again because of time I'm not going to go through the process of creating a child. It's kind of in my opinion child things are a little boring. So it really doesn't make a ton of sense to just run the childify script. You guys would just watch me type that in and then see that it changed some files and then it'd be done. Uh so we'll just use our imagination there for now. Yeah. And so no matter which situation you're using in any I would say in the vast majority of situations if you're building any kind of theme whatsoever, I would highly highly recommend you consider using WP Rig. I don't think most people will quite understand all the benefits to using it until they actually try using it. Even if they've listened to this whole talk and everything, I don't think it really it doesn't really hit until you're actually using it and you're like, "Oh, this is nice." So, please give it a try and uh like I said earlier in the presentation, um if you catch anything, please report it in the issues. I've had several things reported in issues over the past six months. They're all already like fixed and in core uh WP rig. So, thank you to all those people that helped me identify all those things. This is just a breakdown review of kind of all the scenarios we painted here and all the different situations and which you might want to use WP Rig and the tools that are built into it that make it nice for that. And just a reminder again, WP Rig is 100% free and open source. So I'm not selling anybody anything here. I actually had to pay a lot of money to come here out of my own pocket. And so, uh, this is all just to raise awareness about WP Rig so we can hopefully get more people contributing and more people using it and more people appreciating it and and hopefully solving some problems uh for developers out there that have experienced the same problems that I've experienced and have attempted to solve with uh a WP rig. And again, a quick reminder, everything you built with WP Rig is yours. you own it entirely and so you can do whatever you want with it. Just Yeah, I feel like that's a it's a good reminder for people. Uh what else can you do with WP Rig? Uh well, it turns out you can make a whole slideshow presentation with WP Rig. uh because that's what you all have been watching this entire time is a theme that I built about a week or two ago for my own company website. So if you go to bizzle.dev, Bizzle is the name of my company. Hopefully I can get to it. Come on. Come on. So this is a theme. So I like to dog food everything that I make. And so this is a custom theme I made for my company website uh using WP Rig and the slideshow you're watching is all authored in Gutenberg. So the whole every slide you've looked at is a block in Gutenberg being fed through a page template called presentation and all the animations and everything are all powered by reveal.j JS is the library. It's a free free slide library that's available out there. And all the features like going full screen and getting out of full screen and progressing through the slides and everything were all added custom in WP rig. Okay. Again, going to open it up for questions. I hope somebody asks them because we got 22 minutes left. I'd love to have a conversation about anything that has to do with themes. I have lots of opinions. Again, the workshop guide is on wprig.io. Click on learnv3. That's the URL for the GitHub repo. And we do have a Discord server. So, if you want to join our Discord server for say like you're trying to get up and running with WP rig and you run into a problem or issue and you want me to like help you get through that problem or you want to talk about this anytime after this um you can just join the Discord server. I'll just accept anybody I guess and uh and you can just chat with me on there and we could talk and hammer it out. Yeah. >> Thanks very much for the presentation. Uh, I wasn't familiar with WP Rig before this, but it looks really interesting. I'm curious, how would you compare WP Rig with a framework like Roots? >> Oh, Sage particularly. Yes, Root Sage. Yes. >> Um, that's a very good question. I get that asked quite a bit. Um, so, uh, I looked at Sage before I even decided to like WPRG, let alone take it over as my own child project. Um, the biggest difference is that if you if you like Laravel, then you're probably going to like root Sage. If you either a don't like Laravel or B feel that using Laravel paradigms within the WordPress ecosystem is awkward like I do um then you might find WP rig much more attractive. Uh the whole idea is to align with core WordPress ways of doing things as much as possible where roots sage takes a lot of liberties. You've got the blade templating engine. You've got um tailwind is built in by default. And so yeah, I mean if if you like those things, if you like the blade templating engine, if you like tailwind, uh then then maybe root sage is for you. Um, but I will say that Root Sage doesn't have quite the number of modern features as WPRI does now at this point in time. Um, in the past it was probably a little bit better than WP rig. Uh, but we've come a long ways very quickly. So, >> great. Thank you. >> Yeah, no problem. Does anybody else have any other questions? I will also say that root sage is dramatically more popular than WP rig and so what I really hope is that that we close the popularity gap just a little bit just I don't think it's possible to overtake root sage because it is very popular um but I would like to see that gap closed just a tiny bit all right Well, if there's nothing else, uh, I'll give everybody 20 minutes back. Uh, you are welcome to catch me on the sidelines if you have questions. And, uh, thank you so much for your time and I'm happy to join all of you at Port Campus US this year. Thanks.