Multisite – Verborgenes Juwel für große Webprojekte

Music

Jakob: Hello and welcome everyone to Greyd Conversations. Today we are going to talk about multisites, WordPress multisites in specific.

So multisites in general, for the ones of you who don’t know, is a feature that is not really used by everybody in WordPress, but only by a few percent. But actually it’s a really powerful feature. And we’re going to take a look at how you can set up a multisite, how you can use it in the most performant way, examples on what sites you want to use multisites…

And therefore we have one of the most well known and the most famous I would say experts on the topic multisites in general. Welcome Robert Windisch.

Robert: Hi, thanks for having me here.

Jakob: Thanks for being here. So first of all I think most of you probably know Robert Windisch. I mean, you can recognize him by exactly how you can see him here: his straw hat and his green shirt. But for everybody who doesn’t know Robert, Robert maybe explain yourself a little bit. Introduce yourself a little bit. Who are you? What are you doing? Why are you that much known in the WordPress universe?

Robert: Yeah, so I’m in WordPress since two decades now. And, so I when I joined in 2005, it was a really up and coming, CMS and almost everybody talked about it right at that time. So when I joined, there was already so much like buzz going on, and then I joined the German, forum and was like ranking up to a moderator. Being then technical admin for the German website and doing translations for WordPress, and also then joined Inpsyde at that time, to make sure that we can help WordPress grow in Germany.

And that then leads to now 130 people agency for enterprise people in the WordPress space.

Jakob: And why are you considering yourself or I am considering you a WordPress multisite expert? Why? Do you use multisite a lot? Or are you just curious how the feature works?

Robert: Yeah, we are using multisite since 2008 when it was a fork of WordPress called WordPress mu, WPMU, and we were using it at that time to simply achieve, for example, for the German WordPress website. We had a website, we had FAQ, we had some other things, planners and other things to really engage with people. And we did, the multi-user feature or the multisite feature already at that time. And we were then updating it every time when a new version came out, like right after I worked the WordPress release. And so for us, all these features were really normal in a WordPress way. So then when multisite was merged into WordPress with WordPress 3.0, for us, it was really a normal thing, that we finally don’t need to have like this extra version running and to simply be with core WordPress.

And also at the WordCamp in Germany in 2010, in Berlin, that we had the possibility to answer the question „how would we do a multilingual plugin?“ And we were like, yeah, let’s use multisite, because that’s the normal way for us to do. And so our other story of our multilingual plugin, of Multilingual Press, began, because we were simply asked and then the follow up question was, is there a plugin for that? And we were like, not yet. And so then we kicked off the other thing. And for us, it was really something normal as we were using multisite for, almost every client project.

And it’s right now also the main feature for us. So that’s why we called the other thing single site, that nobody in our company is confused by using this normal version of WordPress that everybody’s using, because we are normally using the multisite feature as the default.

Jakob: So for you multisite is actually the default WordPress installation in your company and single site is more of a strange, why would you use it thing?

Robert: Yes. Some people don’t need those lovely features for multisite that really have an ease if you have more sites and bigger sites. And as we deal with enterprise companies and with big companies that have, like, country- stretching entities and then for us, the multisite feature is a normal one. And that’s why we are like known for multisite and multilingual in the WordPress space. And that’s why there’s so many things.

For example, at WordCamp, people, come up to me and go like, hey, someone sent me your way. I have a question about multisite and and so because I’m very easy to see…

Jakob: Yeah, you are always visible.

Robert: Yeah. And when people go like, yeah that’s now too many multisite questions, go find this guy with the straw hat and the green shirt.

Jakob: Yeah, yeah, yeah.

Robert: Then people come my way and I’m happy to talk every day and night about multisite.

Jakob: Yeah, actually I think I already sent some people your way as well. Like I said. Oh yeah. Talk to that guy.

Robert: Yeah. It is an easy way to get to get rid of people, because, you know them, they regret, like having a conversation where you go like they think they have a five minute conversation with me, and I go like, hey, maybe this plugin is something to use for you, or maybe this feature, you should look at that. And then my most loved feature, the multi network feature, the multi multisite feature…

Jakob: I’m gonna have a question on that down the road.

Robert: I’m sure about that.

Jakob: Before we go down that road, because now we’re getting really specific. Let’s just clear clear things up first. So we already referenced the feature multisite a lot, but let’s maybe, maybe you can give an explanation from your point of view. What actually is a multisite? What is the difference between a single site as you call it, and a multisite in WordPress?

Robert: Yes. So the a multisite is basically, multiple instances of WordPress on one installation. So you have just one normal WordPress installation and you have multiple instances, where you can have different plugins and different themes, all over the place and the users are the same. So it really empowers you, if you have kind of similar plugins and themes on on those sites. For example, the biggest use case is WordPress.com.

So everybody then has an easy installation there or easy an instance there where they can simply ramp up an instance of that in a few seconds. And then they can enable different plugins that are set up for them to be enabled, but they cannot install solutions. So it’s really good for tailored solutions where people have a security net below them to not screw up the installation.

Jakob: Yeah. So that’s actually a pretty perfect explanation, I would say. So you have different websites, WordPress websites, they can kind of run simultaneously and have different looks and different different plugins active. But the installation layer is the same. So they are working on the same installation. How, if you, and we are going to do that in a couple of minutes, if I now make my single site a multisite, what is the differentiation, what is happening, a technical perspective as well? What is the difference?

Robert: So, the smallest difference is that you need to log in again. Sorry. Because some cookie things were going on and you need to log in again. And then new tables are able to create, because they were already able to create in the database. But now a WordPress is prepared for, like getting those people in. And then a few extra tables were already installed for the usage of more sites on that. So I think there’s 3 or 4 tables already installed. Like already activated in the database. And then more tables can be added, in a seconds notice.

Jakob: Yeah. And just for the users: you don’t have to enter the tables or create the tables by yourselves. WordPress will take care of it. So by default, as far as I know, I think three extra tables are registered when you create a multisite or make it a multisite. And then one or two things I want to mention is, you will then see, and we will see that in a couple of minutes, a network layer. So you have now a network setup where you can maintain and manage all the sites, but each and every site is specific in its own and can then manage the plugins or themes.

And you also get a new user role essentially. So, not a user role that you see on a single installation. But you can see, once you create a user or edit an existing user, you can now check the box of giving this person, this user super admin access. What is a super admin, Robert?

Robert: Yes, a super admin is a user that has access to all sites in their network, not in the installation. We will come later to that. But in the one site where they have the user capability of super admin, they are more than admin. They are super admin. Just imagine them with a cape on their back. And they have the possibility to jump to all the sites in the multisite, because an administrator as the normal maximum capability on a single site, those users cannot go to a different site in the multisite unless a super admin made them be admin or a different user role in a different site.

Just imagine WordPress.com: they are already separated from each other and they cannot simply jump like, simply not log in into the other site, because on the other site it can be a totally different users. And then only a super admin can log in in all these sites. And because they have already access to them and they can make anybody else a super admin, or they can give like an admin into one site, be a subscriber or an author on a different site.

Since WordPress 3.0, since 2002 this is already a capability brought into WordPress.

Yeah. So because we’re adding an extra layer of management a network management layer, we need an extra capability essentially. So there can still be admins on each specific site, but they cannot or don’t have to be super admins and see all the sites, because this then needs to be a separate capability, because from time to time, you might only add an admin to a specific site and not automatically give them access to all your sites, because this could be kind of tricky.

Jakob: So just to get some terminology right. So we’re talking about a multisite. A multisite has then this layer of network. A network is the entire management layer inside the multisite. So, you’re also going to see it in the URL as well. So there’s some network wp admin area. And each website is a site. Or you can call it sub site for example, which is a website on its own.

We tackled super admin. So this is like the basic type of terminology of what a multisite needs or has. Now you already mentioned WordPress.com and you also kind of mentioned there are a couple of features that can simply be activated. Do you think there is a reason why a user, when he or she sets up a multisite, should not be opting into that feature? Is there a reason for you for not using a multisite?

Robert: Yes. The the easiest like the dealbreaker for multisite is if the WordPress installations are completely different in plugins and themes wise. So, if for some reason you have your own multisite and you decide to have one, like let’s say you have five sites in a multisite and you decide to have a different SEO plugin and all of them, I would say like please consider a different genre in your line of work.

But some people maybe that’s an easy way to have a differentiator. If your mapping of plugins is so different, vastly different from all the other sites, then it doesn’t make sense. So for example, if you think about like, hey, WordPress.com sounds awesome, I can do this. I’m now offering a hosting service and I’m hosting WordPress on a, like I install in multisite. And then I start hosting and charging people to have run the websites. This was tried a decade ago.

Please don’t try it again. It will not survive. You will not survive that. It’s not a sustainable business because many people before you tried it. I’m not saying do it. I’m just saying, the track record didn’t check out for that. Because you’re competing for example with WordPress.com and they offer a free website, so you have a hard time competing with those people. And we saw hosting companies do this. We saw entrepreneurs do this. And, I do not know a current existing hosting solution similar to WordPress.com that is successful. If someone hears this and goes like, I have a successful solution, please come forward to me. I’m really interested to hear that. But the normal way is, if that is your goal and you have vastly different plugins on all the installations, multisite is not a solution you’re looking for.

Jakob: All right. And so, we tackled like this is not what you’re looking for. What are examples, what are scenarios or use case where you would say this is ideal, you should use or at least try to use a multisite for this? What are some of the things you can think of?

Robert: So, wordpress.org has a showcase. And in this showcase there is the flavor multisite. So what I’m now telling you is not the Robert thinks this is use case. This is a use case. Universities. So universities have for example departments in the university that are allowed and able to have vastly different looking websites, because you have the physics department, you have to chemical department, you have the economy department. And all these areas have then their own subsite, so they can have like other parts of the curriculum on those subsites. So, multisite simply enables those admins to be in control of the installation and to be in control of managing those plugins, those themes in the whole installation and have a visibility of, what users are on there? We now have new students that need to come in.

They need access to this department or someone is leaving the university. So they need to remove the access and they just remove the access on one WordPress installation, because it covers all sites in the installation. So it’s an easy onboarding / offboarding solution. And again, an easy way moving forward with that. Like simply using those capabilities and enabling new departments to sprung up and to be having the possibility to really be at service for their students.

And the other thing that we use and have as its customers is the feature called Global Brand Management. So that means that if you are a global company and you are the technical owner of those, sites, we had phone calls ages ago, about 1 particular big pharmacy person. And they were in charge of old sites of this company and they had some nightmares about some of their sites been hacked. Because in some parts of the world it’s just their marketing department and that country just needed a landing page for a local conference.

And they were just paying someone, spinning the site up. And after the conference, everybody forgot about that site. But the site was still online with the URL of the brand. And nobody did updates, because why? The event is over. And the hosting was paid for one year in advance. So from a hosting side everybody was fine. But the brand manager or the person in charge of dealing with the branding impact of a hacked site and defaced websites. They were really interested in the solution that enables them to know that old sites are on the current version of a plugin, and that if they change, for example, the CI, CD, the corporate design corporate identity of their brand that, all sites adhere to this change. So they were really looking for basically a multi-site installation to be able to have a possibility to rake in all the different installations, all the different kinds of deployment that they, that all the websites have in their whole company.

Jakob: So instead of creating single sites for this specific use case, like we have a landing page for this event, you would suggest they create a website in your multisite network? You can make sure it looks all right. And once the event is done, you will still see it in your dashboard. It will still show up. You can now turn it off or delete it entirely, or at least see and then see what’s going on. Have it compatible with the WordPress version, update it because you’re only updating one instance. You don’t have to update each and every site and therefore maybe forgetting about a site like this.

So we talked about universities and use cases where you have the same design or like global brand guidelines. One thing I would like to add there as well is franchise websites, because at that point as well, you do have several different sites and each site has to be maintained and kind of operated individually a little bit. So the site owner, maybe the franchise owner, needs to again have different opening hours, different things. They want to kind of publish or they have different marketing content essentially. But each and every site needs to be set up really, really similar. You need to maintain them all. Like obviously the franchisee probably won’t do WordPress updates.

So you need to take care of that. And also you have the exact same thing. You need to have global brand guidelines that need to be consistent across all sites. And you have like this similar user base. You won’t have that vastly different plugins on each and every site active, because the setup should or is probably exactly the same. And I think another use case that you forgot to mention is multilingual websites, right? Yes, you don’t have to use a multisite to make things multilingual. But I think you have quite an opinion of why would you use a multisite for a multilingual site? Is that a good idea? Is that a bad idea?

Robert: So, yes and no. I added them to the if you are global brand manager then you have like for example, Portugal and Brazil. Their languages are like similar ish, but they are different countries. And you do not want to have the one person from Portugal touching the sites of the Brazilian website. So in that regard a language is already like an extension of the global brand management. But if you are in one country, you just want to have different languages.

The multisite offers you the capability to have posts and pages in different languages that you don’t need to have a plugin do the translation. Or the possibility of the fallback of the language, because, for example, if you’re using the single site plugins and we know why the single site plugins exist, because there’s nothing in core yet that you can do, like it’s on the roadmap, but it’s not in core yet. And so the single site plugins, if you, for example, have a German website and you want to add an English translation to that, then the normal WordPress would simply say like, okay, that’s a 404, you just take the URL that you’re entering.

I have no idea what you mean. I have no idea what you want to see. It’s a 404. And so, those plugins need to then jump in and go like, no, no, no, it is a site. This is a content. Please show this content. And with multisite we don’t need to do this, because multisite will simply see like, ah, the URL you are entering before the site name or the post name, that’s the French version of the website. I mean, like de.yoursite. Yes. Or like example.com/fr/ and then you have like contact and the WordPress will say, okay, I know the first starting of the URL, you know, it’s subdomain or subdirectory or own domain because that’s the luxury of of multisite.

You can have your custom domains for your custom language or for a different language. And so WordPress will already work on that and then show the post in French, show the post in English, because that has nothing to do with translation plugin. Translation plugins are „just“ there to connect those translations with each other so that you don’t get punished by search engines and that you can link between them on the other sites. Other than that the translation plugins in multisite really just enable you to work easy on the backend and make sure that the front end is connected to each other.

But the lion part of the equation on the single site plugins for translations, that is a core feature that we simply use on the multisite way. So that we have less performance things that we need to do, like less calculation. So as I always say, the multisite translation plugins produce performance like trees produce oxygen, by accident, by simply existing. So we are not standing in the way of WordPress core, our multilingual press is not standing in the way of a website being rendered, because that’s all cor and we have nothing to do with that. So that’s why we don’t add extra processing, calculations to the database codes and all of that. That’s just core. That’s not us.

Jakob: Yeah, I do like this aspect of it, like this performance aspect because it’s already core. And you’re just using a feature that core offers and using several instances, several sites as different country specific websites, you’re not adding the layer that the plugin then needs to configure. Okay. Which language are you actually viewing? Okay, I need to go through the database and look at the exact right post. Now deliver it. You don’t need that layer because you just have a single site for it.

Okay. We talked a lot about multisite yet. Let’s maybe just quickly go through the process of how you can actually enable something to be a multisite. So I will share my screen real quick. I’ve set up a really simple local installation of this case. So this is a bare minimum WordPress installation. It’s a single site as of now. And it doesn’t include anything. So this is a default installation. As of now it doesn’t have any plugins. It doesn’t have any specific themes in here. But now it’s simply just a single site.

So let’s go through the process of what we need to do for this to be a multisite. So the first thing that you need to do is actually go into your WP config file of your site and make sure that you add a line to it. So I’ve opened up my WP config. You probably don’t specifically know where this is. So this is usually on your hoster. You can connect via sha, FTP, however you would like it, or your live console like Plesk or something. And in the root installation of your WordPress, you will find a file that is looking like this and it’s called wp-config.php. And if you scroll through it a little bit.

So there’s a lot of things going on. You don’t have to take care of it. If yo scroll through it a little bit, you see something like „add any custom element between this line and stop editing“. Right. So that’s the stop editing. And in here you can add stuff. And the first thing you want to add here is this little line I already previously added but commented out is this „WP allow multisite true“. So this is the only thing that you essentially have to do. So this I will save this now. Usually you have to then uploaded it to FTP. But right now I’m just saving it. And now I’m refreshing this site. And you see nothing has changed, because we only allowed it to happen, but we haven’t set it up yet.

The one thing that you will see appearing is, using tools, you can see this little item „network setup“. So you go through here and now you see you have a decision to make. So Robert, maybe you can tell a little bit about? What core decisions you need to be doing here. And maybe some pros and cons on why. Actually, what is a subdomain? What is a subdirectory?

Robert: So, a sub domain means a URL point before the current domain. So if you have example.com for example, then you have like, if we do it in an localization way, in a translation way, then we would add like for example, the local. So it would be in this example here site-1.Worpress-test-7.local. And the benefit for that is that this is a way of making sure that you have a different URL. With the downsides of cookie can be a bit messy. And the default is then you need to have this subdomain pointing towards the WordPress installation.

So that’s why, in my opinion, it’s not really the the most used feature, because the problem is you need to have the URL you’re just entering for the first few steps, you need to kind of have this to be reached. And you also run into like, okay, then you need to have a SSL certificate. And like all the mess that comes with new domains. So that’s why a wild card is then an easy way to make sure you have the subdomain up and running. The problem is again, then with your hosting company, that if they are enabling you to have this possibility. So I would really recommend to use subdomains.

Then you just have a subdirectory, in your WordPress installation. Cookie wise it’s very easy as well.

Jakob: You mean you would recommend subdomains or subdirectories?

Robert: Sub directory.

Jakob: Okay. Because you just said subdomain.

Robert: I’m here to confuse.

Jakob: Just to clarify. So if you’re having subdomains – obviously this is not a beautiful or nice looking looking URL – but essentially you have to each time register a new site, if you don’t have a wild card record, you have to tell your server essentially that this subdomain exists and points to this installation. So you have to have a different step under setup level on the hosting level essentially to register that site. And if you have subdirectory, Robert, I think you’re pretty much easy to go and just create a new site, correct?

Robert: Yes. And with the features, since I think 4.4 or 5.4, after you created it, you can simply change then again the URL, to whatever you like and keep in mind whatever points to the server. So you cannot simply enter facebook.com and imagine the like then like receiving website on this URL, you need to make sure that from your server configuration something points to this URL, to this server, to this WordPress installation.

Jakob: Yeah, exactly. So, thank you very much for explaining. So we will not go for subdomains, because I haven’t configured anything here locally to make this running. But we will quickly take a look at how this can be later on than used anyway. So we will opt in for going with subdirectory, which was much easier. And we can name our network. I don’t necessarily need to do this right now. I can change this later as well, but WordPress test 7 sites is fine for now.

So I have clicked set up. Now you’re prompted with this screen essentially. So this looks a bit techie and it is a bit techie to be honest. But now you need to be doing two more things. And the first thing is you already added to the WordPress WP config file. And now we need to add some more to it. So this entire text block, select this text, copy it and go back to your WP config. And you can actually remove this line. You could keep it, but you can also remove it and insert the lines prompt it. Be careful here. Don’t reload that screen right now, because you also have to copy this entire setup.

And this you need to be adding to the htaccess in here. So the htaccess is a file that essentially like this server needs to kind of know where to point to, which URL points to what file. Essentially you could frame it a little bit like this. And the htaccess should already be there in your root WordPress installation. So at the same level of your WP config file. And again, copy that text and go to the htaccess. I already opened the htaccess. And you can see here I need to get rid of this entire set up.

So I delete it. I can also get rid of the comments in here, but I don’t want to. And I have to insert the rules that were prompted to me. I have to make sure that I save this. So I saved both of those and now I can actually reload my site, my backend. And now I will be prompted to log in again. This is what Robert was referring to. So now I have to quickly make sure that I log in. So this is just because cookie things are now a bit different, and now I’m logging in and I will be redirected to this exact same page. But you can see it’s already not really an actual page. And now this is a multisite. So that’s it. That’s now our multisite.

And we take a look at the front end and nothing has changed. So for now it is technically multisite enabled. So we do not have multiple sites here. We do only have one site. But the one thing that is different now is you can see this little „my site item“ showing up in the admin bar. Also, if I go into the backend you can see the same site and there you can see one site. For now this is the only site we’re working on. And you can see network admin. And this is what we were referring to as network. But maybe if I click on this dashboard you can see the URL of your site is now changed.

So you have WP admin and then network. And this is the management level of things where you can now add new sites or add remove old sites. So the easiest point is going to sites. And there you can see my site. You can see your sites that are existing here. You have a set up for users, you have a set up for plugins and you have a set of themes. Let’s maybe create a site and talk a little bit about the problems that you could be facing here. So creating a site is as simple as this. So because I went for the subdirectory approach, I’m now prompted to create the subdirectory that I want to use. So let’s maybe call it site 2.

Just really easy. You have to give it a subtitle, site 2, define a language and say who is the admin? Because admin needs to be created there and click Add Site. And that’s it. Now this site is created. I will leave this here for now. And now I can visit the dashboard, edit the site, I want to visit the dashboard and I want to actually visit the site.

So now you can see this site has the subdirectory of site-2. And that’s where the site is. And you can now create pages in here, posts in here, then those will be added to the URL essentially. And this works as an own instance and own website. In this site I can enter a user, I can maintain my plugins and here I can maintain my themes. In here I can say which theme is active, which plugin is active, and stuff like that, can create new users only for this site.

And I can see it now in here as my second site showing up. And maybe let’s edit the site for a moment because this is Robert what were you were referring to. What if I now want to use a different URL of this site, for example? First of all, let’s take a look at your problem. You described that you could potentially have facebook.com as your second sub site. Should we try it?

Robert: Sure. You can still edit the website.

Jakob: So first of all, because you’re not changing the main network site, you are still able to to change the URLs at any time. So yeah, sure.

Robert: Or use greyd.io and just see what happens.

Jakob: Good idea. So I’m trying to use greyd.io as my second site. Let’s maybe make sure that I copy this URL first to revert it, and I save it now and nothing happens. For now, I can still edit the site. I can still see the site in here. If I go to all sites, you can see it’s now greyd.io. Maybe take a look at visit and now you can see I’m not actually at the site, so the WordPress is pointing me to greyd.io. But this is not actually a site in my multisite, so this doesn’t work.

It doesn’t. If you want facebook.com to point to your website, you actually have to have root access of this specific domain and tell the domain to apply to your site. So right now if I want to visit the dashboard, for example, and let’s go one step back and click on dashboard. Now you’re going to greyd.io/admin, which is not how it works right now, because I’m not logged in.

So I cannot actually do anything with that site. But you’re still seeing your site. Your WordPress is still working. So you didn’t really produce an error there, but it’s essentially not working. But you can have actual other domains pointing you just to your site. You just have to have root access here. But let’s edit it for now and revert it to the site too.

But what you can do now is you can, for example, call it site 3. Let’s do that and let’s visit it3 And now you can see it’s site 3. And I’m still logged in, I’m still seeing my test 7 and the URL just has changed. So it’s really easy to set up the site and specifically change it. And you can now also go to the approach of having like a subdirectory if you want to. But then again, you have to tell the server that this specific URL exists and points to this installation.

So it is a bit more tricky, but you can now change it and actually use subdomains and subdirectories simultaneously. Maybe one thing we can add here, Robert, is what if I already have a preexisting installation or a preexisting website? So for example, in my case, what if I already had a site like WordPress local/muse, something like this, and this was a preexisting website, but not pointing to this installation. It’s a slightly different set up somewhere else, hosted somewhere else. What would be happening, Robert? Is that an issue?

Robert: You mean when you you upgrade your single site to a multisite and this was already an existing WordPress?

Jakob: Yeah.

Robert: WordPress will only allow you to use subdomains, because the problem is with the all existing URLs you already could have, like depends on your permalink scheme. It could already be that pages were named for example site two or you had a post format and just had like post name as your permalink. Then the problem is that those sites would no longer exist. Because if you, for example, have a normal WordPress site and you have dogs as a category or a page, then the problem would be if you now have a site called dogs, the site wins.

The site is the first thing that WordPress finds and goes like, okay, that’s not the site. And the connection would no longer be established. So that’s why WordPress will simply tell you you need to use subdomains, because the problem is, you could overwrite exist sites, existing blog posts. And with that, WordPress protects you. And you can overwrite that. That’s an extra step you need to take. If you start with an existing WordPress site and upgrade to multisite, it can be a little bit more work. I mean, it’s, you know what you’re doing. So that’s why we recommend using multisite as early as possible.

If you already know you are going this direction, that you do not have this limitation or need these extra work steps to make sure it happens, to make sure that works.

Jakob: Yeah, I just created a similar conflict right now. So I created a site, a page that I called site three. Now this page has this URL WordPress-test7.local/site-3. But site-3 is actually the site that I have created. So in this case, if I want to take a look at this page, it will not work. This page is now automatically pointing to this entire new website. So what I have to do is either I can rename my page and not make it called site three, but make it called site one.

And if I now view the page, you can see site one is actually pointing to my site or I can go the different route obviously having this as site three, but this is a kind of an example of the conflicts you’re having. Right now is site three, it’s pointing to that. But I can make sure this is on my site too.

Robert: So I would recommend – like domains are cool – you can simply use domains and multisite. And that’s an easy way to distinguish those things. And if you for example, have language, sites from this country then you have an easy way to simply use a domain from this country to simply like, differentiate all these things and make them really home in those countries.

I never like stumble in this problem because we always use domains and domains are easy to get.

Jakob: Yeah. Let’s maybe take a look at this set up and talk a little bit about the pros and cons that a multisite brings you. So obviously we talked a lot about like management and having shared assets and making sure that you’re kind of overviewing all those sites. So maybe talk a little bit about the setup. So a huge pro that I would say is having centralized plugin and theme management. So if I now want to…

So first of all, in this single site installation, I only have Twenty-Twenty-Five available as an option here. And I can control this. Let’s close a lot of those tabs. I can control this from a network level. So in terms of themes I can now say, okay, these two themes are network enabled and I can also add a new theme. Let’s maybe use the Greyd theme, install it, automatically installed, and then I need to make it available for my network.

So I make this network enabled and now I have the options here of actually activating a different theme. And each and every installation here can have their own themes. So I will go to site two and use the Greyd WP theme to actually have a different appearance in this site then on my other site. So the main site has not changed at all. So let’s take a look at the main site. Visit WordPress site seven. So this hasn’t changed, but site two has changed and has the Greyd theme now active.

I can do similar things for plugins. So in here, because we’re not in the network right now, we are on the single site instance, I can not actually install any plugins, so the admin doesn’t have control over installing plugins. But on a network level I can opt in to install some of the plugins. So for example, I don’t know, let’s just select the Gutenberg plugin for now, for example, and installing that and now this plugin once installed becomes available to all the sites.

And this is one of the pros. You have shared plugins, shared themes and shared versions of those plugins and themes. But it’s also maybe one of the downsides. Robert, what do you think?

Robert: Yes. So we have like three versions of plugins, in compatibility with WordPress. So we call them the non compatible plugins. That are plugins that were written by pigs running over a keyboard. And there are more plugins as you can think in the WordPress plugin directory and elsewhere on other plugins sites that are really, a disgrace to programing. And those plugins can have errors on multisite. Because multisite is a feature since WordPress 3.0 in WordPress, but not all the plugin developers know of this feature, and not all plugin developers are using the WordPress APIs to do things.

There are still people there that actively like changing things in the database without using the API of WordPress. You should not use these plugins, but you will bump over them and simply go like, oh, why? Why is this plugin not working yet? That’s one of the reasons. The other plugins are passively compatible. So they are not really programed for multisite, but with them using the functionality of the WordPress API and adhering to the rules, the programing rules of WordPress or WordPress core standards.

Their benefit is that they simply work in a multisite without needing extra care, like making sure that the things work. They just work, but they are not actively doing something for multisite. And then there are the actively compatible plugins for multisite. If you install them on a multisite, you might not see anything in the single installation environments. But you might see a difference, a new button in the network area because they know they are installed in a multisite network and you go like, oh yeah, my features are different in a multisite, you can now manage me for all the sites, I have now a standard and maybe other sites in the multisite can work differently, with their features, but they have the benefit of simply using active components of multisite and enabling administrators of multisite to being used in.

Jakob: Right. So yeah, it is great that you can enable and maintain plugins from a global perspective. But this is one of the heavy downsides. If you have a terrible plugin that crashes your site, chances are your entire network is conflicted and your entire site couldn’t work anymore. So if you for example, have a fatal error in one of the plugins that you network enabled for all of your sites, all of your sites will stop working.

But it’s also kind of easy then to get rid of the plugin, because you only have to get rid of it once and remove it from your installation, and it ultimately is removed from all the sites. And similar with themes and other things. But this is one of the downside. If one site crashes, this could potentially affect other sites as well. If you have a malicious plugin in there, this could really affect this.

Robert: I need to quote myself: don’t run bad code. So that’s why staging sites were invented. And if something touches your production environment, make sure you know what is doing and don’t try out things on the live sites, on the production sites. Have a staging environment for that to then break and you can simply get rid of it. So that’s why don’t run bad code is the thing that I really hold dear to my heart, and empower everybody to please think before you enable plugins.

Jakob: Yeah. But that’s also where multisite steps in kind of in a nice way because once you’ve confirmed that a plugin works the way you intend it to work, you can make sure that every site has access to the plugin. But they don’t have access to whatever plugins they feel like. So they actually cannot install a terrible plugin because you have full control over what plugins are available in your installation, and you have that control layer, instead of them being able to just plug in whatever they feel the need to and have everything in a plugin and have a lot of terrible plugins running. So then multisite steps in and gives you a lot of control.

I think another advantage that we have briefly mentioned is users as well. So now you can actually maintain users on a network level. And once you’ve added them, I can not be removed here because I’m the only user and WordPress would essentially not work anymore. But once you’ve added two users, you can remove them for the entire network from here, and you will already see the sites where the users are registered to. So this is what Robert was referring to. It is really easy for you to onboard and offboard people.

You can just create the user for the entire network and then get rid of the user. And also same thing for themes, same thing for plugins, and some settings as well. Like in a default multisite you only have these settings. But for example we create registers a lot, a couple of settings as well, where you can define something for the entire network and each site then also already uses those options. It has this kind of forced on them. So yeah, I think that’s a good overview of what’s downsides and advantages we have in multisites.

Robert, I now want to actually shake things up a little bit. We have a lot of in-depth discussion now. And we’ve seen some live demo. We’ve seen some code that we actually edited. Now I want to do something different. So, I want to ask you some quick questions. Some of them might be WordPress related. Some of them not at all. And you can feel free to answer them however you like. You can just answer them with a single word. So the idea is maybe you give a brief answer and we go on to the next question. But you can also go ahead and share the story behind it. The last question is probably something where you want to talk a little bit longer about it. So for now, everything clear? Can we start?

Robert: Yeah.

Jakob: Okay. Robert, are you a morning person or night owl?

Robert: Both.

Jakob: Both? Why both?

Robert: When I need to be up in the morning, I am up in the morning. When I need to be up at night, at WordCamps for example, I’m up later in the evening.

Jakob: All right. Good answer. What’s the first website you’ve ever built?

Robert: Geocities.com/a10/delphi/9778 was a website with my friends. In 1997. Yeah. Actually that URL works as of now. GeoCities is no longer active. But you can it’s like, people saved GeoCities. The problem was we were using frame sets at that time, so not everything that we did was saved on these sites GeoCities from being turned off.

Jakob: But I find it interesting that you remember the URL, which is kind of specific.

Robert: Yeah, perfectly.

Jakob: What is one WordPress plugin you cannot live without?

Robert: That’s a good question. I would say, we currently work on a plugin called Multisyde, and we are using it on all multisites we’re using because there’s an easy way to get new features tested that everybody in multisite could use.

Jakob: That’s interesting. If you could fix one issue in WordPress forever what would that be?

Robert: There is an idea of getting multisite as being the standard. There are things we need to do before because the problem is multisite cannot run on all servers on the world. Because as you select installations, is is a little bit weird in some ways, and you need to have server configuration up running. But if can get people to have, if the server is ready to have multisite enabled by default, that would be something we would love to do. And I would love to do it. My company would love to do, because that would enable more people to use this feature, because some people are afraid of multisite, because the installation seems…

I totally get it. I’m technology background. It can be confusing. So, that is one thing. We would love to have an easier way into people using multisite.

Jakob: Yeah, I agree essentially like making it multisite ready by default.

Robert: Yeah, there are ups and downs for that. We need to make sure that servers are ready because people run WordPress on a toaster. So maybe it’s not multisite ready, but your normal day to day WordPress hosting solution could be already subdirectory ready. So that’s something we really would love to have in WordPress.

Jakob: All right. Next question. What is the most unusual place you’ve ever worked from?

Robert: Airplane, but it’s not unusual.

Jakob: Yeah.

Robert: I was once in a bar in Berlin. We were having fun with each other and, like, simply being at 2 a.m., having jokes with each other, and I opened my laptop to do something, so maybe that’s unusual.

Jakob: So you were drunk in a bar. Okay.

Robert: I’m not drinking alcohol.

Jakob: Okay, just having fun in a bar.

Robert: Like, I don’t really have something weird, because everything I do for some people looks weird.

Jakob: Okay. What’s your favorite, non-technical hobby that keeps you creative?

Robert: Like, it’s still technology, in a way. It’s just keeping up with AI and how, like, people engage with each other using technology. So it’s the same thing, like understanding how technology shapes society. Because that’s my day job. And that’s the thing that I do for like over two decades. So that’s something that I do as a pastime hobby. +

Jakob: Okay. Last question. What are a multi multisites?

Robert: They are called multi networks. I coined the term because it’s easier to understand what it is because it’s a network upon a network. So it’s the same thing as we have with multisite, but it’s multiple installations, multiple instances on one installation. And the only thing that is now different is what you just created, and the sites that you added, this was all in the network one. And there is a table in the database, with the sites in it, and you just can add two, three, four, five, six, seven and as much numbers as you can think about.

And these are all different sites, the different networks. And you can have sites in these networks. And as I told you before, you are only the super admin in this site. So the benefit is that you can have a different site where the super admin of the one site is not the super admin of the other site. And the benefit for that is to really enable, for example, different sites you can spin off easily landing pages. For example, you can give someone from marketing an URL and they can simply spin up as much landing pages as they want, but they are not interfering with the main multisites, with the main networks.

So they have their own network, they have network activated plugins and they can be their own network super admin in this network, but they are not a super admin in the first or second networks. So they can simply roam free there, install themes and plugins, or you can easily also limit that to them that you cannot install plugins, cannot install themes. And the benefit for that is really to empower more people to move faster and staying on the same WordPress installation.

Jakob: But I use multiple sites because you coined the term. I’m aware. I’ve heard you say it a couple of times, and I actually read you say it as well. But it’s not a core feature, right? How does it work? Can you explain how could I now convert this? I’ve created this multisite, how do I turn it into a multi multisite?

Robert: That’s the fun with that. This feature was already added in WordPress 3.0. So it’s over a decade old this feature. The only thing missing is the interface for that. Not everybody needs an interface for that. So if you add a new site in it and they add a new line into the database of this table, then you immediately have this site created and you can move sites over. There is an interface for that, it is called Multi Networks.

And then you have an easy way to have a bare minimum interface to interact with these networks. But you can turn off the plugin multi networks. And it still works because the feature that enables you to have different sites in different networks, that was already merged with WordPress in 3.0.

Jakob: Yeah, that’s what I was referring to. So if you are interested in having multiple multisites, kind of like multi networks running, check out the plugin. And probably read through some of the things Robert is discussing or talk to him on one of the next WordCamps. You always find him. I quickly want to talk a little bit about some myths. So there are some myths around WordPress multisites. So I think you’re probably aware of some of them or clients or people who ever came up to you and said, I don’t want multisite, I don’t want to use it because it’s just for blogs. So for example, that’s something that I’ve heard in the past. What are some of the myths you can think of and are they actually valid or is that more of a myth that we say that’s not valid?

Robert: So, the ones that are most prominent that we hear often, we already busted a few of them in this conversation. So the one that I always hear is, it’s inflexible. So people think that not being able that everybody can add a plugin means you cannot add plugins, but you can easily do that as a super admin on the site and like, add them to the possibilities of plugins to be enable. So it’s really something where, if you need for example, for compliance in one country or in one in ten sites you need those plugins, you can add them in those ten sites, or you can network activate them.

You can have a different multi network and have a plugin network enabled in this one and not in the other. So there’s also the possibility of flexibility. You can have different themes, you can have different child themes. And you also have the possibility to extend except where you have like domains match to that.

And the other one that we hear is multisite is unstable. But we already covered that, because with it being merged into WordPress 3.0, which is like over a decade old, it’s really stable. And we already covered the different versions or like different compatibility with WordPress of plugins. So that is the most breaking thing in WordPress and deemed them to be unstable because people used very bad quality of plugins and were wondering why a five bucks plugin that they simply had or a plugin they wrote themselves with vibe coding that it’s not really working on multisite, because the APIs are not really used and that’s why it it can break.

And the other thing that we hear very often is that multisite is too complicated. And I totally get that.

Jakob: That’s one where I think that’s actually a little valid as well. Yeah.

Robert: Yes and no. You are also I think, bad at arching. My assumption. Jakob, I don’t know you, but I think you are not good at arching. That in my opinion, is because you don’t have the training. So if people never used multisite and they think they can like walk over water on multisite? They are probably not. And the fun thing with multisite is that, whatever problem you have, whatever problem you run into in multisite, there is a good chance your problem was solved a decade ago, that someone solved it in 2015.

And you just need to use the same solution, whatever your workflow is, that you say, I need to have this particular workflow. It might be that we already discussed that, we as a community were already going like, yeah, like that’s solved since 2018. And people think they just use the normal single site knowledge and then go like, yeah, that’s the same thing. It is, except in a few instances where it’s not, like the user is shared and people don’t really have it in their mind, whatever they do that they know, the user is the same on all the installations, all the instances.

So it’s really about, the workflows that you need to unlearn, like some things you have that you got like, I always do it that way when I install a new WordPress and you don’t because it’s you just setting up installation or an instance, you don’t install WordPress. And one thing, if you’re using multisite and you are a professional, like you are not shying away from command line, but you’re not really into that, I can recommend to you WordPress CLI. It’s a command line interface for WordPress.

And if you manage more than one site, for example, it’s a real time safer. You can automate things. You can have the possibility to connect commands with each other. So you can go like give me all the posts that have this particular category. And now I’m adding a new category to that. I’m adding a new user to that as the owner of these posts. So you can connect those things. And that’s just a command line example for WordPress. But you can also use it for multisites to install plugins, to manage users, to manage capabilities.

And that’s the one thing each multisite user like needs to know. You don’t need to use it, but you just need to know that there is a command interface for you out there that could really ease the way you work with WordPress.

Jakob: Yeah. I want to add one thing to this term that I said it’s too complicated. I get the feedback. That’s what I mean, I understand that. I mean, what I showed right now, it took me a couple of seconds or maybe a minute, obviously the most time I was wasting because I was discussing what I’m doing. But setting things up, it looks complicated at first. And once a lot of users we’ve talked to essentially told us, okay, once there’s something, that code I need to paste somewhere.

Oh, that is way too complicated. I’m not touching that. So this is something that I can see. This is valid. This is complicated for users. Not just a button that I click. And essentially it just automatically does something for me. So that’s where I see okay, it is a bit complicated. And also you have to understand really what network and network management, what this layer does. So you have to understand a little bit. So it’s kind of complicated at first.

But once you understood it and this is one thing you have to understand, then I think it’s really easy to use. And obviously, yeah, we have to rethink 1 or 2 things, how you approach things. But I can see that this is a valid myth or criticism of multisite. It’s a bit complicated to set up if you’ve really not ever touched any code.

Robert: Another myth. The last thing that I hear: multisite is too slow.

Jakob: Yeah. That’s the one I was going for as well. Maybe share some insights from your process.

Robert: Yeah. So, multisite is slow comes mostly from the people that are not aware that they now host like 5 or 20 WordPress sites on one installation as they were ordering different like, it depends on the hosting solution, that you have different hosting packages that you would do for 20 installations of WordPress. And then you assume you can do all of that in one installation because it’s all managed all the same.

And you don’t like really ramp up the performance or the quality of hosting as you do for like managing 50 or 100 or 200 sites in one multisite. And that’s the most thing I hear from people when I’m asking them questions of like, okay, how did you estimate the size of the network you’re having? And the follow up question is then like, do you use object caching? Which is again, that has nothing to do with multisite.

There’s nothing multisite specific, it is just that, if you going into the more professional side of WordPress and multisites most of the times is, then normal ways to speed up your WordPress and up to caching means that, you have stuff that were coming from the database. Normally it’s throwing away every request you’re doing. WordPress will calculate the menu on the navigation and throws it away after the site has been rendered. And the possibility for caching is for example, to simply have this menu or the navigation with all these sub elements there, tho have it in the memory of the server and to not have a database query for that.

So this easily speeds up WordPress. And that’s in the professional world, a normal is a thing to simply use object caching. But it’s not really a known thing for people that just enter this field. So, the easiest way is simply estimate how big your website can be, go to your hosting company, tell them what want to do, and then they maybe give you a different and more priced environment. But that’s also then be able to handle the load of like 200 maybe not big sites with much traffic, but 200 small ones with maybe 1 or 2 sites that have more traffic. But then you have a hosting package that really can handle those kinds of requests.

Jakob: Yeah. So, are there any specific things other than object caching? Do you see any issues if I have like like WordPress.com is a multisite? So are there, from your experience, any limitations of multisites? Can I manage hundreds of sites? Can I manage thousands of sites? We don’t want to go into detail, but in general are that some of the things that I need to be able to do or take care of in order to… Because I also hear this ah, it’s not scalable. It’s slow. You cannot really manage a lot of sites. Do you see any limitations in terms of the size of a multisite? And if you do, where is that limitation or is there none if you take care of specific things?

Robert: As you know, lie WordPress.com has like I think millions of users. So there’s not really a limitation in a way. There is like Ludicrous DB there’s hyper DB, Ludicrous DB and like other database drop ins for WordPress. If you know you go over 100 sites, then the possibility of using those features to simply ease the load of database so that you have, for example, multiple database servers or can move WordPress sites to a different specific database server to just make sure that they get enough resources as they need.

So those limits on, or those are specific things you could do, you should do if you know you going in a bigger number or region for WordPress sites. Like if you are already thinking you are going ahead over like 5000 and whatever like that amount of sites going up there. If you already know you go in this direction, you need to have, like a database drop in to make sure if you, horizontally scale WordPress to the web server, there needs to be a way for you to also tackle the database load and not have it on one server, because that would be insane. There’s no server big enough. No database server big enough to handle that.

So that’s why, everybody in this field who uses more than a few hundred sites and moves that or even if you go over 100, you should think about that beforehand to have an easy way scaling up all these sites.

Jakob: Yeah, that’s what I’m seeing as well. Like if you want to go in these thousands of sites, you should probably take care of how your database is loaded, where it’s hosted and stuff like that. But usually I would say as well, if you’re not going over the hundreds, if you’re in the tens, I would say there’s not, like obviously it depends a little bit on your traffic and stuff like that as well. Like you have to think about the load and how you want to set up those things. So don’t host on a toaster. Like Robert, you would say that.

But essentially if you go in that direction, you shouldn’t have any significant performance issues. But yeah, the database in thousands of sites gets large because obviously there are more posts, more content. If you have more sites in general. I want to quickly talk about, what we are doing as well. Like, what Greyd or what multisite does for us because, as Greyd, as the plugin we give to our users, obviously there’s a lot of things that we can actually enable for our users by default by just using multisites.

So I want to quickly share, how this looks in WordPress. And you can see this is a demo installation of mine. But by default because you have a multisite installed, in this case it becomes really easy for you to just maintain your sites from one perspective. You can preview you sites, you can see what is going on. You can migrate a site from point A to point B, you can see what is going on in all your sites, and you can even like maintain database files. Everything in each site by just having multisites enabled.

And you can easily create new sites similar to multisites, you can connect them and you can also then for example enable features for all of the sites. So there was that. That’s what I was referring to. We for example specifically registered settings for multisite networks. So you can force sites to use specific features or for sites to not use specific features like having advanced search capabilities, having accessibility rights and stuff like that.

Enabled by default and forcing then kind of into that. Also settings are registered as well. So you can configure something once and each site is just using it. You can navigate a user from a global perspective. And then just to tackle what brand guidelines Robert you were referring to. If you have multisites enabled you don’t need to connect similar sites to each other because they’re already connected. They’re in the multisite WordPress, each and every site potentially knows about the other sites and what is going on there.

So you can now use content across the sites. So for this example, to give you a little insight of what is happening here, we have two sites here which can have different brand look essentially. So they’re looking a little bit different. The styling is different but they’re kind of using the same content. And here you can see those tiles. Those boxes below here are in the same layout. And they’re reusing a lot of the content. That is in some places just by default. There’s nothing fancy we do on a hosting level. Nothing in here. Just by having multisites, you already can utilize a lot of the features that we offer to you.

And if you have a plugin that does it as well, multisites just enables you to do a lot more things. And then it even goes the way that you have. Like you can implement global search. You can you search through all your sites at once. You can use a site to search all your posts of all your sites and take the user directly to the site, that they actually want to use. So a lot of things that usually would only be possible if you have a really complex set up and API endpoints, and a lot of communication between sites, it is just easy to use for you.

Just use multisites. So we love multi sites. We love it as a feature. Users can create instances like this where you can essentially maintain all your clients project in one instance and see what’s going on everywhere without the need of having complicated server setups and complicated stuff. It just out of the box works and gives you a lot more flexibility that you otherwise wouldn’t have. So yeah. Thank you very much for, Robert. There was a really, really insightful discussion. Is there anything in terms of multisites or maybe not in terms multisites, you mentioned the plugin that you working on, anything else you want to share or want to add to the conversation? One thing that we didn’t tackle when it comes to multisite, anything you can think of.

Robert: Yeah, it’s a plugin that I already mentioned: Multisyde with s-y-d-e. We are looking for people that use multisite and to get like the small annoying bus that they are having or, like features they would love, that would make their life easier. Also from you Jacob, the things that you really would like to like as a default in WordPress or in default in multisite. That we can get more people to come forward and don’t keep their bugs, their feature, which is good himself because we know that the issue tracker for WordPress for multisite is not really actively used by many people.

And so we would love to have more engagement with people that are using multisite and to come forward and go like, I have like these kind of 20 lines of code that I add to every installations of WordPress where multisite is used. And we would like to hear them and we would like to have a discussion if there’s something in there that could be, maybe merged into core. So we would really want to hear it. And also feedback for multilingual press.

So if people are using, multilingual solutions, and they are already knowing multisite or they want to explore multisite for that regard, we are happy to give people some training, testing licenses to simply get a feedback because we think for a multisite solution, it’s really an easy way to use multisite for that, because the environments are really so close to each other that there is a benefit of having not that too much of like workarounds as some single site plugins require. So really, we are looking forward to get some feedback from people, who would like to use that. Yeah, we definitely have to stay in touch in regards to the plugin because I have ideas. Feedback.

Jakob: All right. Yeah. Thank you very much, Robert. It was a pleasure, that you’ve been here. Thank you very much for taking the time. I quickly want to mention the next conversation. The next Greyd conversation will be about AI. We have two really, interesting people in the conversation. I will be joining as well. Because we’ll be talking a little bit techie, a little bit in the AI stuff. We have some thoughts, some things we want to share and we want to discuss a lot. So stay tuned. Check that out and also subscribe to the YouTube channel.

And you can find each and every episode as they are appearing on our YouTube channel. Yeah. So, I hope everybody liked it. Robert, thank you very much for being here. Have a great day as well. And, I think we will hear each other in the next episode. Thank you very much.

Robert: Thank you.

Jakob: Bye bye.

Music