 All right, welcome everyone to my talk about building randomnessday.com on Drupal 8. I probably should be giving this talk with this randomness day on my face. However, I actually tried talking, but it's very uncomfortable, so I'm just not going to do that. So I'm just going to go ahead and talk a bit about our story with building probably one of the biggest sites in the UK on Drupal 8. And actually, I'm not just going to talk about the site, but I'm rather going to talk about the products we've built in the process that is now powering randomnessday.com. The site went live already last year, in June 2015, when we actually set off with our fundraising campaign. And we've been adding new features over the course of the months, kind of building up to randomnessday, which is going to happen in just a couple of weeks now. So just a little bit about, I don't know, maybe somebody who hasn't heard of Comic Relief in this room. Everyone knows Comic Relief? Wow, so I guess I can skip my first slide then. But I just mentioned that it is. So Comic Relief is a charity in the UK, and we strive to create a just world free from poverty. We do that mainly by organizing two fundraising campaigns. The most famous one is Red Nose Day, and the other one is Sport Relief. And we kind of alternate. One year we organize Red Nose Day. The other year we organize Sport Relief. And we use the money we raise during these events in all sorts of ways. But we mainly focus on funding projects in the UK, around 50%. And there are 50% with fund projects in Africa. So we kind of fundraising the money, then working with charities on the grounds to distribute the money back and try to do good in the world. And we use the power of our brands to raise awareness of the issues that we care most about. We work a lot with celebrities here in the UK to kind of get our message across. Let me just say a couple of words about myself. I'm currently back at Comic Relief. I've been there for about a year and a half. And you can read about all our technology stories at our technology blog. We don't just write about Drupal. We also write about everything that inspires us to build kind of digital products to help us reach our mission and our vision. I'm also the founder of a small consultancy company digital tech shop, Mark called Merzilex. We've been doing Drupal for, I think, about at least five years. Based in Barcelona, we've got offices in Portugal and also here in the UK. And I'm a longtime Drupal contributor. So I've been working with Drupal since 4.6. I count the number of times I swear to Drupal in these long 10 years. And I've had ups and downs with Drupal, probably like all of you. I've been tired of Drupal. I've been excited again about Drupal. And now I'm kind of currently at the mood where I'm pretty excited about where we're heading, with Drupal, and especially with Drupal. Drupal 8. So let me tell you a little bit about Drupal as comic relief. We've been using, or better, comic relief has been using Drupal for at least four years now, five years. We started launching comic relief.com on Drupal 7 back in 2014. The world started already a while before that. And we were a different team back then. We were working very often with contractors, outside firms that helped us build our web presence. And our code base kind of gradually evolved with that as well. So then, come 2015, we launched the rednoseday.com website on Drupal 7. We actually coupled the code bases of comic-free.com and rednoseday.com together. So we were actually using multi-site support in Drupal 7 that I don't know if anyone actually used it before, but if you haven't, never use it. Ever. Don't think about it. It's wrong. The reason why it's wrong is that when we actually started building the website for our sports relief campaign last year in 2016, we tried initially building this from scratch, again kind of with best practices in days and all this kind of stuff. These are three workouts. So we reverted to our pattern that was kind of working, which was the multi-site input support relief on the same code base as rednoseday 2015 and comic-free, which led to a whole amount of problems. Most notably, when you put three different sites on the same code base, your destiny is bound as well. So if you change something, one little thing we started changing in 2016 was responsive image support. So we wanted to use source sets and all these kind of cool responsive things. So using the picture version 2 module that's available in Drupal. Now, unfortunately, comic-free.com was using the version 1 of the module. So you were thinking, oh, that's fine. We just upgrade to version 2. Well, that didn't work out. We actually broke our backwards content really quite badly. So we went in and started forking the module and put our modules in separate folders in our code base. Now, you can imagine that as time progresses, new features were added. That was kind of the norm. We were starting to fork our code base to support all these three different sites up to the point. We couldn't really maintain it anymore. So we were feeling like this. We want to give up. We just wanted to get the site out in whatever form or way possible. Now, come 2017 or actually end of 2015 when we started to think about our 2017 campaign, we thought we need to radically change here something. We need to build a technology that can actually help us power all the fundraising sites we need to develop over the course of the years. So we started fresh. At the time, end of 2015, Drupal 8 had just barely come out in the first stable release. So that definitely kind of caught our interests. But before I start talking about Drupal 8, yes. Sure, I can do that. I'm going to be very close to you guys with the mic here. If I shout, please tell me. Is that better? Yeah. Great. So we did a fresh start, right? So a fresh start of what? I mean, first of all, what is it that we want to accomplish? So we want to build a campaign website to support our fundraising campaign. But actually, that's not entirely accurate. Rather than building a campaign site, we want to build a product that can build us campaign sites. That's not entirely accurate either because we actually want to build a product that allows editors or our editorial team, which is a brilliant team of people we have at Comic Relief to reorganize raw components or sort of layouts in the websites to build our fundraising website. And we want to be able to continuously iterate over our code base. We want to not be bound by choices we made two years back when we look at the next fundraising campaign we are organizing. So the main theme, I guess, of my talk here is how we build such a product, what that product is. So here are just a couple of elements that I think are important when you think about such product. So first of all, the product should support iterative development. We should be able to add in a new feature and then swap it out for another feature or work on a second version of that feature for the next campaign in iterations without having to start from a fresh start new every single time you do some development. Second of all, you need to support a clear versioning scheme. So we need to know that that product is version 1 or version 2 or version 1.25.3, much like Drupal Core that we know we're using that version on Drupal Core so we can rely on all the functionalities provided by that specific version. We use semantic versioning for everything, which is something that isn't often done when you actually build a website. But it's definitely a great way for us to organize our products. You also need to guarantee the quality of your product. So how you can do that? Well, we all know we need to write tests. Tests are often the thing that you want to do, but you don't because there's no time, because the client is not paying for the tests. Well, I can tell you this. If you're going to build a product and you're not going to build any tests, you better do something else. Because you need to have tests to ensure the quality at every given step of your product development. You need to understand the impact of every change you introduce to your code base and have tests sort of backing up there. Finally, for us, very important, we needed a sensible default for every given campaign. Now, unfortunately, we only organized one campaign a year, so we only need to make that start once a year. I've always thought if you were to do a campaign every month and we need a new website, a new brand, a new logo, all these kind of things, a new product, things will be easier because we will be more geared towards kind of churning out these websites in a more efficient manner. So, when we're starting to think about our next campaign, we want to be ready and build that website in a month time. And finally, we need to allow for some customization, right? We need to be able that when a fundraising campaign needs to collect data from a user or anything else, we need to be able to allow the product to... We need to have the ability in the code base to be able to do these things without having to think about backwards compatibility. So, a little bit about technology choice. It won't surprise you that we chose Roupal 8, but we made it chose Roupal 8 because it's embracing industry PHP standards. Everyone's talking about PHP thick. The standards, we adopted as a community. And this is probably the greatest thing about Roupal 8, at least for me, choosing the right technology. And the reason is that very often in a large organization such as Comic-Con Leaf, you're not just doing one website, you're building a whole ecosystem of websites and applications that work together. Now, we use PHP for a lot of other things as well. We built a whole microservices architecture, for example, for giving pages, or we built an application to declare your gift dates. These are all using PHP standards. So, it's for us very important that our products is tied in or our websites can reuse these same standards. And we can actually start to swap technology between them. We built on top of Symphony, we used Twig, Composer, all these great things. And editorial features out of the box, which are very important because we actually want to build these landing pages. Accessibility, there was a great talk I think today as well about accessibility. That's really important for us. We want the website to be accessible by as many users as possible, or machines, right? Building rest capabilities, and finally, a development challenge. And at some point in 2015, when we were weighing our options, we said, okay, we've got to make a decision. We've got to have this side out in a couple of months. So, let's not think it over too much and just, you know, dive into the course. So, what are these ingredients that I think are very important to build our products? We focused on three things and I'll talk, I try to talk about all these in depth later. First of all, focus on editorial experience, automate and streamline, and then think decoupled, decoupled services. So, I'll start off with editorial experience. We're building a website that's supporting our fundraising campaign. So, for us, engaging landing pages that are beautiful, that are accessible, that are responsive, that are managed by our team of editors, is sort of the norm. It's the baseline of what a website should look like for us. So, we started really focusing on this. In the first iteration, we started using panels with penalizer, I don't know, as anyone use panels, penalizer, most people, are you still using it now? Nobody. Okay, so, well, it was our first iteration and it's a great set of modules. Unfortunately for us, the modules give just too much custom options for our editors so it becomes very difficult to manage. So, our second iteration was using panels, penalizer, and then embedded paragraphs. So, we're still working around the concept of nodes, but it can be extended to its panels and then, as part of the nodes, we have embedded paragraphs. That was already slightly better, but at some point we realized, actually, we're not using penalizer. We're not using panels, so why keep it? Why not just go all the way and use paragraphs? So, we ended up using paragraphs to build our landing pages and use block reference, a paragraph block reference, two reference bits of the website that are less easily editorially customizable, such as a sign up form or something that's provided by custom PHP codes. But still, we wanted to give the editors the flexibility to reference these kind of blocks through a paragraph block reference. So, this is our model of the website, very simple. You have your header, your menu, then you have your nodes, which are different paragraphs in there. And these are the kind of paragraph types we've been developing over the past year. Cards, calls, block reference, content wall where different cards can be positioned in different constellations. And also things like embeds functionality that I'll talk a bit later about. And the main thing, and then we use a library of blocks. These can be editorial blocks, custom blocks like email sign up that are reusable. Because the main difference between paragraphs and blocks are paragraphs are kind of hard tied into your nodes. While you have a series of blocks that are reusable, you can actually build that library and I have the editor kind of work with that library of blocks independence of a page. So we transitioned sort of to a landing page builder where certain elements are reusable and certain elements are not. And that kind of really worked well for us. Coming from a model where we built everything always on the page level and very specific to that page. This is kind of an overview of blocks, paragraphs. And we ended up using blocks for all the contents and paragraphs for lots of the layout. And then we used just a reference from one to the other to kind of make the connection. Paragraphs are only editable in the nodes, while blocks are editable everywhere with quick edits, with contextual names and all the kind of nice things that Drupal 8 gives you pretty much out of the box. The second part in paragraphs is that you actually, when you start thinking in pages that are composed of blocks, of paragraph blocks of data, you can actually think in the display of these independent from your Drupal websites. And actually you can create something which is often referred to as a living style guys. And that's a really powerful way for us to build the websites. Because basically what you start doing is you work on your CSS, your SAS, separately from Drupal in your team. You have your little block of HTML corresponding to your SAS. And then you automatically generate this style guide. So everyone I think understands style guide in the context of typography, button styles, all this kind of stuff. But actually we ended up building all our row components or our paragraph types in the style guides. This is one example of a row component. We built this because it's a small row component. And it's basically a way for our editor to say so much money was raised, that's the effect you've made by raising that money. And we've built this component entirely outside of our Drupal installation first. We can do a QA process on these components, test the components and its behavior on different devices before actually going into any Drupal ones. And this is another example of a row component for paragraph, whatever you want to call it. And you create this automatic style guide with all the different row components outside this component. So, living style guide, how we've done that? Well, we used something that's been around for quite a while now. It's called KSS, Nile Style Sheets, and basically KSS is Documentation Syntax for CSS. So when you write your CSS, you annotate your CSS and these annotations are picked up by KSS and automatically generated into your living style guide. And this resulted in an incubation area for us to trial new row components, to trial new ways of laying out our page, which was great. Code and style guides are one, no need to update one or the other independently, and thus guaranteeing your style guide stays fresh. And we've had great success with that, up to the point that our partners that are also building websites with our kind of theme and our frontend components are reusing the same components elsewhere. So this is kind of the process we followed for making these landing pages. We had a component idea, work through the component in style guides, HTML, SAS 7 and JavaScript, do a series of review, multi-device testing, QA, sign off, before going into actual Drupal developments. And then the Drupal development is pretty standard. You define your content model, your fields, your view modes, sorry. And you package this up in tools, what we call component module. And then you work any custom logic in there using PHP. I'm not sure you'll be able to see much of this, let's try. But this is our improved editor experience. We've actually asked our editors to make a screen cap of using the Reynolds Day 2017 site and the 2015 site. Here we're filling in panels, page manager pages, mini panels, I don't know, all kind of panels variants that have been around boxes, blocks. And it's usually, it's very difficult for editors to deal with that. While the others, well, the Drupal day site, using just a simple paragraph concept was actually pretty easy. And editors are of course much happier and can thus build more engaging pages for our users. This is just an overview of how these different raw components all compose together and are shown on the page here. This is the story component I showed you before in a style guide, here it is in an actual page. The email signup block, I'll talk a bit more about how that works, but that's one of these custom blocks that we control and editor can create these blocks. But they have certain back end logic associated then that editors cannot control. But they can kind of organize the layout within the page. See how I need the time, I think I'm okay. So the next part of this talk is about automating and streamlining everything. How many of you have tried to build your website in one step or know about the built in one step concept? Nobody? So, built in one step is a really powerful way of thinking about your website. So if anyone can build your website in one step, you can start automating stuff that comes after that. So, in our case, we're using the concept of an installation profile. It has been around in Drupal since, I think at least Drupal 6, and we're using CMI. So content management initiative, configuration management initiative rather, to kind of have your Drupal settings stored in files, right? And we use a module called config-develop to kind of package up our configuration related to a paragraph type or node type, put this in a module and kind of manage it in that module directly. I don't think I have the time to kind of dive into this entirely, but I'll be happy to talk more about how we work with config-develop after the talk. Importantly, if you wanna have a built in one step and kind of install your sites in one step, is that you have some default content, right? Because you want to have a good start of any website. So we store our default content in JSON. We use the default content module, which is really great. And basically serializes your nodes, your paragraph types, and your blocks in JSON. And then you need to use some sort of a build tool. So we use FIM, which is a PHP build tool that's been around for quite a while. It has honestly a horrible syntax. It's using XML for everything. We're not used to write XML anymore, but it does the job. And we might be replacing this soon with Composer or with MPM or whatever kind of more modern build tools that are around. And we build, we run FIM builds often. FIM builds basically installs the whole websites from scratch and allows you to start customizing it further. This is an example of some of the modules we have in our profile. This is Cards. This is one of these row components we have. Basically, all the modules are very simple. They contain an info.yaml file which references all the pieces of config. It's module.exports, then .module.file, which is very often empty. And then the config install that actually is a doc, which actually contains the yaml config.exports. The next part in kind of automating our workflow is we need to find, we need to have a way to expose the code that's being written, and that's different developers are working on. So I think this is kind of the norm these days, but we use GitHub for everything. Use a typical Gitflow model with a master develop and a feature branches that work off there. I really like to go in the morning and browse through all the different pull requests that have been made in the past day or so. It's a great way to keep up to date with what developers are writing. And it's a great way to have different people talking to each other that otherwise wouldn't necessarily talk to each other. One of the things we're trying to do now is just hope to get non-technical people involved in our GitHub process, because that can actually help a lot, to avoid a lot of problems we would otherwise face down the road. I'll talk a little bit about tests. There's no automation without tests, right? So what kind of tests are we doing to ensure the quality of our builds? We do a lot of things like code sniffer, PHP mess detection, or code beautifier that run at the first step when the developer is working on the code. And then we do configuration checks using config develop, making sure that our configuration is consistent with what the model describes it should be. Then we do sort of a distribution installation test using fit builds. We need to make sure that our distribution, our campaign profile distribution is actually installing fine. There's no errors sitting in the installation. If not, this test will fail. And then we do behavior tests using Behats, and I'll show one of the tests later. We also do things like every single time a developer commits something to the code base, we do lock checks. That's something that's often forgotten, but is the greatest pain six months into a live site because your locks are exploding and you simply do not have the time to fix them. So since we're installing our site continuously over and over again, and we're actually simulating the editorial behavior using Behats, and kind of this behavior given testing, you can actually see where during all these actions we perform on the website, we actually generate any error logs or warnings or whatever. And if there is one warning, the build will fail and the developer won't be able to commit his or her codes. And then we're, this is very experimental still, but we'll start in the visual regression test where we actually try to kind of compare previous and next version of the codes, visually and kind of compare the difference in percentage of either two websites using an open source tool from the BVC called BVC ways. This is one of the Behats tests we have written. I'm not sure you can read it, but basically it simulates the creation of a landing page from the perspective of an editor. So you create a landing page, you add a number of paragraphs and then you basically assert that whatever you expect to see is present on the page. So if the developer changes one of the paragraph types, this test will fail. Has anyone seen Behats before? Is anyone not doing Behats yet? Okay. Start doing Behats, it will save your life. I mean, it's immense. All the kind of actions you would be doing through the UI, you can write this in Behats. It takes a little bit of time to get used to it, but Drupal has great support. And I even think that Drupal Core is gonna adopt Behats as a testing methodology. I'm not sure when this will happen, but that would be great. Now, testing is pretty much useless if you don't continuously check for that, right? So we use Travis as our continuous integration tool. So we built our code base on every single commits that the developer makes in every single pull request that's being made to our stable branch. And some fails, some don'ts, but we always know that if it fails, it won't be allowed to merge in the stable branch so it cannot generate any problems. Kind of the last part of automation are the way we work with our code is preview branches, which is something, and I'm aware I'm throwing a lot of different topics around where they all kind of fit within our model of creating this collaborative environment of building a product. And I think preview branches is often not talked about enough, but there's actually great tools available right now in Drupal lands, one of them being passed for research. So basically what we do, every time somebody commits something to a feature branch, we rebuild the sites from scratch and show this on a preview environment. We also do something more, which is every time you open a pull request, you build a site from scratch. Every time we commit to the same pull request, we just import the configuration. This is so we speed up the actual preview of the site. If not, you have to wait every time 10 minutes for your site to build. This has saved us a lot of times and we're using it in all our processes. We're using it to QA, QA new versions of the sites to test out new things to experiment with new things and it saves enormous amount of time. Then, and I think I have another five minutes, 10 minutes. The final part, sort of what is important when you build such a product is to think decouples. We all have heard about probably about microservices. We all want to use them, but in Drupal that often microservices are thought about as headless Drupal, right? You separate your backends from your frontends. Well, while this might be right, then you would miss on all of the frontend tools that Drupal gives you, like tweak or when you build paragraphs, how you're going to separate this from back. So that's not the way for us that that would work or make sense. Okay, this is a slightly different topic, but I really like this slide when I saw it because basically means the more code you write, the more errors you get times two. So we try to limit our custom codes all the time. We're using Drupal, we're using contributed modules, so there's no point of us writing a lot of custom codes, right? And basically we minimize our custom codes. I think I've actually went through our code base and we have around 2,000 custom PHP lines to power RedMills.com right now. And these are mostly sort of what we call glue codes. We write a lot of glue codes. Well, not a lot because we only wrote 2,000 lines. And then all the non-glue codes, we kind of package this up and contribute this back in the form of a module. So we've done, we've contributed two modules for this project, RabbitMQ and Social Links. So how do we minimize the custom code? So we basically use two patterns to minimize our custom code. One is what we call the embed pattern. In this case, this is a page with a kids game. You can find it at RedMills.com slash kids. And the embed pattern is used to kind of integrate the third party websites or application via a blog. And then we usually do an iframe into our website. So that's all the way to the couple to distinguish these different services into one website. But the other pattern we use a lot is the queue pattern. And as anyone has, anyone heard about queues and why they would be used? So basically the queue, you have a producer, you have a queue, the producer continues to dumps data into the queue and then on the other, on the other hand to the queue we have a consumer that kind of picks up elements from that queue and does something with them. The easiest example for us in our use case is an email, this subscription, right? We want to get impulse email addresses for newsletter or whatever and mail to them and add them to our address book. So in this case, our producer is a Drupal website. Our queue holds the email addresses, things like a template ID and everything required for the consumer or the processor to do something useful with that, such as sending out an email to the user that just subscribed. Now you might use the Mailchip module in Drupal, right? I mean, that's what it's useful for. However, if you think like this, you're gonna hard couple Mailchip and Drupal together. In our case, we don't care about who's gonna do something with the logic or with the data we push to the queue. In fact, we have a service that enters the email addresses stored in the queue and then sends them out using first of all the email addresses stored in our internal warehousing and then it's also send out using a service called SmartFocus to the user to walk with them. As a result, our custom code on the Drupal site is limited to just drop something in the queue and for this purpose, we wrote a Reviton queue module. Reviton queue being sort of the main, one of the main messaging, queue messaging systems around there. I don't think I have time to go through the codes, so I'll just go through there. But basically, we're actually moving towards microservices by starting to decouple logic like that. I mean, we haven't even talked about Hattus, right? So we use on-beds, iframe for integrating third-party apps into our websites and we use message queues for decoupling logic of two things that don't make sense to actually be together. That's a very powerful system for building microservices because then you can work on your different software components independently from each other. So now you might wonder with builds, we built a product with these characteristics. What about redknowsday.com, right? So redknowsday.com is currently using version 1.36 of this distribution we've built. Comic.com we're currently porting is over to the distribution as well. And Sportary.com might, for example, use version 2 of our distribution. So we actually have, through our version management, we have the power to kind of change things under the hoods without having to worry too much about breaking three sites at the same time. And redknowsday.org, that's our sister campaign in the USA, is also gonna reuse our same code base. And they're currently working on this right now. I don't think I'm gonna go in detail because I think I have a couple of minutes left. So I'll leave some time for questions, but this is kind of how we deal with config and kind of deal with building redknowsday.com on the campaign solution. So questions? Yes, they typically stay around until, so the question was how long does this campaign sites kind of live or stay around for? And they really stay around for about two years when they're replaced by the next campaign because redknowsday.org is every two years, port leaves every other two years. And we're starting to archive this right now on 2015.redknowsday.com. So you kind of see our previous campaigns. Yes? Oh, the start point. Yes. You mentioned that you develop a lot of the mark on the end of the day, I don't think that. But does that mean that you then small as a lot of templates which would start there? Right, that's a very good question. And so the question is how do we deal with our market when we develop in a style guide versus our Drupal counterpart, let's say. And we actually overwrite all our templates from scratch, so we use this place for it for that. And we kind of map it one to one on the handle bar, close-knit, that I showed you before, which lives in a style guide. We're currently in the process of using tweak for this, so we can actually use the exact same HTML for both. That's very experimental. There's a couple of KSS source supports for tweak. But we haven't yet made work together well. But yeah, that's definitely where we want to move this. So we reduce another step. And yes? Do you find you have to QA this twice once in a style guide and once out in the world? Yes. That's a short answer. We need the QA, so the question is do we need to QA the components in the style guides and also again in the website? And actually, I must say we probably QA them right now three times, which is once in the style guides, once in the distribution, and once in the websites that's using the distribution. The reason for that is that we're still kind of finding out what needs to live where, I guess. But very often it's not, there's a couple of integration issues and there's no really big problems with that. But we definitely need to be tested still in different places because of the surrounding context. Any more questions? Yes? I'm used to paragraphs for making these landing pages. Yeah. Obviously over a long page, if you haven't experienced that, it's going to get very upsetting. I don't think I've any tips for that. Yes. I'm going to go back to my landing page. So the question is, how do you deal with very long paragraph edit forms? The answer is, at least, the answer for us is the use of blocks because blocks, while you reference them within the paragraph, you often wouldn't edit them within the nodes or the nodes with paragraphs. And with quick edits, so you will build your page, then you will just, quick edit, just a block, rather than going to the full note of this one, which is a lot lighter than doing that. I think there's also support. They're starting to work on quick edit support or in-line edit support for paragraphs, but that's very experimental, I think, and that will probably do the same thing. And the idea of this long edit force. Anyone else? Back, I think I have one more minute. So you said a couple of modules are probably effective. Yes. Are you planning on contributing more distributions? Yes, and I deliberately left, so the question is, are we planning to contribute to the whole distribution? I deliberately left out one slide that I had prepared, which is we're open sourcing all of this. The reason I left it out is because we're dealing with our legal team to make sure we can have a sort of, I wanted to kind of give it here at Drupal camp, but it's gonna come a little bit later. But definitely we wanna contribute this to have everyone being involved in this. I have one more question there. So the question is, how we separate paragraphs from blocks? And we actually also, I mean, both of them are content, right? The reason is, we put content layout logic in the paragraph. For example, go left, go right, or image, big image on the left, text on the right, or the opposite. This kind of logic is in the paragraph. That the block is basically just the content, which is often a title, an image, and some body text. So that's kind of how we separate it. It's not referring to actually the layout of your Drupal website or your tweak, or anything like that. It's still about content. But it's more for an editor. From an editor's point of view, we can use the same copy, editorial copy, but display it separately in the paragraph context. All right. I think that'll be it. Thank you very much for that. Thank you.