 And welcome to my session on building reusable websites on Drupal 8. Can anyone hear me fine in the back as well? No? All right, let's see. Can you hear me now if I speak a bit louder? Perfect. So today, I'm going to talk a little bit about lessons learned of transforming RedNoseDay.com. First of all, who am I? My name is Peter, and I've been a long time Drupal contributor, probably for more than 10 years I've been involved with Drupal. And I kind of wearing two hats. One hat is tech lead at Comic Relief, which is a major charity in the UK. And the other hat I'm wearing is I'm a founder of Marzulabs, which is a small web development agency originally from Barcelona, Spain, with offices as well in Portugal. A little bit about Comic Relief. Who in the room does not know Comic Relief? All right, so many people actually know Comic Relief, and that's probably because Comic Relief also exists in the US. But I'm speaking here on behalf of the UK team of Comic Relief, which is a major charity in the UK. We raised about over 1 billion pounds since our existence in 1985, money that we spent to tackle the root causes of poverty and social injustice. We do that mostly by organizing two main fundraising campaigns, Sports Relief and RedNoseDay. And you might be familiar with RedNoseDay because RedNoseDay is coming up as well in the US, end of May, on NBC. So obviously, I'm here to talk about Drupal, right? So we've been using Drupal at Comic Relief since 2014, and even before that, when we ported over our main web presence, comicrelief.com to Drupal. Now, we're doing these fundraising events year by year. So in 2015, we started working on our 2015 RedNoseDay campaign, where we chose for multi-sites. Basically, because we wanted to reuse the same code base that we set up for comicrelief.com. Now, when we started in our 2016 campaign for Sports Relief, we wanted to, again, reuse the same code base. So we thought, OK, we have this multi-site setup. Let's continue. Let's put another site on a multi-site setup. And as probably most people in this room know, multi-sites is not really a good idea. You start at some point, you feel like giving up, right? So the reason is that basically you're stopping yourself to innovate from the start by combining code bases from different projects altogether and not allowing you to actually change one thing and having it affect all the other sites that run the same setup. So when we started our RedNoseDay campaign for 2017, we started differently. We wanted to build a platform, a product, to power all our editorially controlled websites. It's a very different thing to think about something like that than to build a website. We don't want to build a website, we want to build a product to power all our campaigns that are coming in the future. And we want to really focus on three main components here, three main streams of work that I think are vital to build such products. The first one is the editorial experience. Editorial experience is very, very important because we want to build a tool that allows our editorial team to build a compelling website with different landing pages for our different audiences. But we also want to make sure that we automate this process and we streamline this process. We want to make sure that we build a product that we can iterate upon with a semantic versioning system behind it so we can actually know which website runs which version of the code base. And finally, I'm going to talk a little bit about decoupled services. And I'm sorry to disappoint you but I'm not going to be talking about headless Drupal. Because I think there's many different ways to decouple services that are not currently touched upon by headless or by existing ways to kind of decouple different parts of the system, right? And finally, not surprisingly again, our technology choice here will be Drupal, specifically Drupal 8, which is a very different kind of system from previous versions of Drupal. I think it's also important to say that I'm not going to really be talking about how we use Drupal or what modules to use and all this kind of stuff but rather how to position Drupal to build a stable product. So first of all, let's start with editorial experience. This is a sample website, a sample page, where you can see different components being used to make a landing page, right? So we want to build a site that can power these kind of pages. To do so, we didn't start this process directly in Drupal. We didn't want to be kind of bogged down by Drupal's code base, database, all these kind of things to develop these components. So we started with our pattern lab. This is very hot right now as well in the community where people are talking about component-driven design. Well, that's very important for us and I think for many websites. In this case, we started kind of dissecting our page into patterns. Examples would be like a quote block or an email signup header and kind of positioning this into a pattern lab. For this, we use something that's called KSS. Now, style sheets with sort of a documentation syntax for CSS. The good thing is that this can now be tested. We can develop these components in isolation and we can actually link them. And I don't know if you can see that at the bottom, there is an actual tweak template that relates to the CSS and to the display that you see on top. And that's reused later on by our Drupal instance. This kind of leads to what we call our pattern lab-driven development. So when we start building our components, we come up with an idea, let's say a quote block. We start building this quote block inside the pattern lab. Just using HTML, SAS, and JS, if for example, there's some interactivity to it as well. And then we kind of iterate over this until we're happy. We do a series of review processes, multi-device, QA, sign of all these things can happen without you having to do that within the Drupal sites. That's a major win because this process is so much faster. And then we move on to the Drupal development stage where we're gonna work on our content model, our view modes, put all this logic inside a component module and work on the tweak and potentially some pre-processing in PHP. Before it shipped off to the final product, the final site, where then the editorial team will take this on and start reusing this on all their different pages. Some things about the previous slide as well is you can actually do that in, you can start sharing this pattern lab with non-Drupal sites as well. So within an organization, you can build a pattern lab. That's generic, and that's all the sites can plug into and reuse the components they wish to use. We're currently in the experimental phase with that, packaging up our pattern lab as an MPM module. So how do we connect this now to Drupal, right? So how do we, what do landing pages, how do we build these landing pages in Drupal? And we went to a series of iterations to kind of get to where we are now. And our first iteration has been panels with penalizer, which is a very flexible approach to build compelling landing pages. However, it's a little bit like a hack because penalizer kind of ties the power of panels into a node, right? It feels, it's a great solution, but it's too flexible and it sort of feels like a hack. Our second iteration then used the same thing, but we started to use the paragraphs module within that penalized node. This, this worked a lot better. This worked so well that we actually didn't need panels anymore at all. So our third iteration was paragraphs. And paragraphs is a fantastic module. Check it out if you haven't. I think it's revolutionizing the way we do contents, content entry, and we build complex pages. And we kind of extended this, not really extended, but we used block reference a lot because the difference, a lot of the things we need to enter in these landing pages are not necessarily contents, such as an email signup form or something that has some custom actions added to it. So for this we use a block reference paragraph type that can kind of pull in blocks in the paragraph node. This is kind of how the system looks like, very simple. All powered by Contrip, no custom code required at all. We have our nodes with our different paragraph types. Main thing to know is paragraphs are not reusable. So if you want pieces of content that you can reuse on different pages, you might wanna structure this into what we do, what we call our library of blocks. And now you can just pull them in through paragraph types again. And this is how you can kind of give a lot of flexibility but don't compromise on the editorial experience. All right, that's the first part. The second part, I think that's very important when you build a product, is you need to focus on automating and streamlining everything. This is something very, very important that you need. And that is, you need to make your build in one step. It's part of Joel's Polsky's original tests for building good software systems. And you need to make this build in one step. How do we do that? Well, we package up our websites and our components using an installation profile. So basically build a distribution. Might sound very familiar to many of you, right? And we use the fantastic CMI in Drupal 8. We kind of slice up our config ourselves manually with config.develop so we know exactly what goes where and we don't have this monolithic blob of configuration. Default contents has been talked about before in the keynotes, very important because when we ship our product, we want to ship it with default content so we can, developers can do something when they extend the functionality. We can do QA, we can do automated testing all reusing that default content. And finally, you should use a build tool. We used to use Fing, which is like a PHP build tool, very powerful, but recently we're switching over to Composer, which feels more native to the projects as well as all the latest changes that went in Drupal 8's core that help you use Composer. If you haven't used it, check it out. Composer is fabulous. It's so much better than what we had before with Drush and Drushmake and all these kind of things that feel, always felt a little bit like they were native to Drupal. Finally, we also need to think about tests, right? Because if you build that product, we need to automate everything using tests. So we do a whole series of checks. Code quality checks, configuration checks to make sure that configuration is in the right place. Distribution installation tests. Every time a developer would commit a new piece of code, you want to make sure that you can reinstall your sites. That's not something was broken. And then you need to look at behavior tests. Like you want to use a tool like Behat to simulate the editor going through the site and adding all these type of landing pages that you've just been developing. After you've done that, you can check the locks, the Drupal locks, for example, to see what errors have been generated through this Behat process. That's a very nice way for you to make sure that all these errors you would otherwise see in production are caught at a much earlier stage. And the last thing that I think is quite important and often sort of forgotten is visual regression tests. Every time you make a change to your front ends, you want to make sure you understand the impact of that change. So you need to have some way to check this. And we're using a BBC's rate tool. There's a couple of other tools out there as well. I don't think it's receiving the right amount of attention. So I hope this will change in the next months or so. Finally, of course, automation is nothing without some sort of continuous integration behind it. So we use Travis, Travis CI. It's a fantastic tool because you can spin up basically a new instance on every commit on Travis infrastructure. And we run through all our checklists. And the builds basically will fail when any of these things fails. It's direct feedback for a developer, especially when you use something like the GitFlow model and you make pull requests. You can actually see the state of code and understand how things are affected by what exact action. Then the last thing that is kind of important to our setup, let's say, our preview branches. Preview branches basically on every commit to the code base built aside for you. And we use the service of, the fantastic service of platform message which can spin this up very easy for you, very cheap, and also directly give you feedback within the pull requests. If you haven't worked in such a setting, it's really great because it allows you to follow the changes as they happen to the code base. And then I come to my third part that I think is very important when we're developing a product, which is you wanna write better codes and you wanna use something like the coupled services. Again, I'm not gonna talk about headless, but I think the coupled services are part of our microservice infrastructure ecosystem. And there is many ways to do these kind of things in the land of Drupal. But first, better codes. Has anyone seen this slide before? Feels slightly familiar when you work on a Drupal project. Basically what I'm trying to say here is the more code you add to your product, to your code base, the more errors you're gonna see times two. So we wanna minimize the custom codes, right? We wanna make sure we only add the right amount of code to our code base and actually went through our current code base as a kind of a test. And I found just around 2,000 custom PHP lines in our distribution. Basically these PHP lines were relating to option callbacks, custom display suites, fields, solar tweaks, all these kind of things that you would call glue codes when you do a Drupal project. All the non-glue codes, on the other hand, we try to contribute this back to a specific module. So we needed a really good reason to do something, to do glue codes, in fact, because if you could refactor it into a module that can be contributed, that's the way forward, because then we can plug into the community to help maintain these codes. And let me now talk about kind of the two patterns I see for doing the couple services in Drupal. The first one might seem very obvious. Basically, we call it the embed pattern and we use iframes. Before you say iframes are bad, don't use iframes, you see iframes everywhere. If you see a tweet embedded within the New York Times article, chances are that tweet is coming from an iframe. So iframes are very much used on the web every day. So basically we make this easier within our CMS by allowing the editor to add iframes from other sites. An example here is a kids game we developed for our younger audience that is developed in a different framework. It's a front-end game using all kinds of 2D, 3D rendering techniques. So we just embed this from a different URL in our websites and kind of surround it with editorial content. That's kind of obvious. The other one is much less talked about, at least for Drupal. And we call that the queue pattern. Queues are a vital component in the land of microservices. Everything is connected, or almost everything is connected with each other very often via queues. And basically a queue system is very simple. You have a producer that produces some data and adds it to a queue. These messages are queued there until a consumer at the right time fetches the data, processes it, and does something with that data. Now, how does this look like in Drupal? Why, how, where do we use this? An example is an email list subscription. We have a producer, which will be our email signup form, would be a custom form. And we have a queue. That's every time somebody adds an email to that email signup form, it gets, a message gets added to the queue, including the email address, maybe a template ID, maybe some more data. And a consumer will eventually, at his, at the right time, pick up the data and do something with it. In this case, this might be a custom app. Might want to experiment with a Node.js app, or it might be a symphony console command tool, or anything that the team that wants to do something with that data is comfortable with using. And that would take the data and talk to Mailchimp, for example. So this is, in essence, a way for you to avoid using a module like Mailchimp, or any other direct email module within Drupal. And you kind of really separate two things from each other. This is great because you can now swap out your email provider for something else at a later time, and you wouldn't even have to touch your Drupal code base. So this is a kind of a recap slide, my final slide. How does our platform ecosystem look like? What kind of websites have we spun up using our products code base? That you see at the top. And currently we're running rednoseday.com on that code base. Rednoseday.org as well, which is the US campaign, is also using that same code base. And we're kind of refactoring all our other editorial websites as we go. And we hope to finish this up in the next couple of months. This is a little slide. Please join the sprints. Drupal is nothing without the contributed code. And thank you for your attention. If you have any questions, please come to the mic. Hi, thanks for your presentation. I was wondering, you mentioned you're using config.develop for breaking up the configuration. I'm wondering how you're doing that and what purpose that serves. We're using config.develop to kind of slice our configuration on a kind of a feature level, much the same way as you would do it in Drupal 7. So you would put the view modes, you would put your content type, you would put your fields all manually together into a module using config.develop. And then it's kind of a way for us to slice up our configuration for our distribution. There's many different ways. We kind of took this idea from AGOF, which is a fantastic Drupal distribution. But there's many other ways you can manage this as well. There's a lot of helper modules being written right now. This kind of works for now for us, but we might swap it out for something else in the future. Thank you.