 Here at Drupal South, our talk today is about how and why we created a modular distribution for Drupal 8 and covers our success and some of our pain that we've had on our journey so far. My name is Daniel, I've worked with Sparks Interactive since 2014 as a backend developer and I'm also the technical head of sector, our open source distribution. The Drupal 8 rebuild has been one of the most exciting things that I've been a part of in my career and it wouldn't be possible without the backing of Sparks. Sector has been really successful for us as a business and we only got this far through all the experience and pain of building sites for the last 10 years. For some of the background as to why Sparks chose to commit to sector and what we did before sector, I brought in Hiker. Cool, so sector in a nutshell. Sector is the open source Drupal distribution that's ready to go and easy to administer. It's built on a flexible framework, provides pre-configured authoring tools, content types, file management, everything you need and more. Sector basically gets you from step one to step 20 without you needing to do all the work every single time you build a new site. It's just already done. Hiker are now supported by an awesome team in Wellington. We have everything from developers to testers to designers to content, everything with a great support by our Auckland office. Sector's been a four-year journey for us at Sparks and all the work and choices we've made have led us to where we are now with Sector Drupal 8. This talked more of multiple times while I was writing it, but it ends up being a case study on our sector experience and why we think modular distributions just make sense. In a few moments, I'm going to hand over to Hiker for a history lesson and some business stuff that's way above my pay grade and then I'll come back and talk about the technical details that are going on in Sector. At the end, if we have time, we'll talk about the contributions that have been made because of Sector and some of the sites we've built and how a modular distribution enhanced that experience. At this point, I'll hand over to Hiker. It's an absolute no brainer. Who wants to click the thousand buttons every single site? I don't. So you can deliver your sites quicker and with less risk, you can reduce your technical debt, you can consolidate your build processes back in front. You have a common tool box to prototype and iterate faster. A common editorial experience, a common customer support strategy, common test scripts, common test strategies and a shared documentation and editor guides. Now you will see this later because we are going to tell you how we met all of those boys in the Sector story. Now, why not contribute to an existing distribution? There are many reasons, different points of use and needs, governance, change control, small fish, yes, small fish, big fish, first an experience of Tenzin and Fragments in the global community, but there are many more. Now, the main reason is that Sector is older than most. So the sector story is four years old, but we started this whole process way earlier, and we were so far down the road when the other distributions came up that the only thing we know we needed to do was to open source, which we did. Sorry, I have to control now. Yes. We decided how we consolidate sites. There was a really interesting talk about automated security updates. We had the same problem in a little thing. You don't want a million different sites that work in a million different ways. Drupal lets you do all of these things, but do you really want to do this? If you reach 50 to 100 sites under customer support? Now, the project was called Nucleus, it was very basic, but the core is still what we are doing today. Nucleus and core standard control heroes, we love and you know that works reliable, and some customers, we did configure a lot. It was easy to use for the authoring tools and content editors, our clients, staff and boards, all done, but at this stage, we had no see. Around 2013, we committed to a full workflow using site building and display suite. Around this time, we also looked for a front end design system or framework, and we choose bootstrap. We moved our infrastructure towards Git and Agus, things that are totally normal now. We moved towards the search based solution on search API and so on, and we had one of our preferred cache solution. The project was quite ignite, but each ignite site was still a clone from a base site using Agus. So we had this core, which nobody was allowed to touch, without, oh, sorry, without reviews. But it was still pretty basic, plus you can't open source this. So there was also a time when Spark's lost the bit for the common web platform to service drive in New Zealand, because it was an interesting experience, we just said, okay, let's try and establish Google. Now, after all of these decisions were made, we still got heaps of RFPs for the need or the tinted at which to have a Google solution. So yes, we can totally do this, requirements look so specifically familiar, and we gathered all tools together, open source that the prototype was called lightning. There's some really good stuff as I kept saying in here. And so we needed to change the name. We learned a lot about namespacing. We need to change the name in the last minute to sector. They were just way faster than that. Okay, so sector second and lessons learned. This is our list. And this is where you have a distribution. Daniel is going to tell you how we did with sector seven. Thanks, Hacker. So deliver your sites quicker and with less risk. All the sites now have the same base, the same configuration we can trust, as long as a developer or a site builder hasn't done anything too funny. We know the basics are just going to work past, reduce your technical debt. We kind of missed this one. Yes, we reduce technical debt in the way that all the sites have the same base and are less custom. But sector in itself carried a lot of weight and a lot of technical debt. So we didn't quite achieve our goals here, not to our standards. Consolidate build processes back and front. In particular, on the front, we moved towards yarn, we modernised our front end tools, we added documentation and processes to use. Now, everyone at Spark, everyone using sector, they use the same tools. Pass. A common editorial experience. This was really valuable. We have a suite of sites, many sites that share editorial teams. We don't want them to have to understand five different admin back ends, five different range of content types. We want it to all just be scalable and shareable so that one editorial team can manage sites. Pass. Our editorial teams, they rave about this. So it's good. A common customer support strategy. It's a little bit out of what I do. But the customer support team, they know sector well. A lot of times they can just fix things without even needing to escalate it further. It just works well. So pass. Common test scripts and strategies. Again, all the sites have the same base. So the same test scripts, the same test strategies. We just build upon them for custom features that we build every site. Pass. And shared documentation editor guides. One of the powerful things about the sector is our documentation site, sector NZ. I reference it all the time. This documentation team has done awesome work open sourcing all of our documentation. Things no longer just really need to exist in one person's head anymore, which is always a problem with the way we do things. So pass. So despite missing one of our goals, we really liked what we did with sector. We're seeing a massive improvement in how we build sites, our processes and our efficiencies. It made sense to us that others might like this as well. So we committed to open sourcing sector in 2015. And we achieved it. Moving from closed source to open source was hard. We had Spark specific data, we had to do rounds of testing, rounds of removal, sign offs, everything. It was non trivial, as you can imagine. So after all that, the important thing is that sector 7 was successful. All things considered. But just to bring us back down to earth, there were things we did wrong and things that just didn't quite work the way we envisioned it. First on being that everything was too big. As part of development in sector 7, while in the closed source, we used a lot of contra modules to achieve the functionality we wanted. The first closed source version of sector had everything. Varnish, solar, media, workbench, maps, it had everything and more. When we made the decision to open source sector, we didn't really strip these things out, we just disabled them. This led to a bloated distribution and module security updates hurt us continuously just by the sheer amount of modules that were in the distribution. Features, not bagging on features at all, there was no other alternative in triple 7 and the team built an amazing tool. I mean, it was incredible. But partly due to our own implementation, it just caused us a lot of pain. We had the right idea of building a modular distribution in triple 7, but everything was just included in the base. So the benefit wasn't really there. Dependency how? Potentially a few people here have done this themselves as well. Because of how many contribs and features we had, things just, a lot of things end up relying on other things. So if you need to turn off a module, you can't or it's difficult because it's relied by four different other things or one other thing. This was a really big pain point with our developers in sector 7. It just was really annoying. Technical debt. To get around the features limitations, we had a lot of custom code in sector. If APIs changed or things broke, things had to be fixed manually and features had to be rebuilt. This happened often with contribs like password policy and web form and the last one is painful to make changes and hard to maintain. Long installation times, features prone to mistakes, long testing cycles just because of the sheer amount of content and config. Sorry, hi, Kya. Sector 7, that's enough. So sector at the age as we worked from scratch, technology-wise, the non-technology foundations might remain the same. So we had this huge head start. We just basically said our tool, oh yeah, sorry. We just said our tool. So now that we could actually build what we wanted to build in the first place, only better. It has the same manifesto, content-first, site building first, same business requirements, ready to go, easy to use, same functionality bundles, same user stories down to the same test scripts. So sector is truly modular. The main value block is the sector starter kit and the sector starter kit can be extended using sector add-ons. So every single add-on sits on its own through the project and the starter kit does what's next for it. Each element in the sector ecosystem follows the same principles. Now some of them are familiar while some of them go way further. So yes, you need some consistent approach to look at. So you need some really standard here. You need some display and store looks back to the starter kit. So this is all what Daniel does on a daily basis. But there also are composite installable. They plug and play. They have test-pented code review. Each add-on has at least two documentation pages on sector and site, one for site builder, one for editorial teams. You have the project pages on blooper.org and you have useful sample content and everything needs to have an online demo. So now Daniel is going to tell us how he cleaned up. Cool. Now that we've looked back at the history and some context, we can look behind the scenes at how we fixed the problems from sector D7. So this will talk about scaling by add-ons, no features, no dependency hell, less technical debt and a talk about the future. So scaling by add-ons. So as we talked about, the first problem was that sector 7 was just too bloated. Sector 7 had almost 100 contra modules. It did everything we needed it to do and more. It was just too heavy. Like I said before, security updates, they really hurt us. So it was time to clean this up. We moved some contra and config into add-ons and as we continued to trim the fat, we saw a 50% decrease or over 50% decrease in the amount of contra modules and as a side effect, we saw a 62% decrease in build size. Both these things will keep dropping further as we trim fat and really clean up our starter kit. Creating the add-on system was something we came up with early in sector 8 and it was my number one priority. We're really starting to see the results of this as time goes on. Add-ons will be covered more as we go, but the idea is simple. In the same way you extend Drupal, you can extend sector. And the last step is removing complex content types and unnecessary config from the profile. For sector 8, we removed everything non-essential and took the distribution back to its roots. It's got a core, it's got a theme, and it's got opinions on what the best practices for the start of a Drupal site are. Sector 7 had years of config and legacy come across from the close source project, like solar and varnish. Does every single site you use have solar or varnish? No. So we rip them out and in time we'll create add-ons. And the same goes for content types. Sector 7 had eight content types, including multi-pages, which is the old version of books, and a media gallery. Does every single site you build really need a media gallery? No, so that's what they went as well. So for a visual representation of what add-ons actually look like, let's have a look at a couple. So if we scroll to the bottom and we go to events, every add-on starts with a landing page. So it's a landing page and then it's got some content. This one here, it says with location map but since Google changed some of their policies and we don't really want to open source our key, let's just pretend there's a map. So straight out of the box you can see there's really nice design. We've got a couple of different displays with blocks. We've got a node view and as we scroll down we can see everything is nice. We've got good realistic sample content. That's what an event should look like. It'll let you see how things are and take them further if you need to. And then if you scroll back down to the footer and open up with a blog, it's the same thing. It starts with a landing page, it's got some nice designs some nice blocks, it starts with a featured blog post and then just keeps going down into some landing page style view content. So if we go into the featured one, same thing, nice style, well-designed good realistic sample content is the important thing. Links and all the links go to our documentation pages so your site builders and your content editors can see some examples and how things should work. And if we have time at the end we can have a look at some of our more complex add-ons like Media Gallery but I think by now you're really starting to get the idea of what an add-on should encompass. So the starter kit itself in the sector has been reduced to four content types. We have page and article, which is article on core, resources and promotions which both come from sector. The remaining content types from the starter kit in D7 have become or in the pipeline of becoming add-ons. This keeps our starter kit light. So for this talk we'll use sector events as our example. Sector events requires three contra modules. Address, geolocation and geolocation address link. In Drupal 7 that would have been three extra contribs that are bloating up the profile that don't need to be there because not every site needs an event. So when you have security updates in sector 8 when addresses a security issue, all the sites that don't use events just don't need to worry. It doesn't matter anymore. It's a win-win. So how are add-ons designed? Our golf add-ons is that their minimal impact. I think all of us have seen how to install a module sometimes. It attaches itself everywhere and then it's a spider web of trying to figure out where things come from, how to remove it. I didn't want that. I really wanted add-ons to be this little isolated bundle that you can just install and remove if you want to. So they're meant to be low impact. Plug and play. They're all just plug and play. You turn them on, they're there, they have content you just go. They can be extended. All config comes bundled in as part of the add-on and when I say here I say and not much more, I really do mean it. Our add-ons come with very little back-end code. Most of the time it's just minor install tasks to do things like set permissions or create site maps, things that aren't well-handled with config at this point. And sample content. This is really important. We have good, we have realistic sample content that's been made by our documentation team. People can really visualize what the content looks like and then they can start extending it and see what they want to do in the future. So I'm moving on to the technical side of things. I wanted to go over what the code structure of an add-on look like. So again we've got the sector events and if we start by going into config and into install and if we scroll down here all the config files that are part of add-on, there's about 30. Everything is just already done. Fields, content types, displays, views, vocabs, it's all just there. And I don't really know about you but I don't want to be clicking all of these buttons and doing all of this config every single time I need an event content type. It's just painful. It's easy to miss. Which one of us hasn't missed a checkbox, an eclipsed field set or not pressed save after doing a thousand things on a form. This just works. So while we're at it, let's go back to events and into the content. So this is using the default content module and all add-ons come with terms, pages, the newer ones come with also media and files. So everything's just there, out of the box and it works. So what I really wanted to demonstrate here is that this is 30 to 35 plus files that aren't part of the distribution anymore. They're in the add-on, the distribution doesn't care about them and if you need them, they're there. It keeps the starter kit light. And more importantly, it keeps sites that aren't using events light. And the other part of most sector add-ons are minor install tasks. So just really little things. You can see that we are granting permissions to content editor. We're granting permissions to content admins. And we are creating XML site map context for the event content type. With all things, like with all most of our add-ons, this is the majority of install tasks that are like of back-end code that's there. There's not really that many moving pieces that can go wrong. The goal is just to do everything that works and isn't going to mess with you. Cool. So the pros and cons of this really become more obvious as we go along. No mistakes. The config is all handled by the add-on and the awesome Drupal configuration system. There's no manually checking or missing boxes. We don't really have to worry about these things anymore. It just works. They're well tested. We use these add-ons at parks and as more people use them, or as with any module, as more people use them, they get tested as they go along. We open source our issue queues just using standard Drupal issue queues. So everything is just there. Everything works. They're tested. And the cons, they're also pretty easy. The add-ons are tied to sector, obviously. If you add sector events to Lightning, it's probably not going to work. And the last one is that things can break if major changes have been made to your instance of sector. Let's say, for example, you delete the body field. Maybe things aren't going to work. So at the moment, they really do require a pretty clean version of sector. We've actually done some kind of preliminary reviews to see if we can mitigate this. But at this point, that's just how it is. So when we first started coming up with the idea of add-ons, I think there was a bit of concern in the team that they would really begin to limit us, that using the same base would make sites follow a kind of cookie-cutter pattern. Everything would have the same look. We want our developers and our designers to actually enjoy their work and not feel like their creativity is being stifled by us. So the add-ons are fully extendable. I mean, they're mostly just standard Drupal configuration. You get all the nice stuff that comes in the add-on and you can do anything extra that you want to. So for this, let's have a look at two sites. Forest and Bird and Torture Learning both use the exact same version of sector events as their base. So if we start with Forest and Bird, we see upcoming events, the same one we saw before. We see a ton of filters. We've got one event per row with a bit of metadata based on dates, tags, an image if it's been applied. And then if we go to Torture, again, exact same upcoming events view. They've changed the label. There's a filter. And now we've got four events per row, required image, bit of meta, and this whole masonry-style layout. Both of these sites, they have the exact same base, but they look totally different. They have their own flares, their own special things, but the same underlying base. So no features. Like I said before, features was the best tool for its time. We bought modular features, but we didn't do it in the right way. And we had way too many features. At certain points we split content types up into a content type feature, a permission feature, a content feature. We had this great vision of the modular distribution. We just didn't quite pull it off in the right way. It made things hard to maintain and hard to keep track of. And to be totally honest, while I can pretend to take a lot of credit for the work in this, before removing the bloat, a massive chunk of this was solved by the amazing work done by the Drupal 8 team and the configuration management system. Changes are easier. I get less grumpy. And things just work out of the box. We clean this up as we go, but it just works with add-ons and the starter kit. And even better when you combine DrashCMI tools. Dependency hell. So again, this has really solved, let's say on day one, with how we decided to build Sect 8. It was an architecture issue. The starter kit only depends on the most critical modules for the installation of the profile. The add-ons, they only depend on the new modules that they bring in. And again, no more features. This was our real spiderweb in Sect 7. With features gone, a lot of the dependency hell just disappears. So with Sect 8, if you need to disable a module on a per-site basis, you don't really have to do this fight anymore or worry that it's not going to work. It just works. Less technical debt. Now you remember from the slides earlier, this was the goal that we just didn't really achieve that we didn't feel right about. So there are countless examples through Sect 7 codebase where we build and change really significant things on the fly to get around features limitations and where things just didn't work how we wanted them to in sector. This consistently led to issues where things broke. Where is it broken? Is it broken in a feature? Is it broken in custom code? Is it broken somewhere else in the module itself? It was just a really annoying debugging process. So in the demo, here's an example of this. Here we're building a password policy from scratch with code to get around a feature limitation. And at some point, password policy, we ran updates and they made this API change with the ID. And the feature broke and we had to figure out how and the fix ended up being this one-liner. There are countless examples of this. Plenty of annoying commits or potentially grumpy commit messages but in sector 8 will resolve this as much as possible. The only custom code we have in sector 8, we still have the install tasks but they're really minor and they generally only touch core or really well trusted contrab things like XML sitemap or remapping sample content. Cool, so on to exciting times, the future. There's a lot to be excited about as we move into the future. For me, the number one thing is adoption. We know that us and some other people are slowly starting to adapt sector but we really want sector to be used on a wide scale. We want to see adaption. We want to see people testing, building sites, playing with sector. Our governance module on sector in Z talks about how to get involved if you want to contribute back to sector but if there's something you'd be interested in but really our goal is just to have people playing with it, trying out the add-ons, trying out sector, giving us feedback. We want more people having eyes on it. So, we're finally moving beyond the beta status. Sector 8 kind of feels like it's been internally in beta for a while. The only thing missing is the 1.0 release and the big green tick on Drupal. We have a couple of small blockers that are stopping this from happening but we really want to fix this. So, the blockers are the... Well, one of the main blockers for me on a personal level is automated tests. We want sector and the add-ons to have an automated test and an automated test strategy. Hiker and I, we both really wanted this all fixed and the 1.0 release before this conference but there's this little annoying thing called client work that just kept coming up and getting in the way. As much as I want to work on sector all the time, there is still a business and we do still have to actually get paid. And the other future plans are to keep developing add-ons. Newer add-ons are always in development for sector 8 as they are needed by clients. Over the last year and a half, we've been making up the missing content types from sector 7 but others are being added to the pipeline as they come up. So, how we develop add-ons. We have a few different processes for how we choose new add-ons for the sector D8 ecosystem. The first is missing bits from the sector 7 version. Sector 7 could be complicated but it had everything. It had workflow, which me and Hiker are talking about tomorrow. It had embargoed content, it had multi-pages. It had editable views, paste from words, solar, varnish. It had everything. So, we ripped all those things out but we'll still need them again so they get added to the pipeline. And the rule of three, this is the rule that I follow. Well, the next two points actually go hand in hand. More than one client asks for a feature and the rule of three. My personal development process is to follow a rule of three which is a pretty classic kind of philosophy. If I've built something twice, I'm probably gonna need it again. So, that's when we think about turning custom code into a library or a module or in this case an add-on. So, just here's a quick example of our add-on pipeline. We have membership and feedback form. These two here are examples of add-ons that didn't actually exist in 7 but have been prioritized for our Drupal 8 clients. Multi-page and workflow, they're both from 7. They need to come to 8. We've actually built workflow in 8, which me and Hiker will talk about. And to make the list not massive, we'll just stop here. Contribute. It's one of our big things. If we see a feature that's having value not to adjust us at Sparks but as the wider Drupal community and adopters of Sector, we publish it. The goal here is to really have all this stuff open source. Open source contributions. So, this was a bonus that I didn't really consider too much when I started building the Drupal 8 version of Sector. Because Sector touches everything from nodes, blocks, media, site maps, everything in between, we've been able to fix bugs and raise issues in core and contribs like the list above. We've also found contribs that we think have a lot of value but have been a bit un-maintained as time goes on, like term condition and advanced form. It's given us an opportunity to take over the maintenance of those modules and keep working in the wider Drupal community. We're publishing Sector and working in this kind of sector world but we want to keep contributing to Drupal outside of Sector as well. On our documentation site, Sector NZ, we have a showcase page. So, on this page, we have a lot of our Drupal 8 and Drupal 7 sites that we've built recently, Heart of the City, Head of the Sector for Forest and Bird, the Ombudsman, Bird of the Year, and Child Youth Well-Being. Great, so that's everything we wanted to talk about with Sector. Do you guys have any questions? On the microphone? How can I add to the process of adding like, is it a contract module that I will add if yes, what happens to the configuration that we exported? So it's all just standard Dural published as contribs. So we have like Sector events, Dural published on Drupal.org. All you need to do is compose or require it, like any other contribe, enable it on your Drupal site, and all the configuration will just be there. Right, so basically it's... At the moment there isn't like a UI that lets you do it? No, so it is still like a task where you need to edit your composer and publish it, yeah. But we haven't done like an old. The only thing that we have done here is to add this block to the starter kit and this module to the starter kit because this is just how the demo works. But we haven't even fixed the buck with the maps because it's just... What you see is what you get. Yeah, that's what Sector looks like straight out of the box. Thank you. What about entering content? Are you using like the body field or Pyra for something like that because I noticed that you have different type of like list or images or different UI elements in the main content of the site. So how do you build that? It's all just using standard Drupal fields. So we have the body field which has our WYSIWYG and all of our like WYSIWYG toolbar and tools. But there's no... In add-ons there's no magic. It's all just Drupal config comes with Sector. There's nothing too scary going on behind the scenes. There's configuration documentation for the Sector add-ons. So it lists everything that is there. It lists all of the components where they are, what we have done. So basically all of this is preconfigured but we also tell you exactly what we have done. And we also further down we tell you if Daniel has done something, I think he has done nothing on the blog. Yeah, so he has done nothing on the blog. There is one where we have manipulated a tweak file. Do you remember that? There is the... Oh, that's the quiz, I think, which isn't public yet. So if you manipulate or if you require patches for additional contribution modules, this definitely requires an additional contribution. Oh, yeah. An example of that is the media gallery, actually. Oh, the media gallery. Okay, so let's go and try to find the media gallery. This is the site builder documentation for the media gallery. And yeah, so these are the contribution modules the trick list that add-on. Daniel also does some incredible stuff where he checks if you have already installed it because of reasons, because as I said, he wants Sector to be yours. So he checks that stuff. And then there should be a note about a tweak file that we have changed. No, it's a core... A core? Yeah, a core patch. If you just search patch, you'll probably be there. Okay. So there's this core patch that goes with that module because something didn't work. Yeah, so basically there's a core issue that we need to fix to make the media gallery work. But because we still wanted to make progress and we still wanted to publish it, we just at the moment have the little note that says if you want to install the media gallery, this core patch is needed as well. But the Sector team is actually working on that patch to get it into core. So I was just wondering about the anatomy of the add-on modules. What proportion of them is just YAML config files? I assume in config store folder, right? Yeah, that's right. And then how much of it is like, are there tweak templates as CSS or is all of that deferred to something else, like the base theme or... So it does, yeah. It does depend a little bit per add-on. Like most of our add-ons are strictly generally just config files, that little few install tasks, and then with CSS, a lot of the times for our really custom add-ons, our really common add-ons, we just add the CSS to our distribution and then just have them disabled by default and turned on or just there in the distribution already because our very clever front-end developer, he has built a modular CSS style that means sometimes for these add-ons you don't even need to add any more CSS. You can just use the stuff that's already there in sector. Yes, there is a base theme in the base distribution. Yeah, yeah. So in this case, Tom needed to put... But the CSS is really... Tom needed to put something in, so it has a dependency. If you want to look at really good, you need to use beta file. I also want... At this stage, I also want to explain something about the use of display suite and view modes. So every single add-on trips with a short teaser and a teaser display and the short teaser and the teaser displays they are built to work in any sector, starter kit view. So it's all really streamlined. So that's probably good segue to my next question, which is how... Have you had issues with config dependencies? So say for example, you've got... Let's say you wanted to add the workflows module, which is in core, right? So the workflows module has a reference to the content types that are part of it. The content types that are part of it are obviously dynamic because they change depending on the site. So scenarios like that, do you just ship stuff that you know is going to be there from the starter kit and then stuff that's add-ons from the events and stuff you just have to manually configure? I mean, if the site owns the configuration, it's not going to be a problem. Yeah, you raise a really interesting... And we talk about this tomorrow a lot. We are full. So workflows are most ambitious projects so far because we just do score, but in the score, most are really amazing work Daniel has done. However, so we are at the moment just in a bit of a... We need to get... Sorry, workflows was just an example. Has there been other... No, so far, so far, you don't need to take a single box, but I promise you that you don't need to take a single box because we ran into this issue with the workflow add-on. And we are not fighting the system, but for example, what Daniel was showing on the XML site map, there's a little install hook because we can't configure the XML site map that it should include this, so there's a little install hook and they're also install hook into the permissions management because everything is just consistent and it just builds on top and on top of each other. And just to say one more thing as well, like for example, we have a content audit add-on, so it's an add-on that really gives your editorial users a lot of control. It just provides extra fields and what we do for that one, because we don't want to attach it to content types, to all content types on install, because maybe you don't want that, we just provide a checkbox in the content edit screen that just says enable, seek the content audit for this content type. So out of the box, it's there but not actually attached and then you can attach it as you like it per go. We have time for the last question. Yeah, I just wanted to confirm that something like this, that ImageFX module is required and there is a patch. I'm assuming you are putting that in the compositor, Jason, off the add-on? For the core patch we didn't at the time, I think there was an issue, but the modules themselves, they're part of the composer, Jason, so you do composer require sector media gallery and that pulls in everything. So this one, media gallery, sector media gallery, it needs a core patch and it needs those modules. So the sector media gallery should be having a compositor.json and that mentions all this as well. Yes, correct. The core patch is the one really unique kind of outlier in all of the system so far. Cool.