[00:00:00] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress, the people, the events, the plugins, the blocks, the themes, and in this case a firsthand look at the CloudFest Hackathon.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you or your idea featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today, we have something different. Usually it’s me, Nathan Wrigley, chatting with a guest about something related to WordPress, whether that’s a plugin, Core updates, or perhaps an aspect of the WordPress community.

This time around, it’s me, and later on, a bunch of guests talking about an event. The event in question has already taken place, but the next iteration of it is just around the corner. And if you read the title of this episode, you’ll already know that I’m talking about CloudFest.

CloudFest is an unusual event. The most obvious indicator of this fact is that it takes place in Europa Park in Rust, Germany. It’s one of the world’s premier theme parks.

CloudFest is at its heart, a tech conference, but every year, just before the main CloudFest conference begins, a very different event takes place. It’s called the CloudFest Hackathon. So whilst the rollercoasters are testing the laws of physics outside, inside a group of developers, UX designers and system architects are testing the limits of the modern internet.

Dozens of the world’s most talented engineers strip away the corporate sales pitches and set themselves a variety of collaborative challenges to be completed in just three days. Now we see hackathons all the time. Usually they’re sponsored by a single company trying to get people to use their specific API, or their high pressure competitions, to build a disruptive startup in 48 hours. But the CloudFest Hackathon isn’t like this. It’s professional, it’s non-commercial, and its primary intention isn’t necessarily to build a product, it’s to maintain the ecosystem.

So let’s hear from somebody who knows all about the CloudFest Hackathon, and that person, is Carole Olinger.

[00:03:04] Carole Olinger: My name is Carole, and I am the head of CloudFest Hackathon. I’m very excited about my role here and to be able to connect so many awesome people and talent around the world.

So I think there are multiple definitions for a hackathon. In this case I would probably define it as a gathering of open source enthusiasts who are going to be working and coding and designing a lot of exciting projects together. They haven’t met before in many cases, and they are put in the same room for three days being fed, being caffeinated and trying to improve the open web.

[00:03:42] Nathan Wrigley: Who’s on the organizing team?

[00:03:44] Carole Olinger: So basically, I am leading the whole operation in my role for CloudFest and the World Hosting Days. And I have the most amazing supporting team around me that anyone could ever imagine. So it is Lucas Ratke from Automattic, Alain Schlesser from Yoast, and Thierry Muller from Google, who are on the project support team, and making sure that we have all these really valuable projects in our event. And that project leads are prepared in the best possible way.

And for the first time we also have a volunteer that is helping during the event. And is specifically helping me wrangling the 110 amazing sheep around me, and to make sure that there are accommodations are covered. That all the catering is being done. And that is a Simon Kraft from Group One.

[00:04:36] Nathan Wrigley: I show up to an event like this, all the jigsaw pieces are in place you think, oh, it just happens, but of course it doesn’t just happen. How long have you spent working on this event? How long have you been wrangling this whole thing into existence?

[00:04:49] Carole Olinger: Usually we start in September. And then it’s more okay, what are our objectives? What are our goals for this edition? We are really trying to take as much feedback as possible from previous year’s attendees, to make sure that we have improvements in place and new additions to the event for the following edition. So that happens in September. Creating the team, making sure that we have specific objectives and goals and those are manageable.

And then the actual work starts in October, and then becoming more and more intense over the upcoming months. And I would say January is probably the most crazy month. I barely slept.

[00:05:31] Nathan Wrigley: So the idea really is that you put. In this case, 10 projects in a room. You’ve got 10 project leads and, in some cases there’s multiple people leading a project. And then you add into that mix over a hundred people, many of whom appear to be developers, and you stir that pot up a bit, and hope that things come out the end that are useful, that have been enjoyable to work on.

How do you decide what the 10, in this case, projects were? And are you oversubscribed with people wishing to be a part of it? And so how do you decide what makes it? How do you decide which projects are interesting to CloudFest Hackathon each year?

[00:06:10] Carole Olinger: So this has been evolving over the years. So I remember additions, three or four years ago, or previous to the pandemic. Where our project team was pulling projects out of the different CMS communities, open source project communities. So we had ideas about what we wanted to tackle, and some projects came out of the communities. So we were like hunting ideas, and also planting ideas inside communities.

This year is the first year where we didn’t have to do any of that. We had 22 pitches from different CMS communities and other open source projects that were pitching their ideas to us. So it was like a kind of a hard choice to determine which ones are going to make it.

So usually we are trying to take into consideration what the theme of the main event CloudFest is, and obviously as everyone is excited about AI these days, that is something we wanted to cover. So we made sure we had some projects that had AI involvement. And then what is really important to my heart, and to the team’s heart, is that we are having cross CMS collaborations.

So we are trying to have WordPress people here, which is obviously the community that I am mostly connected with. But also TYPO3. TYPO3 is one of our, the W3 Association is one of our top level sponsors. We since years we have Joomla people, Drupal people joining us. We are trying to find a good mix to empower those cross CMS collaborations and also cross-project collaborations. So even within one platform, just to name WordPress as an example, we try to make sure that we have projects that could eventually benefit from each other.

[00:07:54] Nathan Wrigley: I’m guessing also, there’s a component of trying to work out projects that if you put a hundred people in a room, there’s not a hundred replicas of the same person. Each of them are different. That there are 10 different places where they can land. Because one thing that I didn’t realize and was really curious to me, is when the Hackathon started, apart from the project leads, nobody’s assigned a place to go. They listen to a little speech at the beginning. It’s like a promotional thing. Two minutes, this is what we want to do, the pitch. And then the people make a decision. And for 10 minutes or something, there’s this sort of chaotic moving of people around, and then it all settles down.

So presumably you have a wide array of project pitches, so that those a hundred plus people can decide, they’re not all surrounding the one table and there’s a table over there that’s empty, I guess that fits in the jigsaw as well.

[00:08:44] Carole Olinger: So we are taking very much care about the selection process of applicants. So when we know what our projects are going to look like, we are trying to match their needs in terms of skills that attendees are going to present to us during their application.

So usually we have between 300 and 400 applications for the Hackathon, and we have 110 slots. But, and this is important to understand, our partners are bringing team members within these 110 attendees. And our partners this year have been super actively involved, which I love. So they were not only giving us money to make this event possible, to be able to invite open source contributors to this place, including their hotel, accommodation and food. They were bringing, people resources. I hate the term, but you know what I mean. So they were sending their crew to lead, to participate in these open source ideas and projects. So in the end we had 60 available spots for open source contributors. And then we made sure that we are matching the skills that they were sharing with us in their applications with the needs that the projects will have on the table.

So we have a pretty good understanding already about who’s going to be at what table. And obviously we are monitoring that. So we give them some time to make the decisions. And if we see that there are skills missing at a certain table, or if there’s another table that is going to be too full and too complicated to manage by the project lead, we are kindly convincing, and reassigning people, to participate in different projects.

[00:10:19] Nathan Wrigley: So that’s interesting. So it’s not just a free for all? The idea is to maximize the output of the projects, the 10 different projects at the end, and you will, like you said, politely, ask people to move over if you believe that the thing that they have said that they’re good at, is, matching. And there’s a, I don’t know, a hole in one particular project.

That brings me to this question then. Is the intention that these projects have a life after this event has finished? Or is it just a case of, okay, we’ve all had a nice time, the event has closed, let’s all move on with our lives.

[00:10:48] Carole Olinger: This is becoming more and more important to us. As I said earlier, we are trying to improve something every year like, like focusing on something when we are fixing our goals that we can do better every year. And what we can definitely do better is spreading the word about what amazing achievements the teams have been building during the event, and make sure that this project’s become more sustainable. So that the world knows that there’s potential in the outcomes of CloudFest Hackathon project, and to potentially unlock support and resources for these projects to continue.

I would love to spread the word, making it possible to unlock these resources. And then also inside our team, building more and more resources to follow up with this project leads from our end.

[00:11:33] Nathan Wrigley: There’s an element of, how to describe it? There’s this time pressure in the whole event. So that the thing is basically three days long, from inception until final judging, three days. So the pressure is on, and I can feel at the moment the pressure is increasing slightly. You can sense that people are getting quite into the project they’re working on.

I noticed last night, long after the event had officially closed down, there was quite a lot of people still sitting there. They’re were obviously wedded to what they’re doing. There is this sort of like Shark Tank element where there’s going to be a judgment at the end and somebody’s going to win.

How does that work? Who gets to decide who’s the winner?

[00:12:06] Carole Olinger: So we do have a jury, and the jury is composed of representatives of our top tier partners. And they send one representative to the jury. Then we do have one representatives from the Groundbreaker Talents charity project. Because, on a side note, all these awards are being sponsored by companies, and everything that we are collecting in terms of sponsorships is going to the Groundbreak Talents initiative. And then we have the project support team, and myself being on the juries. And it’s an uneven number. So we have nine people, which is always good to have on a jury. And after the presentation of results on the last day of the hackathon, the jury is going to deliberate.

And then we are going to listen to the project support team, who has been working the room and connecting with the project tables during the three days in terms of technical achievements, challenges they have seen. So they’re going to give us some impression on that. And that is mostly important for the Tech Visionary Award. And then, all of us have had the chance to obviously see the presentations, which is important for the Pitch Perfect Award. Who has the most appealing presentation of results? We do have the Social Media Master Award, that is fully being tracked.

So Simon and I, we are going to give the jury some insights on who has created the most boss on social media. . And, then we do have the Breaking Barriers Award, which is a new one. So this is about using inclusive technologies, and getting some outputs that are going to be helpful for a diverse set of users, and connecting people on the user base, but also how the people have been working together in terms of having diverse skills and perspectives on the table.

So these are some of the awards, and there’s going to be an overall winner. We have five categories, and an overall winner. And the overall winner is, the one that has the most points.

Thanks to Carole for that comprehensive introduction to the CloudFest Hackathon. Now, let’s look at the why. Why do people travel from 30 plus different countries around the world to do all of this?

In our industry, we talk a lot about the cloud, but we often forget that the cloud is just a massive collection of interconnected open source projects. You have WordPress powering 40 plus percent of the web, you have the Linux kernel, you’ve got PHP and Python communities, and then you have the hosting providers and hardware manufacturers. Normally, these groups live in silos. They communicate via GitHub issues or formal API documentation. Well, the intention of the hackathon is to create what might be called the human API. It’s about taking a person who might maintain a security plugin, and sitting them at the same table as an engineer who manages millions of servers for a global host.

When you remove the barrier of the screen, the friction of the internet disappears. Problems that have been sitting in a backlog for six months get solved over a coffee, or a shared meal because the right people are finally in the same physical space.

Although, as Carole mentioned, there is a winner, this isn’t really about winning a prize. In fact, the prizes are almost secondary to the real goal, which is contributing back to open source projects, some of which already exist, some of which are new. The intention is all free and open source software or FOSS for short.

These contributors aren’t there to build something proprietary and closed. They’re there to ensure the plumbing of the internet stays robust, secure, and interoperable. Oh, and to have some fun collaborating at the same time.

Speaking of contributors, let’s hear from some of them now and get a little taste of what their project was all about.

The room as you will hear was a little noisy.

[00:15:52] Javier Casares: I am Javier Casares and I am one of the co-leads from for the CMS Cloud Manager Project.

[00:15:58] Nathan Wrigley: What does this project hope to achieve?

[00:16:00] Javier Casares: Usually when you have a cPanel or Plesk or some kind of panel, you can install a WordPress, for example, with one click, but the server is not configured.

So in this project, we want to configure not only the CMS, but also the server where the CMS is going to be

[00:16:20] Nathan Wrigley: And how’s it going so far?

[00:16:22] Javier Casares: It’s fine. We have the public part because we want to have a website so you can configure things and prepare everything. And then we have this software, the real software that creates everything. And more or less it’s, fine, at this moment. So I think we can achieve everything for the hackathon, for the finals.

[00:16:46] Mattias Pfefferle: I’m Mathias. I am working on Activity Pub and the Fediverse.

[00:16:51] Nathan Wrigley: And what’s the project that you’re working on at CloudFest, the Hackathon?

[00:16:55] Mattias Pfefferle: We are working on federated events. So it’s very much a special case of the Fediverse.

[00:17:02] Nathan Wrigley: And what is the intention of the project? What are you hoping to get out of it?

[00:17:05] Mattias Pfefferle: We try to build a decentralized, alternative to the big social networks around events, so that people does not have to rely on something they do not have control over. So we would hope to get an alternative to meetup.com, maybe, or any other big closed proprietary social network, around events.

[00:17:29] Nathan Wrigley: And how’s it going so far?

[00:17:30] Mattias Pfefferle: It’s mixed, because even if it’s a standard, there are different variations of using the standard. So we filed a lot of bug reports, and tried to work on a standard that better describes the standard , if that makes sense? And we’re trying to make federation happen using WordPress and some other platforms that are built by people that are part of the Hackathon team.

[00:17:58] Milana Cap: My name is Milana Cap, and I’m on a project WPCLI as MCP. MCP stands for Milana Cap pro. No, it doesn’t

[00:18:09] Nathan Wrigley: What is the intention of this project then?

[00:18:11] Milana Cap: We are introducing AI into WPCLI. So, you could use AI in different aspects of WordPress, like content creation and all of that. But it was missing in development process, especially in local instances. So now we have that, and it’s actually a lot of fun. Much more fun than I thought.

[00:18:32] Nathan Wrigley: And how’s it going so far?

[00:18:34] Milana Cap: So far we build a spam machine, and that’s official name. And we actually had a MVP on first day. It’s really fun. Yeah. And we are just learning how this AI is behaving by itself in our locals.

[00:18:52] Patricia BT: Hello, Nathan. I’m Patricia BT. I’m living in Geneva, Switzerland. I speak French, and I am my own boss, . And I came, with that pitch, as a project for the Hackathon because for me it’s very important to own your data and preserve what exists on the web, and not lose anything.

[00:19:11] Nathan Wrigley: And what’s the name of your project?

[00:19:13] Patricia BT: CMS Freedom.

[00:19:14] Nathan Wrigley: And how’s it going so far?

[00:19:16] Patricia BT: It’s going very well. We have, tech people here, engineer, who are doing amazing work with, especially LLMs. So we are using AI to grab any HTML content and discover the format, the elements, and then later be able to import that into WordPress block theme.

For now it’s WordPress block theme and content. And later the hope is that people from other CMSs, other system, can just modify that last bit and import what the tool extracts, and import to their own system. So we can move from any HTML, render any page on the web and create that for your CMS.

[00:19:59] Nemanja Cimbaljevic: Hi, I am Nemanja. I come from Serbia and currently I’m with GoDaddy as a software engineer.

[00:20:05] Nathan Wrigley: And what’s the name of your project?

[00:20:07] Nemanja Cimbaljevic: I will not break my tongue. We will call it AI Accessibility Content Updater.

[00:20:12] Nathan Wrigley: And what is the intention? What are you hoping to achieve over these three days?

[00:20:16] Nemanja Cimbaljevic: We will try to make a proof of concept that will allow us to move on in the future where the AI is capable to help with accessibility of the websites that can be improved? Not all of them.

[00:20:29] Nathan Wrigley: Are there any constraints around what it is that you are hoping to be able to do? Or is it literally all the accessibility?

[00:20:35] Nemanja Cimbaljevic: It’s all about accessibility, and yes, we will see where we will go. It was announced as a trial and error. So we will see if there is any trial or just error.

[00:20:48] Anne-Mieke Bovelett: Hi, I’m Anne Bovelett.

[00:20:50] Nathan Wrigley: And what’s the name of the project you’ve got at CloudFest Hackathon?

[00:20:54] Anne-Mieke Bovelett: It’s called Accessible Infographics.

[00:20:56] Nathan Wrigley: And what is the intention? What are you hoping to achieve in these three days?

[00:21:01] Anne-Mieke Bovelett: Right now we’re creating a plugin for WordPress. . And when you have infographics on your site because you produce medicine, or machines, or you have statistics on your site. You can use our WordPress block, and upload an image through that, and then it will help you to make it accessible by creating extra information under the hood.

And the best thing of this is it’s not just going to be for WordPress, because we’re conceptualizing that for others so they can easily recreate this in other open source CMSs. And it will save millions and millions of people from sitting in the dark with very important information on websites.

What it actually means is that, also when we manage to move on with this project in the next phase, we’re gonna try and do this in bulk. To do it backwards for companies that already have a lot of infographics on their website, and understand that they have to do it either by law, or because they’re smart and want higher converting web shops, for example.

And then the possibility will come that they can do that backwards in bulk, and it will save them thousands and thousands in money that they have to invest in making this happen.

[00:22:20] Wesley Stessens: Yes. My name is Wesley Stessens, and I’m from Belgium, and we work on the Peer-to-peer Federated RAG Framework with, our team.

[00:22:30] Nathan Wrigley: And can I ask, what is the intention of that project over the three days? What are you hoping to achieve?

[00:22:35] Wesley Stessens: We are hoping to achieve something that hasn’t been done before in the, in the RAG space.

So basically RAG, or Retrieval Augmented Generation is way how you can augment an LLM and AI with extra data. And we want to allow everyone to create their own databases. And anyone can just join our network with their own knowledge.

For example, someone who knows a lot about beers, they can join our network and have like a library full of all information about very specific niche beers, maybe beers they brew themselves or whatever. And then any other node in the network can ask a specific question. And then our purpose is to route that question to the best matching node in a decentralized way. So there’s no servers or big companies. In between everything is done in a peer to peer way. So they get back the best matching documents from other people’s libraries, so to speak.

And then we use that to ask an LLM, or an AI a question with the context that we got from other people’s databases that matched best. And now we show the results to the user, or we create like a chat interface maybe around that. That’s the end result that we hope to achieve.

[00:23:49] Tadas Pukas: I’m Tadas.

[00:23:50] Nathan Wrigley: And what is the name of the project?

[00:23:52] Tadas Pukas: It’s WordPress Staging Environment Manager. It’s a bit complex to understand, but it does very simple thing.

[00:23:59] Nathan Wrigley: And what’s the intention at the end of these three days? What would you ideally like to be shipping? Have finished?

[00:24:05] Tadas Pukas: Yeah, so we want to have open source plugin, and actually we have it almost, so it’s the final touches.

And this will be distributed. It’s already in the public GitHub repo. So people will be able to download zip file, install a plugin, and create staging environments. Not only create but sync changes from staging to live. Actually, our name of the plugin is Staging to Live, so it’s, yeah, almost done.

Almost ready.

[00:24:29] Nathan Wrigley: Okay. I hope that you enjoyed this different style of podcast. Hopefully you learned something about CloudFest and the CloudFest Hackathon.

You certainly got to hear from a wide variety of contributors, and got to peel back the curtain about what a hackathon is, and the different projects people work on. There’s a great energy at events like this, and maybe this will convince you to explore hackathons in the future.

You don’t need to be a coder. Each project needs a wide array of talents from coders to marketers, designers, to project wranglers.

Like I said, at the top of the show, CloudFest 2026 is just around the corner. There’s an annual event both in the US and the one discussed here in Germany.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast.

And we’ll be back next week with more from CloudFest and the CloudFest Hackathon.

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case the future of theme development.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today, we have Rob Ruiz. Rob has been involved in the WordPress ecosystem since around 2010. He began as a designer, but over the years WordPress has helped him transition into a developer, software engineer, and now an architect. Currently, he’s working full-time at an agency whilst taking on side projects independently.

The main topic for today’s conversation, centers around themes, a subject that hasn’t been covered in depth on the podcast for quite some time. You see, Rob is the current custodian of WP Rig, a free and open source toolkit for WordPress theme development. WP Rig offers a modern, minimal, and best practice driven starting point for developers who want to build custom themes. Providing tools like Composer and Node integration to streamline workflows, enforce coding standards, and enable the use of future facing CSS features, right now.

We start the episode with Rob sharing what attracted him to WP Rig, and his journey from user to Project Maintainer. We talk about who WP Rig is for, from experienced developers, to those just starting to dip their toes into theme building and code customization.

The discussion moves on to talking about what a theme development framework actually is, and why this approach might suit people wanting more control, and education, in their WordPress journey. Rob describes the learning curve, the workflow, and the satisfaction of creating your own theme from scratch, while highlighting tools and guardrails built into WP RIG that make professional standards and best practices accessible to all.

We also get into how WP Rig fits into the changing WordPress ecosystem. With the advent of full site editing and block-based themes, Rob explains how WP Rig has evolved to stay relevant, supporting classic, hybrid, and block-based paradigms, even enabling block development at the theme level.

Towards the end, we discuss the community behind WP Rig, how you can get involved, and the many educational resources available for those who want to learn theme development, or even become contributors themselves.

If you’re interested in building custom WordPress themes, want to understand the nuts and bolts of theme frameworks, or are simply looking for a modern and educational starting point for WordPress tinkering, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you, Rob Ruiz.

I am joined on the podcast by Rob Ruiz. Hello, Rob.

[00:03:56] Rob Ruiz: Hi. How are you, Nathan?

[00:03:57] Nathan Wrigley: Rob’s joining me today to talk primarily about themes, which I confess is a subject that we haven’t touched in a good long while. So before we get into that, Rob, would you just mind spending a minute just letting the listeners know who you are? If we are on a WordPress podcast, probably better to align that with what your journey is in the WordPress space, if that’s okay.

[00:04:17] Rob Ruiz: Certainly. Yeah. So my name is Rob Ruiz. I’ve been leveraging WordPress since about 2010 ish, although my web development experience goes prior to that. And so I’ve been tinkering and getting more and more into it as I go along.

I started off as mostly a designer back in the early two thousands, I guess. And WordPress has facilitated my journey from being a designer to more of a developer, software engineer, today, architect. And so yeah, it’s been a very fun journey. I’ve learned so much over the years, so I’m very grateful to WordPress for helping me do that at my own pace.

[00:04:58] Nathan Wrigley: Do you work for yourself? Are you perhaps engaged in an agency or something like that?

[00:05:02] Rob Ruiz: So currently, right now I work full-time at an agency, but I do also do work for myself as well. So it’s kind of a hybrid situation.

[00:05:09] Nathan Wrigley: Okay, so the reason that Rob is on the podcast today, well, there’s a variety of reasons. Most of it will bind itself to the subject of themes, as I said right at the start. But we’re also going to be talking, maybe towards the end a little bit about AI and things like that.

However, Rob is now the custodian. I didn’t realise he was now the custodian. We’ll get into that in a minute. But Rob is the custodian at the moment of a project called WP Rig. And you can find this, it’s a really quick URL to type in, it’s WP Rig, so WPRIG .io.

Completely free to download, completely unencumbered by a pricing page or anything like that. There’s a GitHub repo I think. Yes, that’s right. So do you just want to give us the elevator pitch for what WP Rig is. And just because it makes me happy, can you tell us how you got involved? Because that’s lovely too.

[00:06:00] Rob Ruiz: Yeah. Yeah, for sure. So WP Rig is a theme development toolkit or framework, but it’s also a starter theme as well. So you could think of it as kind of like underscores but with a whole modern development toolkit situation built into it, meaning there’s a bunch of composer dependencies, Node dependencies, and other kind of developer tools baked into it to prepare developers for the best developer experience possible when developing themes for WordPress.

How I got involved with it essentially is I was, first off, I was looking for a theme development framework. I had gone on a journey to explore many. And during that journey, I came across WP Rig, and kind of fell in love with it. It was really, really cool. I liked it a lot. I liked a lot of the opinions. I liked how well aligned it was with Core WordPress itself. I like the WordPress best practices that it enforces, you know, automatically. You don’t even have to like go look them up and think about it. You could just run a tool that’s built into it and it’ll check all your code for said best practices.

And so that was very interesting to me. I was like, I’m going to start using this. And so I did. I did start using it. And then, shortly thereafter, I had been browsing my favorite WordPress news site, WP Tavern, and noticed an interesting article about the project that I had just recently fell in love with out of sheer coincidence, I suppose. Out of sheer coincidence, it just so happens this project is now looking for new maintainers, and that they were having a Zoom call in the near future where anybody interested in maintaining the project could join the Zoom call.

And so I did. I joined the Zoom call and I got to meet the previous maintainers, or maintainer rather, and ended up having ongoing conversations with him after the call. And one thing led to another, and now the project is basically managed solely by me with a handful of other light contributors.

[00:08:04] Nathan Wrigley: So that’s really nice. I love the fact that there’s some sort of combination of WP Tavern and WP Rig out there. That’s lovely. So I appreciate that. The audience for this podcast is pretty varied. So there’ll be developers with a longstanding history with WordPress, you know, deep in the code. Will go to WP Rig and immediately everything will connect, and they’ll be like, yep, I get this. I understand what this is. It’s for me. It’s not for me, yada, yada.

However, we also have quite a lot of people listening to this who are brand new to WordPress. They’ve got no experience with code. They may be living inside of a page builder or something like that where everything is point, click, drag, drop, save, that kind of an environment. It just occurred to me that they very well might not know what even a theme development framework is. So can we begin there? What is the point of a thing like this? What’s the problem you’re trying to solve? Let’s start there.

[00:08:53] Rob Ruiz: Yeah, that’s a great question. So like anything in WordPress, because it’s open source and so beautifully designed, might I add, from an architectural standpoint, there are lots of ways to extend WordPress beyond its base functionality.

Two of the most common ways to do this is via the plugin system, and via the theme system. And so we can add custom plugins to extend the functionality of WordPress, but we can also add custom themes to alter the way our website looks and feels aesthetically.

So if you’re somebody who’s more of a designer maybe, or you appreciate aesthetics and perhaps you’ve dabbled in some CSS, you might be more inclined, if you’re looking to go beyond just what Core WordPress provides to you in terms of a site building experience, I would encourage those people to look at themes and possibly creating your own custom theme. Or altering an existing theme using a concept called child theming where you can take any theme that you get from anywhere, whether you buy it or find it on the wordpress.org theme repository. You can extend themes using child themes, or you can just build your own themes from scratch.

So that does include some work outside of the WordPress admin area. So once you get into developing themes for WordPress, the concept here is you’re kind of straying away from the WordPress admin experience, and you’re now like in the code editor realm, right? Because under the hood, WordPress is all just a bunch of code, PHP, JavaScript, CSS. There’s a lot going on, the React now. There’s a lot of things kind of built into WordPress.

And so the beautiful thing about WordPress is that you can kind of, if you’re interested in learning how to develop, you can kind of dip your toes into the development pool as frequently as possible, as quickly as you want. Whatever you are comfortable with, you can kind of pace yourself there and say, okay, let me try and make a custom theme, or let me try to make a custom plugin. And if it doesn’t work out, it’s easy to just deactivate it, delete it, remove it, whatever. It’s a great way to learn how to develop, in my personal opinion, because a lot of the heavy lifting is done by the Core WordPress system.

Basically what WP Rig offers is, instead of having to create a file system, a theme system from scratch, you know, a lot of people will reach for a concept called a boilerplate. Something that will scaffold kind of like the common files and folders that would be necessary in a theme, and then allow you to work from there. So you’re not just starting from like ground zero, create a new directory, create a new file.

And so that’s kind of what WP Rig offers is like, okay, go to our GitHub repo, clone the GitHub repo down, and then there are directions in the repo on how to get it to scaffold all the tools that come with it, all of the Node and Composer tools. And then you’re kind of off to the races.

[00:11:46] Nathan Wrigley: So with WP Rig, I’m guessing we would describe this as a framework or something like that. The idea being that you can bring this, kind of learn how it works, become adept at it, and then it’s like your constant friend. It’s always in the background. It’s the thing that you can rely on. It’s the muscle memory which develops over time. So you can ship your own themes, which kind of depend on the framework, but also, you know, you’re familiar with it so that bit is taken care of and straightforward.

What is it that attracted you to this particular theme development framework, at the time when you were sort of scrambling around looking for a project to become involved with?

I mean, one of the things that I always found curious was the leaner, the better. You know, the less that there was in such a thing, the more I was drawn towards it, because it gave me a, the basis, the scaffolding basically from which I could start building. Now, I don’t know if that’s what drew you here. So there’s the question. What is it that you thought was superior for want of a better word about this one?

[00:12:41] Rob Ruiz: Well, you nailed it. It’s really that. Like, it is quite minimal at its core. I also really appreciated how it treated CSS, as somebody who comes from a design background. I love modern CSS. I love following CSS influencers on YouTube, and learning all the new tricks. It’s a lot to keep up with and as, now that Internet Explorer is gone, CSS is progressing at an enormous rate, which I’m very excited about. But it also forces you to keep in tune with what you can do with it and what you shouldn’t do with it. And so there are tools built into WP Rig to help you assess those things as you’re developing your CSS in there.

When I originally was brought onto it, we were using a tool called PostCSS. That would essentially allow you to use future CSS before it was adopted by all modern browsers. And during the compilation process, it would convert your future CSS to today CSS essentially. And so the idea there is that as CSS catches up, your compilation would just have to do less work, right? So when it compiles all your CSS, it would, you know, like now that nesting is a thing, right? I was using WP Rig before CSS nesting was supported by all modern browsers, but I was able still to use CSS nesting in WP Rig, which I really liked. So there’s that aspect of things

and yes, it is very light. I’ve used other theme development frameworks where they encourage you to use kind of like a templating language or framework. I didn’t really like that approach because it felt very foreign to WordPress. Nothing else in WordPress uses such a thing. That kind of turned me off a little bit because I was like, I don’t want to learn this whole other concept that like really doesn’t exist anywhere except for Laravel. I liked that about it. It kept it simple in that regard.

And then if you’re using WordPress at like a agency level, if you’re building bespoke custom sites for clients, something like WP Rig is extremely powerful because it allows you to increase your level of customisation as much as you want, and the tools are all there to help you handle that. Also, meanwhile, if you’re working on a team of developers, which is often the case if you’re working with an agency or something like that, WP Rig becomes kind of like a home base, if you will, for opinions, for coding practices, for checks and balances.

All these things, it helps put everybody on the same vehicle, I guess, if you want to think of it like that. Everybody’s using the same vehicle, so there’s not wildly different ways of doing things, which can be very, very handy when working on a team and assessing other people’s code, and perhaps taking over work for other people and so on and so forth.

[00:15:23] Nathan Wrigley: So the thing about frameworks, I guess, is that, if you are in the WordPress space and you are that page builder user, so everything is within the WP admin, you know, you download a plugin, which creates pages or a theme, I guess you could do the same thing, but you’ve got that kind of experience with WordPress. Is this something that would map to those kind of users perfectly, or is there more of a learning curve? Do you need to be leaning more into the developer side of things?

Maybe there’s a happy transition that can be made. Because, you know, when you’re on the website, you have interesting acronyms. So, you know, CSS, JS, we’re probably entirely familiar with those, but then we get into things like esbuild, Lightning CSS, ESLint, NPM, Composer and so on. And at this point I can imagine quite a few of the inexperienced users thinking, you know what, this is going to be tough for me.

So I just want you to give us an impression, reassure people. How hard is it to go from that, I’ve never done anything like this before. To up and running, becoming familiar, if not necessarily completely familiar in a heartbeat?

[00:16:25] Rob Ruiz: In my opinion, it’s not hard because you can kind of just focus on where you want to focus. And so for instance, if you’re only interested in writing CSS styles and you just want to change colors, and sizing, and fonts, and stuff like that, you could use WP Rig to make an extremely simple theme, which is what I would encourage people to do if they’re just getting up and running.

Back to your question about page builders and such, there is like this, I don’t want to call it a problem, but there is a paradigm in WordPress that I think, especially for newer WordPress developers, they need to be very aware of, which is that you kind of have two schools of thought.

You have this school of thought of like, okay, I want to just use the WordPress admin to customise every little bit, every little piece of my WordPress site. I should be able to do it in the WordPress admin. And so that’s where some of these more complex page builders kind of come in and provide a lot more control than just what Core WordPress provides you.

But with that said, it will never be ultimate control. It will never be ultimate control, because there’s always going to be some amount of constraints. You’re always going to be constrained by what configurations, what settings, what fields, what controls that page builder provides you.

And not only that, you have to keep in mind some of these rules, I like to think of them as rules, configurations, settings, whether it’s at the block level, widget level, element level, whatever word you want to use to describe a part of your page, like an object or a component, it’s a very common word. When you’re using a page builder, that’s all getting saved into the database. Anytime you enter a value, you click save or whatever. Everything is in the database, all of it, right?

And so if you need to make a global change across your whole site, let’s say you want all of the blocks on your website to all of a sudden have a border around them, or you want to change something about them, the colour, background colour, something like that. In a page builder world, you’re going to have to go into every single one of those elements, those blocks, whatever, and you’re going to have to change those values everywhere.

Where, when you’re doing things with just code, you have kind of superpowers. In my opinion, coding, if you want ultimate control over your site and you want to be able to do literally anything you can imagine, and be able to do it in a way that’s progressive and is comprehensive, without any barriers, without any limitations, code will always be the best way to exercise that control that you’re going after.

Now, obviously, newer people, too much control can lead to confusion and all this stuff. So I don’t fault people for using some of these other solutions like page builders to kind of get their feet wet and get up and going and kind of figure out how to use just WordPress itself.

But once you get to a point where you’ve been doing that for a while and you’re looking at like other websites that aren’t even WordPress that have all kinds of interesting, cool features built into them, new paradigms being presented and exposed. Let’s say you follow CSS and you’re looking at all the newest CSS features that are coming out. Many of those newest CSS features that are coming out, there’s really no ability to control those things in your WordPress site, because that stuff literally just got adopted by Chrome or whatever, just reached modern browser adoption like recently, right?

And so you have to kind of wait for the page builders, for WordPress to kind of now provide you new controls, new tools, so that you can then control those things. But when you’re doing things with code, you could just do it immediately, and you could do whatever you want.

So when you’re building your own theme from scratch or you’re trying to, even creating your own plugin from scratch, it’s never really going to be a concept that’s for like new WordPress people that are just very, very new to just developing websites in general. But it is nice to know that these tools are out there and they’re there, so that when you do get to a point where you’re ready to kind of spread your wings a little bit more, you know what tools are out there to reach for. And you can begin to play with them a little bit instead of forever feeling confined to one paradigm.

[00:20:40] Nathan Wrigley: Yeah, there is something exceedingly satisfying about understanding how, whatever the thing is works. I imagine that as a child, you were perhaps that child that took things apart and enjoyed the experience of looking at the insides and thinking, how did that work? Okay, that’s how it worked. Okay, that cogs connected to that thing, and then that spins around in that way. And, oh, and look that on the front spins around as well. Got it. I understand that now. And you reassemble it and what have you.

I think there is something exceedingly interesting about that in the WordPress space. Obviously, WordPress, CMS, incredibly powerful out of the box. You’ve got the WP admin, and perhaps that’s as far as you wish to go.

But peeling back the layers and understanding, how is a page constructed? Where does the CSS get called from? How is the HTML finally output? What are the bits and pieces that make it up? How does the theme layer do its bits and pieces? You don’t have to kind of understand it all in one hit. You can, with a framework, the likes of which we’re talking about, WP Rig, there is this capacity to just take little nibbles and have a slow, but realising appreciation. Oh, okay, that’s how it works.

But not only that’s how it works, okay, now that I know how that works, I now am in control of it. Whereas in a way, previously, I just was sort of a passive observer. Perhaps there was a setting area in my page builder or what have you. And if it was there, I could make use of it, and if it wasn’t, I couldn’t.

But also I think it drives you into that journey of understanding the open standards, the open web, the things that make up the technology which is free, available to everybody. What WordPress builds upon.

And I’m talking specifically about HTML, CSS and JavaScript, just those three things. The foundational pieces of the web. And it allows you to get involved in that, and be interested in that and understand where the web is heading. And especially like you said, with modern CSS’, it is coming really fast and it is fast replacing, in many respects, I think a lot of JavaScript really is going to be obsolete, for the front end side of things, in the fairly short term.

So it allows you to sort of nibble away at that and become more experienced. And if you haven’t had that journey but you’ve got a curiosity, this is possibly a great place to start. There is no question there, but I’m just sort of offering that up to see if that jibes with what you think.

[00:22:52] Rob Ruiz: I couldn’t agree more. And not only that, I think an important thing to think about WordPress as we move forward into the future and more competitors to WordPress emerge, I think it has never been more important to make sure that we have tools out there that are designed to facilitate people in their journey to getting into development. Because let’s be real, WordPress is open source, and we have to remember that WordPress is at the mercy of its contributors.

And so if the number of people contributing to WordPress starts to decline, so too will the progress of WordPress itself, unless other big companies with other developers that they’re actually paying are willing to foot the bill to like pay people to contribute to WordPress.

I don’t know that that’s the bright future that WordPress had originally like looked towards, right? I think what’s made WordPress so powerful and so successful over the years are the tinkerers, are the people that are willing to get in there and start to like learn things and figure things out. And then those people will slowly become contributors. And the more contributors we have to WordPress, the more WordPress itself will flourish. And then if that starts to go in the opposite direction, so too will WordPress.

And now these other services, and other solutions that are out there, are going to like eclipse WordPress and then people are kind of forced into a situation where it’s like, oh, well now you have to constantly go out and pay for and buy things, and now you’re at the mercy of these product authors, if you will, as opposed to being a part of a community of people that are all kind of collectively working together to make this one platform better all the time.

[00:24:37] Nathan Wrigley: Yeah, the open web and all of the web standards that are behind that, it is such an interesting time for that. Rewind the clock, I don’t know, 10 years or something, and there was this whole bond fight thing where browser vendors were just distributing things which were either in opposition, certainly in competition to features. And so you could never really figure out what the heck you were doing, and each browser would behave differently.

That is so far in the rear view mirror now. In the majority of cases, new things like new CSS, the new CSS spec is broadly speaking, adopted by everybody out of the box. I mean, there might be a few tiny edge cases where, I don’t know, let’s say Mozilla is just not implementing something because they just haven’t quite got round to it yet.

But there’s no, Mozilla’s not doing that. It’s just a case of, we didn’t get around to it. And understanding that and being interested in that and thinking to yourself, well, goodness me, if I change my CMS of choice, at the end of the day, I still need to be able to output HTML and CSS. And so having that tinkerer mentality, which you are providing within the WordPress space is so interesting and so credible. So thank you for that.

Right, I’m going to pivot a little bit. So again, this is leaning in more to the inexperienced user. Forgive me if you are an experienced user listening to this, you probably know what you are doing. So maybe, you know, you don’t need all the 101 stuff.

What do you need to get WP Rig up and running? Because I think a lot of the audience listening to this will simply be, I have a server somewhere. You know, I don’t really know where it is, but I pay some company and I click a button in some control panel and WordPress magically happens. And then I install a theme and plugins, and that’s basically it.

So what do we need to get WP Rig up and running? What are the core parts, the processes that we would need to go through?

[00:26:24] Rob Ruiz: Yeah, well the important thing to keep in mind here is that it’s all on your own computer that you’re doing all of the work, as opposed to the WP admin approach where, when you’re interacting with WordPress, you are actually interacting with a remote server. The databases on the remote server, the files are on the remote server, all that stuff.

When you’re developing a theme or plugin from scratch, more often than not, I would say 99% of the time you’re doing it on your own computer. And so you do have to have, if you want these tools that facilitate this development process, you have to install them on your computer so that they’re available when you go to use them.

So there are some pre-reqs to using WP Rig. You do have to install Node. Node.js is a very common JavaScript runtime that runs on your computer and allows your computer to process JavaScript as if it’s a browser kind of, but it’s not, it’s just doing it on a server, which essentially any computer can be a server at any time.

And so you have to have Node installed. You have to have Composer installed. Composer is just a package manager for PHP, and it’s used beyond just WordPress. It’s used in Laravel. It’s used in any, even just raw, vanilla PHP development. Composer is very popular. So we do leverage some Composer packages to do some PHP level work in the theme.

And you need a local development environment, of course. So there’s the wp-env package out there. If you’re into the Docker way of doing local development. I’m a big fan of Local WP. I think that’s a great solution. WordPress Studio is another very good one. There’s lots to choose from out there.

So just choosing a local development environment and getting to know one of those is really handy because now you’re not dealing with a WordPress instance that’s on a remote server, you’re dealing with a WordPress instance that’s running on your computer. And this is where all of that magic is going to happen. All the automatic conversion of your CSS, all automatic conversion of TypeScript to ES5 JavaScript. All of the automatic things that WP Rig handles for you, all of that is happening on your computer.

And then there’s a process, a bundle process that happens. Once you’re done working on your theme, you can bundle the theme and then, this is where things get a little weird. So like when you first get working with WP Rig, you can think of the WP Rig theme, the starter theme as kind of like a source theme. But when you bundle, WP Rig actually generates a whole new theme for you that has the name of your theme baked into it. And not just like how it shows up in the WordPress admin, it goes through and it replaces all references to WP Rig in the code everywhere, across the entire code base of the theme. It changes the words WP Rig to whatever the name of your theme is.

So if you build a theme with WP Rig and you decide to sell it or deploy it or ship it or whatever to anybody, user, wherever, anywhere. Anybody that’s looking through that source code, for whatever reason, they would have no way of knowing that it was built with WP Rig because it’s just going to look like your theme.

[00:29:31] Nathan Wrigley: There’s something extremely satisfying about seeing your theme. The first time you see your theme. Stick it on a website somewhere and, oh, look, there’s the thing that I built. Whereas, you know, for many people, it’s been an entire experience of going to the repo, going to commercial theme houses and what have you, and downloading something and tweaking it and what have you.

And you really can start really, really, really small. You know, a few lines is really all that you need to get going and build up from there. Obviously it will start plain, but the more complexity you add.

But given that it’s all happening on your local computer, it’s not like you need to rush. This could be something which is years in the making. You know, you start today and maybe two years from now you are entirely happy and you’ve got something that you think is worthy of the world looking at. Well, that’s the point at which you can start to distribute it. As you’ve just described, because it’s all free, completely open source, when you ship that theme, export it, everything is run in such a way that nobody would ever know, which is just lovely.

Okay, so given all of this fresh, interesting stuff about WordPress themes, we’re in an interesting space in the WordPress theme marketplace, let’s call it that.

Several years ago, full site editing came along and now we’ve got this sort of different way of doing themes. Previously we had to open up an IDE and fiddle with template files and things like that. And now we’ve moved more into a page builder, let’s go with that. You know, there’s this Gutenberg block based editing of themes, where you can do more or less everything in a UI.

How does this fit into that piece, and what do you make of this new paradigm, this new way of doing themes? Are there benefits to it that you see, or drawbacks? Are you still doing it? Do you see a bright future for WP Rig? I’m guessing the answer’s yes, otherwise you wouldn’t be on this podcast.

[00:31:16] Rob Ruiz: That’s right. Yeah. Well, I will say that as somebody who had recently decided to adopt WP Rig, when the whole concept of FSE was first announced or introduced, I did have some strong opinions because I was like, oh my gosh, this is going to make my life very difficult if this becomes the way of doing things. And so I kind of foresaw a lot of where things have gone over the past few years.

So at the beginning I was a little hesitant because it kind of threw a wrench in this new thing that I was excited to adopt and start advancing. Over time I have come to appreciate it quite a bit. And in my opinion, it’s just allowed me as the maintainer of WP Rig, a lot of opportunity to really get in there and learn a lot, and get my hands dirty, and allow WP Rig to become something that was more my own, as opposed to something that I just adopted from some other people that had done a bunch of work, right?

Had that not happened, I probably would’ve just been like encouraged to just kind of sit back and be like, ah, yeah, you know what, this is my thing and it works and whatever. But this presented a lot of challenges and those challenges present a lot of opportunity if you look at it the right way. Not just opportunity to make something my own, not just opportunity to build things, but also opportunity, most importantly, I think, to learn things. And so that’s really been the gift of where all of this has gone for me personally.

Do I think that full site editing makes it so that you don’t have to make your own theme as much? Yes, I do think that is a thing because you have a lot more control of the way your website looks from within the WordPress admin area and creating templates and block patterns and all that stuff from within WordPress. It is different than how we used to do it, let’s put it that way.

However, as somebody who has decided to just like adopt it, I will say that if you can keep the paradigms and concepts all categorised and separated in your brain, then it’s actually quite powerful and can be extremely handy, especially with how fast the WordPress admin experience has gotten over the past few versions. It is very snappy now, almost to the point where it’s satisfying to use. Crazy to say. But it’s just so snappy. And we’ve got lots of little micro animations coming in there now where you can, you know, just the way everything happens is like, to me, it makes it a little bit more fun.

What does that mean for WP Rig? Well, that means there’s multiple paradigms that WP Rig has to support. So because WP Rig was originally created in the classic paradigm, when you first start using WP Rig, it does assume that you’re creating a classic style theme. But that doesn’t mean you’re forced to build a classic style theme. Because one of WP Rig’s strongest features is that there are whole bunch of custom command line commands that you can type in and run that will automatically convert WP Rig into these other paradigms.

So if you want to build a block-based theme or a universal theme, which is kind of halfway between classic and block-based, you could just run a command in your terminal and it will just automatically change a bunch of files in WP Rig to convert it to this other paradigm. And now you have full site editing as part of your theme.

And many people may not be aware of this, but the whole concept of full site editing is controlled by the theme. Whether or not you even have full site editing on WordPress is dependent on the theme. It’s not well, Gutenberg can be removed via a plugin, but in order to enable these functionalities, like if you want to be able to do full site editing, it is the theme that dictates that, not a plugin.

So it is important for WP Rig to facilitate that part of things. And so that is something that I’ve had to build out among many other things. Now WP Rig has a full block authoring experience built into it.

Now, this is where things get very, very opinionated among developers. But a lot of people argue that blocks are a, that’s plugin territory, right? Now, I don’t know about you, I’m not really much for territories. I like to pretend that borders don’t exist sometimes. And so there are situations where building theme level blocks do make sense. Keep in mind that if you decide to bake custom blocks into your theme, you have immediately disqualified yourself from contributing this theme to the wordpress.org theme repository. So keep that in mind. That’s a big cautionary, little tidbit.

But if this theme is just for you, or a client, or for usage outside of the WordPress repository, WordPress does have the ability to enable block authoring within WP Rig. And then now you can start to author blocks within your theme.

Where I like to think of this as like navigation, right? When I’m looking for themes, if I’m like shopping for themes, one of the first things I look at is, what is the navigation for this theme? What is that experience like? Because there’s lots of different kind of like styles of navigation.

If you need to create a custom navigation, maybe there’s a situation where the navigation block in Core WordPress doesn’t suit your needs for whatever reason. Maybe the design of what you’re trying to build somehow goes beyond what that block provides to you in terms of functionality. You could create your own custom navigation block, and in my opinion, that makes a lot of sense to be part of the theme as opposed to a plugin, right?

So there’s opinions there. Again, this is the nice thing about open source. There’s freedom there. But yeah, WP Rig has not just the ability to facilitate full site editing, but also the ability to facilitate block authoring at the theme level. So, yeah, one could look at this and be like, oh, this makes theme development kind of pointless because you could just do everything within the full site editor. I’m somebody that likes to kind of flip things on its head a little bit sometimes and say, actually, you know what that really means is that this gives the theme more control than perhaps you would’ve thought previously. And if you exercise said control, and if somebody provides an easy way to allow you to exercise that control, now we have a whole new paradigm. And in my opinion, that’s extremely interesting.

[00:37:39] Nathan Wrigley: Yeah, I think the thing that I’m taking away, well, there’s a few things from what you just said. The first one, fully hybrid. You know, it could be classic, it could be block based, or it could be somewhere in the middle, like this hybrid sort of approach, which doesn’t really get talked about all that much anymore, actually, which is curious. It was a big thing for a while, and now people seem to be on one side or the other. So there’s that.

But also the bit that I’m taking away from all of this is how much you are encouraging people to use this as an education piece. How to learn and scaffold your learning around something like the WP Rig project. It enables you to sort of peel back the layers. Start from a base of kind of nothing and build that up, slowly one piece at a time.

And your navigation is a really great example. You might have, I don’t know, maybe a client comes along who have proclivities around, it’s got to be 100%, we’ve got to give everything over on the accessibility side, we’ve really got to do that perfectly. Well, this maybe is a great place to start. You know, you start with a blank template for that, and you build your navigation. So you will end up exploring all sorts of documentation over on the W3C website. Probably not necessarily so much on the WordPress side of things. Figure out how to do that really well, import your knowledge that you’ve gained from that into the navigation aspect of WP Rig, ship that, you’re off to the races.

Now, with that in mind, if you go to the WP Rig website, there’s a lot of educational content there. So there’s the inevitable kind of getting started, which is what we talked about earlier, all of the packages and the package managers and what have you that you need to get up and running. So it explains how that is all to be done. Relatively straightforward to follow that through, I would’ve thought.

But then entirely separate to that is two different sections. You’ve got this like learn section where you’ve got documentation, video tutorials and things like that. But then you’ve also got like the docs area where you go into explain, oh I don’t know, how you might use JavaScript or CSS or some sort of compiled CSS or PHP and so on and so forth.

So again, no question there really, but it does feel, from my point of view, looking at this project that education is kind of the big piece. That’s the thing that you are most interested in. I don’t know if I’ve misrepresented this project, but that’s what it feels like.

[00:39:58] Rob Ruiz: A hundred percent. And I think that’s inevitable when it comes to getting into this tinkerer mindset. There must be a way to learn how to tinker properly. It is also nice to add guardrails to said, because let’s be honest, there’s like a million different ways to do everything, but there’s very, very few correct ways to do everything.

And so that’s another nice feature of WP Rig is that it has these sort of guardrails in place that allow you to check and make sure that you’re doing things properly. And if there’s anything that you’re doing improperly, you can obviously ignore those if you want to for whatever reason, or you can like dive into the weeds and say, okay, why is this improper?

So for instance, WordPress, Automattic created a package. It’s essentially an extension for a tool called PHPCS, which stands for PHP Coding Standards. This tool is used by PHP widely beyond just WordPress. But then WordPress adopted it a while back and decided to use it and create their own extension for it called the WordPress Coding Standard. It’s WPCS.

And so they’ve iterated on it over the years and WPCS is baked into WordPress, or into WP Rig rather. So if you want to make sure that your theme is following all of the WordPress coding standards for whatever reason, maybe it’s because you’re going to create a theme that you want to contribute to the wordpress.org theme repository, then that tool is baked into WP Rig for you, so that you can make sure that your theme meets all of the requirements for a properly developed theme before you even try to go and like submit it for a review or whatever.

Because that’s one of the most frustrating things ever is somebody who wants to contribute. If you try to contribute and then you get pushed back on, that’s like not a great experience. And so what I try to do with WP Rig is bake in this layer that is kind of like a, test it yourself type situation. Where you can kind of like have the system sort of, kind of review the code for you, and then that way you can make sure you’ve done your due diligence before you even try to submit it for review. To prevent that unfortunate situation where your theme might get rejected for one reason or another, and now you got to go back and rework it and then back and forth, back and forth, back and forth.

Having a tool like WP Rig that just tells you early on before you even try to submit it, hey, you should change this, you should change that. I think that’s extremely valuable for people. And again, I really want WP Rig to be something that encourages people to get more into contributing back into Core as opposed to. I mean, it can also be looked at as something like, okay, well you want to go develop your own thing and it’s for profit or whatever. It does very much facilitate that way of doing things too. But let’s be honest, anything that meets WordPress’s coding standards is probably going to make your theme, even if you’re putting it up for sale, it’s going to make it better.

[00:42:53] Nathan Wrigley: Yeah, I love that you’ve built all of that in. That’s really interesting. So it does a lot of the heavy lifting, trying to make sure that you are adhering to the standards, which one would hope would be in a shippable, distributable product.

Speaking of community, do you have a community which coalesce around this project? Is it basically just you? Or is there like a little team? And if not necessarily a team, is there a little community which gathers and sort of helps you put this project together? And a corollary to that question really is, do you anticipate in the future that you will like some contributors to help you maintain this as well?

[00:43:27] Rob Ruiz: Yeah, for sure. So when I first started, when I first adopted this as my own, there was more of a team in place because Morten is a very well-known individual. And so he had a lot of followers and so a lot of those followers had followed WP Rig. As time has progressed, a lot of those people have kind of unfortunately gone their own way. For whatever reason, a lot of the people that were following him weren’t really like, they might have been into learning how to develop themes. They certainly were into WordPress. But working on a project like this is more than just knowing how to develop themes. You also have to know how the underlying tools work too.

So that’s been my biggest challenge is learning, what is Lightning CSS? How do you use it? What is esbuild? How does that work? When I first took it over, it was ran on Gulp. What is Gulp? And what is that, and how do I modify it? And like that’s kind of far beyond WordPress, and so I think people became aware of that over time. And so while I rose up to the challenge, other people were just kind of moved on to other things.

So it is largely me. We do have a handful of contributors that kind of, when they have time, you know, they’ll feel ambitious again and jump in and do some more contributions and they’ll fall back and do their own thing for a while. And so there’s a lot of that. It’s not a very active community, certainly not as active as it was when I first adopted it. However, we do have a Discord now. You can find a link to the Discord on the website. If you go to the Learn V3 link in the header, there’s links to our YouTube channel and the Discord server.

So we are looking, I do want more of a community around WP Rig. And so I do encourage people to come on. Obviously we’ve been on GitHub this entire time, so if anybody wants to raise issues or submit a PR, there are guides on there. There’s a contributing.md file in there for anybody that wants to contribute, or wants to raise an issue. If you have ideas for how WP Rig could be better, that’s always been there. It’s just that, for one reason or another, it’s just not popular, which is a big reason why I’m on your show today actually is just to raise awareness about WP Rig now that I have had the opportunity to overhaul it dramatically over the past couple years.

In my opinion, it was a little bit, it started to feel a little bit slow compared to most modern tools. If anybody’s familiar with like Vite, or just modern frontend development frameworks. In general, they use more modern tools that build things faster and better, and they’re leaner. And so WP Rig was falling behind a little bit in that regard. And so I did have to like overhaul the project a lot. That’s why we came out with the version three because it is a pretty substantial overhaul.

And so now that we have version three and it is much better and there are all kinds of new features built into it as a result of it being faster, it’s now more capable. I want to raise awareness. A, I’ve already done the work, so it would be a shame for all that work to go unnoticed and unappreciated. But also, for anybody who was familiar with WP Rig from previous years, back in the version one, version two days, I think it’s important to make people aware that version three is substantially more capable than what it was prior.

[00:46:38] Nathan Wrigley: That’s wonderful. I’m just going to round off the episode by mentioning the URL once more so that after that clarion call, if people have been inspired and they have listened to this and think, I’d like to explore that. You know, for the multitude of reasons that we’ve covered in this topic. The URL, it’s really easy. It’s WP Rig, wprig.io. Go there, there’s a whole bunch of ways to get involved. So there’s the Learn documentation, there’s the contribute tab and so on and so forth. You can peruse at your leisure.

Rob, just before we end, is there a way that people could communicate with you more directly if they wanted to off the back of this? Is there a, like a, I don’t know, a social network or something that you frequent? Or a contact form that you’d like people to be mindful of?

[00:47:22] Rob Ruiz: Yeah, sure. I mean, I am very responsive to people on LinkedIn, so if you want to find me on LinkedIn, I am on there, Rob Ruiz, just look me up. If it looks like it’s a Rob Ruiz that does WordPress stuff, it’s probably me. And then of course, I’m on the Discord server. So if you want to communicate directly with me, joining the Discord and then messaging me directly is a nice way to do that. I’d love to help people, hold their hand if needed, get up and running with WP Rig. If you have any questions about specifics, I’m happy to address them, or you just need a little guidance, I’d be happy to help there as well.

[00:47:54] Nathan Wrigley: Well, thank you so much for chatting to me today, Rob. It’s been really interesting. So once more, just before we end to find out more. Rob Ruiz, thank you very much for chatting to me today.

[00:48:04] Rob Ruiz: Thank you so much for your time, Nathan. I really appreciate it.