 Okay, thank you, Ken, for that. So, today, I'm really happy to be able to present to the backfrest community. And I'm going to be talking about how we can supercharge WordPress development using Bedrock. So, just to cover the agenda for today's session, I'll just kick off a brief introduction to myself. And then we'll be looking at what exactly is Bedrock. We'll examine some of the benefits, the drawbacks, asking the question should be Bedrock or not to Bedrock. And then we'll be looking at some of the changes that we can expect from a Bedrock install to a standard WordPress installation. And then we'll just go into a walkthrough of an actual live Bedrock project. So, as Ken introduced, my name is Gary MacPherson. I am a software developer by trade. I've had 20 plus years, mostly in web with a little bit of mobile and back in the dark days, a dash of desktop application and development as well, but we don't talk about those years anymore. I've been working with WordPress, for the last seven years or so. And over the course of my career, I've had a range of different roles, I've worked as a developer, team lead architects, CTO and co-founder at different stages. And currently I work as a consulting developer. I'm an instructor. I live in a couple of electric communities, and I'm into a number of junior developers as well. So that's enough about me. Let's move on to the subject of today. So, what exactly is Bedrock? I'm so sorry for the distraction, I just had a giant inset to come in my room, but I'll try and ignore it for now. So, Bedrock is a modern WordPress boilerplate that aims to improve the structure, management and security of WordPress development projects. So, one thing that's important to state is that it's not theme, it's not a plugin. It's more a framework that rearranges and reorganizes WordPress to follow more kind of best practices than the default application does. So, some of the benefits that we can get from utilizing Bedrock and some of the reasons why we're considering using it. It offers us very robust dependency management. It allows us to enhance the security of WordPress. We have improvements in our delivery workflows, and it offers us a cleaner structure. So, for dependency management, in a standard WordPress instance, you would typically handle your dependencies, what we call like plugins and themes, even WordPress core through the admin interface. You know, which will let you know when there are interface, when there are updates available, and then you would apply updates, or you may have a hosting platform that allows you to use automated updates and so you might do that as well. While these are convenient, they are not very robust, they can be quite brittle in a sense that an update can break compatibility and cause some issues, be it performance or functional in the site, and that's not something that we typically want in a production environment. It enhances the security of WordPress in a number of ways. For one, it strengthens the password algorithm, so the passwords are encrypted more strongly in our databases. It also helps with, I guess, security through obscurity in the sense that through some of the changes that are made, typical attacks that may look for the standard WordPress assets will not find them there. And it also allows us to handle configuration in a much more secure way, so rather than having configuration mixed in with our source code, it provides separation between those, which allows us to have greater security in our development workflows as well. When we say improve delivery workflows, what we're talking about is the ability to build a workflow to deliver the work to your client or to your team. So that means you can better support multiple development environments, you might have a local dev environment, pre-production or stage, and then a production environment. And being able to synchronize those environments and track the flow of work between them is much easier in a better based solution. And then the cleaner structure is something we'll look at later on, but better changes the default structural WordPress in a way that makes it easier for developers to understand and work with. So we'll be looking at some of these in a bit more detail as we go. If anyone has questions, feel free to raise the hand or throw them into chat. You don't have to wait till the end for Q&A. So if there's something that I go over that you're curious about, then please just alert me and I'll try and address it as soon as. And while there are a large number of significant benefits to using Bedrock, there are also some drawbacks or considerations that we have to keep in mind as well. So the first of those is strict hosting requirements. So as we know WordPress can be hosted on a very broad range of hosting platforms from shared up to, you know, dedicated through to kind of cloud based environments. So if you're using Bedrock that does tighten the requirements and so there are a number of hosting platforms that you wouldn't be able to run a bedrock based site on. You can have certain tools that may not be compatible because they're not built in a way that accounts for the variations that Bedrock introduces into the WordPress structure. So some of the tooling you work with may not work 100% with a Bedrock based project. There is a higher maintenance complexity and what that means is, while the default maintenance process that WordPress provides is convenient, but it's also potentially fragile. So Bedrock allows us to have a much more robust process, but it does introduce some complexities. So for example, if you're using premium plugins, it can be more effort to keep them up to date, then you might be accustomed to in a standard style. There are various approaches we can take to try and mitigate some of those complexities, but generally there's going to be a bit more overhead with your maintenance then with a default WordPress installation. And then finally, we do have a steeper learning curve to adjust to. There are a number of components are introduced by Bedrock which all developers may be familiar with. And so you may find yourself having to learn a number of different tools at the same time. You certainly will want to be comfortable or willing to learn how to use the command line is there's a lot more command line interaction, then you would be accustomed to in a standard WordPress install. But it does pay off in the long run in terms of how you can manage the products in the long run. But these are some things that are worth considering if you're considering utilizing Bedrock for any of your future projects. So then that brings us to the question of, you know, to Bedrock or not to Bedrock. And so there's maybe four factors that you can consider. There's maybe another one that should include here, but we'll go through them. So the first is hosting. And if the hosting platform you're using isn't compatible, or you don't have control over the selection of platforms or if you're maybe working for a client that's not willing or able to move from their hosting platform and that isn't compatible, then Bedrock isn't for you. If your requirements for the product that you're doing are mostly design or configuration where you're just sort of configuring a site, managing content, we're doing design work, then the overheads that Bedrock introduces are probably not worth it. So you're going to show its value for development projects and by development, I mean projects where there is a significant amount of custom functionality being built in PHP. So if you're writing code to any kind of extent, and not just, you know, maybe like a couple of functions in your theme functions file, but you're actually building functionality, then you should definitely be considering Bedrock. And in terms of the technical implementation, that's really just talking around the duration perhaps of that implementation. So if it's a fixed duration, if you are maybe building a project to deliver to a customer and then you're handing it over. And after that there won't be any ongoing sort of technical delivery. Then Bedrock again is probably not the best solution to go with. The value again comes from ongoing technical projects where there is functionality being delivered on a constant basis, your managing code and functionality, you know, in the indefinite long term basis. So if it's like a one-off project where you're building something to hand over or you're building it to then just maintain it, then again Bedrock may not be the most appropriate solution to go with. The fourth point then is deployment. So if you or your team are typically deploying WordPress using manual processes, if you're like pushing files via FTP doing maybe like plugging backups and stuff like that. Again, this may not be the ideal solution unless you're willing to move to a more modern automated deployment process. So if you do use automated processes or you're aiming to, then Bedrock is very well suited for that type of work. And then the fifth point that I could have added I think I mentioned before was simply around the, I guess, technical awareness of yourself or the team. If you're familiar with, you know, I would say command line, you know, manipulation, then this is a good sign because you'll be doing a lot more work through the command line than you may be accustomed to as opposed to going through the admin interface that this provides. So if you can effectively answer all of these questions with the answers in the green column, then you should really think about using Bedrock. It's probably going to be a good match for that project and it's worth giving a try to see if you can get the most benefit out of it. So let's move on to some of the changes that you might expect to see. So we have two examples of the structure of a standard WordPress site and a project that's built on Bedrock. So as you can see, there are some fairly significant differences in how they're arranged. So in WordPress, we tend to have a kind of flat structure with all of our core WordPress files kind of listed in our root directory. In Bedrock, it rearranges this to try and make things more logical and to introduce degrees of separation. So the first file that you'll see that you probably wouldn't expect to see in a standard WordPress instance is Composer.json. So this is the file that's used by Composer, which is the dependency manager to determine which dependencies and which versions of those dependencies are included in a project. So let's look at that in the walkthrough. Then we have our config folder and this holds the code that handles all the configuration of the application. So one of the differences that, again, I probably could have listed is that our configuration is actually handled very differently. In a standard WordPress instance, our configuration is managed through the WP config file. And one of the disadvantages of this approach is that if you want to move to using version control, for example, you would then be risking putting sensitive configuration data like database connection strings or API keys in source control, which is something we always want to avoid. So with Bedrock, it gives us the opportunity to separate our configuration. We also get to implement environment specific configuration so we can change configuration for our development staging production environments. And the actual configuration values are taken out the code base entirely. We can use .en files or if your hosting platform supports it, you can define environment values directly in the platform. And it means that your code and configuration don't mix as they do in a standard WordPress site. We then have the vendor folder, which is where all the composite dependencies are held. And then finally we have a web folder, which is the public root of our website. And that is then furlough split in two. So we have the app folder. And this is really where we have all of our custom code. So plugins, themes, the uploads, which is the renamed WP uploads folder. And then we finally have the WP folder, which is where all of the WordPress core files state. And effectively, we don't touch these files. So it's always been best practice not to modify WordPress core files. But in this arrangement, it kind of separates the files that we can work with being in the app folder and files that we shouldn't touch, which are located in the WP folder. So that's overview of the main structural changes. Then one of the next major changes is with how we handle updates. So as I mentioned, we use dependency management in Bedrock. And for that we use a tool called Composer, which is a PHP dependency manager. So in a standard instance, we'd go in the back end and it would alert us when there are updates available for WordPress or the themes or plugins that we're using. When we're working with Bedrock, we handle this process on the command line that can be automated, it can be integrated into your continuous deployment process. But it happens via the command line, so it looks very different to what you would be accustomed to seeing in WordPress by default. The next thing that changes that you would want to be aware of is how our URLs are managed. So by default in WordPress, there are two, I guess root URLs you could think of them as we have the home URL and the site URL. In a default WordPress instance, these point to the same URL, which is typically the root of our website. So if I have got a website at mysite.com, the home URL and the site URL both point to the same place. However, because of the separation that Bedrock introduces, we now have two different values. And this is where sometimes we have these incompatibility of our tools, or even with certain code that hasn't been written, I guess, to WordPress standards. So our home URL is no longer the same as the site URL. The site URL points to where is the site available, and the home URL points to where are the WordPress core files available. So because of the organization changes that we looked at earlier, the home URL now becomes site URL slash WP. So if I had mysite.com, my home URL will now be mysite.com slash WP. So Ken asked, would that be any command line or the WP command line. So when you're working with Bedrock, you'd be working with the general command line. The WP CLI operates within your terminal environment, whatever that is, be it bash, SSH, PowerShell, etc. So when you're working in the back end, you don't need the WP CLI to do like updates. You can run those commands because those are composer commands, and that's kind of separate to the CLI. So you would use the WP CLI if you were wanting to manipulate or, you know, administer the instance via the command line. But for kind of updates and updating the core managing versions, you can just do that through the regular terminal, you don't need the WP CLI for that. So those are the introductory fundamentals of Bedrock, and I didn't really want to spend my whole time just doing slides and presenting. So I'm going to do like an actual walkthrough. I don't know if anyone has any questions now before we jump into that, but if you do feel free to ask, you can just unmute or just put questions in the chat. Otherwise we can start having a look at the actual code base. I don't see any questions, so switch this. Okay, so this is an actual project. In fact, this is a project that I maintain. Built on WordPress and using Bedrock. I will just walk through some of the key elements of the project. So the one thing that I didn't show in the slides was the config and so I'll just give a kind of brief overview of how that works in practice. So typically we would have our WP config file and we'd have, you know, our database connection string, our source, etc. They would all be held in that file. As I say, Bedrock aims to separate those out from my actual code base. So what we have here is a file that will define all of those constants that we would typically see in WP config. And so here is an example of us declaring the defining the WP home constant, which you would be familiar with any kind of PHP or WordPress code base. So what we're doing is we are setting the value of the WP home constant to be whatever the value of our WP home environment variable is. So EMV is just loading a variable from our environment. And so the reason this is so important is that it means that we're not defining this value directly in code. So in this particular environment, where that comes from is this file called the dot EMV file. And you may be able to tell hopefully, you know what I mean. It takes a little bit of, you may be able to tell that the dot EMV file is grayed out in comparison to the ones around it. Because this is a version controlled code base that exists in Git, and we exclude the dot EMV file from source control so it never gets pushed away from my computer up to GitHub. And that's because this is where all of the details of our connections and databases exist. And so that's why we don't have that live. Let me not actually share that one. I'm going to bring across one. Yeah, I do that. It doesn't let me cause that is in a virtual machine so I'll just open it manually. It is in this example file. Okay, so this is what the dot EMV file looks like is this an example one. What we have is we're defining the database name user password. We would provide the path to our actual database. And then we have a number of other variables as well so here you can see that WP home value that we loaded into our configuration. So in this case we're basically pulling a previous environment variable. So here is the main name, and we're just converting that into a URL. And this URL gets converted into the constant in our code base as does our site URL. And so you can see the difference here. So we're taking the home URL and then we're simply append ashes is this is the wrong way around but yeah we are pending the WP point to a great location. So all of our values would be defined in this file and in production will have a separate file will be using the platform to define those environment variables. So this is a much more secure way of defining our configuration. And as I just quickly mentioned we do have the ability to specify specific variables for different environments. So for my development environment, I can override the debugging setting so that enables debugging. We have logging enabled if our environment variable is not set to false and the same for displaying. So we can have different configuration depending on the environment that we are working with. So that's how we handle our configuration. And then you might notice there's a bunch of these various kind of dot files we call them. So these are just configuration files for the various tools that are being used in this project. These are all specific to bedrock, but using bedrock enables you to define a kind of more robust and resilient kind of development workflow, and these are some of the tools that you may use alongside that. For example, this is a configuration file for tool called ESLint. So that does linting for our JavaScript. So any JavaScript content that we have, we can effectively key that JavaScript to match certain coding standards. And we can check when code is being committed that all the code being submitted is matching that standard. We have a version configuration. So this particular project is deployed to its production and staging environments using GitHub. So we can control when a deployment is triggered by effectively defining what versions should go where. So we have branches and I don't know if anyone here is familiar with Git, but it allows us to have multiple branches. And so by pushing to one branch, we automatically deploy to the staging environment. And then by pushing to our production branch, we can automatically deploy to our production environment. And when we deploy to production, we can update the version of the code. So we know if we have any kind of bugs or any support issues that arise, we know exactly the state of the code base for the complaint we issue that is being investigated. These are just a number of backups that have been generated. I'll have to clear up at some point, but using the command line, you can import and export database backups very easily. And so these are just various backups I've made a long way. If I need to, you know, handle migration or I'm migrating a site from one environment to the other, then you can create your own database backups very easily. And one thing that I will show is in our GitHub folder. So we are using GitHub to manage. And so I'll just give you a quick view of what that looks like in GitHub itself. So here's the repository for this particular project. So this code is pushed to this project. And we can see that in our tags, this marks all of the releases that have been deployed to our production environment. And so you can see the versionings. This is all done automatically through GitHub actions. And if I go to the actions, you can see the history of all the actions have been fun. So these are just recent dependency updates where we've had a plug in kind of automatically updated. So while we don't allow automatic updates to go through to production, we do allow specific updates to go to staging. And if there is a security patch that can be automatically merged and deployed to staging. But if there is a major version that wouldn't be automatically merged somebody would have to check it review it and then merge it to go up. So we're able to kind of control how our dependencies are managed to make sure that we're not causing any disruption to the website itself. And also have the ability to deploy a any version of the site. So if in the eventuality that we actually did have a bad deployment that went through to production, we can actually use GitHub actions to allow us to roll back to a specific version of the site. And that means that we can very quickly undo any problematic deployments. So if I was to push and then something's gone wrong, you know, as the bulk of the site has crashed. I come to GitHub and say, right, I'm going to go back to the last one good deployment. And that will roll back to the previous version, really very, very quickly. How are we doing the time I feel like I may have. Oh yeah, we're good with time. If anybody had any questions definitely feel free to share them. But yeah, we're good with time. We have about I think maybe 1015 more minutes or we're good. Okay. I don't know if anyone wants to see or ask about any questions or if one question. And I'm looking at this because you know is really robust and there's a lot of file structuring here. And I know you had mentioned kind of those prerequisites when it comes to what are some of the things that people might want to consider when they talk about possibly building a bedrock development project. Like any examples that you have that would show why someone would want to use bedrock over a standard WordPress build. Yeah, so for me the time and bedrock sort of comes into it so as I say if you are, you know, I don't use bedrock for every project because it doesn't make sense for every project so when it's, you know, maybe like customized as I mentioned customizations or design or work, you know, content, but we're not doing any ongoing or significant technical kind of functionality. Then, you know, there is this overhead of setting this up and you know making sure you have the processes to support it. But when you are doing that type of work, if you are, you know, delivering functionality on a game basis you are writing code you are working with the team if you're working with the team. So this is the type of process that you really should be thinking about introducing even if you don't use bedrock. So I'll give an example of a project I was introduced to a few years ago, the client had engaged two different developer teams so I think they'd engaged one. They didn't have capacity to do what they needed and then they engaged the second one. So when I came on board, the project was a shambles that you know there was no communication, there was a lot of non technical problems as well as technical problems. On the technical side, both teams were pushing up their work manually by FTP, and they were literally treading on each other's toes they were, you know, one developer would put up their work and it's literally conflicting or breaking with something that the other developers pushed there was no synchronization at all. So when I came on board like the first thing I did was like, you know, this process is completely broken. We're not doing this because this is just wild. And so I shifted the poll project to a structure like this, a bedrock based structure, and effectively mandated that everybody was going to have to be pushing up their work, forget and not using direct uploads as they were before. So that meant they had to issue PRs, code could be reviewed, there were issues for the work that was being done so we knew why work was going up and you could check it. And there was no way that someone could just push work up and break something because no one else was aware of it. So in those kind of situations this type of setup is just invaluable because otherwise you're just giving yourself a world of hurt trying to manage multiple changes from multiple contributors. Whereas having a git based workflow, even if it's not used bedrock allows you to have much more control over how that work is managed. But because if you are using git bait, I mean if you already have a technical team, if you have a git based workflow, then bedrock just fits into that very, very easily. So for example with this particular project, if as I may well be doing in the next couple of months, if I need to migrate it, this process will be a much simpler job than if I was kind of developing this in a traditional way. One of the things that is different and not bedrock specific is that this project uses S3 for all of the assets. So what would normally be in the WP uploads folder, all of that is hosted on S3. And what that means is that because this project is effectively built in the environment, there's very little in the code base compared to a normal installation. You have hundreds of megabytes or even gigabytes of content, you know, photos, videos, whatever. And in a traditional migration, if I want to change hosting provider, I would have to transfer somehow all the files, plugins and assets from one provider to another. With this type of setup, it's very minimal like it's literally I don't even have say if I was to show you in our web folder, you would notice, we don't even have the WP folder. So in my local instance, in the web folder, we have app conf and WP. So this is where the core files are. But again, you can see this is a great out folder because this is a folder that is effectively built by Composer. So everything in this folder is not in source control. It's not in GitHub, which is why it doesn't exist here. So the code base is actually very, very minimal. And in order to set up a new environment or to even transfer to a whole new hosting platform, I don't even need to do any manual transfer. I would update the actions here to point to a new host. So I would point it to my new hosting environment. I would set up the environment variables in the environment, and I would deploy it via Git. And that's it. And then it would literally rebuild the site, reconnect to S3. Everything else would get set up in the new environment. And that's not something you can do without a kind of framework like this. So I guess the answer is this is better suited for, I guess, heavier projects where there's this kind of, you know, level of technical involvement. And that's where the value kind of comes in. If it's a lightweight kind of, you know, we're going to make a few changes here and there, then kind of implementing these kind of structural changes probably don't have the payoff that would justify the effort. And it definitely sounds as if when you're looking at something, I mean, and like you said, it doesn't have to be bedrock, but if there's something along the lines of potentially being a heavily demanding website that requires a whole bunch of complexities and a whole bunch of various, I want to say, technical departments, but different developers who do different things than it probably would be highly recommended to do something like GitHub contributions as well as using something like bedrock that can help to mitigate what goes up before it reaches production. Yeah, so I mean I this is my own kind of I guess side project and so even before I had other people collaborating. I managed my own projects like this because just because of the technical for me that's the primary thing is like, if it's a primarily technical project, then I don't, I don't work with code that's not source control I would never work with code base I don't even work with developers that don't like I can't do that like for me if you're building a technical project you your coach be version control full stop. And so if I'm working on that type of project where there is ongoing technical delivery, then I will use this kind of setup, even if I'm the only developer. It makes even more sense is the value to multiply it when you have a team, but even as a solo developer the benefits of having version control. It's a automated deployment. Once you have gone through the pain of setting everything up. And you know right now I'm working on the next project and each one becomes easier because I'm just reusing elements I've implemented in previous ones, but once you have the setup. After that, you know it's just constant pay off. So you have to go through that kind of climb that wall of getting running the way that you want, but once everything is configured. It's just pure productivity benefits all the way after that indefinitely as long as you're maintaining that project. Anybody else have any questions I don't want to prolong any time and I don't want anybody to fill that out. Is there anything else that you want to share. So, I guess I would just talk about so I don't know where from his but those that may be watching later on so, for example, another of the benefits around team based development. You know, I've always been a bit of a stickler when it comes to like coding standards. I love, you know, well format clean code and so I will make the effort in my own code to do that even though I'm not working with anyone else. And so you have the opportunity to do that as well. So for example, here we have this file called the editor config. So what this file does, it allows anybody who works on this project to have their editor set up in the same way. So, I don't know if you're kind of developing you've worked in a team before you know that over the years you may have had conflicts where, you know, one developer has their editor set up to use tabs, another one has their itself to use spaces and so, you know, one person checks out the work pushes it up and then you've got a whole bunch of changes that are nothing but workspace because they're going to have their editor set up differently. So you can introduce things like this where everybody who checks out this work will have the editor configured in the same way. So there's no more debates or arguments about how should we use tabs should we use spaces that is just takes care of it and you just, you just write your code to write about how it's going to be formatted or whatever else it will take care of for you. So when you're dealing with kind of I guess larger or more involved code bases, making sure that the quality of code is as high as possible, and this setup fits in very well with that source of requirement. So that as well. So anything else. Oh, I did say so with the composer so I didn't mention how we manage dependencies so this is the configuration file composer, which controls how we manage the dependencies that are part of this project. Over most of the stuff. And now these are defining where we're getting all of our code from, but the most interesting part is here. So this is the require section, and this defines all of the dependencies that make up this particular project. And so we have development kind of components in here. We have the. So this is WordPress core. So we're actually loading this. This is why the WP folder doesn't exist in the source because we're actually loading WordPress itself as a dependency of the project. So rather than having WordPress code directly loaded into our source control, we're simply loading in the files as an external dependency. So right now we can see that this particular projects is set to use with a six dot six dot X, and currently it's got with a six one one. And so it allows us to define. So this one needs to get updated soon as well. I think we're behind now we should be on six point two at this point. So this project will need to be defined, updated soon. And so here we have a number of other kind of plugins that have been loaded. So, and we can see the versions that are being installed for these. So here's where we're defining the various plugins that are being used in this particular site. And if at any point we need to change. So for example, if I really wanted to, I could revert this back to version 5.5 by changing that value and then I would run composer update, and it would roll WordPress back to 5.5. So if you don't want to do that could be, you know, I might be debugging an issue. I mean, I don't know why I go back that far but I might need to go back to 6.0 for a previous version, and if you need to do that, you can. So you can control the version or let's say for example, we might have a plugin that's been updated to the latest version. So if the version includes a breaking change, then we can change the version to fix it to a safe version so let's say 4.2.8 kind of broke the site. We're like, we don't want to have that so we need to keep it at 4.2.7. So now I can force it to remain at that version until we know that there's a safe version that's been released and we can update to that. So we manage the dependencies that we're including and the versions of those dependencies. And then we say I should go over. So this is how we now handle a lot of the technical side of things so we have these scripts that we can manage how the project behaves. We have these details but this is when we are whenever you run an update so whenever we update the dependencies, we can define specific logic that has to take place. So in this case whenever we do an update, I make sure that we've got a custom site specific plugin, and we make sure that that is updated. We also have a script that handles some issues with the hosting platform and so we take care of that as well. So we have a lot of control over the logic of how deployments are actually initialized and managed. It all looks quite alien when you see it was the first time but again this is part of the control that it gives you over the project. That's mostly it. Oh, we do have the ability to generate change logs. So when we are handling our updates, we can actually view the changes over time so these are also generated automatically. So we follow a specific convention for how our changes are committed and those messages are converted whenever we release the production. Those messages are now committed and generated into this change of so we can literally go back to the history. We can see what was done at any one point so this particular release had a new feature and we can actually link to that PR order commit on GitHub. And so we can see the code that was changed for that particular feature. And then we can look at bugs that were fixed so we had a couple of bugs that were fixed here. It also labels any PRs or issues that were closed by that bug being fixed. So it gives us this nice history of all the changes that have been made. This is something that's nice for this project but if you are building, you know, a plugin or theme for public consumption, this is like so useful because it spares you having to manually generate this change log it can be done automatically. And this is an example of where that initial effort and setting up just pays off constantly down the road. So yeah, that's how the change log gets generated. Yeah, I guess I will leave it there. Hey look here I would absolutely tell you hey this is really really impressive stuff man and I tell you I'm gonna have to find a little time to look into bear I can just you know tinker with a little bit and probably share this video and reach out to you personally just to kind of give more insight on how to get this done because this is great. And I definitely want to thank you for sharing this information. Before we close up shop for today. If you don't mind share where people could find you how to access you and how they can learn more about you and how to you better. Yeah, so I guess probably the best. Yeah, I'll probably drop some links in the slack later. But the best place to find me is probably LinkedIn. So, let's go to mine. So you can find me as Gary MacPherson LinkedIn. Not too difficult to find I don't think so finding me on there is probably the easiest thing. I will definitely share links for the different components that we've discussed so bedrock itself. Composer local. I didn't even show my local development tool but yes I'll share those links in the slack as well. And I can probably provide like a PDF off the slides if anyone wants those later as well. Yeah, if you want to connect with me feel free to find me a LinkedIn. If you're a developer type feel free to put me up on GitHub. I'll share that as well. So that is, I'm just Jean. So you can find me on GitHub. I came at first and my username is genius with a YG and why us. So LinkedIn or get up feel free to let me up and happy to connect. And again, thank you so much Gary. Again, Gary MacPherson appreciates you so much for sharing this training on using bedrock or to supercharge your WordPress development. Again, hopefully here in the near future we'll have some more webinars trainings for within the WordPress black press community so definitely be on the lookout for more of those. But at this time I guess I'll go ahead and stop the recording and thank you so much again Gary for sharing your information your knowledge. No problem. Yeah, glad to help. And if anyone wants to follow up feel free in the black press slack so reach out to me on any other channel. Happy to connect. All right, thank you again. All right, thank you for your time.