 Hi everyone, my name is Kyle Bondo and I hail from Projectsburg, Virginia just outside DC. So we took a little trek down here to Asheville because on a vacation one time we came through this town and we're like, this place is pretty nice. So let's come back. And I discovered the mountain bike trails of Solly just about an hour outside this place. And that's become like my annual birthday ride. So every time I come down here I think, man, it'd be cool if I could work here, I could stay here. And so this is kind of like we're keep probing into Asheville to see whether or not this is a place where we can actually move to because I tell you what, DC sucks. So this presentation is on monsters of wordpress and I kind of struggled with the title for this because I wasn't too sure on if I should call it multi-press, does it have a purpose or why does everyone hate multi-site, not multi-press, multi-site. So multi-site being a kind of a subsection off of wordpress in particular is kind of got a bad rap. And a lot of times it's got a bad rap is because a lot of people try to make it do a lot of things that it doesn't, it's not designed to do. So we're going to go over a couple of things on first kind of what is it just for kind of a, you know, gender boiler plates of primer for, you know, those of you who may not be totally familiar with what it does. Those who, some strategies for when you've gotten in trouble with multi-site if you have experimented with it and then some strategies for if you're planning on doing a multi-site, what are some good ways to do it? So just kind of a little background on myself. I am a recovering Java developer so and I'm a closet recovering Drupal guy, I don't like to omit that very much. So I came to wordpress kind of through the back door of I tried every other CMS out there and finally found one that I liked that wasn't super hard that like with Drupal he didn't need a PhD to understand. So it's kind of been a love affair with wordpress. I started off as a freelancer in the early 2000s working by yourself sucks, joined some partners, we formed a company, things started going great, economy crashed. So now that's how to go back and find another job again. And so about two years ago working with, I do a lot of mountain biking, a lot of outdoor work. I belong to a club called the Potomac Vila Club, we ride mountain bikes and stuff. And while we're working on the trail someone goes, man our website really sucks, I wish we'd fix it. I say, oh I kind of know how to do that. And so I built their website out and from there I started an idea of well maybe I don't have to work inside another company again. I can actually start going on my own again. Maybe it's time to start stepping outside. So I formed Trench Bucket. And Trench Bucket is kind of the idea of I do a lot of endurance sports, a lot of cycling sites, a lot of things to do with trail running. So you'll see a theme through this of some of the things I've worked with. So that being said, once upon a time I was in the Navy. So to kind of give you an idea of the topic of kind of understanding purpose. This is the USS Boxer. The USS Boxer is a multi-purpose warship. It's a WASC class amphibious assault ship. It's got helicopters. It's got vertical and takeoff and landing aircraft. It's got hovercraft coming out of the back, comes with 25,000 Marines. It's awesome. However, if a little tiny ship came up to it, it can't defend itself. It has no offensive weapons whatsoever. Basically, this is a giant target. So its purpose, however, is to attack a beach, take the land, the beach head, and do a lot of wreck and havoc in another country. But offensively in the water, it can't do anything. It is relying on everything else to protect it. So the ships in the background, the destroyers and frigates, have to be there if this ship wants to be protected, otherwise it's in big trouble. So multi-purpose has its place. Space is not an attack ship when it comes to fighting other ships. So I'll tell you a little story about when I was in the Navy. I worked with a lieutenant who knew everything, and I don't know if you've had a boss that knew everything. I had a lieutenant who was fresh out of the academy who knew everything. And when we did presentations, we did presentations back in the 90s on transparencies. And we had this monster in our workspace, this giant HP thing that weighs about 300 pounds. And it did transparencies very well if you use the right ones. And the transparencies we had bought, we originally bought this printer, were the wrong ones. They were thick ones. And we kept them in a drawer somewhere because we knew not to use them. Well, the lieutenant knew everything. He needed to make transparency at 3 o'clock in the morning. So he grabbed these transparencies he wasn't supposed to grab. We tried to tell him no, but he didn't want to listen. And put them in this printer. Now if you know anything about early printers, the machinery within those things is very fine and a big thick transparency when it gets jammed through this sucker, jams. Now the transparencies are plastic. Plastic in a printer like this is hot, hot plastic in a workspace inside a warship. You now have the ingredients for a pretty good looking fire. And which is what happened. Smoke starts building out of this thing, fire everywhere, he panics. So he takes the fire extinguisher and puts it out. So now we have this big melted mess in the corner. So it's 3 o'clock in the morning. Who's going to notice it's missing? Tells us to go down to the storage area, grab our extra one, bring it in, put this one, toss it over the side. We'll put this one here in its place, no one will ever know it happened. We're like, okay, well he's the lieutenant, he's in charge, let's go, we'll follow his lead. So my friend and I, we heave this big monster out of its place, we put the new one, we make sure it works, everything's great. We take this big guy and we toss it over the side. Now this is what the lieutenant thought was going to happen if he didn't do that. There'd be a huge fire and that this whole thing would melt to the ground and that he'd be in trouble and he'd lose his commission and everything. Instead, this is what happened. 3 o'clock in the morning you drop a 300 pound object off a ship, you get a nice big splash, which sounds really cool. 30 seconds after that splash, we hear bong, bong, bong, man overboard, man overboard, man overboard on the board side. Yes, so now the lights come on, the whole crew wakes up, the ship starts doing big circles in the water and we're looking for a guy who isn't there. Mr. HP has gone to Davy Jones Locker, but we don't know that for another three hours where everyone is making sure everyone's on board. So man overboard, definitely not very multi-purpose. So in relation to multi-site, it kind of has that same kind of attitude. Is there are certain things that the WordPress multi-site software within WordPress itself, it's kind of built in, has places for it and not places for it. And there's ways to abuse it and there's ways to make it actually work successfully. And this is just a gratuitous photo, because my daughter said that there's no place you can't take a selfie. Well, I think there's one actual place you can't. So let's go ahead and talk a little bit about multi-site in itself. So there's kind of three people who approach multi-site within the WordPress community. Those are people who are experienced loading WordPress and know how to do single installations. A lot of single installation websites work just fine. Plugins work just fine. You can make them really big. There's a lot of things a single instance can do. Then there are people who have already built one of these things. And I call these monsters because when you've built a multi-site website that's gotten out of control, that's exactly what it's become. It's become a monster. And then there are the people in the middle. People like maybe you, who are thinking about building a monster. But I'm not too sure how to care and feed this sucker. So I like to call the single instance the fish. Because fish are easy. They travel in schools. They're one-offs. They're pretty easy to catch, pretty easy to install. From a developer's point of view, once you get the learning curve. But most site WordPress sites are these one-off fishes. There can be a lot to them, but they're pretty much the simple thing. They have a single site deployment, code-based, single database, usually a single theme. Even though you can move, you can put a whole bunch of themes in there. You can only use one at a time. So that's your typical fish site. Now a monster, however, is, and this was hidden back a long time ago in the Drupal world, was if you hack core, someone kills a kitten. And then I found this slide that says every time you talk about killing a kitten, God kills a kitten. So it's in respect, we kind of just killed two right now. But a monster site, as you saw those domos chasing a little kitten in the background, is kind of that introduction to things that are getting to get a little more complicated. Because you can't just go, hey, I've loaded my WordPress and I press a button, and wow, I've got multi-site. It doesn't quite work that way. You have to know how to install it, and then you have to know how to go under the hood and do a couple little tweaks in order to get multi-site to work. The code's there, but you have to actually go inside the WordPress config file and add a line that tells WordPress, hey, guess what? We're not going to be regular anymore. We're going to be a monster. So you still have a single code base, and you still have a single database. But now you can do something that you couldn't do before, which is you can actually build sub-sites off of the single code base you used. So if you have myspace.com and myotherplace.com and mythirdplace.com, they can all use a single code base without having to have an instance for each one. The advantage to this is I can only log in once, and I can get to all three. Now, we'll talk about some disadvantages to that, but right now that's kind of the advantages. Plus, I can also say, hey, that has that theme, that has that theme, that has that theme, and I can apply them all to my sites without having to load them three separate times. I have three separate sites. Now, if you really want to get deep into the configurations and the finite administration detail, Mika Epstein has written two fantastic books that let you do that, which is Multi-Site 101 and 110. Another game, Rob Hardy, has also made a pretty good book. And this gives you all the little details, how to finite, secure, hard, and those kind of things. And that's really kind of not what we're talking about today. Today we're talking about monsters. So we need to understand kind of what it is before you ever get into this problem, what a monster really does. So I'm going to try to talk a couple little bit about people who have already built one. Now, as you're preparing to build a monster, you may want to heed some of these warnings of why they are called monsters. So we'll talk about a couple of special issues. And I've named them, because it's the monsters of WordPress, each one of my strategies has a monster's name. So the first one is the Great White Bortex. And what is the Great White Bortex? Well, Great White, like the shark, eats everything in its path. So Multi-Site has the ability to scale in a way that you've probably never done in a WordPress before. You can add a sub-site to your Multi-Site till your heart's content. You can go on and on and on and on. You can add 10 sites, 20 sites, 50 sites, 100 sites. I've heard of people adding 300, 500 sites. It can get really crazy. Now, when you scale to that large magnitude, you run into some problems. So the first problem is, although these are one code base, with all these sites hanging off one code base, you still have to minister every single one of these sites. So the sites have embedment problems where you need to have someone watching these areas so you don't have orphans or stale content. So another thing about this is that when you have all these admins controlling all these sites, you also have a lot of access coming in inside your site. So you need to be able to prepare yourself for the amount of volume that you're gonna be trafficking by having these thousands of sites. Solutions for this, of course, is to plan your growth. You don't want to go start doing Multi-Site with a thousand sites. That's crazy. You want to start with three. That's sort of simple. Grow in a way that you would grow anything else. You also want to have the admin resources to take care of all this stuff. You don't want one admin for 100 sites. That's crazy. You want to be able to cut this up so that there are certain sections of admins in for certain sites. And you either want to fish or cut bait. And what I mean by that is some sites probably don't need to be Multi-Sites. You might need to split them off and make them their own sites. The second one I call the Hydra Divergence. Now the Hydra, like the Mythical Monster, every time you chop a Ted, to grow in its place. So this is kind of the problem you have when you build a bunch of Multi-Sites. And then you decide, out of the 50 sites you've built, site 20, you want to make its own site. Now there's some plugins and things that can help you do this, but this is not an easy thing to do. You really kind of have to understand what is going on. So if you are kind of new to WordPress, separating a site out of Multi-Site is not a simple task. So you want to make sure that if you're doing any kind of migrations with these kind of networks, that you want to build them from the ground up the way you want them. Don't build them inside Multi-Site and then say, oh, you know, I really wish that was a single site and then pluck it out. That's not going to work for you. It's going to be too hard. It's going to be too much to do. It's easier to have thought this out beforehand before having to pluck one out. So some of the solutions for this, of course, is start a whole new network and build them up from there to start to separate this. You could try doing some backups and cloning the migrates. There's other things in the back you can do before you start chopping heads off. But always, always, always, planning before you start doing this is better than deciding halfway through a large Multi-Site installation that you want to pluck stuff out. The last one is called the Giant Squid Incursion. And if you guys heard a raised talk just before this, this is back to backup, backup, backup, early and often. The no recovery plan is probably the Achilles heel of the Multi-Site installation. Multi-Site is a single code base, which means if your Multi-Site instance gets hacked, they now have access to every site hanging off that thing. They can do a lot of damage. So if you have 75 sites hanging off a Multi-Site and they get into the one core installation, they got all 75 sites, with a matter of speaking. So you want to make sure that because of the single point of entry that you are protecting yourself often with lots of updates, with lots of making sure everything's update, all your security is in place and that you are backing up everything, including the database, on a routine basis. Another bad thing about something of this kind of occurrence is that with 75 sites, you load a plug-in and that plug-in breaks your site, it breaks them all. And if you don't know where you put that plug-in or which plug-in broke it, you now have a problem of troubleshooting 75 sites to figure out where the problem took place. So you definitely want to test things off of your Multi-Site instance before you throw it on the live operation. So now kind of going with, that's what can happen to people who have built these things, these monsters. Now it's kind of time to talk about, okay, maybe you're thinking about it. Okay, Multi-Site's not that scary. Okay, Kyle, you said a bunch of monster stuff, that's fine. Yeah, yeah, yeah, we know to back up, that's great. So now, if we're building one for the first time, what do we do? So the first thing I thought I'd like to say is, just like I said, get smart. Make sure you understand what the heck is going on before you build this stuff. There's nothing wrong with building a single instance if you can get away with it. But if you actually think that you need one of these, I have five patterns, I think, work very well with the Multi-Site installation. And these are kind of configured to the purpose of each one to a particular style or particular industry that I think work well. Now you could disagree, you could say, I don't think it works that well with that, or I have another one, there's multiple combinations you can have. But these ones that I've done some experiments with that we've put a couple in the real world, I think work okay. So, food for thought. So the first one I call the Jelly Cloud. The Jelly Cloud is the multi-branch. And the multi-branch is really simple. So if you have a company that has very distinct industry segments, or you have a university that has individual colleges hanging off it, the Jelly Cloud pattern works very, very well. It's a single theme deployment, which means that each one of your subsites uses the same theme, so you're not doing mix and match them themes. You have a unified design and brand, and you have a finite number of branches. So the simplistic version of this is the main college site, or the main site, the trunk of this branch is the entry point, or where all the corporate headquarters keeps this thing. And then the divisionary branch sites hanging off this. So an example of this was a project we did with Ditch Lite. Ditch Lite was a government contractor up in Cumber. So they had a corporate headquarters. Corporate headquarters had all the various about us and the team and those kind of things. But they also did something in the mobile sector, where they tried to do, they took their mobile strategy and pushed it to helping government organizations get cell phones and iPads and things like that. So they had a whole mobile sector that was doing something very different than their consulting. They were implementing hardware and software. Then they also had a defense side. They had the ability to put mobile technology to soldiers out in the field and had a whole practice based upon that. So they were able to divide in a multi-site, divide their website up into three completely different websites, but with one admin, one code source, and a single. Now you could have done this with single site for sure, but they wanted to have it all kind of in one concisal area with admin and this in multi-site worked very well. So the advantages, it's a simple network. It's easy to administer. It's, your content is very specific to each one of the sites, but the branching kind of is your judgment call. You want to decide whether or not it's better off as a single site or as a multi-site. You want to make sure you have a clear linking strategy between all these sites and you really don't want to duplicate content. One of the things that we found that Google doesn't like when you have a website that is associated with another website that is exactly identical content, doesn't like that. So when you're doing multi-site, you want to make sure that the content on your sub-sites is not mirroring other websites, other stuff unless it's like an indexing of things. And I'll talk about that later. The second monster is the Wakemaker. This is the multifunctional multi-site operation. And this is really good for member associations and clubs. And this is one where you use multiple theme deployments. You have similar design and brand. You have room for growth. So this is kind of a more variation off the branch, but it allows you to have the ability to secure some things, to move an event. So if you're an association or a club, you have the Join Us. So the Join Us is the site where people come in and become, I want to be a member, tell me what you do, what are your benefits. But a lot of nonprofits, especially, in club associations have events. They have dinners and raffles and they have five Ks. And with this particular one, with the Bicycle Club, is they have a fundraiser every year. They have a mountain bike racing series, which they have an event site for. But they also have a need for a members-only kind of area. And that members-only area can be a secure place where members can go in and do like, oh, I need to do volunteer time. Here are some options. Or I have a need to track. It's like in the racing club example, they don't need to track how many races you did to be part of the race group or the race team. You got to do 20 races a year in order to be considered a race member and get a free jersey. So they wanted to keep track of that. So this became the way where you could hide the application that did all that. So this defines clearly a separation of functions. The event site is very different than the Join Us site. The members-only site is very different than the two. You keep the club name and the domain name. So one of the advantages of having a multi-site is because you're using sub-name, their sub-domain naming is I have Potomac Vila Club, PotomacVilaClub.com, and then I have WAW, which is Wednesdays at Wakefield, PotomacVilaClub.com, and then I have club at PotomacVila.com. So I've kept the name and everything. So I'm using it kind of as a branding mechanism so that everyone knows that they're coming into our association or coming into our club the right way. The difficulty with something like this, of course, is scope creep. As you can see, with three sites it's pretty easy. What if I have two events or three events or five events or six events or I have an event every year, it's rebranded and I didn't get rid of the other site, but I added another site, so I can get this kind of crazy really quick. So you want to make sure that you're keeping control, nice small networks work so much better with multi-site than big ones. You want to be able to, if you have some managed member accounts, it can be another difficulty, in which in the member section, you now have to worry about, do you have members see more than they're supposed to see and you have to worry about security in there. And then you have to worry about organizing and staffing. One thing I found with nonprofits, not a lot of people work in nonprofits. You have small groups, especially IT in nonprofits, usually are freelancers or a volunteer. So you want to make sure you're not overdoing the staffing when you build a site that's going to an organization or a club. The third pattern that I like in particular is the multi-linguistic. Now in this pattern, you're really kind of talking about languages. Now I've played with a couple of the WordPress plugins with translations and if you talk to people who that language is being translated into from English, it's not always a one for one, it still needs some work. So with this particular example, you're looking for companies of global markets and multi-lingual organizations that have the ability to have translated content with their other content. The goal of this one is a single theme deployment. So you have the same theme over all three. You have a unified design and brand. Your professionally translated content is a key piece of that, but you're using subfolders this time. Now inside Multi-Press, you can have the choice of a subdomain or a subfolder. You can also use primary domains, there's so you can have a domain name for each one, but primarily the easy way to do this is subdomains or subfolders. And what that means is that each one of these, the primary site sits on the main domain. So in this instance, it was at riskinternational.com. And then the two language translations sat inside an English or a language folder. So in this case, this company, which is doing security for the Olympics in Rio in 2016, needed a Portuguese translation of their company that actually operates in Brazil. So Brazilian and Portuguese was a major translation that they needed to have. So we built the multi-site where it just sits in a subfolder. Now they're also expanding into South America. So the expansion for Spanish was an obvious, not an obvious next step for them. But you have all three languages working within multi-site, within one site, one administration. A good thing about this is that you get better translation control, that one-for-one thing, you can get rid of that, you don't have to worry about the plugins for that. The plugins I'm sure will come along, but right now, having the translation was key. You get better analytics off of who's visiting what. So you know which site people are actually going to, I thought, because the way they're broken up just makes it easier for you to trans-define the analytics better. You can add and remove specific pages. One thing we found was in the English side, the Brazilian stuff didn't need to be in there. So in the vice versa, there was English stuff, there was things they were doing in Virginia that they didn't need to do in Rio that we can remove pages for. So you could have two complete different sites, although using the same theme with different pages. So you don't even need the same pages on each site. We also found this advantageous with language-specific admins. So the Brazilian IT guy who's loading content in with Portuguese can log into this and do the Portuguese translation stuff, and you can actually get WordPress to show all its menu systems in Portuguese, which is pretty cool. So now the guy from Portuguese, from Brazil, can put his own translations in and his own content in without having to worry about figuring out what the English means, and then us going in and doing the English, we didn't have to worry about the Portuguese meant. So the next one, I called the colossal croc. Our next monster, this is multi-tenant. And multi-tenant is kind of the one where things kind of get kind of scary. So it seemed perfect that a crocodile would be the guy to kind of lead this way because crocodiles eat everything. Well, they say there's an African proverb that says if you see calm water, don't think it's empty because the crocodile's waiting in there to eat you. So this is one that worked well with event management companies and music and game developers. And it worked well because you could use multiple themes. Like again, multi-site, each site doesn't need the same theme as the other site had. So you use the similar design and brand, but you have customer specific sections. So this kind of works in a way that where you have the studio in one site, an application site of where you have a product or maybe where you're collecting information from people, customer reports, forums, whatever. And then you have the actual game or the studio or the music group continuously created along the lines using your own templates. So in this pattern, we have the example of the Grand Piano Warfare, which is a music studio. Unfortunately, it's not around anymore. But Grand Piano Warfare had the ability to, they wanted to have their company site, but then they wanted a way for additions and events to hang off their site as well. So in multi-site, we built the main studio site and the addition of the events so people could load their songs or links to their SoundCloud or could show the events of where the groups were on a calendar so that you'd know when each band is going or when they were doing auditions. And then each time they had a new talent or a new band, we added a sub-site with the band name and the name. So you have the band name plus the studio belong to existing and multi-safe for each one. So you had fan sites that we would then give access to the musicians so they could go on there and load their photos and load video and they could talk to their fans and they could have blog posts and they could have their own kind of unique band site separate from the studio but still kind of controlled by that. Now, advantage of this course is the semi-autonomous admin. We give admin away. We give admin rights to some of these people that we don't have to do it anymore. They could actually control it. You could also then control the theme in which when you launch their site it was in a way that you liked it. So most of the content or most of the theme was locked down so they couldn't make any kind of strange changes. So it still had kind of the brand was carried over. Plus you could also aggregate content. So every time there's dates or posts from each of the individual bands we could put that on a main site and you could have a main site of all the bands and then each band had their own thing. Which kind of goes against some of the things I talked about what Google said about stuff on the same site but if you're aggregating on a giant pan of 15 different bands you can mix that stuff up really well. Plus you also have the events and things going on. The bad thing about this is when you have semi-autonomous admin is now you have to content monitor. Now bands are notorious for not being PG, right? So R rated content, photos that maybe shouldn't be there. You kind of have to make sure you're controlling that when you give admin away that you at least have a control over what they're doing on those sites if that's your kind of your agenda. The next thing of course is slow and asymmetric publishing. Bands posted when they wanted to. When they're on the road, when they got around to it. So when you have this aggregated type of thing within multi-site and no one's publishing any content that aggregation becomes nothing found or no updates for the past week. That kind of sucks. So you definitely want to have those kind of challenges controlled when you do this. Our last pattern is probably my favorite. And this is the Kraken. Ooh, big scary, right? So multi-focus is what this is called. And multi-focus works very well with application startups and software companies. And the reason that is is because a lot of times application companies and software companies are trying to sell a product. They have a piece of software. They probably have a software as a service thing, things like they're trying to sell some sort of like balsamic cells or wire framing. You have the ability to sell that particular product but you're looking for customer feedback on different levels. So this kind of, oops, did I kill it? There we go, there we go. So this kind of breaks it up into kind of what kind of customer segments are you looking for? So when you're looking in some kind of customer driven way of capturing different types of content and different kind of channels, you can set up multi-site to do that for you in a way that I think does better than a single site because you can administer it all by itself plus you have the ability to give a certain person access control to this, access control to that, but all contained within a single network. So in this particular pattern you have for customers you have your updates. So this is your blog posts and stuff that you're doing within the actual community of the software you're creating. You have your self-help, the FAQs, the documentation, all the stuff for your product so that your customer doesn't have to go find it anywhere, it sits on its own site. You have feedback, this is your forum and your stuff where your customer is like, ah, you know I did this and then I got a big red X and that was bad and you can have your actual customer service reps through answering back to the forum. You can have your, the experience piece to where you start talking about the product itself. So you're experiencing the product online so if it's a SaaS or you're doing a demo or you could have your own little demo site off the site so people can try it out, give it, kick the tires and see what it's like. And then you could also have a concept site hanging off the side as well that would give kind of like teaching back to why you do this. A couple sites I've seen that do this are things like, I mentioned Balsamic does a, teaches people how to do UX. It's a whole other side off to the side so you have that ability to have the product and then all the channels your customers are looking for all built into one network and you don't have to worry about separate everything spread out. So like I said, customer focused sections, you have your segmented metrics which help really well when you're doing that kind of driven thing of who's responding to what and then your product feedback tech channels make it a nice, concise little tight little network that you can do one admin, one network update so you can do all your things in one spot. Kind of the challenges that of course it requires orchestration. You kind of need to have the ability to make sure that you're responding to all this content being pushed in. So it's all this inbound content is gonna be managed just like you're managing all your other content and the other patterns. It's also product specific. If you do two products or three products or four products, maybe you need to have different networks for each one. So I'm gonna do on a time. So what kind of comes next? What sort of the monster conclusions for all this? Well, there's a couple I haven't talked about which are like the multi-community and multi-development kind of monsters. Multi-community is what WordPress does. This is the semi-autonomous one where you go in and make an account and boom, you have a blog. That's all done on WordPress.com. WordPress.com is using multi-site on the back end to create those blogs that you create when you first start doing a WordPress.com account. So you're actually using multi-parole site and you didn't even realize you were doing it. Multi-development works too. If you have a developer or a development lab, sometimes having a multi-site to kind of just spin off a site and do some work on the back end works well. If you're planning on not pulling that thing out and putting it somewhere else, which can be done. And of course you're talking about developers that you can probably figure out a good way to do that. But I find it to be very challenging to pull a site out of multi-site. But when you do it in a laboratory environment where you just kind of see what's this theme do and what if I did this and what if I did that and let me test this kind of thing out. Multi-site works well. Kind of spin one of those guys off without wrecking something else you're working on. So some of the takeaways that I would have from this is know your purpose. Know what you are planning on doing with this thing, with this monster before you go down this road. Have a scaling strategy. Know where the finite end of these sites are. Know that you have the resources and the admins to take care of all this. Educate yourself. There is some very strange particulars of multi-site that strange things that happen that you need to be aware of and that you can control rather than being caught off guard. A good example is you delete a multi-site, gone forever. Kind of like when a WordPress site, if you do some deletions, you can actually bring them back. In a multi-site, if you delete a site, it can be gone forever and you don't want to do that. So you want to educate yourself to make sure that you're understanding not only how multi-site works but how to secure it well and that you're keeping everything controlled and not kind of allowing it to get out of hand. Plan for growth, of course. I just said that. You want to avoid those separations. You want to start off with small monsters first. If you're going to do a multi-site project, do something small. Some of these patterns are very small patterns. They're not giant. And keep it small and tight. I usually use the rule of threes with a lot of sites. If a site could probably be multi-site, three sites max is usually a good way, easy to manage, very easy to control, and you're not going to get out of getting crazy. And then, of course, back up, back up, back up, back up. When you're on multi-site and it's a single code base that one hacker go in and screw everything up, make sure that you have backups everything often and early. So, and that kind of, that's the end of my thing. You can find the slides I have on monstersofwordpress.com as one of the very recent blog posts. And thank you for listening.