 Hello, Felix. It's a pleasure for me to meet you here at World Camp Europe and to know more about your work, about your multi-state work. Can you tell us your multi-state history? How have you gotten involved in multi-state development at all? Hey, first of all, thanks for the invitation. I started working with multi-site about three and a half years ago. I haven't been part of the World Press community back then, but I got a client that was a producer of music events like festivals and concerts. I have to admit that I took over this project, so there was already a multi-site. I didn't set it up on a scratch. It was a multi-network, actually, where they had one network for the core site of that event producer, which has all the events. Then they had another network, and that network actually only had one site, but it was the root site of this whole setup. Then it had a second network for festival sites, which is kind of comparable to World Camp work, because they have these different festivals. We have different work camps, and they also have it every year, so it's pretty much the same. They can always have the year, the festival, and the festival. The second network and the point of doing it that way was that there was also a festival theme, which was specifically, particularly useful for the festivals, and we used that same theme across the whole network, and made it customizable so that the pages of the sites were different, but they all pretty much had the same kind of content. All the post-sites were also similar, and that's why it made sense to use multi-network for that setup, because the festival sites were completely different from the main site, which had regular concerts. And there was a third network, which I barely touched. I have to say, which was like, well, they had part of the company, also at the work site. But yeah, and that client got me, got me in front of me with multi-site, and even multi-network. Didn't you have any experience before? No, well, with work, as I have, but that was my main multi-site. How did you feel for the first time? Was it really complicated, or it was all like that? Well, I mean, the good thing is, like I said, I didn't have to set it up. I got to experience how it works slowly, because it was running already. Of course, when the issues came up, at first I was like, okay, what is this? I had to find out how sometimes how things work. But yeah, I think at least the core concept of multi-site is not that complicated. So yeah, I guess I got around it when I needed to. So this was your starting point, right? Can you think of some particular project that you developed, that you made, did you particularly proud of? So what we did was for the same time, we started, it's not directly related to multi-site, but we built an app using Ionic framework, like a hybrid mobile app for that client, where we connected to the rest API of all these sites. And so we built like a single, it was like a single Github project, which we then reused for all the different festival apps, but we also had like one aggregate app that is for the entire multi-site. Like you have horsecams at Apple Store? I haven't actually used that. No, I don't know. Possibly, yeah. But you managed to get with rest API the information from all that multi-site network website and combine them into the app? Yes, we had that, but we also had suckers for the festivals. But it was all connected, depending on whether sometimes users just wanted to go to the festival, but some maybe they're more interested and they won't be so experienced. But it was all managed by one of code banks. Yeah, pretty much like you could argue like maybe that it was almost like the festival apps were just like one side of the multi-site, and yeah, the whole thing was the whole multi-site. Right. And yeah, that was a fun, that was an interesting project. Yeah, well it was, of course, for one part it was the mobile app which was built with JavaScript framework based on Angular back then and then the rest of the integrations which span, look for, to a huge extent, the span for single individual sites, but also multi-site, the whole network. And we needed to deal with, like users for example, we offloaded the whole sign up and authorization process to Facebook API because at least people are young there at Facebook, so why not use that? And so we connected like the sign up flow in WordPress and authorization by using the process. Because the REST API doesn't really have secure authorization at that point, it's really hard to implement it with a lot of tools, so we just use Facebook to get that done. And there were just fun projects that were part of this whole thing. There was that we had built an interactive map of each for each REST. There was an interactive map that the designer created an image for. We used the Google Maps API to overlay it at the right coordinates, like you can put a picture of over the Google map. And then we have an interface in the WordPress pack where the organizer of the festival could log in and place pins. And this was across the whole multi-site network? Yes, so yeah, and it was all fetched from there, and yeah, this was in the mobile app. You know when this project is in production, when it's functional and ready, how do you feel? Was it a good decision to choose multi-site? Are there any other ways to do what you've done? Well, you could absolutely use individual sites for that, and I think you could possibly have used a multi-site for only the festival part and then a single site for the other... But the maintenance won't be that easy. The best part, I think the main argument for using the multi-network there was the consistent user base. We just easily help all the users and say, if you have an account with one festival, you can easily use the same account for each other festival. So user doesn't have to register for each festival every time, right? And we didn't actually do that, but I'm just now thinking you could have done something like maybe someone favourites an artist and then in the next festival they still have their favourite artist or something like that. Yes, there is a whole area of customization and for providing more and more interesting solutions for the client and user. Yes, yes, absolutely. And do you remember any obstacles, some that you can predict, predictable obstacles or not predictable, that came out during development? I have to think, not. Actually, well, it may sound like miracle, but not related to multi-site. That's really solid. Like miracle. Yeah, it was tricky getting the authorization in place. Was that a book? Yes, yes. But it was not really related to multi-site movement in WordPress in general and connected with Facebook. That sounds very inspiring. How do you feel? Is it a good solution at all? Well, like I said, I'm sorry. Like I said, the setup was in place. So initially, so I did not have to fight, like for example, detecting which site we're on in a multi-network. I know now that it's not that trivial, but that was already done before I jumped in that project. Someone has prepared this. How do you feel now? Is it a good solution at all for the company in that area, in the niche, organizing events and not just music festivals and music events, to use multi-site for their needs? Absolutely, if you... There were some ticket creators and everything that produced actually multi-site. Do I get to try it? Do I get to try it? That we can easily put a ticket creator or any event agency at all to use multi-site as a success? Yeah, I think for any kind of event that reoccurs in some period of time, like in Newly, for example, they usually don't change that much. Like I said, WordCam is a perfect example of that. Their websites, they also have a base theme that you can just tweak a little bit and they reuse it everywhere. And I'm not sure from the top of my head if it's in the same environment that WordPress has worked on the rest of it is. But it may be. Well, at least I know that WordPress... The WordPress website is for everything around it. This is my local network. So the WordCam part could be a matter. I'm not sure if it's actually true. But it would be a very perfect example. Yes, but we know for sure that it's multi-site at least. Yes, absolutely. And that's another example of using multi-site a network company. Great. Yeah, well, I'm obviously now a large huge fan of multi-network because I was exposed to it at the same time as I was learning multi-site. I immediately had to learn multi-network which is an even bigger edge case than multi-site. And I think you should think twice before you set up multi-network. That is a use case where you achieve much less frequent. Yeah, but I would say... Like I mentioned, I would say at the point of the festival the site was mostly the consistent use case. The argument for using this network. But I think the main scenario I would take a think of is like universities, like with Jeremy and Sergey. Like a classical example now. Like a classical example now. The university is perfect for multi-network. You don't want to have thousands of multi-sites to manage. You can just do it in one thing Yeah, it's even just the hierarchical organization. You have this whole university, which is the global, the whole thing. And then you have the faculties which could be each of them. It could be a network. And then whatever is needed. You could also have other networks. Another good example would be... Think about, well maybe anything that is... I have not actually worked with such a project, but anything that is... Anything you think of can be a multi-site. Maybe you want to make it multi-lingual. But if it's already multi-site, without being multi-lingual you could make it multi-network. And then each site becomes a network where the translations are the sites. Yes, yes, yes. That could be an interesting useful. Because you can always think of, well if the one site has to work completely the same like all the translations of it. But the other sites are separate. So then you could use multi-network. Sounds very interesting. And from your experience working with non-technical stuff Were there any products from non-technical stuff to manage to maintain afterwards to work with cross-multi-site or cross-multi-site network? Or it's as easy and useful as our usual request network? I definitely think, well if you expose people to multi-site you need to train them more than with regular WordPress. Or maybe not more because it's not that much content to learn but it's definitely extra attention. I generally think multi-site is definitely less user-friendly than the rest of WordPress. Which I think about as it's kind of logic because well multi-site was merged almost at 3.0 I think. And so it was merged into an already old code base. So it kind of started years after the original WordPress had started. So it had less time to get there. I see it that way. So I think there's a reason that you need to go into the conflict file to actually allow it. It should not be as trivial as the setup because you need to be aware of what you're doing. But I absolutely have the goal of getting the focus of the point where it's as user-friendly as the rest and hopefully at some point you don't even need to go into the conflict. So this is the one of the points for pre-multi-site development improvement in future. Do you have any other examples of how it should be transformed? At the moment we are working on improving the APIs themselves because they're messy and old. They're still what was originally merged to the most part. And this will then be a foundation to actually work with all the users in the admin. We want to be a user of the REST API. We want to improve the UI of the admin screens, particularly the adding a user screen. It's messy because they have two forms. One for existing, one for new users, which could be used anytime you want to do that.