Composable WordPress

Michelle Frechette 00:00:02  Welcome to our very first ever WP Speakers Post Status Virtual Stage. I think I said in reverse order this time it’s it’s the same thing. It doesn’t matter. It’s so good to see you, Chris. Thanks for being our first person up. It’s always fun to open an event and you are the opener today. So thanks for joining me. I’m going to read your bio. So anybody who’s not aware of who you are, we’ll find out. Chris is a Developer Advocate at Pantheon. Previously, Chris has worked as a Senior Software Engineer at Pantheon, working on their integrations and open source software around WordPress. Has worked in WordPress agency settings as a Senior Engineer at Human Made and Developer Lead for Web Dev Studios. He’s been an author of online training videos for Pluralsight, a developer, project manager, and support technician at Event Espresso, a WordPress freelancer, and a Specialty Team member at Whole Foods. Though vegan, they can still be snobby about cheese and chocolate. Chris maintains a number of open source plugins and projects on GitHub, and WordPress.org has been involved in their local WordCamp and has been involved in their local WordCamp and WordPress user group in Salt Lake City since 2011. When not coding, they can most likely be found planning for their next Dungeons and Dragons session. Well, that is a bio right there if I ever heard one. Welcome, Chris.

Chris Reynolds 00:01:20  Thank you. Thank you for having me.Thanks for kicking off this this new series.

Michelle Frechette 00:01:24  Yeah, it’s exciting to me. It’s, It’s very exciting. I will say to anybody who is watching, I’m going to remove myself in a minute. Let Chris have the floor. If you have questions or comments and you’d like to put them in the chat, we will come and circle back to those. At the end. We’ll do a live Q&A, and commentary with Chris at the end. So, Chris, I’m going to add yours, your slides, and I’m going to remove myself. The floor is yours.

Chris Reynolds 00:01:49  Great. Thanks, Michelle, for that amazing introduction. My name is Chris. Today I’m going to talk about Composer and WordPress. A couple of my favorite things. and let’s get going again. My name is Chris. The Developer Advocate. Michelle told you all of these things, so I’m not going to spend a ton of time, on this slide, you can find me online. I’m jazzs3quence in most places. Sometimes there’s a three, sometimes there’s not. Depends on the platform. and, I kind of look like that, although maybe not, I don’t know. So Composer. Composer is a package manager for PHP. It’s platform agnostic, it’s open source, and it can widely be used to manage dependencies and projects that use PHP. It’s not exclusive. You can use it in conjunction with other things like NPM for JavaScript or Homebrew for Mac OS tools and libraries. But if you have been using older package management systems for PHP like Pear and Pickle Composer, sort of replacement for those. And if you don’t know what those two words mean, or think that pear is just a fruit, don’t worry about it because you don’t need to know them ever again. So package managers as a as a whole primarily solve dependency management problems. So when you want to manage and keep track of versions of dependencies that you might be monitoring or testing for problems, and you want to do that iteratively like NPM, Composer can also be a way to manage scripts, to handle things like automated tests and linting or build processes. So like NPM Run whatever, you can do the same sorts of things with composer. Now, like any other package manager, it’s possible to introduce security vulnerabilities into your code base by using libraries and packages that are no longer maintained, or if you’re not actively monitoring those dependencies and miss out on updates. WordPress itself is kind of a package manager because it’s got its own built in plugin and theme and core update system, and it’s the same rules apply there. If you aren’t monitoring or managing the updates to your plugins and themes and WordPress Core, then you might be introducing security vulnerabilities. Composer is run on a client machine, whether that’s your local machine or like a CI somewhere. So it’s possible for code bases to have disparate versions of dependencies depending on what your versioning rules are. When you last updated, that sort of thing. But it is worth noting that Drupal has been using Composer for ten years. Now I know it makes sense in its own way that WordPress built its own update system, as opposed to using a package management system like Composer the way that Drupal did. But I believe that using Composer with WordPress projects can greatly benefit teams and developers for all the same reasons that Drupal adopted it back in version eight. So why would I want to use a Composer and WordPress well, with WordPress today managing updates can sometimes be a headache. WordPress Core, theme and plugin updates might be handled manually. The reason why you might want to handle these things manually is because you don’t want to just have your plugins, updates, or Core itself blindly updating itself in the background in case there’s a conflict in your code that breaks your site. But just manually managing updates doesn’t necessarily mean that an update isn’t going to break your site. And if you’re bulk updating your plugins and themes, you might not even know what broke your site. So to avoid these sorts of white screens, your administrator or your dev teams might want to monitor change logs for all of the plugins on the site to watch for potentially breaking changes. When I was working at Web Dev Studios, we had a maintenance team, and one of the things that they did once a month was go through all of the updates of all the plugins of the sites that we were maintaining, and scan through the change logs to see if there is anything there that might break a site or might be worth considering. Even then, things can still break because those things weren’t sufficiently documented, or there might be changes or bugs that that were released along with the update, which then still requires that every update you do might still need to be tested manually before applying. And obviously, you don’t want to avoid updates because you’re afraid of breaking your site. Because outdated plugins and themes again, can introduce security vulnerabilities if they’re left unchecked. There must be a better way. Using Composer with WordPress allows you to let the robots do some of this work for you. Composer uses semantic versioning by default, so as long as plugins, themes, or even WordPress Core to whatever degree is using a major dot minor dot patch versioning system, you can apply broad rules that that will always update your packages if they match a certain criteria. So for instance, if you want to always get patch updates but not get minor updates to your dependencies. You can set your your Composer configuration so that those things will automatically update when you run an update and it won’t go past a certain version, and we’ll look at that in a minute. This also means that it’s easier to test those major or minor updates prior to deploying, and not sweating the small stuff. Projects that are not WordPress specific or not published in WordPress.org. For example, if you’ve got private plugins or generic PHP libraries can also be managed alongside WordPress itself and Core plugins and themes that are that are coming from WordPress.org. You can add linting and test suites, behavioral testing or continuous integration to your project to automate testing and ensure that you don’t ship any code that is breaking. So how does it all work? What does this look like? I’m going to go over here and I’ve got a empty folder with nothing in it. We’re going to just get the latest copy of WordPress, and I’m going to unzip that, and we’re going to drop into the Composer, the WordPress folder. And obviously that’s a fresh copy of WordPress. And my warp terminal already knows that I’ve done this a million times. So it just telling me what I need to do next, which is really handy of it. I’m going to run a Composer in it, and what this is going to do is it’s going to ask me a series of questions is basically like a wizard, and it’s going to step me through all the things to set up my initial Composer configuration file. So we’re actually going to call this jazz sequence, which is the vendor name. It’s me, and WordPress Post Status demo. Just a WordPress site with Composer dropped in. And I am the author. Minimum stability is a parameter that you can set the if you want. Usually it will default to stable just to get the latest stable version of things. But you can get like development or alpha or beta or release candidates. We’re going to leave that at the default. We’re going to call this a project, and I’m going to give it a GPL 2.0 or later license. Pretty sure that that’s the correct syntax for the license. There is a little bit, if you are going to publish packages, Composer packages. There’s a specific format for those. I’m pretty sure that. That’s right. I’m not going to define my dependencies yet. I’m not going to define dev dependencies yet. And it can also do Composer can also do auto loading. Which is nice. It’ll automatically load in PHP files. WordPress doesn’t really. WordPress has to be have a little bit of work, to to auto load things added. So we’re not going to worry about that and skip. And now it’s giving me a confirmation to say, hey, I’m going to make this file. Does this look correct? And I think that that does. So now I have a Composer JSON that is pretty empty, in my, in my WordPress repository. So Composer uses something called Packagist, which if you’ve used NPM or node, there is a NPM repository of all of the packages, for for node, all the node packages that you can, that you can install natively Packagist is that thing for composer. So by default I can do Composer require and get anything that’s in this Packagist repository. However, it does not natively support WordPress plugins because they live in a different repository. And for that there is a project called W Packagist, which is basically a wordpress.org. Mirror for Composer, everything that is in here, is just points back to the WordPress.org repository. So I could do a search for WordPress SEO. And it’s going to give me, Yoast SEO, right there. It just links out there and it tells me what the latest versions are. It says it’s active. That’s cool. So it’s basically, like I said, it’s just a mirror of of WordPress.org for Packagist. But in order to use it, I need to copy this code and put it in my Composer file. This is saying that it’s going to be it’s going to allow Composer packages from Wpackages.org of the package type W packagist plugin and W packages theme. And these package types are the same thing as like my package right here is a project. These packages on this repository are W packages plugins and W packages themes. All right. So right somewhere before the require I’m going to drop that that repositories line. And now that means that I can go over here and do Composer require. And I’m going to require the Safe Redirect Manager plugin. And it’s going to do some stuff. Presumably. All right. So what it’s doing now by default, Composer is going to drop all of its packages into a vendor folder. So you can see it’s already got Composer, a Composer vendor folder, and it’s got this installers package in there. and it’s trying to put something in W packages plugin safe redirect manager. Now what it’s asking me is do I trust the Composer installers. Composer plugin. And do I, to execute code? What Composer installers does is it understands things like that aren’t necessarily native, out of the box to Composer specifically package types like W Packages plugin and W Packages theme. So for us what it’s doing is it wants to it’s asking me, do I want to run this this code Composer Installers and what Composer Installer is going to do for us is it’s going to understand that W Packages plugins should go into the WP content plugins folder and W packages theme should go into the WP Content themes directory. And if there was a W Packagist just MU plugin, then maybe that would go into the MU plugins that there’s not any MU plugins on W packages, so that doesn’t really exist, but that’s what the installers could do. So yes, I do trust it. I’m going to say yes, it’s going to actually install the files, installed that package and that it also installed Safe Redirect Manager. I go into vendor, there’s my installers. It’s got a bunch of stuff there. That’s cool. but if I go into content plugins. There is my Safe Redirect Manager plugin, so it did the thing that I wanted it to do. I can also add a theme and it’s going to do the same thing this time. It doesn’t prompt me because it already knows that I gave it permission, and it adds that into my themes folder. And there we go. You can also do other things. I could do it if I wanted to add unit testing. I wrote a package called WP Unit Helpers. And what this is, is it sort of reimagines, if you’re doing unit testing, you probably copy pasted the installer process, for, for getting it from the WP CLI command. I wrote a package that basically standardizes all of that, so that I can recall it as a Composer dependency. So in this case, I’m doing require with the dev parameter, and that means it’s going to install here in a required dev section. And for this, if I do a Composer install with a flag pass to not install dev packages. So like if I was going to do this on a production server, then it’s not going to install the dev stuff. So this is only going to be installed in environments where we want dev packages. This is also a Composer plugin or has a Composer plugin as part of it. So I need to allow that. And it gives me a helpful little thing that I can copy in here because as I said, I can use scripts in Composer files. So now I’ve got scripts to run PHP unit tests I can it runs the install. All that stuff is good. I don’t have any tests, so I’m not going to run it. I can also install coding standards again. I’m going to do that with the dev flag. And what’s interesting about, about this is I’m only asking it to install Pantheon Systems WP coding standards. Right? But what it’s giving me is all of the dependencies of all of the things that are that WP Pantheon, WP coding standards requires, like VIP WPCS. It’s adding a Composer installer package, it’s adding a R2 sniffer, it’s adding a bunch of PHP compatibility and PHP compatibility. WordPress packages is adding all these things because all of those are part of or dependencies of my coding standards. And so it’s giving me all of that stuff. But all I need to keep track of is, is the one thing it’s probably asking me for for something. No. It’s not. Okay. great. Oh, it updated, and this didn’t. There we go. That’s why it didn’t show up there. So all I need to worry about is, Is this is the thing that I want. That’s the thing that I want. There’s some stuff that installs things that I want to allow explicitly, because it’s basically running code on your machine. And it’s it’s a security thing to make sure that you trust the code that’s being run on your machine. And then, and then the specific packages that are WordPress dependent. It’s worth pointing out, that in this case I have Composer managing plugins and themes, but not WordPress Core. WordPress is going to continue to update Core the way it normally does, because it’s not a dependency in my Composer file. All right. Let’s go back to slides, which I believe are this direction. Okay. So what might this look like in the real world? At Pantheon I helped build a Composer based WordPress upstream. And upstream at Pantheon is basically the template used to create the site. And in this case, like the WordPress Core and, and any additions that we might make on our end. And in this case, we want a WordPress site that uses Composer. The repository that we use for our upstream kind of looks like this. And you might notice that there is a pretty important thing that is missing from this directory structure, WordPress. There’s no WP content folder. There’s no WP include, just no WP any files at all. It’s just a bunch of other stuff. And that’s because WordPress in this, in this architecture is being managed as a dependency like any other dependency in the project, which means that rather than one system Composer managing all of your plugin plugins and themes like in the demo and using a different system, WordPress itself to handle WordPress Core updates, the WordPress Composer managed upstream handles everything together with Composer. The other thing that you might notice if you were paying attention to that screenshot, is that our upstream is based on Roots Bedrock. We chose Bedrock as a foundation for our upstream because it is a solid base for Composer based WordPress sites. It’s supported by a vibrant open source community. It has built in handling for MU plugins. You don’t need to do a loader thing. And it handles WordPress as a dependency of your Core project, Which was the most important thing. There’s another package out there that that also does a similar thing. We chose Roots because of the ecosystem around it. All right. So let us do another quick demo. I’m going to go into a different tab. And in this case I’m going to run a Terminus command. And Terminus is the command line tool that we develop at Pantheon. That just wraps around Pantheon stuff. you can run WPCLI commands through Terminus. You can use Terminus to do Pantheon actions. And in this context, I’m saying I want to create a site. I’m giving it an org. It’s basically my demo org. I’m giving the site a sort of a slug, and then the name of the site is going to be Composer Managed Live demo. And it’s importantly using this WordPress Composer managed upstream. So I hit that. That’s going to send it off doing a thing. That name is already taken, probably because I did that a while ago. I can make this demo two, and then that’s going to probably ask me to log in to Terminus, actually. Oh, good. I’m already logged in. Okay. So that’s going to take a while. I’m not going to, I’m not going to let this run. It’ll be running in the background. But what it’s doing right now is it’s, spinning up a whole new site. It’s determining whether it’s a WordPress or Drupal site. It figured that out, and then it’s going to start building that site for me. I can already just do a Terminus local clone of a site that I’ve already prepared handily. And this is literally just pulling down, from Git from the Git repository for this site. the demo. And then I’m going to the demo code, and then I’m going to CD into that. I’m going to open that in VS code. It’s going to open over here. All right. Get me set up a little bit. And then I can open my Composer file. And you can see this is already pre-populated. And it’s notably already has WP packagist or W Packagist, as a repository. So it already supports WordPress plugins and themes from the WP W Packagist repository out of the box. It’s already got a bunch of stuff in there. It’s got some Pantheon, the pantheon plugin. Pantheon Advanced Page Cache, Native PHP sessions, which are basically plugins that we put on. We suggest that be on everything the MU plugin is on everything, whether it’s composer based or not. It’s only got one WordPress theme 2022 that it comes out of the box. And then there’s a bunch of other things in here. But notably, this is the package that’s coming from Roots that is, WordPress Core. So I can locally do a Composer install to get all those things. And you can see that the vendor folder is already get ignored. It’s getting a bunch of stuff in there. And if I go into, web, that’s where my WordPress, stuff is. So WordPress Core is installed into WP. It needs to be in a separate directory so that it can be versioned and managed just independently of of other stuff. So WordPress Core files are in web app WP and or web WP. And the web app folder is where my plugins and themes and plugins go. So you can see there’s my Pantheon MU plugin. There’s a Bedrock plugin there. There’s the two plugins that we have and there’s our 2022 theme. So now I can do the same thing, right? I can do Composer install W package plugin, safe redirect manager. I don’t need to add, W Packagist at all. And it’s that’s because I did Composer install and not require, because I trusted, I trusted my command line tool to remember the last thing that I did, and it lied. All right, so when I use the write command, it actually does the right thing. And I go back over to plug ins, and there’s my Safe Redirect Manager plugin. I can require the Riu theme again. This is a theme that my partner uses on her blog. And you’ll notice that the Riu theme is not ignored. You can see the ignore thing. The ignore things are darker gray. The Riu theme is not ignored. It wants to install 90 files and the reason for that is because of our. Gitignore structure. So you do need to be a little bit more intentional about how you handle your. Gitignore. by default we’re ignoring everything in the uploads folder. Some we’re ignoring all the Core WordPress files. And we’re ignoring MU plugins, because we’re assuming those are going to be managed by Composer. Similarly, we’re ignoring normal plug ins, because we’re assuming those are going to be managed by Composer and we’re ignoring everything that is a 20 theme. But that’s the sort of extent of the generic rules. The reason for this is really because, if you’re building a site, probably you’re building a custom theme, you might not be using something out of the box. In this case, we’re just using something out of the box. So I would want to also ignore web app themes for you. And then that’s going to affect my theme there. That’s good, I like that. And then if I was going to develop a custom plugin, then you want to explicitly say, don’t ignore web app plugins. My plugin or whatever your plugin is called. So that that’s, so that you can commit that stuff to version control. Because the thing here is that this is also going to make it a lot, make your commits a lot, Smaller because you’re not committing an entire plugin. An entire theme, an entire package. You’re just committing, really If I go into my my changes, really, all I’m changing. All I’m committing is a text file. It’s just saying these are the lines of text representing these packages that are being that are being managed elsewhere, that, that are getting changed or updated or added. So custom code, my own code can get version controlled and committed to the repository. Whereas other stuff that’s third party code I don’t need to worry about. And that stuff can be managed with Composer. again, if we go back to Composer JSON, it’s already got some. It’s already got coding standards. If I wanted, I could also install my WP Unit Helpers if I wanted to add, unit testing. And in this case, I would want to just copy these lines because, if I scroll down to my scripts, I already have a bunch of scripts in here. Test is notably empty. I can replace that with the stuff from my command. And now I can run, WordPress unit tests. All right. Let’s. So. So I talked about how you can use this as a way to let the robots do the work for you. Right now, let’s talk about versioning. Right now, I’ve got WordPress is just taking any version. It’s got a star. 2022 is taking any version on the one dot branch because it’s 1.2 with a little carrot. That’s kind of what the carrot does. Same thing with my plugins. if I wanted to install 6.7.0, for WordPress. I could just do that. And what I’m doing, I’m not putting the little carrot before that, so it’s pinning it to that version. So if I do Composer update, which helpfully, my ID or my my terminal is suggesting that I do oh, it’s saying that, there’s something that doesn’t, that doesn’t match. I bet. What is that? That’s fun. I didn’t literally did not see that yesterday. Let’s try 6.7. Does that work? No. That’s cool. There’s probably some other dependency that is not support, that does not support WordPress. 6.70 I see it’s WP Config because WP Config. Oh, I see, I change the wrong thing. That’s what I’m doing wrong. If I use the right, tools. Then? Nope. If I use the right tools and I use the right commands, then the right thing happens. Okay, great. That was fun. Live demos. Okay, cool. So what you can see is that it downgraded a number of packages. It even downgraded, PHP code sniffer, which I didn’t even. Oh, no, it upgraded that. Never mind. Because I did an update. but what you’ll see is that it’s got WordPress 6.7,2. It’s downgrading it to 6.7. So now I’ve got WordPress 6.7. If I wanted to bump that up by one. I can do that. Composer update is going to go from 6.7 to 6 .7.1. That’s cool. And then let’s say I don’t I want to install or manage any version on the 6.7 branch. I don’t care about the patch version. I can do that. Like this. And that’s going to give me 6.7.2. Actually it’s not it’s not going to give me anything new. Cool. if I think I’ve got 2.2.2 so I can do that with Safe Redirect Manager, that’s not going to do anything. I will pin that to an earlier version and then we can. Yeah. So that’s 2.2. 2 to 2 .2.0. Oh, there we go. WordPress got updated from 6.7 1 to 6 .7.2. I’m now going to put the carrot in front of my Safe Redirect Manager version. So the key is like it’s the position, not necessarily the version. This could be whoops. This could be. Well, I’m not that one. I’m pressing buttons, and I don’t know what I’m doing. Okay. This can be anything. Except for that, it doesn’t matter, which version it is. it’s going to do anything that is just going to look at this position and it’s. And the carrot says, anything in this position, I’ll just pull down the latest that is available. So we’ll put it back to 2.2.0. It’s important that it has the dot 0, because if I dropped that, even then it’s just going to look at that position and update from 2.2 to 2.3 to 2.4. so we’re going to put that in there, run an update, and it should go from 2.2. 0 to 2 .2.2. Yep. All right. So that’s a little bit how versioning works. There’s a whole like there’s a whole rabbit hole that you can get into with versioning. But again this is, this is like if, if I trust that, the that this represents minor patch updates, then I can let a Composer update those things for me when those when those updates are available and not worry as much, and then focus my attention to when this version updates or when this version updates. And if I really want to be explicit and not not do anything, not update anything unless it’s explicitly tested. I could pin versions to, to specific versions that I trust. That’s the wrong direction. All right. So why bother using Composer with WordPress? Well, I believe that on the whole, you spend less time managing plugin theme and Core updates because you can be very specific about the types of updates that you’re just always allowing. When you combine this with a dev to test, to live workflow or like having a dev stage and production server environment, you can build out automation tools that use Composer, to test and test major and minor updates in development or test environments in isolation with CI or whatever prior to a deploy to live. And importantly, updates leave a paper trail in version control. Your old workflow might have involved ignoring large chunks of WordPress Core, or plugins and themes so that they can be managed themselves internally by WordPress itself. But when you update a version in the composer JSON file, that change is committed to your repository, so it’s easier to see and revert when there’s issues to see exactly what what actually changed. That’s the wrong direction again. So you can see again, like, I know explicitly, what’s being affected here. Composer has has changed for me, how I think about WordPress projects. And I don’t think I would ever go back to not using Composure. I use it on everything that I build with WordPress by default. I’ve been using Composer since I worked at Human Made, where it was a really big part of how we did our workflow and how we included packages, for, for site builds. And I basically just pulled that with me ever since, if you’re not using Composer based WordPress packages, I hope that this, presentation makes you consider using it for your next project. I’m always happy to talk about Composer with WordPress any time you can find me on the internet. Again, I’m jazz sequence in most places. I’m in the Post Status Slack. I’m around. And yeah, that’s that’s pretty much it.

Michelle Frechette 00:34:15  Excellent. Thank you so much, Chris. I think that was. I mean, I am not a developer. Like, I see screens that look like lots of code and my eyes glaze over a little bit, but this held my attention quite a bit. I’m wondering, though clearly Composer not for me with just basically one website or two websites that I’m working on. Who is it most ideal for?

Chris Reynolds 00:34:40  I think Composer for WordPress projects specifically works best in, like an agency environment where you’ve got a bunch of different people, and particularly when you’re working with a site, any site that has a development team that is managing or maintaining it because, in my mind, the distinction about, a Composer is that it puts the tools for managing updates in the hands of the people who know how to fix problems when problems come up. So if you let your, your site administrators or whoever or editors, run WordPress updates in the WordPress dashboard and a white screen happens, they’re not going to know how to fix that. But but if you use Composer, and you have a development team that’s managing those updates. They’re going to know how to deal with that white screen, or at least look for the logs and figure out what to do next.

Michelle Frechette 00:35:34  Yeah, that makes perfect sense. So small brochure sites, things like that. This is not something that is necessarily applicable, but you’re looking at large scale sites. That’s you’re going to you’re going to say but go ahead.

Chris Reynolds 00:35:45  Yeah I mean, I, I feel like it depends on, how how live or die your site is. Right? Like how important it is when the site breaks. but particularly particularly if you’ve got, like, a team of people who know how to fix stuff.

Michelle Frechette 00:36:05  So ideally you’re doing this to staging though? And then moving to production. Are you just doing this on a live site?

Chris Reynolds 00:36:12  you can do a bunch of different things. But yeah, ideally you’re running, you have Composer that, and like, there’s, there’s lots of different ways of running Composer because you can run you can do your Composer install and push up all of the compiled stuff to your site that could be part of your workflow. So like your compiled, your your compiled your the site that your the code, the server you’re pushing the files to has like what you have and compile locally. You can have a build step in the process like using GitHub actions or whatever. And have that stuff being done on GitHub. On Pantheon we have what’s called Integrated Composer, where, it’ll just do that Composer install for you if you’re using a, a site that, that uses Composer, it’ll, it’ll run that on the platform for you. So you don’t have to do it in your, on your local or on a build pipeline or whatever. So there’s different ways of managing it. and then and then yeah. Where like ideally it’s, it’s, there’s some sort of stating server probably, and there’s some sort of live server that’s getting the compiled things. But again, it can vary depending on, on, on what you want to do. And I do see there’s a question. Yeah.

Michelle Frechette 00:37:20  Yep. So Jason’s asking if there are good tutorials on building with Bedrock and Composer?

Chris Reynolds 00:37:25  Bedrock has a lot of really, really good documentation if you just go to the Roots io/ bedrock site. There’s lots of really good documentation there. At Pantheon, we have some docs on our specific upstream, to help you get started. You can also like, you know, get a free site on Pantheon and spin up a use the same commands that I used to spin up a site and just play with it that way. But yeah, I would definitely point to, to Bedrock’s own, to Root’s own, documentation on Bedrock, as, as probably the go to.

Michelle Frechette 00:37:59  And the comment confirming all environments share the same database.

Chris Reynolds 00:38:03  That again depends on architecture. So at Pantheon, we have completely separate dev environment, test environment, and live environment that have databases. And so we have tools internally that can move that migrate the database over from one site, from one environment to another. So you could use the same database, with a dev and a staging server. If that was, how you wanted to run things. That’s not specific to the Composer. Really.

Michelle Frechette 00:38:42  Awesome. And Brian says thank you.

Chris Reynolds 00:38:45  You’re welcome. Brian.

Michelle Frechette 00:38:47  Any other questions? If you’ve got questions, put them in the chat before we wrap up here in just a few minutes. Any, any, like, sage advice for getting started for somebody who maybe hasn’t done anything with this yet? Something that you might not have, commented in, in your presentation itself.

Chris Reynolds 00:39:05  I will say that that Bedrock, because it has sort of a different architecture. It can be a little bit daunting at first because if there’s like the web folder, there’s an app folder and there’s a WP folder and there’s a, there’s a config folder, and basically you’re not touching your WP Config file the way that you would be used to. There’s instead a, inside the config folder, there’s an application PHP folder. And then you can also have like different application for different environments. So you can have a application test, I think an application dev, that sort of thing. So it’s a little bit it’s a little bit different to get used to. But the flip side is, I know in my agency life I’ve written and maintained and managed a lot of MU plugins. And to do that, because my plugins are just executed, you know, as part of the WordPress runtime. If you have a MU plugin that’s inside of a directory or if you’re moving a regular plugin is and making that a MU plugin, then it’s not, it’s not going to automatically load unless you tell another file load this thing. And Bedrock, has tools. It has packages that just do that out of the box. So you can just drop folders in there, which is really handy because it’s one less thing I need to worry about.

Michelle Frechette 00:40:27  Yeah. Very true. if you’ve developed any of your own in-house plugins, can you just manage those exactly the same way through Composer?

Chris Reynolds 00:40:36  Yeah, exactly. You can you can either make those, you can either publish your own packages, which I’ve done, and you can either put them on W Packagist or if you put them on, WordPress.org, they’ll be in W Packagist. You can just put them directly onto Packagist. And there’s a number of WordPress plugins that do that. I know Yoast is one of those things, and Pantheon has put our plugins there. You can also do other things with Composer with like, defining, this, like where you want the source of the files to come from. So if it’s not published anywhere but it is on GitHub or something, then you can say, here is here’s where I want you to look for this particular plugin or like what I was talking about in the presentation. Like if it’s just custom code that is only for this site. I’m just committed to version control and exclude that from your Gitignore so that that becomes part of your code base. Whereas the third party stuff that you don’t care about or is coming from someplace else, you don’t want to be adding into your, your, your, you know, the stuff that you’re committing to to source control.

Michelle Frechette 00:41:38  Sure. This is probably going to truncate, but. Oh, no, but. Actually, I’ll get in there. Chris says “ Awesome presentation. I might have missed this it if it was already covered, but do you have any tips for keeping track of your packages and their versions per site other than the composer JSON file itself?

Chris Reynolds 00:41:54  Do I have any tips for keeping track of the package?

Michelle Frechette 00:41:57  I think that thinking about issues with accounting at scale.

Chris Reynolds 00:42:02  Well, I will say that, and I, I really am not trying to, like, make this an advertisement for Pantheon, but we kind of have figured this out. Pantheon has the concept of of. So I talked about upstream. You can also have a custom upstream. And a custom upstream at Pantheon is basically an upstream that you manage. And that code is then the code that you can ship to any of your sites. So in that way, if you’re doing this at scale, I might have a single git repository or GitHub repository for my custom upstream. I manage my dependencies in that, and that pushes out to all of my sites. And that is so that’s, that’s one way of doing it. I don’t know, like, I would have to reverse engineer that concept to apply it outside of Pantheon. I’m, I’m pretty positive that it would, that it could be applied just like you put a GitHub repository and that becomes your sort of source of truth, and you kind of branch off of that or fork off of that. But that’s kind of the, the, that’s how I would probably approach if I wanted to at scale, manage, versions for all the things and the, the, the bonus of that is that then if I have my custom upstream and I have a site that’s basically it’s like a representation of that custom upstream. I can do all my testing on that thing. So I know that my custom upstream or my, you know, my source of truth is tested. I’ve done all this stuff. I’ve got automated testing or whatever there. So I know that when I’m pulling stuff out of that, then it’s to all of my disparate sites that, that at least the base has been tested.

Michelle Frechette 00:43:46  And an added note. Love the gloves, by the way.

Chris Reynolds 00:43:48  I have really bad circulation. So, that’s what these are for.

Michelle Frechette 00:43:52  Are they on both hands? Do we get jazz hands?

Chris Reynolds 00:43:54  Oh, yeah.

Michelle Frechette 00:43:54  Get it jazz sequins hands. Yes. Awesome. And then, final comment “Yes, that makes sense. Thank you”

Chris Reynolds 00:44:01  Great, great, great, great.

Michelle Frechette 00:44:04  Awesome. Well, those are all the questions we have. All the questions I have for you. I do want to give you my gratitude. Thank you for especially being our first person on the stage and working through some of the the bumps as we get started with me. I appreciate your constant communication, but also your willingness to come here and share what you know on the stage. For people who aren’t aware, this is the Post Status, Post Status WP Speakers Virtual Stage Series. Mostly for those of us who have been trying to get talks out into the world and haven’t been picked up in other places, this is the place to do it.  So if you are interested in presenting here, all you have to do is go to poststatus.com. search virtual stage. We’re working on a new brand new site which will have better navigation, etc. So that’ll be a little more apparent later. But, or just message me and I will send you the link directly. It’ll also be in our newsletter every week. So, yeah, we’d love to have more people. We have about eight already for the next eight weeks all set up, which is pretty cool. But we are looking to add more people as we go. Again, thank you Chris so much for spending some time with us today and sharing your vast knowledge. Very much appreciated.

Chris Reynolds 00:45:11  No problem. Thanks for having me.

Michelle Frechette 00:45:13  My pleasure.