Hello, everybody. I'm very happy to show you today or talk a little bit about the Mutti Mutti Mutti. I'm also very happy about all the questions which appeared because this fits perfectly into what I will tell you now because we're interested in, hey, how do we really do this in Magnolia? And my goal is really to show you or explain a little bit our idea and our supposure of how you could solve all of this in the Magnolia Vanilla Way. Some words about me. I'm Tobias Cashbaum working as a pre-sales and consulting manager for Magnolia now for six and a half years. So what I do, I work a lot in pre-sales and maybe some of you already or still know me from some pitches. But I also do a lot of posts, so also existing customers. It's always very nice for me to meet customers where I pitched a long time ago. We meet again here, so it's always nice to meet you guys. And yeah, beside of that, I also lead the demo development team, which is very interesting because during your talk, I recognized that actually we really much face the same challenges. Because I mean you come from the same challenges where also we came from because we had a very same landscape of very, very loose couple demo systems. But we also wanted to actually synchronize them and show them perfectly and also solve the same challenges of branding and creating demo pages, but in the Magnolia Vanilla Way actually. So, speaking of the agenda, so what I will put you through is first of all the Vanilla Promise. I will explain in a minute what that means. I will guide you through a little bit of multi-site. This is just a little bit of a reminder. It's not a big topic. I think the big topic today is the Multi-brand. I think we already heard this is a very important topic for a lot of you. Then also multi-tech. I think it's also not very much news for you that we are able to multi-tech, but in the context of branding, I think this is a very interesting topic. And then some take homes for everybody, I hope, also for people who are with us for a long time. Hopefully they can take something out of this and then we will do a quick Q&A. So, first of all, the Vanilla Promise. Yeah, custom code is very budgetized, I think, maybe especially the customers who would really agree with me. Maybe to elaborate a little bit on what I do mean with this. In pitches, I always say that there is two different ways of bringing features into Magnolia, so from a customer or partner perspective. So, I always talk about customization or configuration and customization, actually, right? And I mean, customization, custom code, custom Java code, it's often, people think it's the only solution, but I mean, it adds technical debt, it adds a lot of costs, and also for maintenance for later migrations. Yeah, it's always the things what make the budget die, actually. So, from my point of view, the biggest goal, and this is also where Magnolia is really leading to, is to make it possible to do most or the majority of the things what people need, templating, branding, everything, in the Vanilla way, with configuration, with only YAML, right? Because this is also very efficient then for future migrations, and this will really give you much less costs, actually. It's not working very good. So, talking about the three multis. Oh, this looks different. I think the slide was not changed, but it's no problem. So, talking to the three topics of what I will cover today. So, the multi-site, right? All of you notice, you have multiple websites, which is actually multi-domains, what could be multiple differences. We saw a lot about this one. You have multiple websites, multiple domains. But the important thing is the multiple brands. So, it's not only multiple domains. You have the branding. And, actually, what I wanted to talk about is the forking, because there's, I think, Emi gives us a very good example that you want to reuse the templates, actually, and you don't want to redo every new website, right? So, you want to reuse the template set in order to make it more efficient. And, yeah, the multi-tech is actually then the same backend. We already heard this also. But you can choose the different frontend stack in the end. So, first, starting with the multi-site. Yeah, that's the classic, right? But they did do it right. And what means multi-site? You can have multiple site definitions, actually. Every site has its own domain. You can have shared workspaces. We all know this, right? You have pages. You have methods. You have content types. There's also navigations. There's the live copy. But what is actually the thing that I want to provide to you today is live copy is not the answer for everything. Because I think in the past, thank you, there was actually, in a lot of cases, a customer coming to us and saying, Hey, we have multiple websites and we want to share some content. And the only solution, what we provided a lot of times, was, hey, you have to go to live copy. And what I want to do today is to give you another possibility and maybe to rethink this thing as set in the vanilla approach. And, of course, what you can also do, everybody knows this, you can do precise permissions. So, diving a little bit into the NGFC here. This is the example of our demo system. I mean, this is what we achieved now in order to be able to show Magnolia in different verticals, right? And you see, you can have multiple websites, of course. This is how it looks in Magnolia. And this is what you see is the front pages. It's multiple different brands. And now I will show you how you could manage this, actually. There's banking, there's manufacturing, there's also finance and insurance, actually. So, talking about a multi-brand, what is a brand, actually? Or what does the brand bring into? A brand is the destination. Sorry, first of all, the site. The site is the destination, right? So, you have the domain configuration, you have different languages. We heard this. We have also the navigation. But what is really making the brand out of it, right? The brand is the tone of voice. So, I mean, it's the content, what you put on the websites. It's the color configuration. You put in the logo, you put in the favicon. Yeah, it's just a story. So, the term is like a brand, right? It can have multiple different websites. So, this is also what we wanted to say here. It's like, for my view, you could have a brand configuration used in a B2B portal, but also in a website, right? So, the brand is not only about the template, it can be also reused, even maybe in different technologies. And traditionally, you would just duplicate all of this, but yeah, now I will show you how you can do it differently. So, the solution, what we came up with, and I think this sums up a lot what we heard before, would be to put the definition, the configuration of the brand into Magnolia, and enable the editors, in the end, to do the configuration of the brand in Magnolia itself. So, what is the big benefit if we do this? Is that we don't have to call out IT if I want to change my logo or my favicon, if I want to change the brand configuration, I can do the styling all in Magnolia, actually. There's also a screenshot of the inside app, so you can choose the font, you can choose the logos. Maybe there's also some placeholders, right? What you can put in on the website. And the big benefit is, if you think about, you want to launch a new website, you want to do a new branding, you could actually do this without even having to call the IT. You can do it in the solution. And how we solved it here is that, because this was also the question, like, how you make sure that the accessibility is not lost, right? That it's not broken. And how we solved it for our demo systems is that we made sure that we limit the options of colors and fonts, and we tested all of this configuration, actually, with our style set. And we limit the options, actually, in the brand set. So the brand manager can actually not do anything wrong, but he can make use of the possibilities what we give him in the brand application. And in the end, this brand metadata is linked to the root page in Magnolia, and therefore, yeah, you can do very easy changes. And they are directly reflected in the templates in the end. And all the components on the web pages actually make use of this configuration. So if I change the color in the brand, then the buttons will change, the link colors will change, right? The whole site will adapt to the brand configuration. Yeah, makes it super efficient to make use of this. So you pick the brand, and yeah, the page picks up, the template picks up the rest in the end. And this, combined with the next example, is the component factory. So the component factory is something, I think Katalina already gave you a lot of good reasons yesterday to go to 6.4. And there is another one, and this is the Stories App Everywhere, I think we call this feature. It's really a nice feature, which brings you the possibility, without any Java customization, without any Java custom code, to have additional pages apps in Magnolia. And what this enables us, is that we can create reusable component factories very easily, where you can create these reusable components in a visual way, and can link them then into the websites. And this, combined with the Brands app, is a super good combination, because you can make them reusable. They are linked into the pages, and styled accordingly to the brand, right? So you can even, for example, a banner component, or a hero component, you define it once, right? The content is actually in the component factory, but it's styled accordingly to the brand in the website when it's used, actually. So what does this bring you as a value? It's a once, you know, a once-central library of components, built once, organized by brand and site, and like I said, you can use it everywhere. They are linked, they are not copied, right? So this also fits into the term that we always say, right? Created once, uses everywhere. And yeah, if you change it, right, it's also changed everywhere, and you can check it before you publish it. So yeah, you have the same page template, three brands, authored by one author, and how does this look? This is, for example, our finance website, and this is the hero banner. So this is the same template set, it's the same component, but we styled three times through the Brands app differently. So you see now it's green, and the text is on the left side, for example. And the insurance example, it's the same template set, it looks quite different, right? Because you have the purple color, even the styling is different. And there's a third example with our, with the manufacturing, and also there, same component, same template set. But we changed the logo, we changed the styling, we changed the navigation through the Brands app, which is super nice, it's super efficient. And yeah, also for partners, right? This is not, like I said, this is, I would say, not only a very big benefit for customers or for partners. If you want to do custom demos, if you want to create customized demos for specific customers very quickly, it's a very efficient way to do this, and yeah, that it just still looks fine, and you have a very good first impression, what you can show the customers. Yeah, because the template set is very beneficial. Good. Yeah, and we haven't even left the backend yet, right? So this is the statement. Yeah, and this combined with the multi-tech, like I said, this is also just a reminder. You all know that you can use different technologies in one authoring system, right? Magnolia is able to do FTA rendering, so server-side, but you can also do headless stuff. And the thing is, combined these two things, or three things, component factory in combination with the brand set, combined with multi-tech, enables you to really achieve reusability and brand configuration in a very efficient way, actually. This is an example of the headless frontend. So what we did actually for the demo is exactly that we also used the brand set, like I said, also in our headless e-commerce demo. So, yeah, it's the same principle, we do the same thing, and yeah, it enables you just to also, for example, e-commerce demos very easily. Vanilla across every layer, right? So no customization, everything is done by configuration in a very efficient way. And, Vanilla scales further than you think. This is, I think, the thing that I wanted to get across to you guys today, that maybe you were not aware, right? About the Pages App Everywhere, maybe about this possibility, about this concept of the Brands App. I think this could really, I talked already to a lot of people yesterday, and they thought, hey, this is a very good idea, right? We never thought about this one. And the good thing is, it's also available for sharing, right? I mean, the whole template set that I showed, I can share this with you. So if you're interested in, as a partner, also as a customer, to get a look at this, we can share it. Also the Brands App, also the Components Factory App, it's ready to share. And we are more than happy to show it to you, and to give you the possibility to actually make use of this. Yeah, and to sum this up a little bit, if the pointer is working. That's right, broken. So, is it? Ah, now it works. Yes, so what the Vanilla Way, what it buys out for you. Less code, less maintenance, right? I mean, this is the thing that I said in the beginning. This is quite a little bit broken, sorry for that one. I mean, what do you mean with this, right? The less Java code what you write in your project, the less customization you use, yeah, the less code you have to maintain. So I would really, yeah, tell you, use the things what we provide, talk to us, because there is involvement, there is new things. What could help you? What could make the projects better, right? Yeah, so no per brand or per site forks. So don't go there and just copy paste the whole project and adapt it. I think even in existing projects, it can be, could be a way, I mean, this always depends on the use case, but I think even in existing projects, it could be worth to think about it. Hey, could we do this maybe in this way and could just adapt to it, right? To this, yeah, to this procedure. Yeah, upgrades, the upgrades, no migrations. I mean, this is the thing, right? If you need to migrate to a newer version and you only use configurations, it's way cheaper, right? And, yeah, no site, no brand. It's super easy. We saw it with Amy. I can really say I have the same thing with the demos. It's awesome. We are able to do very nice, very good site, very good-looking custom demos in 30 minutes. I mean, we're not creating that much content in you guys, but it looks just awesome. It's really nice to see. It's very also appreciated from the customers because it's the first impression, right? The thing what we show, the first impression, what I show the customers on my demos, I mean, this is the first impression they get from Magnolia. So this should be, it should look good, right? Yes. And, yeah, with the tech, I think this is also just a thought what we can take away, that this configurations of the branding can be also used in the multi-tech scenario. I think this is also something that not everybody is aware of, and maybe my talk inspired you to think about this. And let's talk about it via coffee or later. More than happy to get into this discussion. So in summary, one CMS, many sites, many brands, many stacks, zero forks. This would be the goal, right? And, yeah, hopefully we will go this way. Thank you. Thank you. Are there any questions for Toby? We have time for two or three questions, one, two, three questions before we head to the break. So, Toby, all of this is available? Yes. Oh, we have a question. There's one. Hi, everybody. I get a question regarding the component factory. Was it that way? Component factory, yes. Yes. So if you create a component and then you reuse it in your site, is it possible to adjust the content inside the component, or do you just need to get what was created in the component factory? Yeah. I mean, in general, how we did it, I would say it's not possible to override it, because how we did it, it's really a link, it's not a copy. If you would like to do this, I think there's possibilities, but you would have to actually think through it, because I think you would have to, but it depends on how many components you make available in the component factory, right? This is, you can decide how many you make possible, because you could, for example, turn the component factory in a banner factory, and you say, hey, there's only the possibility to create banners. And if you limit it to only one component, you can very easily, in the dialogue where you choose the banner, say, like, hey, I can override maybe some fields. But I think if you do the component factory flexible, and you let maybe grids in there, and you have tons of different components, it would be maybe very hard to get clear, right, what you override. But in general, if you limit the components in the component factory, I think it's very easily achievable. It depends on how you implement it, right? Or you configure it. It's not, you know. Yeah.