The Changelog: Software Development, Open Source - Modern WordPress using Bedrock and Sage (Interview)

Episode Date: May 22, 2015

Ben Word and Scott Walkinshaw joined the show to talk about a more modern WordPress stack, Bedrock and Sage, dependency management, WordPress deployment, smarter development setup with tools like Ansible and Vagrant, and more. If you're someone who wants to use WordPress in more modern ways, this show is for you.

Welcome back, everyone. This is The Change Log, and I'm your host, Adams Dukowiak. This is episode 156, and on today's show, we're joined by Ben Word and Scott Walkinshaw to talk about WordPress, and more specifically, Ben and Scott are from Roots. That's the organization that created Bedrock and Sage. Bedrock is a modern WordPress stack and Sage is an awesome WordPress starter theme. Great conversation today with these two guys talking about WordPress and all sorts of stuff. So stay tuned.

Got three awesome sponsors, CodeShip, TopTile, and CodeSchool. We'll tell you a bit more about TopTile and CodeSchool, but our first sponsor, CodeShip, TopTile, and CodeSchool. We'll tell you a bit more about TopTile and CodeSchool, but our first sponsor, CodeShip, is a hosted continuous delivery service focusing on speed, security, and customizability. You can set up continuous integration for your app in a matter of seconds and automatically deploy when your tests have passed. CodeShip supports your GitHub and your Bitbucket projects. And you can get started today with CodeShip's free plan. Should you decide to go with a premium plan, you can save 20% off any plan you choose for three months by using this code, the changelog podcast. Again,

that code is the changelog podcast. Head to codeship.com slash the changelog to get started. And now onto the show. All right, everybody, we're back. This is Adam. I'm joined by Ben Word and Scott Watkinson. I think I poisoned you. You did this, Scott. You did that.

Walk in Shaw. I'm going to leave that. We're going to we're going to leave that one in there because in the pre-call, we were talking about Scott's last name and my last name because they're both above nine letters. And Scott was saying how he gets called Wilkinson all the time or Walkinson or something like that. And I said there's no end at the end, and he poisoned me. So he got Walkinson instead of Walkinshaw. So sorry about that, Scott. No problem.

So you guys run this project called Roots. And around WordPress, a lot of fun stuff. A lot of people people are sort of haters i guess to a degree on wordpress and uh mostly it comes with like a database and everybody loves jekyll and no database and flat files and stuff um but you know the change log we use wordpress to to run the change log it's got it's got multi-author, all that fun stuff. So we love WordPress to a degree. And we might get into some of that in the show. And I'm sure you can probably both say the same thing, that you love WordPress to a degree as well.

Would you agree with that? Yeah, for sure. So let's get some introductions out of the way. Ben, let's start with you. Who are you to Roots and all that good stuff? I am the creator and lead developer of Roots. I started working with WordPress back in 2004. I've been making themes for about the same time.

Roots started because I worked at basically a website factory where I was pumping out a bunch of sites every day. And I just wanted to stop repeating myself. So Roots was born and then the other projects came along further down the line. What about you, Scott? Sure. My involvement in Roots started when soon after Ben started it. He often needed some more complex PHP help since he's more of a front end guy. So us knowing each other before that, he would always ask me for PHP help.

So I've been involved pretty much from the start. But I mean, started off in a more kind of unofficial, just helping behind the scenes. As Roots started to get more popular, I got more involved. That was with the Roots theme itself over the years. And then recently that's resulted in kind of projects that I've started, such as Bedrock and its kind of sister project, Bedrock Ansible. When you go to roots.io right now, the main headline you see is Roots helps you build better WordPress sites faster. It started out with Roots was originally a startup theme, right, Ben?

Right. And then this project has morphed as Scott came on and others will mention. That's come on Austin, Nick, and Chris. Now it's Sage. Now it's Bedrock. Maybe let's start back at the beginning. I think even in the pre-call, you mentioned that you and Scott got introduced together through your passion for Call of Duty. Is that correct? Yeah, we used to run Call of Duty gaming tournaments

for the PC version. It was called Survival of the Fittest. And I actually met Scott. He packeted me offline. That was my first interaction with Scott Walkinshaw was him taking me offline. So there's that. That's how I met Scott.

What does that mean mean taking you offline uh you know ddosing scott ddos me yeah that's not nice guy yeah we were young was back in uh 2003 i think okay so this is okay this is a while ago okay yeah so you guys have been you guys been doing some stuff together for a while. Yeah. All right. Well, let's go back to the beginning then, I guess, to a degree. More so with Roots than, I guess, like maybe what was some of your early relationships? Was it around WordPress? Have you been using WordPress since?

I guess it was born in around 2004, 2005, wasn't it? Roots? Well, Roots wasn't really born until 2009. Well, not Roots, but WordPress. WordPress was... How old is WordPress? You know, WordPress is pretty old. I want to say that WordPress is older than 2004 for sure.

I think I first started using it around 2003, late. 2004 was when I first started using it. And I think it was between that and gray matter. Way, way, way back when. I mean, this is forever ago yeah i think that's like when they finally started implementing more cms type features and it was moving away from just wordpress is used for blogging pages was a hack basically right yeah all that yeah oh man what what back in the day okay so i guess where did roots come from? You said that you were working at a consultancy.

Is that right? I was working for an agency in Colorado. And, man, they just pump out sites like it's nothing. It's basically a website factory. So I would get templates throughout the day that I had to turn into WordPress themes, basically. And I was working, I want to say HTML5 boilerplate wasn't yet the official name of the project. It was called front end pro template. So I took that from Paul Irish and I just threw blueprint CSS on top of it. And then from there, it just kind of evolved into

more things. Like I added more things on it, more specific to my use case for having to pump out like client sites three times a day. So Roots also kind of had this reputation early on for being bloated and too opinionated. And that's not really the case anymore. Like if you look at Sage nowadays, it's very lean. It's very very minimal it uses dependency managers and the actual amount of code in the theme i think it's like 600 lines when you compare that to some of the other starter themes out there like it's very clear that sage is not a real bloated tool so roots was the was the starter point which then became sage right so have you had some issues with the naming by any chance yeah so the naming got a little weird once we introduced bedrock because

it's like all right we've got the roots theme and then we've got bedrock like this is getting confusing people started referring to the project as like roots.io once we got that domain name so i mean it just made sense to stop calling the theme roots and call it its own project name that is going to avoid confusion in the future like brute should just be known as the organization gotcha yeah that started when we actually got the roots organization username on github and at that point it was you know root slash roots for the theme. And I mean, it was over a period of months, we went back and forth on kind of how to solve the branding issue. And we didn't really want to rename the theme because it's difficult when there's documentation all across the Internet. There's blogs about it.

There's Stack Overflow questions. And we knew it was going to be hard. But at the end of the day, I mean, it was the right decision to make. So how long ago was that? Because I remember when I first got introduced to it, it was about a year and a half ago, I want to say. And I thought, okay, it's Roots and then Bedrock. And that was clear to me.

And then during the last year and a half as it progressed, as I'd gone back to it again to reference it back to our team, because I worked at a nonprofit called Pure Charity. And one part of our, I guess, a little sneak peek into their business model is to leverage open source in a way that can help them build nonprofit sites really easy because they're using WordPress, you know, open source plugins, open source themes, as you all know, which has been the way to go. And so we were starting to use WordPress more and more and tie back into our Rails API to pull sort of data out of this sort of larger site.

But long story short, as I went back to it, I was like, what is this Sage thing? And so as somebody who came to it post the rename, I was maybe twice as confused. I was like, so it changed. I guess it was easy to replace in my mind that it had changed. But for a bit there, I was like, what's up with that? Yeah, so we renamed the theme from Roots to Sage with version 8, which came out at the end of February this year. So it's a pretty recent change.

Right, okay. And yeah, we had discussed it internally before that, and we had come up with the name Sage before version 8 and made it public I want to say a few weeks beforehand just to give people a heads up but yeah I mean it's still a little bit confusing just because people associate roots with just the starter theme. While we're in the clarification moment here could one of you break down Sage and one of you break down Bedrock for the listeners? Okay so Sage is a WordPress starter theme, as in you're going to start a new project

and you want to start from scratch with your front-end templates and your CSS and your JS and all that. You use Sage to build your theme. It uses a theme wrapper, which is a non-conventional WordPress thing. It's a don't-repeat-yourself method that a lot of people outside of the WordPress world are familiar with. It also uses Gulp for the build process. We use Bower to bring in front-end packages, and Bootstrap is the default CSS framework that's included. But you shouldn't limit yourself to not using Sage. If

you don't use Bootstrap, it takes literally three seconds to remove or replace with something else. All right. And maybe Scott, you want to take Bedrock? Yeah, for sure. So I wish I had a better history, kind of how it started. It spun off from when we were recreating Roots.io. I come from the Rails world. And although it's not the best framework out there, I'm not arguing that. One of the things that I was going for is its whole convention over configuration. And my experience with Rails is, you know, it has a very well-defined folder structure. It makes sense. It's logical. And you know where things are. That's basically the complete opposite of WordPress by default.

If you look in a typical WordPress project, like if you download WordPress itself from their official website, you'll get a bunch of files mixed in the root, which is the WordPress core. And then there's an actual folder called, you know, WP-content that contains plugins, themes and so on. So the whole theory behind Bedrock was give WordPress better structure and organization. So we refer to it as kind of a WordPress stack, which isn't the best term, but it was borrowed from one of the WordPress core team members, Mark Jaquith, and I hope I'm saying his name correctly. He had two projects, one called WordPress Skeleton and one called WordPress Stack. WordPress Skeleton was just a model of how the WordPress core fits in its own subdirectory. So instead of mixing that in the root folder, it has its own subdirectory called WordPress or WordPress core, whatever you want to call it.

And he managed that as a Git submodule. Git submodules aren't ideal, so we switched to using composer it's the official php dependency package manager so that's the two main things about bedrock is it gives you a better folder structure and it uses composer for dependencies and those dependencies include the wordpress core itself and any plugins that you're going to add the folder structure structure, I think, maybe let's pause there on that mention because we're talking about Bedrock. I guess who says, I know you say it here, but who else complains about the folder structure of WordPress?

Because when I use WordPress, I almost don't really care about, I guess to a degree, what WordPress itself is doing. I just sort of care about my theme. Is that the consensus with most of the people you're working with when it comes to Bedrock and the problems you're trying to solve? Yeah, well, the other thing I should have introduced with Bedrock is I kind of created it with teams in mind. You know, if you just have your own personal blog or you're spinning off quick sites like Ben mentioned, if you're kind of working at one of those agencies that does quick things and passes them off to a client, it's not necessarily the best project to use. But if you have a longer running, more serious project where you might

have multiple team members and you know it's going to be kind of like a CMS for your website for, you know, years to come, it's more important that you get into proper dependency management. And if you keep WordPress's default folder structure, it's really difficult to do that. And I mean, you ask, like, is this a known problem? Do people complain? And they definitely do.

I mean, on the main WordPress documentation, there's a whole article about giving WordPress its own subdirectory. And this has been around for years and years. It's not common, or sorry, it's not new. And there's projects that existed like wp skeleton i guess i'm just not privy to those i so maybe um i don't want to i think let's start with bedrock then so i got some questions initially out of there i mean i

think sure i'm interested in the sage but i think it's solving some pretty well-known problems that i think we'll dig into but when it comes to this folder structure, can you break down, can you like, I know it's difficult without like a whiteboard in front of us, but could you break down what that folder structure might be like? You know, can you describe it? Yeah, I think I can. So the very first thing that Bedrock does is there, there's a configuration, there's a folder called config that contains the actual WordPress config files. And then there's a top-level folder called web. And so when you're setting up Apache or Nginx and you have to create your virtual site and you have to set your document root to a folder, usually you set it to just your WordPress root folder. In this case, we set it to the web folder so that you can securely keep configuration files a level above it

so they can't be accessed publicly. And you don't need to go through and kind of blacklist individual files. You'll often see people say, oh, I want to deny access to a.git folder. So one of the advantages with a top-level web folder is that's already taken care of automatically. So there's a config folder and a top-level web folder. And then there's also a vendor folder. And that's where your Composer dependencies are.

So what kind of things go in there? What are some of the things you see Composer installing for people that are dependencies? Sure. Well, that's where it gets a little confusing. There's a couple kinds of dependencies on a WordPress project. There's the WordPress core itself. So that you have to kind of have a special rule that say, hey, install this. It needs to be at the same level. It's in your web folder, right? Yeah, it's got to be one level. They hard code it. They say it has to either be at the same level as your wp-config file, which everyone's used to modifying, or it has to be one level up. So we take advantage of the one level up rule. So in Bedrock, you have a folder called wp.

That's what we call it. The nice thing is, is that you can delete that entire folder whenever you want and just rerun composer install and it will regenerate it. You can bump a version number. So WordPress 4.2.2 just comes out. All you have to do is do composer update and the version number, and it will re-download that. Is the WP folder at the same level as the web folder, or is it a child to the web folder? The WP folder is inside the web folder. Okay, gotcha.

And then, yeah, sorry, just what Ben said. And so I'll get back to this. There's a couple kinds of dependencies. There's the core itself. There's WordPress plugins. And as you know, WordPress plugins have to go in your WP content folder. There's a plugins folder. There's also your must-use plugins.

So there's also some special cases where if those package types are set to WordPress plugin, we tell it install in this folder. Now, the nice thing about Composer is if, let's say you have a theme and you want to take advantage of trying to think of a really popular PHP package off the top of my head, some other templating language, like I don't know if you've heard of Mustache. It's a popular templating language. So frequently, or in the past, if a WordPress theme wanted to use Mustache, you would have to, what we call vendor that whole library inside your theme. So you'd have to download

the whole Mustache library, embed it in your theme, and commit it to the source repository. And whenever you want to update that, you need to pull in all their files and update it. This way you can say, hey, I've got a dependency on Mustache, and Composer will handle all of the downloading and will stick it in the spender folder.

And that every team member who kind of downloads it will have the exact same version. You can recreate stuff from scratch and you don't have to kind of pollute your own, say, Git repository with all these third-party code. Okay, I'm feeling it now. Now I'm getting the better folder structure that you're saying there because this is starting Okay, I'm feeling it now. Now I'm getting the better folder structure that you're saying there

because this is starting to make a lot more sense now. Yeah, it's a little hard to describe just over audio. But obviously people are encouraged to go and check it out right in our GitHub repo and you will be able to see exactly what we're talking about. And the repo you're talking about is like a Bedrock Capistrano? No, it's just github.com slash root slash Bedrock. Okay. Okay, gotcha.

I'm following along. So you got config, you got scripts in there, you got vendor, you got web. Yeah, and if you look in web, you'll start to see the kind of more normal WordPress folder structure that you're used to. Although one little thing that I should mention is typically you have that WP-content folder. We've renamed that to just app. And that might sound like, you know, why are we doing that? It's just confusing. It's for two reasons. One, we kind of want to get across that it contains your application code. And we're trying to take WordPress on a kind of higher level as a CMS versus just, you know, the blog. Yeah. And it more mirrors a lot of the other frameworks that exist,

things like Rails and I believe even Symfony in the PHP world. It more mirrors the expectations of existing frameworks that people are used to. Yeah. So that's why we do that. Yeah, looking at this, I'm seeing the index file, in this case, WP config, because that's probably a naming convention that just you have to adopt from where you can't just change it to config because that's probably a naming convention that just you have to adopt from where you can't just change it to config because that's not what they want and then you're seeing the app

folder which inside the app folder you've got things like your plugins your themes your uploads which is actually your site your real the real thing pretty much yeah the app folder is the wp content folder right yep what about uploads then i'm seeing uploads in here and i'm wondering that seems more like maybe it doesn't fit i guess to a degree it does i guess it is i mean yeah that's the standard uploads folder that would exist under wp content i mean we just added in there because wordpress expects it exists although i think it will just be created uh if not so earlier before we got started on the call i asked you guys what would be something I can ask you. And maybe this is a good time to bring it out because it seems like you've done so much restructuring of like vanilla WordPress.

I guess one question is how well does WordPress support setting a variable for like here's where you find this, here's where you find that. Because moving these things around, you've got to do that somehow. So I'm thinking like when you do automatic installs, you know, you don't want to lose that great feature from WordPress. So when you do installations, WordPress has got to know where to put things. How difficult is that to overcome? So I'll address a few of those points. The creation of Bedrock involved a lot of trial and error, like figuring out what WordPress supports, how to work around things. So it definitely took a little while to learn and figure out what it allowed, what it didn't allow. coded like I mentioned, they expect the config file and the WordPress core folder to be at

relative levels. And you can't break that. But now that it is set up, it works just like a normal WordPress site. I mean, WordPress has constants that let you define where certain folders live, what certain URLs are going to be. And because we've set those up, we've done kind of the hard work for people. It works perfectly fine with WordPress itself. The kind of good or bad thing you could say about Bedrock is occasionally we'll get people who come over and create an issue and they say, hey, Bedrock doesn't work with this plugin or this theme. And right away we know that's because that theme or plugin is doing something they shouldn't be doing. And that's because they're referencing a hard-coded path or URL when they should be using either of those constant functions that WordPress provides to get the correct path or location to those things.

Yeah, it's real obvious to tell when plugins are doing things, I guess, the wrong way. For instance, they'll try and load a core file and expect a specific path for someone's WordPress installation, not even accounting for the fact that WordPress could be installed in the subdirectory no matter what. So it's not even necessarily like an issue with Bedrock. It's just an issue with the way that someone was writing that plug-in or theme. Yeah. How difficult has it been to get some of those uh plugins updated not so much you guys doing it but you know identifying that that's the issue and then you know the fact that wordpress plugins aren't hosted on github so they're not quite the github flow that everybody's used to

um how difficult is it to like sort of reach out to those authors and maintainers and get those updates in place you know we don't actually really reach out to those plugin authors normally. It'll usually be a situation where someone posts on our discourse saying like, oh, hey, this is broken. One of us will go in there and see what's happening. Like the plugin's trying to load wp-load.php directly, expecting a certain path. At that point, we just tell the user, hey, you know, the plugin's doing it wrong. Here are some resources showing why they're doing it wrong. There's already been like core contributors that have written blog posts on the subject

as to like why these things break. So it's easy to just reference them, reference those blog posts to them, and then they can go and, you know, tell the plugin author who will hopefully get their act together. All right. Let's talk about who Bedrock is for because I'm thinking I've got a good friend who's probably listening to this. Whenever I think about WordPress and getting even more advanced with WordPress, I always think about this fella.

Hi, Ben. It's not the Ben word on the call. It's the other Ben that's my friend. But I know he's going to listen to the show because why wouldn't he? But he's who I think about when I think about WordPress and getting more advanced with it. Like who is going to use Bedrock? Is it somebody who's familiar with the command line? Like what kind of developer is going to care about Bedrock and what it does for WordPress?

It definitely caters to a more advanced WordPress developer. One of the things about Bedrock right off the bat is that it's a little harder to get set up on shared hosting, for example. If you're not using Composer or Bedrock, in my opinion, there's not much reason in using Bedrock. You can just use a normal WordPress subdirectory install or just a normal WordPress install. So right off the bat, that kind of limits people.

It almost acts like a filter. So Composer, if you're not using Composer, you don't want to use Bedrock? Is that what you said? Yeah, I mean, that's the primary reason for kind of Bedrock existing. If you don't want like the dependency management, then you can still get some of the advantages of the better folder structure, in my opinion, but you can use other projects.

What about the deployment process? The deployment process is, again, something that some people may not be used to. A lot of people may use it just to be FTPing over files or rsyncing or some a lot of there's projects that just do like a straight git deployment and the main step that you need in a bedrock deployment the one in all WordPress site is that composer part of it so basically you need to ship your code off to the server somehow you can do that via git via FTP, doesn't really matter. But the main part is that you need to run Composer install after that to get those newest dependencies and packages and WordPress core and plugins. So talking about, we got there by asking the question, which is, who is this for? So it

seems like somebody who's, and to your credit, Scott, you came from a Rails world where you've got Capistrano, which you're using here. And Capistrano is still a Ruby project, but it's usable by anything as long as you can run Ruby locally or on your server. So that's not a problem. more fluent with those types of ways, whereas those who live in the WordPress world aren't that privy to, you know, like command line deployments like Heroku might offer or things like that. So I'm wondering how big of a hurdle that is to get over. Like, what's the adoption of Bedrock? I guess your deeper developers are probably like, yes, this is awesome. But even those who you might consider advanced WordPress users

are still not quite command line users. Yeah. Well, just quickly going back to kind of who uses it. It was designed for teams and more professionals versus just someone creating a blog, like I mentioned, or maybe a freelancer who creates a lot of sites really quickly and then passes them off to a client. You can still do that. It's not for them. It's not for those. Okay. It wasn't designed for them, but it can certainly still be used

in any way. So obviously right there, you've kind of limited your market, if you will, to a smaller subset. But we still see a wide range of people. I mean, some people on the core, uh, roots team, I think we might talk about later on. A lot of them came in and use bedrock for different things. Some of them are freelancers. Some people just appreciate, um, the structure and kind of how it takes it to, uh, I'll say a more kind of rigorous or professional level with the dependency management. And I definitely know of a lot of, I'm not going to say, companies who have multiple developers working on long-term projects. That's where you get the most advantages of it.

So bigger companies who've got an install in place, they don't plan on moving away from WordPress. They have a team that's doing it. They have developers who are willing to go the extra mile and let's say, learn how to use the command if they're not currently using it. They're willing to take those extra steps to have a better team management. And Bedrock is really developed for that kind of team.

Yeah, definitely. It's also really good even if you're just working individually. I mean, because no matter what, you're going to be working on your code and it's going to be in a Git repository. Right. And you don't want to be checking in the entire WordPress install into the Git repository or any other dependencies or plugins. It's much nicer to be using Bedrock to pull on all those things just to not have that code in your repo. And then as

far as deployments go, I mean, there's probably a lot of people that are using Bedrock that aren't using one of the deployment methods that we offer. Other than just Capistrano, we actually have Ansible-based deploys as well. And I mean, take deploys completely out of the picture. Bedrock is still really useful to use as your WordPress stack. You could have a completely different deployment method. It could just be Git-based. You could use something like Laravel Forge.

I know people that use even like DeployHQ. There's a lot of different ways you could deploy your site, but the Bedrock project structure is probably the biggest advantage in my opinion. I think we need to move the Better Folder Structure feature up one bullet point. Yeah. I feel like that's where the biggest gain is.

And then opt-in to Composer, opt-in to deployments. But I'm speaking out of turn because I'm still discovering with you guys. But since you mentioned, Ben, deployments, let's take a quick break. But when we come back, we're going to talk about deployments because that's a deep subject for me, for sure, and for anybody who develops WordPress sites. So let's take a quick break and we'll come back and talk about deployments. TopTile is by far the best place to work as a freelance software developer. I had a chance to sit down on top of Brendan Beneshot, the co-founder and COO of TopTile. And I asked Brendan to share some details

about the foundation of TopTile, what makes TopTile different and what makes their network of elite engineers so strong. Take a listen. I mean, I'm one of the co-founders and I'm an engineer. I studied chemical engineering and to pay for this super expensive degree, I was freelancing as a software developer. And by the time I finished, realized that being a

software developer was pretty awesome. And so I kept doing that. And my co-founder is in a similar situation as well. And so we wanted to solve a problem as engineers and do it as a network of engineers, kind of for engineers by engineers and having that perspective and, and consistently bringing on new team members who also share this really makes TopTel different in that it's a network of engineers, not kind of like you have TopTel and then the developers, it's never about us and them. It's, it's always us. Like everybody at TopTel for the most. Everybody at TopTel, for the most part,

refers to TopTel as their company, and they feel like it's their company. And everybody acts like a core team member, even though they're freelancers within the TopTel network. And all of these things are extremely important to us. All right. If you're interested in learning more about what TopTel is all about, head to toptel.com slash developers. That's T-o-p-t-a-l.com slash developers to learn more and make sure you tell them the change law sent you all right we're back so deployments let's since we just talked about sort of the the bullet pointed feature of better folder structure seems like that's the biggest win for bedrock and composers are nice to have for the developers who care about those things which i think a lot of people do care about them

but to some people it's just like dependencies what are those um because that's more i think it's getting into your more modern developer and i'm not saying that we shouldn't strive to be modern developers but some are just fine with being the old way. Some are fine with FTP, and that's not wrong because it works, right? I mean, FTP is wrong. I mean, I'm not saying it's

right in quotes, but if it works, then it works, right? I'd go one step higher than you, and I'd say, for example, you use rsync. For that, I would concede that it works, it's fine. FTP, though, I wouldn't. No? Okay.

You got some of those developers out there who are just like, you know what, I'm not interested in the command line. I got this thing here, I drag and drop, and boom goes the dynamite. Oh, I mean, we're not kind of ignorant of of those people that exist because they they find ourselves to our projects i mean we'll find them in our github issues on our forum um we write blog posts and we've written we've made screencasts to kind of educate and teach people how to use these more advanced topics so i mean we realize that there's people who are at kind of all levels of the WordPress kind of developer spectrum from people who either don't

know about these things or do know and don't know why they're important or why they should be doing them or, you know, there's people who don't care and that's fine too. Right. Well, you mentioned there, Scott, that you left a little cat out of the bag. So here at the Change Law, we use WordPress to run our site. We like it. It's great. Every time we've tried to move away from it, it's pulled us right back and said, you're just trying to rebuild me in some of the language, and that's crazy. So just keep me. WordPress actually whispers those words to us.

And we deploy via rsync. We use gulp. We could use rake. And I actually, I'll put my hand up and I'll say it. I wanted to try it a cooler way. I took my existing rake task that worked just fine to rsync my theme only up to my server. And then I changed it to use gulp. So that's the only thing i use with

gulp that i think and some other things but i i could definitely use it uh do review with it so rate tasks are just fine too um but i'm a fan of finding a better way to deploy i knew that ftp didn't work for me it works for some people it doesn't work for me um so i knew i wanted to do one thing i could you know do scp to do it. I could use RC to do it. I just figured I'm not that worried about it. I'm a one person. Jared helps me with our stuff, but not with WordPress. Not because he doesn't want to, just because he's better at other things.

So I pretty much take care of all that. So being the only person who does design and development on our WordPress site, I figured, okay, it's fine with just doing, you know, grunt deploy and dealing with it like that. So what does Bedrock do above and beyond that kind of scenario? So when Bedrock was first created, I mean, the main thing to do with deployments was we kind of had Capistrano built in. So again, like, you know, I had Rails experience and Ruby. It wasn't a big deal to me. You know, I have Ruby locally. I have worked in other sites with Capistrano built in. So again, like, you know, I had Rails experience and Ruby, it wasn't a big deal to me. You know, I have Ruby locally, I've worked in other sites with Capistrano. So what that meant was we just had Capistrano configs in the project that had the necessary settings to work kind of out of the box with Bedrock. And we had documentation,

you know, on how to get started with Capistrano and how to deploy. And I mean, really the only thing that was, that you needed to add on to the default Capistrano deployment workflow was running Composer, which as I mentioned before, is pretty much that only necessary step beyond just getting the code onto a remote server. So that existed in Bedrock for a long time and we still support it. It's actually been moved to another repository right now. It's at root slash bedrock dash Capistrano. And that's just, I think we, we learned over time to kind of unbundle some things because sometimes someone will come in and just say Capistrano and they'll just kind of leave without realizing it's really easy either not to use or remove themselves. Most of the projects that we create, we say they're

like delete key friendly. If you don't want something, just remove it. But so now Capistrano is in a different project, but still supported, still works. And we kind of have an accompanying project to Bedrock, which is a set of Ansible playbooks. Ansible is just server configuration management. If you've ever heard of Chef, Puppet, Salt, Ansible is just like that, but different. I'm sure folks are familiar with it to a degree, but we haven't really talked about Ansible really much on the show yet. Yeah, if we want to get into that, we can. But just very briefly, we kind of have a better integrated, more official way of not only

provisioning and setting up servers for Bedrock, but also deploying. So those are kind of our two official methods. And we haven't necessarily documented how to use other deployment tools. Ben mentioned a couple like DeployHQ and Laravel Forge. But really, any of those tools usually let you kind of hook into their deployment workflow and specify manual commands to be run. So if you just kind of specify, you know, run Composer install, most deployment methods will work fine. Well, I'm very interested in the Ansible setup. I'm interested in how Vagrant plays into this. I use Vagrant quite a bit for development reasons and stuff like that.

Where do we begin with going down that road with actually using Ansible or using, because Capistrano's deployment, Ansible is sort of a little bit of both. And then Vagrant's sort of like localized version of it. Those out there who are tried and true WordPress developers probably know MAMP, should know MAMP. If you don't know MAMP, that's a sad thing. But maybe it's a better thing now that you've listened to this show because

you won't use MAMP anymore. Hopefully. Yeah, don't do that. Hopefully. Don't do that. So, I mean, that's the interest for me is with Vagrant when it comes to WordPress is I don't want to mess with my system. You know, I'm okay with it with the ways I can do it with like Ruby and using RVM and things like that because there's necessary tools. But I think that the WordPress and PHP ecosystem that I'm aware of isn't quite mature like those other versions are.

And it's easier to do it in a Ansible-created, Vagrant, Ubuntu, Fortuna 4 machine that I could just spin up, destroy. And so walk us through the process of Vagrant and Ansible and maybe even how deployments work at some point with Capistrano. Sure. Okay, so I'll start with Vagrant and Ansible and maybe even how deployments work at some point with Capistrano? Sure. Okay, so I'll start with Vagrant. I think that of kind of any tool that we use in the organization, Vagrant might be the most well-known. Most kind of communities have really picked it up, which is great. So Vagrant is a project to help create development virtual machines on your computer. So like you said, you really want to avoid messing with your local system.

One, because you might have incompatible versions, you might have different software that you're running on your production server. It's a little harder to modify versions and get the proper ones you want. Like Mac OS X comes with whatever default version at the time of things like PHP and Ruby and Python, and those might be different versions than you need. And they don't worry about keeping them updated either, and they're not going to concern themselves with what version it is

because they're not trying to be a development server. They're trying to just deliver an operating system to you. Yeah, so like you said, Vagrant creates a local virtual machine running on your machine, so you can do whatever you want in there, and it's not going to interfere with your system. So that's kind of the first step. And most people, when they get into Vagrant, they use it just for creating kind of a bare Ubuntu server. And then they'll go in manually and, you know, run app to get install Nginx or whatever software you need, MySQL. So what we've done is created a set of Ansible playbooks.

So when you type Vagrant up, it automatically runs all these Ansible playbooks, and it will give you a machine with all the software you need to run a WordPress site, which is a little specific to Bedrock, but it will work with any standard WordPress site as well. And the benefit of the Bedrock Ansible project is that the exact same playbooks that you use to create your development virtual machine, you use to create your remote staging and production servers. So it's one thing that we try to promote

is parity between your environments, as we call them, so that you know that if you're developing locally in development, you know with much higher confidence that if you push that code to staging and into production, that it's going to work because there's no mismatch between either types of software or versions of software or even things like you might need caching and test out memcache, for example, which most people wouldn't have running MAMP locally. Yeah, we got to get rid of the MAMP. MAMP's okay. It's just what you said.

It's not parity for your local environment. It comes back to the reasons why Bedrock exists, period, was to reduce the things you were redoing every time, like even hopping into a Vagrant machine and running app get every single time it's, it's, it's, it's not a dry process. So if you can reuse that process and match your development machine to your production machine,

then it's a lot easier to test bugs and things like that. And that comes from, I'm assuming it comes from your Ruby roots. Yeah, definitely. I mean, no pun intended, of course, since you're a Ruby. You liked that, didn't you?

I think that's kind of the biggest thing about Bedrock and our Ansible project is we just we try and take like the best practices that a lot of other communities are a little, were a little earlier to develop and i mean the php world and more specifically wordpress is getting better finally of kind of looking out and seeing what other you know languages frameworks or communities what tools and what best practices they're using and trying to integrate them back i would say it's really slow and it's finally getting a little better and so that's what that's all we try to do. I'm not claiming that we've invented things from scratch. I mean, I take a lot of stuff from Rails. Like I said, I took a lot of ideas

from NotMarch. That's the best way to do it. We were using Chef before we were using Ansible, actually. I like, you know, I'm a Rubyist in my heart, so I like Chef. And those who are DevOps, you know, I'm a Rubyist in my heart, so I like Chef. And those who are DevOps, you know, super DevOps people, they love Chef and they love Ansible.

And they may have a case where they prefer Chef over Ansible. But those are like, those are different kind of people than I am. And to me, when I look at Ansible, I'm like, this is a lot easier. It takes a little bit more learning, but it's a lot easier to read it. And it's a lot easier to me to just work around with Ansible. So I like it a lot. That's actually my favorite part is how easy it is to work with. You might be familiar with a tool or a project called VVV.

It uses Vagrant to create a WordPress development environment. But what it uses is, I forgot how many lines it is, it's just a giant bash script, basically, to provision the server. So if you take that and you compare it to what we've got in the Bedrock Ansible repo, it's just so much easier to work with these configuration files. And not to mention, you've got all these third-party packages through Ansible Galaxy that you can also take advantage of as well. Yeah, that's true.

Yeah, that's true. Varying vagrant vagrants. We'll link out to that in the show notes because it's a long one. I'm not going to spell that URL on GitHub, but VVV is its project name. And I used that at one point. That was neat.

Okay, that got me into a better development environment, but it helped me scratch the itch that I already had, which was I don't like what I'm doing currently. I don't like using MAMP. I want to have better control over my local environment in comparison and with parity for my production environment. And I want to be able to solve problems a little bit easier. And most of all, you know, Vagrant's a cool tool anyways.

So let's take a quick pause. We're going to come back. I know we've talked quite a bit about Bedrock. I do want to dive a bit into Sage and more so into the Roots organization and some of the other stuff you guys are doing. So let's take a quick break. We'll come back. We'll talk. We'll tail off Bedrock and we'll dive into Sage.

All right. Put them away. Put them back. Put the books back on the shelf. You don't need them. And learn to code by doing with CodeSchool. CodeSchool offers a variety of courses, JavaScript, HTML, CSS, Ruby, iOS, Git, and many, many more to help you expand your skills and learn new technologies. CodeSchool knows that learning to code can be a daunting task, and they've combined

experienced instructors with proven learning techniques to make coding educational and memorable. It gives you the confidence you need to continue past those rough, tough hurdles that you will definitely face learning to code. CodeSchool also knows that languages are a moving target. They're always updating their content to give you the latest and the greatest learning resources. You can even try before you buy. Roughly one out of every five courses on Code School is absolutely and totally free. This includes instructor classes on Git, Ruby, jQuery, and much more, which allow free members to play full courses with coding challenges all included. You can also pay as you go.

One monthly fee gives you access to every CodeSchool course. And if you ever need a breather, take a break, you can suspend your account at any time. Don't worry, your account history, your points, your badges, they'll all be there when you're ready to pick things up again. Get started on sharpening your skills today at CodeSchool.com. Once again, that is CodeSchool.com. All right.

So what can we wrap up here with Bedrock? I know we've spent most of our time here today on today's call talking about Bedrock, which is important. Bedrock is awesome. It is awesome. What else can we cover that makes a lot of sense? And then let's go into Sage. Sure.

I mean, I'll try and finish up with kind of, I guess, our overall vision and why we think it's important. And I mean, we've gone over a lot of the features and a lot of the things like dependency management and things you probably should use and may not. But I think the point where we're getting to now is a deep integration between Bedrock and our Ansible project. And once we get more integration between these, it just becomes really easy to create that development VM where you can run one or multiple sites and then mirror that with staging and production servers. I mean, soon we're going to be adding in a thing to automate creating like a digital ocean droplet, for example so with you know one command you could run vagrant up with another command you could spin up a digital ocean

droplet and it's going to run those same ansible playbooks and you'll get your staging and production servers and everything is tied together so that's where we're headed and i mean from what we see just talking to people they're already when, when it works, it's great. And we're fixing bugs. Some of these things are new. But they're really liking the kind of the higher vision of when all these tools integrate together. Oh, and actually, the final thing I should mention is underneath our organization on GitHub, we have a new project. It's called Roots Example Project.

There's dashes in there but just go to github.com slash roots and i'm sure you'll link it i'll link it what we've yeah what we've done is we've a lot of people had questions about how to integrate these tools together so we have an example repository that uses bedrock bedrock ansible and sage and some of our other plugins as well and it's a complete working repository. It's running on a production site, rootsexampleproject.com. And so they can see exactly what settings they need to change,

how these things work together, and the exact steps that we took to actually create it. And we're going to continue improving that. But I think that's one of the best starting points if someone kind of wants to see what Roots offers at a high level and the advantages of it this is uh definitely neat and being able to deploy the digital ocean and having

commands for all that is is super neat as well any direct a any direct collaboration with get digital ocean on the on that front um yeah ben can answer that not direct um they did sponsor us and they they provide us with our hosting, so that's very nice of them. We do plan on adding, hopefully, a one-click DigitalOcean install to the Bedrock Ansible project as well, though. Very cool. Yeah, DigitalOcean is what we're actually hosted on,

so we're big fans of DigitalOcean, and plus they support this podcast, so that's awesome that they support your project as well to move this forward because we all need support, and thank you, DigitalOcean, and plus they support this podcast, so that's awesome that they support your project as well to move this forward, because we all need support, and thank you, DigitalOcean, for that. So, any final words, I guess, Scott or Ben, on the developers out there

that are using WordPress, that are not using Bedrock, that should use Bedrock because they're the kind of developer that Bedrock is targeted for? I would just encourage people to take a look at it. I mean, that's the first thing is just check it out. We've written a lot of blog posts. We give a lot of support on their screencasts.

Like if you want to learn about features, if you want to find out how to use them, why they're important, I mean, just take a look at it. Some people might dismiss it. Some people might just say, hey, you know, I'm fine with what I have and why. But I guess all we can say is just for people to check it out. And we and many, many other people believe that there's big advantages to it.

Awesome. And that must tie into, I mean, similar philosophies in what Bedrock does for WordPress and deployments and dependency management must come into Sage Sage the same way, but at the theme level, not the entire WordPress app level. Right. We introduced Sage a little earlier as a theme. How do we describe this?

Let's start a theme based on HTML5, Bulletplate plate gulp bower uh and bootstrap some of these things are optional i'm sure but uh the the one thing in this it's the stands out to me is the workflow i know that everyone has their own crazy way to sort of organize their theme how does sage change that and then what's the workflow to i guess develop this theme okay so the sage gulp file is pretty badass and that's pretty much all thanks to austin pray um thanks austin anyways um so our gulp file um it compiles and concatenates css and javascript you know the typical things it also does image minification and we've got browser sync. So basically, when you have Sage installed on your machine, and you're running Gulp Watch,

you've got a browser sync session that launches and you load up the assets directory and you start choosing what you want to do, whether that's writing style sheets or writing JavaScript or even actually bringing in third-party CSS or JS from Bower. So if you were to be developing your theme, you could add a Bower package and it's automatically going to add that to the theme JavaScript. And in your browser sync session, it's going to automatically reload that. So for instance, if you're working on a new WordPress theme and you wanted to add responsive videos, you would just do Bower install FitVids. And before you know it, your browser sync session is working with FitVids. In addition to the things you mentioned there, something unusual to those who are developing themes for WordPress is this theme wrapper. And you mentioned before, Ben, that it was unconventional to WordPress. Can you talk about that a little bit

and what kind of hurdles you've had to deal with and what kind of gains you've had to, I guess, embrace because of it? So if you bring up the Sage code base, there's a file that we have called base.php. And what this is, it's the base wrapper file for a WordPress theme. If you look at a normal WordPress theme and you bring up the individual template files, such as like index HTML doc type, your HTML head, as well as the footer and all the different separate parts of your WordPress theme. So what the wrapper is doing is it's giving you one place to put your base markup, and then it's including individual templates from there. So instead of having your markup scattered

across maybe a dozen different template files, the base markup is controlled from one place. It encourages basically the separation of application logic from the templates. You don't want to have templates with conditional statements. You just want to have different partials that you include to keep things lean. I've done something similar in ours. I think I, if I'm going from memory, I don't have the project in front of me. I can pull it open though, while I'm sitting here talking about it though. I think I did something a little similar to this. I have kind of a, and by no means am I trying to compete with Sage, but I know I have a loop file, loop.php file, which has a while have post calling it and an end while,

and it does things like give me all my different sort of, you know, in the Rails world partials for the different post formats and things like that. That's what I'm doing. So how difficult is it to sort of retrain somebody doing things like I'm doing to embrace what's happening, I guess, in Sage with this kind of main wrapper? It's really not that hard. The number one thing to keep in mind is that nothing changes as far as the WordPress template hierarchy goes. For some reason, people get confused as far as that goes,

and they seem to think that things are different. But extending page templates works the exact same way. I haven't really heard of too much hassle with the wrapper lately. I know at first when we implemented it, there was a lot of people pushing back saying, whoa, this is weird, this isn't the WordPress way of doing things. It made them a little bit uncomfortable. And then sure enough, all these people that were hesitant to adopt the theme wrapper, they then came back and said, oh, well, this makes sense.

Why am I not going to implement something like this? So we actually have Austin Prey, I mentioned. He's on the Roots team. He did not come from the WordPress world. His first experience with WordPress theming was actually using Sage. And to him, everything made sense as far as the WordPress theme wrapper went. And then he went to go work on another project that was a non-sage theme and he was confused as to how the template files were working and why they were duplicating code across all the template files

and to him it was just like well that's weird the wrapper makes sense because he doesn't come from WordPress he came from outside of WordPress land where that's the normal way of doing things. So if you look at a normal WordPress theme and you bring up one of your templates, you're doing get header to get the page header. But inside there, you're also calling your main content area and defining the markup for that as well. And that's just not something that needs to be in those template files since that's going to be that needs to be in those template files since that's

going to be the same across the entire site yeah it's in my index.php file i have get header get sidebar and then i have get template part and then i'm referencing the loop.php file and i'm saying get footer and that's what my index looks like and and i can see how this wrapper would certainly change that quite a bit and probably help me reduce a little bit of the code repetition. But there's not too much because I'm trying to avoid that now. But my version of it is, you know, not as advanced as what you guys have got going on here. And I can see where yours is definitely improving the process a lot better.

Especially, I think the question I have after this is, just like we did with Bedrock, who is Sage for? Is it for everyone out there, or is it for the theme development companies? Who is going to use the way Sage says this is how a theme should be built? That's a good question. I wouldn't say that Sage is for everybody, and we actually have a blog post that says Sage should not be your first wordpress theme um okay you know it's nice for some people like a lot of people have told us that they've learned so much because of sage like we introduced them to tools such as gulp and bower right things that these people have never used before

but at the same time like if you wanted to build a theme for WordPress.org, we actually don't follow WordPress coding standards. We also don't include some of the things that they require in those themes. I mean, that said, there are still themes in the WordPress theme repository that are built with Sage. It's more for, in my opinion,

people doing client work or working on their own projects or building an app. It's not necessarily meant for widespread theme distribution. And that's because of the build process for the most part. I mean, you could package up your theme with the dist folder that's got all of the built assets. But I mean, that's not what we recommend in the first place. We are all about keeping those sorts of files outside of your Git repository. So I mean, Sage is definitely not for everybody. I mean, if you're just building a theme to sell it on something like ThemeForest, Sage might work for you, but the front end side of things is probably not going to work. You're probably not going to want to include

a gold file to offer to someone that's going to be installing this WordPress theme on their marketing website and they don't have any idea what CSS or JS is. So I'd definitely say that Sage is targeted more towards developers and also developers that are interested in, you know, these tools. This is really for those.

Sorry, go ahead. For the listeners, we're still dealing with some roboticness from Skype. So that's why you might hear us lately talk together. But yeah, I'm with you that this is more for teams that are or the someone who is really like managing their own site that wants to craftfully take care of their own site versus doing these antiquated ways. They're using more modern ways to manage their own theme. Could be an in-house could be an in-house marketing agency or marketing team for a larger company. I know my wife and Ben, the guy I mentioned earlier, worked at a company like that where they essentially have a WordPress install and they don't plan to move away from it. It's their marketing funnel,

so they're putting a lot of people to it, so it's really important. And they want to modernize and really craftfully take care of this WordPress install. And it seems like it's really important and they want to modernize and really craftfully take care of this wordpress install and it seems like it's for people like that not so much those who are developing themes and selling them which is great too because i mean that's that's a whole different market but you're trying to put better tools in developers hands to take care of their stuff and those stuff is a wordpress install and a theme install to that WordPress install. Right. Well, cool. In addition to this, I'm sure we could probably go on a bit more, but we're running out of time. In addition to this, you've got roots, the roots, the

organization itself. You've got screencast. Talk a little bit about the organization because you've got these two larger pieces to the project. You've which we haven't really talked about which maybe you could touch on a little bit but you've got screencasts you're doing some of those i think they're all paid if i if i recall correctly um paid paid screencasts that you can learn how to use gulp and bauer for theme development capistrano for wordpress deployment and composer for dependency management but talk about the organization the core team and what's going on behind the scenes that roots beyond these two press deployment and composer for dependency management. But talk about the organization, the core team and what's going on behind the scenes that roots beyond these two projects we've talked about most of the time here on the show today.

So we've got quite a few people on the team. The core team would be Scott and I, along with Nick Fox, Chris Carr and Austin Prey. But we also have a bunch of other people that help out with our projects. There is Michael from Florida, we got Phil, we've got Julian, Kaylin, Nathaniel, and Craig. And all these guys help out on a daily basis, whether it's on the forum or contributing code, or just talking about WordPress and making things better just internally and the direction of where we're going to go with our own projects. One of the things that Craig on the team said a few weeks ago,

let me find it. He said, I think we're all on the same page when it comes to WordPress. WordPress is a lemon, but the industry likes WordPress. So let's make lemonade. That's basically the roots organization right there. Yeah, it shouldn't be like that, though. It really shouldn't be, but I'm with you. Like I said, with the change law, we've rebuilt ourselves from Tumblr to WordPress,

and every time we've tried to do something alternative to WordPress, like we could build our own Ruby CMS, and it would be ours, and we can open source it potentially, or we can use something that's already out that's open source. We could use Jekyll. We can use several other things, but there's things that come with WordPress that don't come with other software that you can use. Plus, WordPress is open source.

We'll talk a bit about here in a second. I'll give you guys a chance to talk about your most favorite thing to talk about, that you can use. Plus, WordPress is open source. We'll talk a bit about here in a second. I'll give you guys a chance to talk about your most favorite thing to talk about, which is how WordPress, contributing to WordPress is broken. So we'll talk a bit about that. But for us, every time we try to do something different than WordPress,

we always were just trying to recreate what it does. And I feel like what you are trying to do with roots and what you're trying to do with the organization roots and then Bedrock and Sage so far is improve upon this lemon, you know, make it a better lemon, you know, or put a little sweetener in that lemon if we're talking about some puns here or something like that. You know, something to make it a bit brighter environment to work in because those who come from the Ruby world or other more modern deployment process worlds, you know, you come to WordPress and you're like, this is horrible. Not that WordPress is bad. It's the workflows that don't help the teams be better and more efficient.

Right. And I think that's really what you're trying to solve is being better and more efficient with WordPress. And, you know, the fact that it's in PHP doesn't matter to me. I think PHP is a great language to a degree. Some favor other languages, but I'm fine with it. If I had my rathers, you know, somebody might jump on the,

you know, somebody might jump on a different, you know, but that doesn't matter. You know, it's the tool itself is so ingrained to the web. There's so many sites on WordPress. Yeah, you can't argue with the numbers.

Yeah, you can't fight it either. So I think that's maybe the point. Who was it that said that? It was Craig that said that. Craig. So it's probably the point that Craig was trying to make. He's like, you know what? We can't fight it.

There you go. Sorry, just to underscore that, I believe even the newest numbers that someone on LoopConf, the WordPress conference just mentioned again, was that it powers 23% of the web. Yeah. I mean, who knows how accurate that number is, but we all know it's a lot.

I bet you it's accurate. I mean, that's what I'd like to know. Is it the American web? Is it the European web? Is it the China web? It's a staggering number. You know, it's what I'd like to know. Is it the American web? Is it the European web? Is it the China web? It's a staggering number. It's a big number, though, and I'm sure that's the case because it's open source. It's so easily deployed.

PHP is so vastly available on shared servers. Unlike other languages that have issues with getting there, it's just so easy to launch a WordPress site. So it's ubiquitous to the web. So I think it makes sense to leverage it. But I also think it makes sense to do what you guys are doing here, which is to improve upon its workflows and just in general,

make it a better environment. So let's zoom out a little bit and talk about, I don't know which one of you guys want to take this one. Maybe you both can do it. Tag team on, I don't care. But before the call was started, I wanted to ask you guys a question that you wanted to answer.

You wanted to talk about, and you all wanted to talk about, contributing to WordPress, WordPress Core, and how it's a broken process. What did you mean by that? So for people who aren't familiar with WordPress Core, they have always, or up until very recently, been on subversion for source control and they use their own wiki slash repo host called track it's an open source project and the project itself is fine that's not necessarily the issue what we're talking about when kind of contributing to wordpress core is broken and we don't just mean contributing as in writing code we also mean uh reporting issues responding to issues um keeping up to date with them and their workflow around you know patches bugs features things such as that I think the most common occurrence that's ever had chats between me and Ben, our old HipChat channel,

our current Slack channel, is searching track for some bug feature issue, finding it, pasting in the channel, and then remarking how it was open for anywhere from four to seven years and still hasn't been dealt with. I think Ben has a list of maybe like 100 track tickets, and their average lifetime is in the four to six year range. And I mean, that's the first problem. And the second problem is that I have a theory, and I don't know if this is true. So I don't want to step on their toes too much. But I feel like WordPress likes kind of insulating themselves in their own world. And that world is kind of track. It's the internal WordPress community. It's very weird that in this day and age,

you have a company like Microsoft, who's famously kind of closed source, doesn't embrace open source, and they're removing all their projects to GitHub. And then here you have this great kind of open source organization in automatic and WordPress, who's kind of siloed off in their own world in this track project.

And it makes it very hard to contribute. One of my pet peeves with it is to actually contribute code, you need to work with their subversion and generate patch files. So you need to create an issue. You need to create a patch file, upload the patch file. And then when you contrast that with the typical GitHub workflow is you can open a pull request and you can get a nice diff and people can comment right on lines and go back and forth with your code.

That's not really possible in WordPress's track. You can't link to a line, you can't comment on it. The whole pull request contribution workflow is broken. And that's the main thing that we talk about. Here you have a whole group of people in this rich organization who would love to give back and help WordPress, but they kind of actively discourage that and make it very difficult for you to do. Yeah. I mean, I think on this show we've covered the blessing. I think GitHub has been to the proliferation and the progress of open source

and it does astound me that that you got two parts you got some companies who want to stay in their systems they've already built out because they're used to it and they have their own agendas or they don't want to move or whatever the reasons are and then you have other other organizations like we just had a show with the ruby heroes talking about ruby and how they don't want to move ruby fully onto github because then that has a uh you know a company that has a profitable company a for-profit company that has like their hands completely wrapped around this open source project and they don't want to have that as dependency so you have all these different competing reasons of why GitHub may or may not be.

But as a community, as a contributor, as a user, as a developer, you just want access to contribute, whether it's a comment, whether it's better documentation, an actual code commit, sending patch files and diff files. And, you know, it's just, it's too much work.

And that's why GitHub exists. That's why github exists that's why git has gone the way it has and that's why we we're doing what we do now because github has certainly pushed that envelope to the to the nth degree to make it possible definitely yeah now we're used to it yeah and i should just clarify like this isn't about oh you know move to github because it's cool and it's popular and you know sub not cool anymore. And it's not even necessarily about GitHub themselves. If WordPress wanted to host their own, there's a GitLab and another one, they may have merged, they let you create your own GitHub, basically.

If they moved to something like that that was much facilitated, kind of like a pull request-based workflow, they'd see the same kind of benefits. Obviously you wouldn't have, you know, the built-in user base of GitHub, but it's a combination of the, you know, the large community on GitHub, but also just the ease of contributing and dealing with issues in pull requests. So if Matt Mullenweg or somebody high up on the team is listening to the show right now and they can make a change,

what change would you guys request to the WordPress team to make it more accessible? What are some of those? I mean, it might've been obvious, but what's a clear directive for them? Well, I mean, in my opinion, the easiest or most direct move would be move your project on to github and you know kind of embrace that pull request based workflow um i mean like i said the main issue is it's just really hard to deal with patch files and code reviews and as someone who may have wanted to contribute patches i have not done that simply because and you're talking about someone who's

been on github for years has contributed to I can't even count the number of open source projects. And this is me who doesn't even want to help out with WordPress. So I can't imagine what it's like for others as well. And I think the result of that is you get a very kind of insulated WordPress community of the same people. Yeah. Yeah, I feel your pain. So anybody out there who has some pull to that team and can

clue them into this show, tell them to come and listen to what Ben and Scott and the rest of their team have been doing their roots. Certainly enjoyed the conversation around Bedrock. Certainly enjoyed the conversation around Sage. certainly enjoyed the conversation around sage

definitely want to encourage you guys to keep moving forward and adopting new members to your team what's a call to action for for roots and sage i guess sorry bedrock see i'm i'm stuck again with the with the branding and the naming for bedrock and sage and the roots organization which you guys have going on there what's the call to action for the community? How can people step in and help you move the initiative forward that you have going? I mean, really, at this point, there's not too much that needs to change on like the Sage theme itself. We're moving to a Yeoman generator. So, I mean, it would be great if people would like to fork Sage and replace Bootstrap with their own front-end framework.

I mean, that's going to make things like the Yeoman generator a lot easier for us. And then our Bedrock Ansible project, we're trying to get a 1.0 out for that. So the more people that use it and test it and give us feedback on that, the better it is for us to improve it. Yeah, and I was just going to mirror the last part and just say that more than anything, we like to hear about people using it and their feedback. And I think one of the bad things about kind of the open source world is that you tend to hear about, you know, the bugs and the things that don't work and then the people who it's working great for don't speak up.

And I mean, they're both equally valuable. It's great to get bug reports, to get improvements and suggestions and things that don't work, but it's equally good to get that opposite message of, hey, this is working great and these are the specific things we like. And especially getting into the Ansible side of things, it's just we need more people using it and we need more people reporting back either things that don't work or things that they like.

Good deal. Well, Ben, Scott, thank you so much for joining us today. But for those who are listening, thank you so much for tuning in. All the links we talked about will be in the show notes, so check out the episode show page for that. This episode is, I believe it's 156. So go to changelog.com slash 156 to get all the links. Definitely want to thank our sponsors for supporting the show. Digital Ocean was mentioned.

Not sure if there'll be a sponsor for this show or not because I do those. I record those in the aftermath. But next week's show is going to be a fun show. Let me see what that show is actually. It's going to be with Sarah Allen. If anybody's familiar with Sarah Allen, so talk about the Ruby world. Sarah Allen was one of the founders of RailsBridge. A lot of cool stuff coming out of what Sarah Allen's doing.

Such a contributor to educating those who want to become developers and junior developers. There's a lot of, a lot of passion from Sarah. We're excited to have her on the show finally. And with that fellas, let's, let's say goodbye and call the show done.

Awesome. Thanks a lot for having us, Adam. Yeah, thanks. It was great to be on. It's great having you guys on. All right.

Thanks guys. Bye. yeah thanks it was great to be on it was great having you guys on alright thanks guys bye bye Bye.