 If you would like to follow along, I just tweeted a link to the slides because that's easier than giving you some random string before a bitly link. So you can follow along with the slides there if you like. I give you some kind of basic code examples in the slides. It's not too much for you to read, but in case you'd like to follow along or see the code examples there, you can. In fact, I've never said this before. I started this talk before because I get to talk to a lot of people about this. But I will say usually the most interesting part of this presentation is not actually the presentation itself, but kind of either the questions that come after or just kind of the questions that come after the event, talking to someone else about this concept later on, different things like that. It's just kind of a new way to look at some of the ways you do things with WordPress, and it tends to kind of create just interesting perspectives and questions afterwards. So I don't expect this to be bad per se, but just a little bit more like my goal here is to introduce you to a concept you might not have thought about before and show you how it can work and that it does in fact work and then kind of let your wheels spin a little bit more. So we have one really big idea that I'm covering, and it's pretty simple, but walking through some of the details of it will be fun and often use confusing language and things like that. So it's important that we remember the big idea that we're talking about. So when we talk about multi-tenancy, which I'll cover in a second, is not multi-site. Multi-tenancy is multiple independent instances of WordPress running off one non-hacked core directory. And I'll also show you how to share one non-hacked directory of plugins, of themes, of must use plugins as well. So nothing groundbreaking. If any of you have worked in software that's not just WordPress, this is in no way a new concept at all. But WordPress gets very insular and a little bit of a bubble, and sometimes for whatever reason we don't talk to people who write other types of software. And so this isn't a super prevalent thing. I will also explain why possibly you may not have heard of this before, or if you do go looking for it, you'll see that it used to be highly nerdy, difficult, and very technical, and that's not really so much the case anymore. But just a couple of big high-level examples of what this type of thing can do. Not only does this kind of just reduce the general footprint that you're putting on a server by having redundant files on the same server over and over and over again, doing the exact same thing for different sites, but it also really ends up speeding large-scale scripting and other types of that thing up pretty dramatically and making it a lot easier to deal with and a lot simpler to roll back changes you might not like or push changes you want to test out. So for instance, on Friday there was a WordPress beginners workshop, not the designer one, not the developer one. I think it was called Getting Started with WordPress. And so multi-tenancy was used for that, and I spun up a hundred websites in a matter of seconds, basically, using a random string that would be generated by an Excel spreadsheet or something, just like Atlanta one, Atlanta two, take a string of text, throw it into a script, spins it all up, never has to install WordPress because it's already there, and all the sites are there within a matter of seconds. Just a lot more tenable, no nerdy pun intended when it comes to handling kind of larger scale items like that, and that's relatively small, but makes a lot of things like that easier. So I'll talk about deployment and scripting a little bit later, but that's just one useful scenario. I will cover, Russell mentioned, a side project. I'll tell you a quick story about this, but before I do, I want you to know, if you're in this room learning about this right now, you are definitely not the target audience for this concept. So this is in no way a sales pitch because if you're a developer, you shouldn't be doing anything like this. So this was originally a side project for me called Evermore. That was a way for me to deal with lower budget clients who had basically priced out of my contracting work over time. You do a good job with people. They come back to you three, four, five years later and they want you to do more work. I was really too expensive for them by that point. So I was trying to figure out a way to really design the entire website creation process for super low budget nonprofits and businesses. People who really didn't need a $20,000 or $30,000 website project from an agency and needed to take six months and all that. A lot of times people just need a decent site that works on a phone that loads really quickly, that has a place for content, that is readable where you can click on things and they work. And so the concept behind that was not only did I want to kind of design the process, but I also wanted to design the architecture and that's where I started playing around with multi-tenancy because it made a lot more sense to me to have hundreds or thousands of websites using the same core directory instead of installing it a million times and having to use Jetpack or some other tool to directly update and manipulate all these things individually or every time you go to update a website and use that tool and wait for it to do this really slow thing over and over again for every site. Instead, every site in an instance that shares the same WordPress directory can be updated in usually under a second because you're using the same directory. So the point in bringing this up is not only to tell you where I started experimenting but to also tell you this concept works at scale pretty much flawlessly. It's very easy to use. It's honestly really fun to work with. I just wanted to present that idea to you so that you know this isn't some chimzy concept that I just came up with that I'm pitching you. This is something that works in the real world with People's Production websites that produces, when configured correctly, very fast, very easy to deploy websites that are really easy to manage at scale. So why did we use multi-tenancy instead of multi-site or separate standard installations? Multi-tenancy can offer you a few different types of advantages. And as I covered earlier, obviously, a smaller footprint, less files on your server and different kind of tangential improvements like that. You may not care that you have less files on the server and that's fine. All of these things, again, are pretty microscopic until you start dealing with them over long periods of time and deploying them for a lot of websites at once, after which point it starts to become increasingly advantageous and a little bit more fun. So a smaller footprint on the server, faster code deployment because you're only deploying to one place instead of all the places. Easier updating processes all around like I just mentioned with WordPress, one directory is obviously a lot faster to update than a ton of other ones and if you do it right, you don't really have to go through the whole built-in WordPress updating process. You can just update it from source control or something else like that. And then additionally, which I'll cover, using single instances of themes and plugins means that if you have 5,000 sites on a multi-tenant installation, not that you should, per se, just saying, if you have all of them in one place and they're all sharing themes and plugins, then think about whenever a breaking change comes to a plugin or, excuse me, maybe a plugin broke, there's a security update, there's a fix that's in there and all the sites are down until they're there. Well, when you only have one place in which that file lives, you update it once and then all the sites are fixed at the same time as opposed to having to deploy that update to each individual site, finding out one of the updates broke, not being able to figure out which one it is and doing that whole process. And because you're in one place, you have the benefits of version control sitting right where you want to. So if you push something out that you didn't mean to, version control means you can roll it back for everything, again, usually in under a second, depending on how big that repository is. So everyone gets updates at the same time, far easier to deal with and this is a slightly controversial way to look at it, but I'm going to also present this with as much context as I can. The GPL and then paying people for things is complicated sometimes because basically you have every right to do anything you want with the code that you can and no one can take that right from you and so usually what you're paying for is support future access to code updates and different kind of ways that we can finagle the GPL. A lot of people will sell you multiple instances of a plugin. You only technically need one instance when you're using multi-tenancy and sharing it with all the sites. So that does not negate or change any licensing agreements that you have with anybody, 100% of the time that I use a premium plugin in this environment, I talk to the developer first because I want them to understand what is happening and how it's humanly possible to be able to basically deploy this to a ton of sites and yet I only need one place where the code is updated and then in the case of Evermore, we kind of white-label everything and so no one ever contacts the plugin developer, so there's only one person that would ever ask for support and then if a bug occurs because of multi-tenancy, I fix it before I get in touch with anybody. I don't usually ask them to fix it on my behalf, so just kind of an interesting thing to bring up when you only have one actual instance that needs to be updated and so it just brings up some interesting points but so these are some benefits and some reasons it might be worth looking at. Again, it's kind of a method of scale at this point, so another thing we'll bring up, note that this is totally and completely different from multi-site. There are a couple of reasons I bring this up, one because the words are really similar and people just think that's what we're talking about and then they end up in here and then they're very disappointed that we're not talking about blogging or something, so not only are the words similar and they can get confused but also it's confusing because the benefits that multi-tenancy can offer you when done well are often the benefits that people are trying to extract from multi-site. So a lot of times people will talk about only having to update plugins and themes in one place, being able to have these different kind of benefits that multi-site is not really designed to do. Multi-site is designed to create a network of websites and so if you fit the criteria for wanting to use multi-site and it being built for your use case you definitely use it. But some people try to use it often to kind of sidestep the process of having a bunch of websites where I have to update all the different plugins and all this stuff. That's not really what it's built for and so even if that works for you that doesn't mean that that's what it's going to do well in the future and that may be another place that multi-tenancy could benefit you if you're interested in looking at it. The big differences though between this and multi-site, again the big idea was multiple independent instances of WordPress running off one core directory. In multi-site you don't have independent instances for each of those sites. They're usually all in one giant database in different tables laid out in different ways and so if you want the kind of secure walls between websites that independent instances offer you that may be something you can do with either again traditionally a ton of independent WordPress websites or that multi-tenancy can offer you because the things that it is sharing amongst the sites are not the sensitive parts. It's not sharing databases with other websites. It's sharing code, code that's common to all the websites and so you're able to have those walls of security so to speak between them that multi-site doesn't offer you because you're cramming everything into one table. Additionally, this is getting less and less I think over time but sometimes you'll have trouble with multi-site in using certain types of plugins with them if they don't have multi-site support or they haven't really thought about it you might find a hiccup with it. I find that those are generally harder to deal with than any hiccups you might find through multi-tenancy. The cool thing about finding a bug by using multi-tenancy or by putting WordPress in a sub-domain which we'll talk about is one they should be able to support that anyway because that's a supported way to use WordPress and two, it's generally a matter of just assuming that files are in a certain place and so it's usually pretty easy to fix just by helping the developer use the right functionality whereas with multi-site you might find yourself in a rabbit hole of hell that you don't feel like getting back out of and so that's just kind of the case with that sort of thing. So the other reason that can be mentioned a little bit less now but I think is still interesting is that as I mentioned when I developed the concept for Evermore before it turned into a business that other people run much more than me at this point and they're doing a great job the other thing I wanted to do when I was building for those low-budget clients is I never want to trap them into a scenario where I can't get their whole website back out and hand it to them and say go take it to another web host or another developer and be free you know use the power of WordPress and GPL and all the good stuff and never be trapped into the way I decided to do things until I think really just a few months ago there was almost no good way to pull a singular website out of multi-site and have it be a standalone independent WordPress install that a common person so to speak could take to another host. You might do a lot of coding and a lot of rejiggering to figure it out but that really wasn't the fun thing whereas with multi-tenancy again everything's independent and you're able to easily take database and other things like that out of there and provide somebody with 100% of everything they need to go to a different host as a side note in case anyone is interested on the fringes here what I was saying about two or three months ago I think an awesome company called Delicious Brains who writes really great plugins and other blogs and things like that came out with a plugin designed to extract sites out of multi-site never use multi-site for reasons that it was not intended to be used for but if your use case is being able to use them in a network and then wanting to pull them out to individual sites that sounds like a really great plugin to use that didn't exist and again the concept of something not existing and now being easier is kind of a common theme throughout this so anyway that's something to definitely check out if that fits your use case so another thing to cover on this is that if you start Googling around this multi-tency you will find a lot of very bad ideas very bad ideas dumb ideas just like useless kind of ways around the problem to make this work that usually involved doing something very hacky or just being overly complicated so that's why I want to kind of lay the context of why this may be a newer concept even though it's been worked on for at this point probably ten years as far as I can tell in some different use cases especially at higher levels more commercial and enterprise level clients one of these is that SimLink plugins began being supported in WordPress 3.9 prior to that actual multi-tenancy for things like plugins was very iffy because this whole thing as we'll see in a second relies on symbolic links saying we're going to call we're going to have a file that's named the folder you're looking for but we're going to tell you that the actual files are over here this whole concept was pretty broken until 3.9 and so attempting to use it especially for plugins was a big risk at that time so when that came out as supported and I remember that because I was experimenting with a patched version of Core even though I didn't want to because that seemed a way to make it work and then I was able to watch that ticket actually get pushed in my life a whole lot easier so that's one reason that things are a lot different and one reason why the things you might find in a Google search might not be relevant anymore because you don't have to use the workarounds second within the last several years be it just the availability of the WordPress mirror on GitHub and the prevalence of Git or WPCLI different things like that where command line tools have become far easier to use for WordPress far more prevalent in our deployment processes this has made multi-tenancy a lot easier because it used to require some interesting debugging on the server level and some interesting ways of kind of dealing with the different problems you've introduced through multi-tenancy so again these are things that probably would have been easier back when people were beginning to experiment with it five to ten years ago and reasons why you should look at the post date when you're reading something about multi-tenancy another side note of a side note of a side note basically at this point WPCLI has some interesting behavior when using WordPress in a sub-domain I have seen it work I've also seen it break terribly so if you're planning to put those things together just kind of be aware of it and be prepared to experiment hey Mike yeah yes absolutely and I think I mentioned this a few minutes ago and may even mention a little bit later as well but yeah bugs with multi-tenancy tend to be there in the form of either symlinked plugins not being appropriately supported somehow or just people assuming that things are in the wrong directories and things like that I've yet to come up against one that I couldn't easily fix by simply following the WordPress coding standards and then submitting that back to the developer with a very sarcastic smile but a hug also so yeah so those have been the kind of interesting pieces of context around this concept so enough about the asides let me show you kind of how it works again this is the way that I have implemented it I am not the authority on this I'm just a person presenting about it at WordPress or at WordCamp and people haven't talked about it too much and I feel like it should be discussed and so that's what I'm doing several people Mark Jayquith, Eric Mann and several other people I've seen work specifically on multi-tenancy concepts and published their work those are people whose work I looked at built upon and drew inspiration from even though they were working on it years before that so anyway so this is the way that we run it and the way that works right now so each site that spun up in its own directory has this sort of a structure right now so you'll see instead of your usual root directory full of wp-things instead you have an index file a config file you have a sim link to WordPress in a sub directory I'll break all of these down but a sim link to WordPress in a sub directory so again that's our single non-hatch instance of core and then we have you could use wp-content I've always hated that folder name being in the URL so I changed it to content so inside of that we have an actual content folder and the inside of that we have an actual uploads folder because if you think about it the only things that are truly unique about most WordPress websites are configs to get to the right database the database itself and then the uploads those are never shared among sites and so those are the things that need to be unique in most of these cases all the rest of these yet again are sim links are folders holding all of the stuff we need for all of our sites so telling it look over here for the directory full of plugins full of themes full of must use plugins and different things like that so I'm obviously not showing caching configurations and different stuff like that but I wanted to keep it simple to explain the concept and then also yeah go ahead how would you set up child themes well it actually wouldn't work any differently than the way any other site would instead you would just have your actual child theme would live wherever this folder is but this yet again in this case where you are in fact sharing themes and plugins and all that you would need to be okay with either everything in these folders being accessible to all of the sites or inside an MU plugin that we run essentially DQ plugins and themes we don't want people to see conditionally based on packages, domains, whatever else is there so you've got kind of an interesting configuration but yeah everything would live inside the same directory in that case so yeah so that's kind of a good thing to bring up is even though I'm showing you in this case how to share themes and plugins amongst all of the sites you have are by no means limited to this type of structure if you want to create a unique themes folder for everybody but share plugins with all the sites do that only have the sim link for plugins and have an individual unique themes folder for everyone else you lose some of the benefits of updateability in that case but if you're maintaining everyone's theme and you're keeping it pretty simple you don't want them to have access to the other ones you can do it that way so yeah there are a lot of ways if you want to run an individual MU plugin and not have everyone share the same one just create the folder itself don't create a sim link so the biggest idea in this again is the sim link to WordPress itself which should not be unique for all of your individual sites so far as I can tell the other thing I'll bring up real fast before I show you the rest of a little bit of this code there are some assumptions that I'll explain for each one of these just about the way servers can be set up about nginx versus apache things like that quite honestly if you know what you're doing in a server you're going to know what I'm talking about and you're going to know what to be careful with and how to experiment if you don't you're going to have a very hard time doing this if it doesn't work exactly right the first time doesn't mean you should give up it means that you shouldn't try it in production the first time you ever tried because it's interesting ok so what's an index.php well this so there's an index.php inside WordPress itself right but inside of our site directories we're not actually touching WordPress so we have our own index file and it's telling it to look inside of our sub directory for the blog header which just kind of like pulls everything together and gets things started for us on WordPress so all this is doing differently is telling it to look inside the different sub directory where we have WordPress and the site is in a different directory entirely so not too much different going on there some examples of things that could go on inside the config file again these are where a lot of your assumptions are so some of these assume that the directory you're serving it from is named the domain that you want to be using from the site I'm using it for example purposes here but you can kind of understand where I'm going with it basically making sure that these configuration options are set up properly so that WordPress understands we're in a directory but we're looking for WordPress over here and then in our case here look for content in a folder called content instead of wp-content and so with the two most confusing configuration constants ever in WordPress WP home is telling us what the domain is and WP site URL is telling us where WordPress is and the site URL is because of things so that's all I got there again so all this is telling WordPress in general is to look in the sub directory for the WordPress core files and then here we're just kind of clarifying where to look for content if you change the name of the content just trying to share as much as I can again I don't know I still don't like the way the wp-content folder is named and that's about it so yeah let's see what's in there um now we use a cdn for uploads so the uploads folder is mostly there for backup if we want to keep it it's also there for plugins that don't hook in to uploads quite the right way but we don't know about it and so they don't know how to get uploaded to the cdn automatically with whatever we're using but again regardless of whether you do that or not the uploads directory is real and it stays as is so you just need to make sure you have the right permissions and all that for it nothing really changes about that the other sim links point to single directories on the server containing one copy of the themes of the plugins available on the site so the way that we do this in particular is that the directory that has MU plugins themes and plugins in their own three directories that whole repository there is a single source controlled repository so that's used on all internal development and staging servers everything is updated in one place so your commits are pushed to a single repository after they're tested and lented and whatever else they're pushed out to deployment and this is really great because as long as you do your commits and updates thoughtfully and make sure you do it in the proper types of chunks that can be easily rolled back and understood if something breaks it's really nice you can update things on a regular basis as soon as they need to be updated you look for either you can update them all at one time you can update one plugin at a time whatever push those commits up and then push them to your deployment situation your servers whatever it is you want to do and they're all there if you push up I don't know a major release of Yoast and it totally breaks which would never happen then you can immediately roll it back if you've done your commits well right and it's almost instant because then again you're sitting in source control deployment situations and all jokes aside like even easier than that is maybe when you've done several things at one time and now you're not sure what you did maybe you accidentally updated a theme and a plugin at the same time you have no idea what's breaking you can roll everything back up a little bit easier and try to figure out what's happening so again the way we do it not necessarily the way you have to do it but shows an example of what can be done in this particular case in the WP directory which again the WordPress in the sub directory constant or concept is officially supported by WordPress it's in the code codex it's something you can actually do you do not have to name it WP you can name it WordPress you can name it sunglasses you can name it whatever you want the name of the folder itself doesn't matter as long as you consistently tell WordPress where to go I really want to name one sunglasses now because I don't know where that came from the only thing that is different again this is a way to not hack WordPress but to do what's required to make this thing work inside of the single WordPress repository is a WP config file that's telling it to look basically back in the original site for the config file itself because it's going to start by looking inside the WordPress directory for the config file and you're just telling it go back out there and look for that there again using the server information kind of depends on the way your server is set up you can hard code all these well you actually couldn't hard code this value but you would need some way to say tell me folder is basically starting this request look back there for the WP config file just in case this is unclear this is not hacking because an actual WP-config file is not included in WordPress it's generated from a sample file or you make it yourself right so we can totally update this directory anytime and anyway we want to and this file will never be overridden unless you're doing something really crazy somehow so that's how we can make that kind of stuff work together and we can continue to use it without fear in a get checkout or whatever and yeah okay so coming up next is an example of how this actually works if you wanted to run get directly on the server to prove the point and make it really easy to deal with you can use an actual like get hub clone of it on your server you can wait for the WordPress mirror to push to the get hub repository you can also use SVN for this so don't get me wrong I'm just showing what's possible so inside your WordPress directory wherever it is on your server you can fetch the tags because you don't want to be checking out the master nightlies in production but you can just force check out your tags which would be the latest release of WordPress and then you have basically you can use get checkout pretty quick and you can use any number of other methods of more sophisticated deployment to make this work but at any rate that's your one WordPress instance that you've had update and even if you do it this way which is mildly crude to be honest it still happens in I don't know two seconds three seconds all the sites are updated and all you might have to do is do that really stupid clicking of the update database button which I still don't totally understand but that's the only thing that you have to do at that point and that's no different than if you updated everything else every other way but I can tell you that it doesn't happen for hundreds or thousands of sites in two or three seconds if you use some kind of remote management tool so this is a totally different way to do it and again it's a lot easier it's a huge benefit of multi-tenancy on top of all the other things we mentioned and if something happens with a latest version of WordPress something crazy goes nuts as far as I can recall I don't ever remember something dramatically breaking for a lot of people but maybe something broke for you and you didn't expect it and maybe you upgraded to a major version and it had a big change and you didn't expect it you can just roll back to where you were almost immediately and it's pretty easy to deal with hopefully you should never have to roll back security update or something like that so so yeah so like I mentioned once you have this stuff together it becomes a little bit more concise and it becomes a little bit easier to think of scripting your way through things again if you can get WPCLI to work in the way you want it to and you like that works just the same who was it who was just giving an awesome talk on all the scripts AJ right yeah so he had a bunch of awesome scripts that had WPCLI so same thing you can do that you can do batch scripts you can do whatever it is that makes you comfortable with a lot of this but again it becomes a lot easier to handle these types of updates across servers and in my opinion I am not really an ops guy I'm not going to pretend that I am even though I've kind of been able to dabble a little bit in it but thinking of WordPress this way like brought some of the processes down to a level I could understand a bit easier and helped me really manage some larger things at scale and so like for instance for us we have one major script that launches our websites and not only does it do the standard kind of deployment stuff that AJ showed in terms of creating a database and making sure all the things are in the right place but there's a lot of other stuff that we do on site spin up that can be included in all this and becomes a lot easier to deal with setting up an S3 bucket setting up a cloud front CDN domain that ties to it adding things to Cloudflare partner account the domain is ready to go adding staging domains all this stuff is a lot easier to process put into a script and just run and have everything go and there's just a lot less going on on the server when you have it set up in this manner and then lastly I just want to cover things that we should look out for again based on the way that you have things set up if you're willing to try this a lot of people get excited about this right and just everything I ever tell people is just like just take it really easy man if you don't if you don't totally understand what's going on here it's not that you can't do it you can but take it very slowly because there are lots of these little kind of crevices that you find in the way that your server might be set up that'll just throw you for a loop might not make sense might end up white screening might end up breaking might end up showing another site any number of things based on a lot of times the way your server is configured to handle sim links and open base directory and just other numbers of things like that as well as I mentioned earlier don't dare try to copy and paste the code from these slides into your server and expect them to work you have to think about it in terms of a system you have to make sure that it's working the right way and like I said really the most important key part of wordpress multi-tenancy itself is ensuring that that config file that sits in the single instance of wordpress knows how to go back out and look for the right individual config file so you might have to tinker with that and figure out how it works on your server further in case this isn't clear enough the way your server is set up on your computer might not be the way the server is set up in production unless you've really done a lot of stuff well so you need to be careful about that as well not all environments are the same so just several things to look out for I guess in this case one like I mentioned and like Mike asked about often times you run into interesting situations where plugins assume a more traditional structure of some type when wordpress is in a subdirectory and it's trying to directly pull a load file or something like that it's not really going to find it for the most part and that often sucks because if it's relying on certain files to be able to make the plugin work and you're trying to tell the plugin where to look for it before the plugin has been able to load its own thing you run into trouble that was hard to say even much less code but there are things to look out for aside from that one particular thing of pulling in the load file a lot of times people are just they're in queuing a CSS file in their plugin and they just assume the wrong directory they're trying to pull in something random that wordpress bundles and they're just assuming something false usually these are very simply fixed by looking at the codex submitting a patch to the developer and saying use this function instead of hard coding a string in your plugin because some people aren't set up that way so far I've submitted probably five or six patches to major plugins that didn't really change the way that they worked but ensured that they worked for a lot more people using wordpress in a subdirectory and I have only had one person ever say I'm not really interested in fixing this and that's because they run an IDX plugin and they hate everybody so I don't know so another thing to point out just because it's in the codex I have not really experimented with this a ton but when sim linking your plugins directory like I said you don't have to do those parts but if you're going to utilize that the codex itself suggests that you make sure all of your plugins are in an actual directory you know you can technically write just myplugin.php and sit it inside the plugins directory and it'll run just fine for whatever reason they suggest not doing that putting it in a directory, I'm going to be honest with you I have not tried to break that I'm not really interested in finding out why it doesn't work so I just put it on my slide and now I'm telling you and then again just because maybe I haven't mentioned it enough make sure you test all of your processes and it'll work just to give maybe an example to you of kind of the other side of the benefits of being able to really really quickly deploy a lot of things at one time so one fun story you might find that basically hits WordPress multi-tenancy with a baseball bat and kicks it until it bleeds is from like 2010 or something like that where WordPress VIP had this major amount of downtime because they used a slightly strange version of multi-tenancy for their customers or at least they did, I don't know enough but I know that they were using a form of multi-tenancy and so the cool thing about being able to push a ton of code and have it deploy within seconds is pretty obvious if you push terrible code and it deploys within seconds everything goes down within seconds there's very little rolling process for you to notice that things are slowly going down but once just kind of like lights out all over the place and so there is a really interesting and frankly very angry article about that from some guy I've never heard of but it's interesting to look at and it's interesting to consider again from this perspective aside from just testing your deployment processes you would also want to make sure that your deployment mindset basically changes to accompany the way that this might actually work in your environment if you push a ton of code and you're kind of sharing the same plugin and you have maybe a custom plugin running and you push dumb code you just broke everyone's website at the same time and that's really bad if you push a security update or should I say an insecure update to everyone's site everyone's site is vulnerable at the same time so these are kind of things you have to consider in my opinion it helps a lot because as a developer it puts stronger bounds it makes me make sure that I am checking for fatal errors I am checking for security flaws I am running tests I am doing the types of things I ought to be doing as a developer that are far too easy to just ignore when you're just kind of pushing in a traditional way so yeah so all of that is there and that is the concept and now you know kind of the whole idea and how you can at least begin to approach it so like I said usually the questions are the most fun part about it normally I tell people no for questions but like I love so many people in this room that that wasn't necessary does anyone have any questions that they would like to talk about now so let's start over here so I am not totally sure how that would be any different than having a bunch of independent sites running it oh I got you yeah so without getting too far I guess into the details speaking of just kind of like context shifting around that stuff so the way that would be handled right now we don't force activate anything on an MU plugin like if I can't write it as an MU plugin I don't think it should be forcefully activated but in that case to me I back up out of WordPress and if I need to run database updates across things then I just run so again it just kind of to me it helps separate things back out into more of a traditional multi-tenant software setup to get things a little bit more in that angle does that make sense cool yeah sure so I think I can do that pretty quickly one fun thing that I forgot to mention that's always really fun to say is even though this is multi-tenancy and not multi-site you can still run multi-site instances in a multi-tenant environment okay great so yeah no I can actually I think I can do this really quickly so let's say you had a bunch of you've already got a bunch of sites and directories on the server right so the way you could in theory convert all of these very quickly one is you start with I'm gonna so yeah I'm sorry for just flipping through things very quickly so step one would be if you wanted to go the get way or whatever however you did it FTP don't care just put a new single instance of WordPress you could start with having them on the same level as all the rest of those directories right so have them there your second step would be updating updating your config file to make it point to the new subdirectory instead of looking in its own root directory right so you'd be pretty far along already and in fact that would probably as far as I know yeah that would go ahead and start running them in a multi-tenant situation pretty much immediately because now it's just looking in a new location for WordPress itself it's no longer looking at the files that are in there so you can delete those whenever and as long as you've got the where's that fancy config thing yeah as long as you've got that config file in your new single instance of WordPress and you've got that working whatever this is that should take care of it out of the box yeah and so then like assuming this wouldn't result in 2,000 plugins sitting inside of a folder you could then create the new directory on the server basically just start copying all the plugins and themes putting them all in the same place and then basically do the same process over again does that help sort of okay awesome mm-hmm right and I tried not to go too far into it because that becomes a different web server thing but yeah it should all work the same yeah so yeah that's the thing I always try to give a caveat on so if you have existing sites that you're interested in converting to multi-site don't change the content thing just leave it as WP-content that kind of adds an extra level of complexity that's much easier to handle when you're spinning them up from scratch but yeah other than that like I was telling Russell as long as the the actual directories that you're pointing to with your Simlinks as long as those continue to have the theme and the plugin files that they expected already once you Simlink them they continue to work great as long as your server is set up to follow Simlinks which it normally does yeah Mike say that again sure because I consider those to be independent parts of an individual site so I want to be able to extract them back out easily I don't have to I'm not interested in going back in and trying to divvy that up it doesn't save me any space or efficiency on the server in that way yeah the way that the the web server and the DNS would all work in theory is totally the same until you start expanding it out there's some different way that you would normally do I don't know if there is or not have an experiment with it exactly some folks have talked to me about mounting instead of doing it the way it's being done here I think that that's interesting but at least for again for our purposes in the way we're doing it we have a concept of how much resource server should have we have alerts and boundaries on those auto scaling servers to start detecting way ahead of time of when spikes are even going to kill it at which point like we'll just deal with the migration and things like that for us as well because we make sure and help manage a lot of DNS as well becomes a lot easier for us to have the control to port people over to new servers if we need to yeah well I mean we have a bunch of servers but they're not they're not divvied up by any particular order I guess it's not really done by number again it's sort of similar to this there's just monitoring and alerts setup everything auto scales right so what I'm interested in is making sure I'm getting notifications when something is hitting two thirds of the possible resources on a server because they had a decent size spike that's when I'm interested in finding out what that is and figuring out how to move them on past that yeah absolutely because again in our case and this is why I said this is not targeted towards developers in the room it's specifically designed for low budget small businesses and non-profits so we can spin up sites super quickly front load all the problems they usually have and kind of take out all the pain from that but that also results in if they're non e-commerce membership whatever sites they can be heavily cashed if you actually know what you're doing at which point they can handle a ton of traffic if you know what you're doing and so there ends up being kind of like a nebulous amount that can live on a server as long as you're kind of looking at it that way so yeah I've had problems using every caching plugin ever so yeah plugins and different kind of hands fun things yeah none of them are perfect but I've not seen any of them be affected by multi-tenancy I have my own scripts right now because we make sure that we have a if anyone does decide to leave or whatever we automatically make sure that we have a full archive ready to send them along because even if someone leaves kicking and screaming or angry or something like this is your site that's like a core value like this is your site this is all of your stuff so here it is so yeah right now it's a hands fun script so we I don't know if I'm allowed to talk about this don't care we have we work with SiteGround we use their cloud server infrastructure we do something pretty different than the traditional cloud server that you would get if you just signed up with them because of the way that we work let me check on time we're running out cool we don't have for instance like cPanel WHM and all the other stuff that usually comes on a server we also don't like run a mail server anything like that it's all offloaded to a different plugin so the other benefit of this type of thing too which I forgot to mention but it's kind of fun if you control 100% of the code that's on your server at any given point you can do whatever you want as long as you test it so you want to run PHP 7 totally can like you don't have to worry about anything because as long as you test all the plugins that are sitting on your server that's the only code that can exist there so you don't have the same problems that other hosts have where they have to worry about what type of code is there and how much it'll break and things like that so that's another key benefit is basically like we can run whatever version of anything we want to run because I know what code is sitting there and I've looked at all the plugins before they go up cool well thank you so much everybody I wish you the best of luck on winning a model train set or something like that and we'll see you next year