 Hello Johnny, how are you? I'm good, thank you. How are you? I'm great, I'm happy to meet you here and happy to hear something about multisite music. Can you tell us your multisite story, how you got involved in it? So I've been using WordPress for 13 years now. I started on my personal blog and I loved it. I have made a career out of it. I worked in the agency for a while for four years and then I moved to Time. Time in the UK is the UK's largest magazine publisher. Time is one of the world's biggest publishers. Time magazine is a big brand and it was a massive step up for me to go from working in a relatively small agency to working on this massive WordPress site. I felt very panicked. I didn't know very much and I spent probably three months of my life really deep diving into WordPress. I felt like I wanted to know it deeply. The project was a multisite project. Time into like 660 magazine websites that they have there and it made sense that it was a multisite. It was one theme with lots of customiser options, the massively customising, the widget based. So it was 660 websites in the one instance of WordPress? But when I started the project, it was only meant to be for smaller websites, originally only meant to be 30 sites. It didn't care about as much as smaller brands because they were costing a lot of money to maintain a set of different instances of WordPress. So it made sense to underline them all together into one that can sort of WordPress. By the time I was leaving, it was such a nice platform and so easy to customise and so easy to use. Even the bigger brands like Enemy and Naughty Clare looked at me and started to move over to it. So I was about half of the time I was leaving, as big as it was. But using WordPress at scale, we had lots of training tools like New Relic and I looked at the data on the panel for bugs, things that weren't working properly and things that weren't caching. So I went along to a Contributor Day, wrote my first patch and kind of ever since then, yeah, that was 4 years ago and now I'm a maintainer of multisite. So yeah, it's been a kind of crazy ride from this guy that I felt like I knew nothing to now being an expert in my field. And making these things happen right now. And what was that patch about? What was that problem that you found solution for? So in core, you've got the logs table, which is where all the sites are kept. And all of the query, there was like, I think about 45 places in core, it was doing raw SQL queries on that table with no caching on it. Which is a massive problem obviously, there's no caching on it. So I wrote my first big patch was WP Psych query. So that's a new query class, very similar to WP query, but through that table, it had caching built into it. And then all the patches after that was getting, converting all those WordPress to use WP Psych query. So they all go through one, like it actually removed a lot of code. So we're doing a lot of, we want to go to this today in one place, just nice to catch you. Which as a first patch was massive, it was like 2,000 lines of code. Most of the first patches are like one to two lines. That's a very, very useful improvement. But yeah, I remember going to WordCamp London, sitting there with my headphones on, and I didn't see anyone the entire day except for eight hours of code. And then I didn't even finish that, then I went home and did three more hours of coding. So it took me 11 hours to build. And then we did another research week to get merged with the three actors of the dog. But yeah, as a kind of a big first thing to put into code, that was kind of, I'm very proud of that. So it's such a big thing to change. Yeah, that was my first thing. It sounds amazing. And do you have some special projects in your mind that you want to tell us about? I built it with WordPress Multisite. So the project I worked on at the time, probably the most interesting thing I've worked on, that was both Multisite and Multinetwork. Multinetwork, are they Multisite or Multisites? Yeah, I didn't, there's massively hidden functionalities of anyone that doesn't know WordPress has the ability to not only break into separate sites, but into a network of sites so you can group the sites together. Why did they choose there? Or it was your suggestion to use them? So it's my suggestion. So from a business standpoint, Time is a really big company, 16 to 16 magazines, but they're all broken into departments. Right. So you've got women's brands, men's brands, sports, they're all separate things. And there was some value in having the ability to have super admins on one network because they would be the managing director of sports brands. We didn't want them to have access to the women's brands or the men's brands. So breaking into mobile networks was the best thing. The thing with that as well was we tried to hit one platform but then break that kind of segment off into different sections. So there's a plugin called HyperDB and that's used for partitioning tables. So that's originally written by Automatic, but when we came to look at it, it hadn't been maintained in like nearly five years. So Automatic basically had abandoned it. So we started using it and we found some bugs. We pushed them back to Automatic. I even bugged the people that I knew of. So you adopted this like... Yeah. Right. So there's a fork of HyperDB that's called LudivusDB and we use that to sort of partition the database. That's one of the things that a lot of people are frustrated by, multi-site by is everything's in one database. But it's very easy to break off into multiple databases. So for every network, all of the sites were on one database server. So we had four networks with four different departments. We broke them off into different networks. We had one global database that had users and stuff that's global for everything. Great. But then everything was working up into separate databases which is kind of a really interesting use case for multi-site capability to have a shared code base. So the worry is if you have everything in one database, if that one database falls over, then the entire path will go down. Whereas being separated to get only one type of site will go down. Right. And I'm reliably told that they've even broken up into more partitions. So now the biggest sites are enemy and very clear that the high-traffic sites, they're on their own database servers as well. So there's now I think the best. So it's most secure for them? Yeah. So the idea is that you don't want to take the whole network down. Sounds great. And were there any obstacles during the development of this project? Were there any problems that you have to overcome? Predictable or not? Yeah. So I think the biggest problem for me was that it was unknown. So I built that like four years ago when multi-network was a massively hidden feature. And I just sort of stumbled upon the multi-network and I was like, I didn't know this is even a thing that I could do. And it really panicked me that I was doing something that felt really unknown, such a high scale, because if it fails, then it fails. Everything? Everything fails. But it was just a matter of doing the research, having testing environments, providing training tools against it to have confidence to be able to launch it. So it's a kind of high-risk responsibility for the development of the site, right? Yeah. The other big problem we had with that project particularly was maintaining different aliases for the sites. Right. So... They are top level domains? Yeah. So you have like, obviously you have enemy.com. But we had like at least four different environments we had to have the sites on. So we had like a pretty quiet environment, a set environment, a dev environment, a very good environment. And we wanted it so we could just take the database and dump it into different environments and it does work. Which is very hard in the WordPress space, because there's so many hard part of references in the database to interlinking, which is a lot of the articles we're doing, you want to not pick up the website. I used a plugin called Mercader, which is a domain mapping plugin that human-made makes. And I also added some stuff on top of that. So basically in the database, you always store, so if there's a link, you'll always remain jump.com. And then using filters, I would switch it to be the main that you're currently accessing it on. So if you're accessing... On the phone. On demand, it changes it. Using a filter. That was really cool, because it means you just need to take dump databases and move them around and it made it really portable. So I think that's one of the big issues I'd have doing websites is domain mapping. Yeah. And kind of resume. How do you feel about the experience of making for... How do you feel about using the multi-site for publishing houses? How do the client feels about using the multi-site? From their site. So they wanted to use WordPress, because WordPress is such a great user experience from the admin at the same point. And they'd gone down the route doing custom CMSs before, but they were never great, because you're always doing for this for a client. Whereas with WordPress, you just get a lot of shunning things that you would never work on as a business. I know it's silly, but embedding YouTube videos is unbelievably easy. You just take the link and put it in. A business wouldn't spend their time to do that, because it's just a nice thing that you can get by without. You get some nice features with WordPress, publishers love it. I think the key problem with using multi-site for that project was because the sites were basically one template was customizable. Each brand didn't have their own custom content. And we had to make some sort of sacrifices with that to say, we have to keep this generic enough so that everyone can use it. You can't have your own with bang header. It doesn't make any sense, because if we start giving you a header, then this guy wants a header, and this guy wants a header, and this guy wants a sidebar, and then it's the point where all the sites are completely different and why we're doing multi-site. Right. So it was about making things as customizable as possible, but within constraints. But what was interesting was, from an editorial standpoint, a lot of the times they would like to blame the technology team for their work set wasn't a success. They say our work set isn't very good, because it doesn't look like another web or a competitor's work set. You go, okay, alright, I don't believe that, but let's see. We migrated Cycling Weekly to it, and within the first couple of months they fought it four times. Which is amazing. Four times the same, just by putting it on to work. Then we'd have other brands that would move over, and they wouldn't do as well, and they would say, well, your platform is bad. And I'd say, well, no, it's not. We've moved these brands that have good content strategies onto the platform, and they're doing great. Ultimately, people don't care. As long as the site works on the browser, people really care what it looks like. They care about the content. The content and about the usability? Yeah. As long as it's responsive, that's a big thing, it works on my phone, and the experience isn't terrible. It can be horrible colours if you want to have a screen. They almost design blind. They just want the text. They came here for the content? Yeah. So why don't you just ask me the question, what do you think of the future of multi-site? Yes. What is the future? Matt was talking today about the future of WordPress in general, and it was about JavaScript's future for WordPress. At this point, it seems to me, how do you feel about multi-site? What is the future for multi-site? So I think Matt touched on the idea that going forward will be a much more JavaScript-experiencing avenue. I think, going forward, the PHP will just be to produce a REST API and then all the user interactions will be in react. I can imagine the future where the entire admin terminal is a react app. It's kind of an interesting idea that you would separate the visual aspect completely from how the data is handled. And it could mean, like Gutenberg is at the moment, you could take the UI of the admin terminal and use it in a different project. And the PHP and the React could live a separate project almost, which I think is incredibly interesting. But to get to that point, we need to make the API much better. At the moment, the API... Sorry, it will make WordPress multi-site like a platform in Boston. How do you mean? That you can get information from WordPress multi-site from any other website using WordPress REST API? Yeah. Right. So, at the moment, we should have APIs to do everything you can do in the app. But they aren't there. There's some very obvious ones missing. Activating themes and plugins. There's no API for that. Men use a weird one that's also missing. Widgets is also missing. But from a multi-site example, the biggest ones are networks, sites, network options. And then now we've got a new table we've added into core in WordPress 5 of sitenetter as well. None of these have API endpoints. This is a real shame. So what we're working on as a core team is to try and sanitize a lot of this code. The code is very messy at the moment. As standard functions like WP and CERT network, WP and CERT site, so the naming is a bit clearer and the 8-lib arguments that are sent to it are more standardized to WordPress. And once we have all those code functions, code is great for the editor league. Once we have all those functions in, we can then leverage all those functions in the REST API. And then generating the REST API endpoint will not be difficult. You could basically copy the network's endpoints and just get those in different sources. The problem is the functions that the API would use are not there at the moment. So there are tickets and we're very actively working on making the whole developer experience a lot much better. So this is the most closest roadmap for WordPress multi-site development. So we've worked on our roadmap for over a year. We published that on the Make The Old blog. I think that was at WordCamp US, we published that. It's on a Google Doc but I think you can get it in the blog post as well. It's a still-evolving thing and we're trying to work on things in it. Everything has to be worked on in order because we need the functions there to work on the APIs. So we had to do a roadmap. I think I'm very proud of the multi-site team. We actually have a roadmap because it feels like a lot of the other teams don't have a roadmap. And we're telling them, this is where we want to be in like two and a half years. Come on the ride with us, you know. And if you don't agree with the roadmap, you can help change it if you think there's something better that we should be doing. Thank you. I will definitely do these because it's like a normal for me to do parts in developing something in the tail or job. But there's... There's so many ways you can help out. Even if you don't want to be making patches, being part of the conversation is really useful. So having another head to look at this stuff because it's quite a small team that works on it. You've got me, Bill Hedgstone, the DOJ, John Blackburn sometimes help us with that. There's only five people and we're not always available, you know, because many of us have freelancers and we don't always have time to attend the meetings and stuff like that. But yeah, if you can help anyone who can jump in despite looking at tickets and talking strategy and how we should do stuff and thinking about, you know, there's so many different use cases for multi-site. People are using it a lot now to have apps, so you can have, you know, use it as a... If you had an iPhone app to spin up a multi-site and you can use that and it's all WordPress. This is an endpoint you never actually use WordPress. A lot of people are using multi-site for multiple languages and there's so many different use cases and there's so many hidden ones that are not even in our minds, you know, and multi-site is so customizable there's so many ways you can customize it. It's so valuable to have people that are using it and are doing weird and wonderful things with it to give us feedback because if we assume that everyone's doing it this way and then you're doing it this way and we make a change that breaks your stuff, we don't know. Thank you, Johnny. It was super useful and it was a pleasure for me to meet you here today. Thank you very much.