​[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, why you might like to add Composer into your WordPress website workflow.

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 forward slash feed forward slash 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 forward slash contact forward slash jukebox, and use the form there.

So on the podcast today we have Chris Reynolds. Chris has been working with WordPress for over 15 years. He’s freelanced, worked with Event Espresso, WebDevStudios, Human Made, and is now at Pantheon as a CMS ecosystem engineer and WordPress technical lead.

He’s spoken at WordCamps and at OpenWest about all aspects of WordPress.

I suspect that many of the people listening to this podcast are not using Composer in their WordPress workflow, and to Chris this is something that you should think about implementing, and he’s here to explain why.

Chris starts off by talking about the kinds of projects that he’s worked on, and how we found WordPress.

We then get into the weeds of what Composer is and the benefits that it brings. It’s essentially a package management system, and makes it easy to set dependencies for your project and manage them within Composer.

Why would you want to do that though? If you’re just building brochure websites, then perhaps you’ve don’t. But if your project is more complex then this might save you a lot of time.

Chris describes scenarios in which she thinks Composer is a good fit; if you want to add in specific packages and how those packages are managed and updated.

He explains how you can install composer depending on the OS that you’re working with, and how it structures the files and directories that are created.

Towards the end of the podcast, we talk about how composer can be useful for teams, and Chris’s use of Composer to keep everyone clear on how the project is structured.

If you’ve thought about using a package management system, such as composer, 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 forward slash podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Chris Reynolds.

I am joined on the podcast today by Chris Reynolds. Hello, Chris.

[00:03:40] Chris Reynolds: Hi. How’s it going?

[00:03:41] Nathan Wrigley: Very well, thank you. Chris is on the podcast today to talk to us about something that I confess I know very little about. I’m going to guess that if you’re a typical WordPress user, you too may be learning a few new things today. It’s all going to be about Composer. Before we get into Composer, what it is, how it works, and all of that, wouldn’t mind Chris if you just orientate our listeners. Give us a little bit of insight into you and your WordPress journey. The companies that you’ve worked at. The things that you’ve been involved in and so on. So over to you, Chris, give us your intro.

[00:04:14] Chris Reynolds: Sure. I came across WordPress right around the time that my son was born, which was 2005. The internet was a very different place back then, wasn’t it? At the time I was looking for something to like share pictures with family and stuff, make a website.

Back then I had what was then referred to as a weblog. It was before that was shortened to blogs, and it was literally a log of things that I did on my website, update changes. And that was all hard coded html. So when I was trying to think of something to share pictures, didn’t want to do it hard coded. I did do that for a little while and then I decided this was not the thing I wanted to be doing.

So there used to be a website called Hot Scripts. There I found a blogging platform called S Blog, and I was using that for a really long time. But as happens in open source, and actually honestly, as part of what happened in the WordPress history, the original maintainer and author disappeared for a little bit, and it wasn’t getting updates and I think there were some security things at some point. And I started looking for something else. Had some friends that were talking about WordPress, so I was like, I’ll try this thing out, and basically haven’t looked back.

At a certain point after my son was born, I decided that I wanted to quit my regular job, which at the time was doing tech support for grocery stores, and become a freelance web designer. And I did that for a few years. Was familiar with all of those Elance and I don’t even remember all, like freelancer.net or something. Like all those really old sites to get freelance work. And I worked for a time for a company that’s actually local, as an outsource, freelance web designer.

There, I believe owner, ran off with all their money or something, and the company closed down. That was a fun story. And then I met the folks from Event Espresso, which is a event management plugin. I met them at WordCamp Salt Lake City because they’re local, and Salt Lake City is where I live.

And I started working with them initially just doing tech support for them, and then I got into a little bit of development and then I got into a little bit of project management and development. And then I was at a WordCamp, I was speaking. And Pluralsight, which is an online training platform saw me speak and asked me if I wanted to do that sort of thing for them as a, as an author of WordPress related training courses.

So I started doing that while I was working at Event Espresso, and then eventually I quit to focus on that. And did that for about a year or so. And then, I started getting into agency world. So I worked at WebDevStudios for a couple years. And then I went to Human Made. I was there for almost five years. And now I’m working at Pantheon as a software engineer focusing on WordPress ecosystem things.

So I’ve been involved in very small projects. I’ve been involved in very large projects. I’ve been involved in training. For a while I did some work with the docs team for WordPress documentation. I went to the community summit in San Francisco way back in the day. I’ve spoken at lots of local WordCamps and OpenWest which is also held locally. And yeah, I’ve been around for a little while.

[00:07:12] Nathan Wrigley: Yeah, you really have. That’s an amazingly long history, and going back with WordPress to 2005, you really were right at the forefront. It was just the very beginnings at that point.

[00:07:22] Chris Reynolds: It had been around for a while. If you look at the screenshots of the admin, I wasn’t the very first iteration, but I think I was maybe the second iteration.

[00:07:31] Nathan Wrigley: Who knew back in 2005 that it would become such an important part of the ecosystem of the web in general. We’re at the point now where 40 plus percent, I still never quite know what that number means, but it’s a big number and WordPress is an important part of it.

You say that you’re a Pantheon at the moment. Just give us a little bit of insight into Pantheon because I confess, I don’t know a great deal about it. But in my mind I’m thinking managed WordPress hosting and also managed CMS hosting possibly some other variants as well. Just tell us a little bit about what Pantheons skin in the game is with WordPress.

[00:08:09] Chris Reynolds: You’re not wrong. We like to call ourselves a web ops platform and we also have kind of coined that web ops phrase, which means that outside of, speaking about Pantheon, it almost doesn’t exist. What web ops is, it’s website operations, right? It’s the things that make your website go.

And what that means practically is that the way that the platform has been built is from the ground up to make sure that teams are able to develop on their websites in a way that is easy to deploy, that is safe, and that is secure. And there’s all sorts of platform centric things that are part of the workflow.

Pantheon was one of the first, when I was working at WebDev, was the first exposure that I really had to Pantheon. And it was the first platform that I had used that had integrated Git. So you didn’t have to like, put your stuff on GitHub and then figure out a way to point that deploys to a server somewhere.

It was already built in. And they had been doing that from the very beginning. It also had as part of that there is a dev test live workflow where there’s separate environments. And this isn’t uncommon today, but it was one of the first places where you could do that and had it built in.

And then the real sort key feature that I enjoyed as a developer and still enjoy as an employee honestly is the concept of multi devs. Where if you have a branch that you are doing work on and you want to see what that branch would look like. Typically in my agency days, the way that you would handle this is by merging that into dev, and dev becomes really messy, dirty because it’s got lots of basically untested code, or code that was maybe tested and then rolled back or whatever.

Dev is always nasty, a nasty place to be, and you never deploy from dev. That was always the rule when I was working in agency stuff. Multi devs solve that problem by spinning up an entirely new environment for a branch. So you can create a multi dev off of whatever branch, and then you can test it there, and then you can merge that into dev or whatever.

Your dev branch is clean because it’s not, you’re not getting all this test code, experimental code that’s getting merged in, and then maybe you’re making some changes or maybe you’re fixing some stuff, undo some stuff that was from an old merge.

That way you can keep your branches clean. And that’s a really cool thing that Pantheon does that I’ve often have wished for when I was working elsewhere, or working on sites that were not hosted on Pantheon. So that’s one of the things that Pantheon does.

We were talking before we started recording that Pantheon was built by four or five Drupal dudes. So it’s been a Drupal shop for a very long time. And then maybe about 10 or so years ago, when I became aware of them they started doing WordPress sites. Still built on the same infrastructure that they had built with all the same live workflows, multi dev, all that sort of stuff.

And now we’re getting into a point where we’re really trying to build out and optimize for WordPress and find where our gaps are in terms of how the platform has been built and what WordPress specifically needs. And that’s essentially what my team is involved in.

[00:11:10] Nathan Wrigley: Nice. Yeah, that’s a real interesting set of things that you talk about there. I didn’t actually know prior to our conversation we had before we hit record, I didn’t know that it had all begun on the Drupal side of things, but obviously as WordPress has been in the ascendancy for the last 10 years, it does feel like an important pivot for any company really to make, is to give an experience to WordPress users which is optimized for them.

So, yeah, I’ll make sure to link in the show notes to anything that we talk about. So if you’re listening to this, don’t worry too much, you can go to the WP Tavern website and search for this episode and find all the links there.

Now I’m going to include quite a few links to what we’re about to talk about. This is the main thrust of the podcast. It’s something called Composer. Now, when Chris reached out to me, he mentioned that he wanted to talk about Composer, and I’ll be really honest, it’s not something that I’m familiar with. Chris was very kind to gather a bunch of links, which I’ve now read, and I’ve tried to understand.

But I feel that Chris, you are going to school me today, so we’ll go right back to the basics. The first thing I think to mention is that I don’t think I know anybody else in the WordPress community who is using Composer with the sort of urgency that you feel it should be being adopted. Most of the people that I know are freelancers, possibly working in an agency and the typical workflow is, you know, if you’re working with a team, you’ve got a method of doing that.

But you may well be working on your own website. You may be working for client websites, and you’re just installing WordPress and a bunch of plugins and themes and so on and so forth. But you’ve got this bee in your bonnet about Composer and the virtues of it. So let’s go right back to the beginning. You’ve probably heard the word Composer before if you’re listening to this podcast, I imagine. But you may not know what it is. So let’s go there. What is Composer and why is it in any way important?

[00:12:59] Chris Reynolds: At its base Composer is a package management system. So if you’re at all familiar with npm which is primarily for JavaScript packages, maybe you’ve used that for Gutenberg stuff. Maybe you’ve used that for other JavaScript things. Composer is that thing for PHP packages.

In the past there were things like Pear and PECL, P E C L which did the same sort of thing. Composer does those same-ish things, but better. So at its core, it’s a package management system, which means it’s able to do like dependency management. And what that means is, if I have a package, and I have a certain version of a package.

Say I want php code sniffing, I can require that package with Composer. I can make sure that package is up to date. But I can also be specific about the versions of that package that I want to keep. Maybe I want to be on PHP code sniffing version eight or eight dot whatever, but I don’t want to upgrade to nine yet, or something like that.

I can be specific about my version dependencies, the versioning system that I’m choosing and be really, either really explicit. I can pin it to a specific release. I could do, I only want the security or patch releases. Or I could be really vague and say, just give me the latest version of whatever.

And Composer has, it’s based on the idea of semantic versioning. So as long as your packages and WordPress itself doesn’t use semantic versioning notably, and neither to do a couple other things like Yoast doesn’t do it, because they’re using sort of the version numbers don’t matter school of thought, which kind of breaks the whole thing a little bit.

But if you’re doing that sort of semantic versioning, which is common throughout just open source software in general, of major dot minor dot patch fr security then you can be really, you can update your things and feel fairly confident that an update is not going to break your thing, break your site. This is perhaps not a myth now as things in WordPress have improved. But the analogy that I like to think of and the reason why feel like Composer is, really important in a WordPress environment is the, I’ve got a million plugins, maybe not a million, maybe 20.

And I’ve got a couple themes and I go to my WordPress updates page, or maybe it’s got auto updates, right? And something happens and an update happens, and I wasn’t there. Either I bulk updated all of them or it happened in the background. Either way, I’m not looking at each individual update that I’m doing, and something breaks. My website white screens, and I have no idea what caused that problem.

I have to go back, I have to undo everything. I have to like, rename my plug-ins folder. I’m now in panic mode because my production site is white screening. It’s because of an update. It’s because something went through that I was either not paying enough attention to, or that happened automatically in the background that broke my site.

Composer, and the way that WordPress is built with allowing, essentially anybody who has access to the plugins page or the updates page to run those updates means that you’re putting the power and the control over administrating code that is deployed to your site, to whoever has access to those screens, right?

And Composer almost flips that and says, no, we’re going to give this power to people who actually touched the code. Who maybe are more aware of dependencies and change logs and what an update might mean to a site. And that’s, sort of where I, see the value of Composer just broadly.

[00:16:21] Nathan Wrigley: Okay. That was, yeah, a really interesting description of how it works. Could you give us the nuts and the bolts of that? In other words, could you unpack what’s going on? In other words, how is it, how is it installed? How do you get it to bind to the different variations? You mentioned, that you may want it to update to a certain version of such a thing. How do you actually do all of that?

[00:16:44] Chris Reynolds: Composer is software that runs on your computer. You can install basically anywhere. So if you’re on a Mac, you might use Homebrew to install it. You can run it on a Windows machine, it’s just a binary. You can run it on a Linux machine, there are packages for it. It’s essentially cross platforms, so you can use it or you can run it anywhere. Once you have it on your operating system. . Then, we’ll just use a WordPress, vanilla WordPress site, as an example, if I had a WordPress site maybe I do wget or download the zip file of WordPress and I unzip the package. Okay, that’s great.

And then I have Composer on my, on my, system so I can run at the command line Composer in it. And that’s going to start the process of building a Composer dot json file. And then once I have that Composer dot json file, I can start pulling in dependencies. I can say Composer require this thing, this package by this vendor.

And that’s going to, by default, install my dependencies into a vendor folder. Composer also has a built-in auto loading system. Which means that then in my project, if it’s a WordPress project, I can have a file. I could throw it into wp-content or a rather wp-config, or I can throw it into a mu plugin that loads the Composer auto loader file so that any packages that are being pulled in through Composer or libraries or whatever, are automatically pulled in because Composers does that, just does it for me.

If I’m doing WordPress specific things, what I would also need to put in my Composer file is a additional repository for W Packagist. So out of the box, Composer works with a platform, a website, a repository called Packagist, and that’s where all of the packages live.

If you go to packagist.org today, you can do a search and you can find all sorts of stuff. What you won’t find is a ton of WordPress related stuff. You’ll find some. There’s Human Made has a ton of stuff up there, which I know because I worked there. And I’ve put a bunch of Pantheon things up there.

There’s some other people who have been putting stuff on Packagist, just core like, Yoast notably has stuff up there. But it’s not a WordPress place, it’s just a general open source place, just like npm again. W Packagist is a bridge between the wordpress.org repository and Composer.

And it is just a mirror of the WordPress plugins and theme repositories for Composer based WordPress projects. So if you add W Packagist as a repository in your Composer json, now I can do Composer require and I can say W Packagist plugin slash WordPress SEO. And that’ll pull in the latest version of Yoast SEO into my Composer file.

Or I can say Composer require P Packagist theme 2010, and it’s going to pull in the 2010 theme, of most recent version. That’s sort of a little bit of the nuts and bolts. That’s how the Ccomposer json is built. You can also obviously edit this file manually. And then if you want to get into versioning, when you pull that stuff in, it’s going to give you a sort of its default. Which is typically the major dot minor with a little caret before it, which means that it’ll accept all minor versions, but it will pause if the version number, the latest version number changes for the major version, right?

if it was like 1.5, 1.6, 1.7, 1.7.2, .3, .5 point whatever, all of those things would get pulled in. But as soon as that 1.7 turns to 2.0, because maybe they made a major release, it’s not going to get 2.0. It’s only going to be one point, whatever. Until I change that in my Composer file.

That’s sort of the default setting. You can be more specific. You can go all the way out to the minor point release and just say, the only updates I ever want to get are these minor or patch releases. To make sure I’m getting all the security updates or whatever. And not getting minor version updates because maybe I’m afraid that one of those minor updates might do something bad, or I’m not, prepared for it yet. Or you can be very vague, and say, just star and give me everything. Or you could say just one, no points, just caret 10 or something. That means that anything above version 10 you’ll get, doesn’t matter what the point release is.

And that’s a way that you can solve for that white screen of death scenario that I talked about earlier. Because if I’m being specific and explicit about what versions I’m allowing in my updates then I’m not going to, I shouldn’t get to a point where something unexpected happens because of an update that happened that ran on my system.

And in addition to that the way that those updates happen at all is by me or an automation system running a Composer update command. And that’s the thing that says, go look for things that have changed and pull in any differences based on my defined versioning scheme.

[00:21:21] Nathan Wrigley: So you can get really granular with it. You can instruct it to do whatever you choose to do. I like the example there of pausing at the point release. So instead of going from 1.9 to two automatically it just pauses because it’s two. But 1.8 to 1.9 was okay to do. Yeah, it’s really interesting, you can get really granular. And then you run the command to run all of the updates and off it goes.

It sounds like, I could be wrong about this. It sounds like you could broadly break down your description for why to use Composer into three things. I’m thinking, first of all, security. It sounds like it provides, it’s not really providing security, but it’s providing security in the sense that it’s going to update plugins and themes and whatever else you may have coded yourself. It’s going to do that without your intervention. It’s going to run on a schedule and it’ll just get those things updated for you.

Which as we know in a lot of cases, a lot of WordPress websites, I don’t think the updates are happening for weeks, possibly months, who knows, maybe even years. So all of that gets taken care of. It also sounds like there’s a big time save here. If you can get this into your workflow, then you can step away from the dull task of updating things. This will just happen on the fly. You could have a setup in Composer that you reuse over and over again on a sort of typical website that you might set up.

And thereby you can just drag in all of the packages on day one of the project. And within moments you’re up and running with a typical install that you mentioned. Suck in a particular theme or suck in a particular SEO plugin or what have you. You just run the Composer and all of that is just dragged in and you’re off to the races. It’s a quick way to get started.

But also, you didn’t mention this, but it feels like this is a real win for teams. It feels like a team using this workflow, there may be benefits there. So broadly speaking, I’m talking about teams, times and security. Is there anything in that? Have I sort of got that about right?

[00:23:16] Chris Reynolds: Yeah, I think so. Obviously there needs to be an automated step somewhere in the process of actually running the Composer update. But beyond that, yes, absolutely. And interestingly one of the things that you touched on maybe accidentally even, the idea of sucking in all of these different packages. When I was at Human Made, I worked on Altis, and Altus is their digital experience platform.

And Altis is built almost entirely on Composer, and lots of cool Composer things happening. Altis itself is what’s known as a meta package. When you install Altis, the initial Composer file is just linking out to a whole bunch of other projects or packages that it brings in. And those themselves have their dependencies. So each, each of the modules, like the security module or the core module or whatever, each of those has its own set of dependencies that it pulls in. So it, really does just sort of like package a whole bunch of stuff that you get just for free when you initially set up a new site using that.

And that was one of the things that going from the idea of, oh, I’m just going to throw this Composer file in my WordPress site and call that good. That’s one of the things that really made me think, oh, actually there’s, there’s a lot more to it here. And one of the things that I first was exposed to when I was working at Human Made, and that I’m actively doing now with what I’m working on a Pantheon, is the concept of WordPress itself being just a dependency of your project.

And so like with the initial example, I’ve got a WordPress site. I unzip it. I throw my Composer, json in the root folder. That means that I’m using Composer probably to manage my plugins and themes, any other packages I might have. But I’m still using WordPress itself to update itself. Because WordPress is still part of that root directory, and it’s not part of the Composer structure.

There are projects, there’s a couple things out there in the world that’s already, that have been existed, but one, a big thing that’s been part of the WordPress ecosystem for a while is by the Roots team called Bedrock. And that’s what we use at Pantheon. And that, among other things, what Bedrock does is it pulls WordPress in so that it can be a dependency. So that can be just another thing in your Composer file that is being versioned.

So again, same rules apply, right? You can say I want everything past six. You can say I want 6.1 dot anything beyond that. Or you can say, I only want 6.1.1, and when the next version comes out, I’m going to manually make that change so that I can be explicit about my testing process to make sure that I’m not going to ship broken code.

[00:25:42] Nathan Wrigley: Yeah, that’s really interesting. The idea that WordPress itself is a package. Okay. I can imagine, given the audience of this podcast, it really does span the whole community, you know. There’s people in every part of the WordPress ecosystem listening to this. And I can imagine there’ll be a certain proportion of them who as soon as you start to say things like npm and packages and all of this, and you mentioned, you know, things to do in the command line and da, da, da.

They’re scratching their heads thinking I don’t know if this is for me. This all sounds a little bit complicated. So just address that. There’s a certain level of tech geeky here, I would imagine, But, is it difficult? Is the payback for a, let’s say a user who is just playing with five or six sites, they’ve got a few client sites and they can well manage to go in and update the plugins and the themes and all of the bits and pieces that they got set up.

Is there a use case here where, okay, if you’re sitting on that side of the fence, don’t even bother? This is probably not needed. Whereas if you’re on this side and you know you’ve got more sites than a certain number where it’s going to be of more use.

[00:26:47] Chris Reynolds: I mean, I definitely think that a lot of the freelancers that I know when I talk to are of the mind that, it’s just one more thing I need to worry about. And certainly if you are not going to on behalf of your clients go in and make updates, and you’re handing, once you’re done at your site, you’re handing that responsibility off to them.

It’s going to be too much work for your clients probably. I’m thinking like small business. I’m thinking like mom and pop shop. That sort of thing where it’s really just a user, one person or two people that are running the site. They’re probably not going to want to do stuff on the command line and you’re not going to want to train them and that’s fine.

But I think about when I was at WebDev and we were doing maintenance contracts with clients, and WordPress updates came around and we had basically a person dedicated to reading all of the change logs of every plugin on every site before making any updates. Just to make sure that nothing was going to happen that could potentially break.

And then if there was something that was maybe potentially breaking, they would have to like manually test that themselves on a dev environment, or a local environment or whatever. Just to make sure we’re not going to run an update and it’s going to break something. And I think that that process is very tedious and time consuming.

And that process is the process that you’re saving by using something where you can be more explicit like Composer. And you know that your updates are not going to break anything because the way that you’ve set up your versioning is the thing that you want it to be, and you feel confident about that structure so that when there are updates, you can go in and yeah, you still need to do testing, you still need to evaluate those things, but you know that you’re not going to accidentally push something out.

Or you can be at least fairly confident that you’re not going to accidentally push something out that’s going to break something. Because breaking things is not a good thing. It’s not a good feeling to have shipped something when you’re just doing a maintenance WordPress update release and your client is calling an hour later saying, why is my website white?

[00:28:42] Nathan Wrigley: Yeah, I guess in the case of some of the agencies where you’ve worked, so Human Made WebDevStudios and so on, it really is enterprise level stuff, and there is no scope for bringing a site down because of a careless update. So the notion that most WordPress users would go in and read the change log before clicking update.

I think that’s probably not the case. I would imagine most people are fairly cavalier because it’s their own site, or it’s a client site that they’ve got a backup of, and there’s some mitigation that they’re, doing all of that. But in the case that you’ve just outlined where, I don’t know, maybe these are international brands that we’ve heard of where the press damage alone in having a website go down for 50 minutes is just unconscionable. You’ve got to do the background research, and so having these systems in place is truly important.

[00:29:36] Chris Reynolds: Yeah, for sure.

[00:29:36] Nathan Wrigley: In terms of, we’ve been talking quite a lot about updates. I just wonder what your thoughts are on the, I mean, it’s not that recent, it’s several years ago now. The idea that in WordPress you can click a link in the, let’s say the plugin page. And you can say just go on, update. Whenever something new rolls out, just get on with it and update it. So you can, if you like, trust it. What are your thoughts on that?

[00:29:58] Chris Reynolds: I think it’s nice for the people that it’s good for. And I think it’s definitely helped with WordPress adoption. Because if all I was doing, if I wasn’t a WordPress developer and all I was doing was being a podcaster and I had a website that was just about my podcast. I’m not going to care about code. I’m never going to want to touch the code. I’m going to want to install WordPress and never look at FTP, or know my server configuration, or care about my database.

None of that. None of that is interesting to me. What I want is I want to plug it in, turn it on, and let it run. And be fairly confident that it is going to continue to run when I have my eyes closed and I’m not looking at it. So I think that it’s nice in the sense of creating an ecosystem in which things that you do in WordPress are relatively easy. And the counterpoint to that, I work at Pantheon. Pantheon’s been involved in the Drupal committee for a very long time.

Talking earlier too about how Drupal has, I think since version eight, integrated Composer into the core of how Drupal works. So sort of the antithesis of this idea of, I’m going to turn it on and set auto update and then walk away, is the idea of Composerizing everything. So that every change is a code level change.

And what I’ve found interesting, that I’ve learned over the last year of being at Pantheon in a difference between the sort of like Drupal ecosystem and WordPress ecosystem, is in WordPress, yeah, there are some people who make it their job to kind of do just general site administration for people.

But it’s not a huge thing. It’s like there’s a couple people that do that sort of thing or they don’t actually touch the code, but they will do your WordPress updates and that sort of thing for you. In Drupal, there’s entire agencies where all of what they’re doing is essentially that, just the maintenance stuff of having a website.

And part of that is because the Drupal admin is a lot more complicated to use, to create sites and pages and views and all sorts of things. It’s a lot more complicated than the WordPress admin, which I credit to how WordPress is built personally. But the other part of it is the understanding of like, when it’s okay to update this Drupal module to the next version or that sort of thing. To be aware of what’s happening on their other sites. And then what combinations work together and that sort of thing.

There’s a whole ecosystem that it’s really just essentially website management, which doesn’t exist in the same way in WordPress. And so that’s sort of what we’re talking about. The difference between having really hands-on updates. Making sure that things are safe to do. Or making it so that the people who actually do the content editing or other administration on the site, they don’t have to worry about the stuff that’s happening in the background because they know somebody’s taking care of it, versus having just the software take care of that for itself.

And so I think there’s a place for it. And I think that the reason why WordPress has grown so much over the last many years is because it’s embraced this, well, we’re going to just auto update things and not have people stress over that stuff. But, also like the reason why there’s so many people that are holding onto Drupal is because they want to make sure, they want to ensure that their site is stable and secure and all of those things. And that those things matter for really big companies. It is that divide, right of more casual users versus the enterprise level stuff.

[00:33:09] Nathan Wrigley: I guess because Composer is essentially nothing to do with WordPress. I mean, you know, you’ve described a scenario in which WordPress can combine with it, which is very helpful. Updating plugins, themes and so on and so forth. I guess this can reach beyond WordPress. So if you’ve got something bespoke, unique, you’ve got a package, which is nothing to do with WordPress. Composer can take care of that as well.

[00:33:34] Chris Reynolds: Yeah, and it’s really useful when you, so in both npm and Composer, there’s the concept of dev dependencies. And these are dependencies that will install when you do like a Composer install. But you can also say, you can omit the developer dependencies on your production installs, right?

And that means that you can run things like linting and unit testing and all that sort of stuff, which doesn’t matter if it’s on the prod site. But maybe if you’re going to push it to your dev site or you’re going to keep it on your local machine. And you can manage all those things really easily with Composer.

There’s definitely WordPress coding standards and there’s WordPress suites for unit testing. Those things all exist and you can manage those in WordPress. But essentially, like the core thing, like PHP Code Sniffer is not a WordPress thing. It’s just a, it’s just a package that exists in the world. And same thing as PHP unit. It’s just a thing that exists in the world that we have adopted and embraced and brought it into our ecosystem. So for sure, yeah, there’s definitely value of using Composer to manage sort of like external things.

[00:34:29] Nathan Wrigley: Okay, given that if you went down this route and you made Composer an integral part of your process. You then to some extent become dependent upon the functioning of Composer for your whole process to work. And so that brings me to the Composer ecosystem.

So we’re all always talking about how great the WordPress ecosystem is. There’s a forum for this. There’s a Slack channel for that. If you want to find something out there’s ways of learning. Is the same true of Composer? It’s an open source project. Does it have a thriving community? Does it receive the updates that one would hope? Does it progress in the same way that we hope WordPress does? Does it have that same feel? Are there resources for learning and so on?

[00:35:07] Chris Reynolds: Well, I will say that the website for Composer getcomposer.org, I believe, is really, the documentation’s really good. At its core, it’s a pretty simple idea. The documentation’s pretty self-explanatory. Where it gets hairy is the distinction between a caret versus a squiggly line, in terms of how you’re going to do your versioning stuff.

Because there’s a very subtle but specific difference there. And how to pull in different repositories or how to do more complex things. It gets a little bit hairy. But again, the documentation is all there and it’s all really good and I found it very useful.

And there’s enough people in the open source ecosystem generally that are using Composer, that it’s not terribly difficult to find answers to any questions about Composer. Most things you would encounter have probably been done by someone, and there’s probably some prior art that you can use to base it on.

So I think that it’s generally pretty good. And packagist is a great place to find stuff. What I will do when I’m looking for stuff is I’ll look on packages, even if I’m looking for a WordPress thing, just to see if, if that developer has pushed their thing to packages before even looking at wordpress.org, or pulling it in from the W Packagist mirror.

That means it’s getting a little bit, it’s like one step closer to the source, right? Because all Packagist does really, to submit a package on Packagist, here’s your pro tip. You have an account obviously, and then you just say, submit a package and you give it a GitHub repository url, and then it just looks at GitHub. And as long as the GitHub project uses releases, even if it doesn’t really need to, it just looks at the branches. But if it has releases, then you will have those versions. And if it doesn’t have releases you can still pull that stuff in using a dev prefix or whatever.

That stuff is all self-contained. It all exists. It’s all well-maintained, all that sort of stuff. That’s all good. Composer itself does occasionally get updates. The last big thing was sort of a transition from Composer one to Composer two. And that was a little bit of a, there’s definitely some growing pains in the transition process of going from one version to the next.

And then they threw a wrench recently, not super recently. But they threw a wrench into things a little bit where there is a new thing that goes into your Composer file called allowed plugins. So if it, if it’s a dependency is calling something else or whatever. You have basically have to give permission to other vendors to, install things on your behalf. So as long as you, if they’re in the allowed plugins list then those things will get updated, and if they’re not in the allowed plugins list, then it’s not going to update those things. And I believe that was for like, security type things.

That did cause a problem with you know, at Pantheon we have a lot of stuff that’s based on Composer and we don’t want to introduce merge conflicts. So if we have a Composer file, that is basically the thing that is used to build sites. And then suddenly that Composer file needs to have a new part of the Composer file, and we push that change. It’s going to cause a merge conflict with everybody’s repository that didn’t already have that.

So it’s a little bit of a headache for us, but for the user it’s obviously a net win. Those sorts of things give me pause a little bit, as somebody who is now at least partially responsible for, thousands of people running sites that use Composer. But in terms of like individual users and stuff, I think that Composer has a really good thing going and has a good ecosystem around it.

[00:38:16] Nathan Wrigley: Just to give us some insight into how you are using it. Your work at Pantheon and all the other companies that you’ve mentioned that you’ve worked at. Is this something that is just typical? This is just part of the process. Everything is built with Composer bolted in. Or is this something that you cherry pick? Okay, this one needs it, this one doesn’t. Is it basically everywhere, all the time?

[00:38:38] Chris Reynolds: When I was at WebDev, which admittedly is many years ago now, we didn’t use Composer. We could have benefited from using Composer. And I think they’re probably using Composer now. I don’t know that for sure, but based on the types of projects that they’re doing, and types of things that I see them working on, I think that’re probably doing it now.

When I was at Human Made, it was just there. Everything that we did had Composer as part of it. And it was a sort of a fundamental part of how projects were built. And obviously like Altis is Composer. It’s a Composer built thing. It’s entirely built on top of Composer. One of the things that gives it its stability, but also if you look at the documentation for Altis or things, it’s always lagging, and is always going to be lagging a little bit behind the latest WordPress release.

And for enterprise, that’s fine. Because they’re not concerned about the major or minor point releases. They’re concerned that their site is secure and it’s updated and it’s getting those patch releases. So with each new Altis version that typically aligns with a new WordPress version it sort of, when I was there anyway, the release cycle for Altis followed by a month or so, offset from the last WordPress release, so that they could make sure that the next WordPress version was part of the next Altis version.

[00:39:48] Nathan Wrigley: Okay, so should somebody have been interested in this, you know, their interest has been peaked by everything that you’ve been saying. Where’s some good resources? I’m looking at getcomposer.org and there’s a get started link right at the top. That seems like it might be a decent place to start. But maybe there’s more, how to describe it? Maybe there’s some things which would help a WordPresser as well.

[00:40:13] Chris Reynolds: I definitely would point towards the Roots Bedrock Project as being a really good place if you’re looking at wanting to have WordPress as built as dependency, I think they’ve got a really good framework. And at Human Made, we were doing that thing, but we weren’t using Bedrock. So it would be a little bit more difficult to come up with those ideas and that system and that framework independently. And that’s one of the things I think that you would get from the Roots ecosystem. So definitely yeah the, just the get Composer to learn about it and to look at the documentation, to dig into it.

And then from a WordPress standpoint specifically, I would definitely look into Bedrock to understand like how that works. And they’ve got a thriving community as well around that. And, a whole Patreon thing and Discord channel and whatnot, so that you can actually talk to human beings and get some amount of support.

[00:41:02] Nathan Wrigley: Yeah I’ll make sure to link to everything that you sent in my direction into the show notes. But, if anybody wants to check those out, you can see them on the WP Tavern website. Search for this episode, and you’ll be able to see all of those links there. If anybody wants to link to you Chris, if anybody’s been interested in, just think they’d like bit of a helping hand. They’d like to understand this a little bit more from, from the horse’s mouth if you like. Where do we find you?

[00:41:27] Chris Reynolds: Online I’m jazz sequence most places. Frequently jazz sequence with a three. So j a z z s 3 q u e n c e. That’s my Twitter handle and Instagram, various other things. I am at @jazzsequence@mstdn.social on Mastodon. And, my website is jazzsequence.com without the three, cause I like to, be confusing. And LinkedIn and places like that. But the Twitters and lately Mastodon, and those sorts of social places where you’ll probably get my attention.

I’m also, you know, on the WordPress Core Slack and like I said I live in Salt Lake City so, we haven’t had very many WordCamps in the last couple years. There’s some weird pandemic thing happening, but when those things do happen I often will try to visit the things that are, within driving range. I’m hoping to be at at US in National Harbor this year. So, maybe I’ll see folks there.

[00:42:16] Nathan Wrigley: Nice. Chris Reynolds, thank you for joining us on the podcast today. I appreciate it.

[00:42:20] Chris Reynolds: Yeah, no worries.