 All right. I think we can start. Hello, everybody. Thanks for coming. Welcome to our presentation. So this presentation is going about how to build content layouts in Drupal 8. We're pretty excited to be presenting together for the first time. Yeah, let's just jump in. As you can see on the bottom, there's a URL that I've already shared on Twitter as well. So you don't have to copy everything. Just go online and find the slides. It's tinyurl.com slash Dublin layouts. So who we are? Let's start with Inky. Hi, I'm Inky. Proper name is Ingrid, but everyone calls me Inky. I'm currently the project manager at Amazylabs in Cape Town. I've been working with Drupal since Drupal 6 in 2009. Up until last year, when I joined Amazylabs, I was working as a freelancer. So I was doing the full scope of projects, site building, front end, everything myself. So it's not that I'm just a project manager. I'm also a site builder and developer as well. I've been involved in the community in Cape Town, the Drupal community in Cape Town for quite a few years. And yeah, this is my first DrupalCon. It's not my first DrupalCon. My name is Josef Darbenig. I'm originally from Vienna. I live in Zurich in Switzerland. I've been working with Amazylabs for two years. I started Drupal actually in Nicaragua. So I'm really passionate about the Drupal community all over the world. And yeah. So my role at Amazylabs is I'm a tech lead that doesn't mean working a lot with code at the moment. That mainly means guiding the team, supporting the team, and taking decisions. And I've been doing Drupal a lot back then in Drupal 6 and 7 as a site builder. So that's why both of us share a lot of passion in that area. But then, yeah, other things we have in common. So besides Drupal, which is mainly at the moment our Drupal8, we both work for Amazylabs. But we actually only met for the first time in real life yesterday. So we've been putting this together across continents. And the other thing that we have in common is cycling. Hands up. Who has heard about Tudor Drupal? Yeah, that's a pretty big number. And who has been cycling for Tudor Drupal this summer? Nobody. So there's six people that have cycled. And yeah, both Inky and me are really passionate about the topic cycling, apart from Drupal in general. So that's going to be the base theme. And what we're going to talk about today, apart from the general introduction, like explain a bit, set the baseline. Who of you has worked with Drupal8 already? Awesome. Wow. OK, so you're probably going to learn so much. Sorry. So we're going to give you an overview how to create landing pages, for example. And then we're going to jump into a couple of different approaches. And we're going to explain that by, like, WYSIWYG versus paragraphs, Display Suite versus context, panelizer, and tweak templates. So we're going to really show a real-world example by talking about all of these topics. And hopefully, there's going to be room for Q&A to kind of find out what are the current questions that you have. Yes. So the big picture, we said, OK, we're both really into cycling. So obviously, we wanted to create a site together remotely, like on a shared development environment using CMI. So the big topic is it's going to be a cycling site, and Ink is going to walk us through the topics. So basically, the idea that we put together was that if we were to build a website around cycling, what would you need? And for anyone who would want to find out where to go and where's a good route, so one of the content types would be routes, which would have a description about it and a couple of pictures about the map. Then obviously, you need cyclists to sign up. So the cyclists are the user profiles. And cyclists also have generally multiple bicycles. It's always n plus 1. And so we've got our user profiles. And then cyclists are also generally, well, sometimes, part of clubs, for our case that we are. And so we've got clubs as another content type that all three then pull together. And maybe to set the stage a bit, this is site building. So don't expect us to have a fancy theme on top of it. This is usually done by our other great team members. Yes. So there's a lot of possibilities how to approach this. And we come from different backgrounds. So we actually, obviously, the fun part about doing a presentation together is to figure out what are the approaches that Inky would take, what are approaches that I would take. So I personally, more come from a panel's background. And in Drupal 7, amazing labs in general, we specialize on doing everything with panels. Because we know, OK, there's panels everywhere. For the big page, there's panels for the landing pages. There's panelizer for the content pages. But I also see that there's a point maybe for. Yeah. So for Drupal 7, I was using Contex a lot, using it to completely overwrite the general block layout. And every aspect of my site was built with Contex. And they generally use blocks generating content. And it's been really great for me. And one of the reasons that I chose Contex at one point of a panel was just because the HTML that is generated is much cleaner. And panels, for me, it was just crazy to try and work out at what level I'm trying to theme something. And there was always something overriding something else. But for me, Contex is simply a cleaner way to go. Let's get a feeling. Who is on the Contex side of the hemisphere? All right. OK, come on. Join me, panels. OK, so for Drupal 8, that's definitely something as amazing. We have been starting building Drupal 8 sites two years ago already. So it's a constant changing targets, which of the modules are available. So what we're going to talk about today is going to be a bit more than we have been using, like, two years ago, obviously. Let's set the baseline. Who of you has started Drupal only within the last year? Cool. Welcome. Awesome. So probably you already know how the basics work, but I just quickly want to reiterate. So there's themes in Drupal. We can download modules. They add functionality. And we can download themes. They do the styling of the website. And it's important to know that we have a content area, which is kind of the magic big center. And then around it, any theme can define any number of regions. So we can see, for example, that would be a header region. That would be sidebar, sidebar true. This picture is really old. We don't suggest anyone to build a sidebar region anymore, but just for historical reasons or to understand how the system works. Obviously, a sidebar is just a bad idea at all. So we can place blocks into it. And between Drupal 7 and Drupal 8, a lot of stuff has been converted to blocks, which is Inky is going to talk about as well. And every of these, it's like an onion. So the whole page is a template. Then the region is a template. Every block is a template. And within those blocks, all the contents also have sub templates. For example, each field would be a template to set the baseline. What are the tools that Drupal Core basically provides us with? So now with those, plus also with some additional stuff, we were thinking, OK, what are the options that we can use to build stuff? So blocks, as we just shown, that's the real basic of how to place different pieces of content around the site. And then obviously within the content area itself, using WYSIWYG to be able to do layouts and content within just the content of the node itself. Something that's been used slightly in Drupal 7, but I think in Drupal 8 now, it's become quite a big thing as paragraphs. And you've got DisplaySuite as one of your options. I'm pleased. Yeah, so there's like a lot of ways we're using DisplaySuite. Inky is using a context. There's panelizer and panels. There's the templates. So all of these options are available. Now the tricky question is to figure out when are we going to use what and what are they good for? And one good argument that we had is like, well, the question, who will be able to edit what? I mean, a content layout can be defined by the administrator, can be defined by the client themselves, can be defined by a certain user role. So the definition of what is static and what the user can adapt is a quite important one to take. So the other question is also, how much do you trust your client with editing access? So you can give them a WYSIWYG with a full set of features, but then you end up with huge images that are five megs and 5,000 pixels wide, but it's actually scaled down to 300 pixel and looks like a thumbnail, which, yeah, that's not great. And then if you give them too many options with the text editor, you end up getting pink text and comic science, and it doesn't fit in with your styling. So when you build them with things, it's keeping in mind, obviously giving the client a certain amount of accessibility to be able to do what they would like to do, but then at the same time, keep a bit of control over what's going on. Yeah, that's really important. All right, so I think that's enough for the introduction. Let's take a look at what we actually can do. And first of all, we're gonna have some overview pages, the cyclists and the routes and what we're gonna use for them. So we've got between our cyclists and our routes, we've got some listing pages, very sort of standard list of all the users on the site and all the routes that have been loaded up. And one of the aspects that we wanted to put on these pages at the top was the header sort of sectioned intro with the image and a little bit of intro text. So for this, just as a sort of a bit of a sidestep here, just generally about blocks, what's new in Drupal 8. Although I must say, if all of you were at the keynote now, I think what I'm about to say is slightly changed from what Gries was just talking about. But some things that are changed are the fact that site branding, page title and tabs and a couple of other aspects are not actually blocks that you place through the block layout as opposed to being the template. You can reuse blocks within the block layout as well. So this is, yeah, sort of mini game changer but I mean it's really useful so you can load your main navigation up in the main header area and in the footer and it's the same menu block. You don't have to have two menus that will load your navigation up twice. So that's really, really useful. Then also now menu blocks is also part of core. So it's a little bit sort of limited compared to the full menu blocks module that we had in Drupal 7. But you can load up your menu and limited to either just the top level or just the secondary level and limited to how deep you want that to go. Then also now we have custom block types. So you can create your own custom block but we'll show you a little bit more but it's not just your sand block with a description anymore. And what makes the developers happy is the blocks are now plugged in. So they are extensible. We can make them configurable through the user interface. They are exportable so we can also export the configuration that we, when we configure a block type for example, really, really important. And something that me really makes us really happy for the rules and initiative for example that there's a condition API which is abstract and part of Drupal core which allows us to specify visibility conditions for blocks for example and any other module could add to those conditions. And when we take a look back and the example that we look at, so these header, I mean, we can just do that via WYSIWYG or as Inky indicated, we created actually a block type and that works similar as content type. So we specified each of the section header blocks should have a banner image, should have an introduction and the title and that way we can maintain a form that all the administrators will then, for each section create a block of that type so that it's structured and it doesn't get like weird, like differently formatted for different sections. Sorry for the formatting, it looks good here. So one of the challenges that I've always found with purely using the block layout is the fact that when you start loading a lot in it starts getting confusing. The way it's in between things starts getting a little bit sort of jittery and you just have your entire site then built on one layout to manage it just starts to get a little bit too much. A couple of the extensions that we found recently that have been very useful is block access. So it works very much on the same granularity as node access in terms of editing, creating, deleting. So in the case of this, if you were to create a custom block type and you could give your client access to just edit the section headers that you've created. So they can go in and through the front end just go upload a new image, upload their text but then not have the access necessarily to the whole block UI where they can then go and shift around what's what and change the context that the block appears. So that's very, very useful extension onto blocks. Then the other one is the block visibility groups. And so for that, I'll train a moment but for our cyclists header, we've used a very standard block placement for the condition. So it's just on forward slash cyclists and then also on forward slash users. So that header also appears on user profiles. So for this you can only at the moment for a block for each instance that you're using it, you can only use one condition at a time but then we now have block visibility groups. So as the name suggests, it just groups the conditions. So in the case for our routes, we hadn't added on path auto yet for this demo site. So for us to then go and add forward slash routes and then forward slash routes slash wildcard we didn't have that path auto automatically generated. So using block visibility groups, we can say that the content type is route and the path is also forward slash route so that we've got that section header on our listing page and on the nodes. So yeah, block visibility groups, very, very useful. All right, so we've talked about the overview. What about the, so we're gonna talk first about an actual or content implementation comparing WYSIWYG and paragraphs. So paragraphs like the new kit on the block, finally having multilingual support in Drupal 8. So that's like the main reason why we didn't use it in Drupal 7 because it's not multilingual compatible fully. So this beautiful routes description basically contains of, okay, people can upload the images of what routes they have been taken. They fill in some base data and then we wanna have them tell us the story, right? I mean, the route is like, really, I have accomplished something. I cycled 70 kilometers. Why did you put that in? This is the WYSIWYG example. Cool, yeah, so we can see, one of the options is obviously WYSIWYG, the CK editor that is now part of Drupal Core. You can also add another editor. What it does is, as we can see on the left side, we enter the base information but then we can use this WYSIWYG field that by default is a bit small but you can make it a lot bigger and people just enter the contents. They can use any formatting that you allow them. So on this side, we allow them to use Comic Sans as a form which makes it much more pleasant. Yeah, so, and that's a bit opinionated obviously. So from my perspective, using only WYSIWYG has it advantages so we can copy and paste long form content, for example. So we can just, an editor that is used to using a word processor, which is copy and paste it over and has it almost as formatted as it was. But on the other hand, it's one big chunk of HTML and it can get messy especially when it comes to alignment and special format things. So it's not something very structured. Something that we have been using a lot in Drupal 7 are the CK editor templates. So those are like templates that you via a button can insert to kind of give the editor a more advanced markup being generated. For example, like image and then some text on the side. We try to limit WYSIWYG as much as possible for Drupal 8 because of the following situation. So we've been using paragraphs quite a lot and quite a few of our projects recently and one of the things going back to the comment about how much access do you give your client, one of the solutions to that is to use as many fields as possible to load up content specifically so that you can manage your content and your layouts through your side and not giving your client too much freedom. And then also using fields, especially for image uploads that the Drupal side and image styles, they manage the images so you don't get that 5,000 pixel wide image. So for paragraphs, these are sections of structured content which you can create, I'm teaching different types on your site. So they're all loud options. So you could have one paragraph style which is a text and media and then another paragraph style which is a large image section header that just has a title over it that you can then go and add parallax or something onto it. And then with this you can use for each, for all the content type itself. So in this case, on the routes, you create one field for a paragraph content and then within that you load up as many options of paragraph styles that you've created. So for this we just created two, one being a section of sort of a little bit of story about a segment of the route and then the general text and media which is a bit of a blah blah about the route itself. And you can use multiple instances of paragraphs per field on your node. They're very easy to reorder so it's kind of a little bit like field collections but this is now part of the node, not a separate entity. And you can also nest the paragraphs down to two levels. So if you have your text and media, you can have your text area which is just the text and maybe a title in front of it. Then you have your second paragraph field which then you can choose whether you want to load up an image or a video or something else. So you can go down two levels and then those can then be reused in other paragraphs or as a paragraph sort of by itself at a higher level. So you've got quite a bit of flexibility in how you load them. In which case you only need one template for that. And also paragraphs are integrated into views so it makes it quite easy to be able to pull things through separately if you want to. Let's maybe we'll take a quick look at the actual implementation, how it feels like on the real side. So this is the doubling cycling demo populated with some exciting content that we filled in. So when we go into the routes, as we have explained initially, so we have the section header on top and then we have a listing of those routes and around the mountain with coffee. Should be the one that's based on WYSIWYG with the comic science. So yeah, it's standard, triple eight editing and we didn't really customize the WYSIWYG editor a lot but we can see we have a lot of full HTML that's very permissive. That's like the editing experience that a lot of clients will ask for, I guess. So they can do a lot, but it's also like, yeah, just danger what can happen if you give them so much powers. On the other hand side, when we go back, the other route was C point, yes. We go and add it here and Inki is gonna tell you. Yeah, so this one, I bypass the WYSIWYG section and just use the paragraphs. So here, oops, the text and media. So this is just, so you've got your title, field, story and then your image and I have included here sort of a left and right placement and I'll chat about the left when we get into mention templates and then down here, I've loaded up a number of sections and the sections also again have a title, have a distance, got a grading and then a story. And so this, as I say, you can easily move them around. So if I decide actually, hang on, I want to shift that over. Those just sort of pop around and so it makes for quite a more rich way for someone to be able to load a lot of interesting content but to be able to give them various options and a slightly more structured way to load it up. And we can see when the editor now wants to add content, he can choose from the different paragraph types that are available in terms of I create a section now or I create some text and media or I would want to add a gallery and you can really administer them as you can administer content types. It's basically the same thing, very cool. All right, so that was the first section. So cyclists, so here we're gonna have a look at display suite versus context. So the cyclist knows, as I said earlier, that these are the user profiles and on the profiles we've got a little bit of information about who we are, birth dates, gender, all those kind of basic bits. Then we're also using paragraphs. We've got a section to be able to add some a little bit of biography or story about oneself and then also an entity reference to the clubs that are created to be able to say what clubs you've got and then also on the profiles, we want to be able to display the bicycles that you've loaded as a separate content. And we can see already there's, like in terms of layout, there's the image next to some base data and then we have this in the sidebar. So as we don't know CSS, we kind of have to come up with the solution how to structure that content or even if we knew CSS, we have to first group the items so that they can be laid out in the way that we see it. So the first step that we take is using DisplaySuite and what DisplaySuite basically does, it enhances the display of any entity. So that can be of content like nodes that you can also put DisplaySuite on top of users or you could also use it for paragraphs as Inki has been using it. DisplaySuite supports a layout plugin which was temporarily in core. It's a separate module that defines like you can describe a layout in terms of which are the regions that the layout depends on and then the layout can also add some CSS. So when we jump into here, let's go back. So we were talking about the cyclists which is a separate section and those are basically users. So I can go to Inki for example, like look at her cyclist profile and we see it's basically as we've shown it in the screenshot. Something that's nice is that when you add the DisplaySuite module, it adds this kind of managed display tab directly to the content that you're viewing so you don't have to know where to go into the backend. So when I click on manage display, I'll get redirected into the managed display of the people configuration. So when DisplaySuite is activated, it will allow you to select from one of the layouts and these layouts are provided by default by DisplaySuite but there's also extension modules that provide additional layouts or you can define your own layouts in your theme which is pretty awesome. And then when you activate that on the upper side, it just works very similar to managing fields normally but you can now switch them around between the regions that you have pretty fine. So I have the picture on the left, I have some information on the right. So that's pretty awesome already to kind of lay out content itself but in order to pull in additional information, we also have the cyclist clubs and the cyclist clubs is a listing of all the clubs that the cyclist pertains to and that's something that usually would place like as an additional block somewhere outside but here we decided we want this to be part of the content because I don't know, the cyclist, the club just belongs to the content in terms of visual representation. In order to do that, something interesting that we have found is that in DisplaySuite you can also define so-called DisplaySuite fields and one of the field types is a block field. So basically I can define a block to be available as a field on the user in that case. So that's really interesting that we now can also place blocks into the content found that really helpful. So when I go back to the example, we can see those cyclist clubs, they are actually part of the rendered entity. You wanna continue with the context? Yeah, so the other aspect that we used for this was putting the sidebar using context. It ended up being fairly basic compared to what I'd actually been planning to do and it's the first time I've really been able to play with context since it came out in Drupal 8. So the concept for this was to generate the sort of biography is a field on the users but it's not being displayed as part of the content. It's being put out in a views block in the sidebar. So that's where with using paragraphs and views that's being generated through that. And so that block, it is just being placed and this you could use as the stand block layout. It's the condition is the user and then very similar to context in Drupal 7. You've got it's loaded up into the sidebar. The thing that I came across with this though and I'm not sure whether it's bugged we haven't quite had time to look into it further yet is that I found that as soon as I loaded up the context all the other blocks that are loaded through the blocks UI, those weren't working now on that context. So I ended up having to create a general site layout as an additional context which basically is placed on the same condition and that's loading up everything else. So I'm not quite sure yet as to what the plan is with that whether it is just I was doing something wrong but that's just something that we picked up along the process. So it might be that if you start using context you have to use context for all your block layouts throughout the site. So yeah, so context as it is at the moment it is pretty much the same as it was in Drupal 7. Nothing new sort of huge things at the moment. There are a few conditions based on the conditions API. It's very similar to what you've got in blocks block visibility groups. There's also work in context as a condition. So I think it's still fairly early days for it but it's coming, it'll be similar to what it was and then with everything else that Drupal 8 has to offer. Block context is not that. No. All right, so we saw two examples for overviews. Let's take a look at even more. So we wanna compare panels with views for the upcoming sections. So it's again the same story. We have the section header but just that we implemented a bit differently. So panels and so I've heard a lot of people are familiar with the panels module but if you aren't just be aware it's quite a big thing and that's for a good reason. So what you can see here is that similarly as with any layouting tool I can organize stuff. So it works pretty similar as the block placement but it does it in this whole container of functionality the panel provides us with. So if you're looking into any of those features like access conditions so you can define together with page manager which is separate module you can define that this landing page this overview page is only accessible for users of that certain role. So that's the functionality it provides and then you can also define different variants. So you could say the page should have a different layout for this kind of user it should have a totally different variant based under a certain condition circumstances which is quite nice trick that we've been using a lot in Drupal 7. Then yeah we can select the layout so they are intercompatible. So layouts that are compatible with this place we will also be compatible with panels. So that's kind of the big suite that we're using and then there's something named context and every time we talk about context we have to fight with that name conflict. So the context here or the context API that also has been integrated in Drupal Core now this is more like a system that allows us to describe contextual arguments that are passed. For example the page knows about the current user being logged in and that user object will then be passed on to the panel or can. So we can also make for example relationships between context I could determine from the user I could determine a node reference for example and pass that node being referenced on to and that makes for a really powerful system later on for people that think in object oriented ways they can really turn this into the site onto the site building level and configure a context for example for a certain block. I want the block to be configured with the user so that I show just a user teaser for example. So this system is still in the works like not all the UIs are available but panels per se is pretty stable and can already be used. So then for one of our last sort of listing header we decided we would play with views for this and each view as per previous versions of Drupal can have a header and photo content but nowadays it's getting more than just the text area. You and the result summary that's also something that's always been there and then obviously in the text area being able to pull through any of the replacement patterns from the content itself on that page but in the view area now you can also embed another view which can be interesting depending on what you're trying to do and then also rendered entity is also something that's now available to put in a header which means that you can actually load a block. So in our case we could then create a block based off our custom block type with our image and intro text and on a specific view page then load through that actual block to be in that header area. So it's using things just in different, yeah, slightly different way, same content. Yeah, I think it's in like, I almost forgot that functionality exists in views because I'm so used to using panels and stuff but if you don't want to depend on any of these modules this comes for free with Drupal core. You can always add some stuff to the header or to the footer, build that kind of simple layout with Drupal core functionality. So we wanna talk about the final content section which are the clubs. So we've seen the routes, we've seen the cyclists and they together are in clubs. What we're gonna look at is penalizer and tweak templates. Yes. So for the clubs, they've sort of a pretty basic type of content. You've got your location and image or club logo if there is and then a story about the club itself and then through link through that one can then extend on other blocks that can get pulled through of who's a member of that club and various additional information, what routes they do, what bikes are part of that. We didn't build that to the great degree but we were learning of some of the basic content of the who, what, why of the club. So let's jump into our side again to take a look at it. So what's really exciting for me is just like the way it starts. So when I go to structure content types club, usually penalizer as in Drupal 7 it integrates into the managed display, oops, sorry. And immediately we can see a difference now because with Drupal 7 we would still see the managed display in terms of having all the fields and just a check box and it just happens a lot that people start to reorder fields and then they find out it doesn't work. And so a very nice small improvement for Drupal 8 is that as soon as you penalize the viewboat and this is how it gets activated. So in order to use penalizer, I just enable it and I can also enable a setting called allow custom overrides for each entity and that's kind of enabling penalizer. Also penalizer in Drupal 8 works based on the panel's IPE that's the in-place editor and we're gonna find out how it looks like just in a second. So I never used that back to site but usability experts have found out it's really important. So we are with the clubs and let's take a look at one of these clubs. So the Cape Town Nutriders. As we look at it, it's pretty basic, it doesn't have much information but we can see on the bottom is the in-place editing functionality that is now also stable and available for Drupal 8. So in-place editing kind of similar to what Reece's vision is, what we have talked about today outside in. So I wanna look at something and I wanna be able to change it. This is what we can do here with the in-place editing. So I'm at the content, I can change the layout. So I can choose from the same layouts that are available in the back cam, maybe make a brick setup and update it right away here. And boom, we are in the in-place editing and that basically allows us to drag and drop around like in a whizzy week manner the different fields. Save it. And now when I save it, I can choose between saving as default which would be the global template that Panelizer provides or it would be a custom override of that specific entity. So let's do a custom override. So we have, we see some reordering where the image is on the right and when we go back to another club, this other club is not affected. This other club is also overridden as I can see and then whichever club I have, like with the specific Panelizer override, I can revert it to the global layout. So it's pretty nice. Also, when you edit, so when you edit, you can rearrange and when you manage content, you can add additional stuff and all of these additional stuff can be like blocks, it can be, so you have to enable C tools, some C tools sub module for all the fields to be available and so forth. So yeah, it's a pretty extensible system that is really powerful. Definitely worth checking out if you want that complexity and all of that functionality available. So the last thing we wanna mention is the tweak templates and this is usually something that we hand over to other team members because we're just not good in writing markup but the way that for example, a site builder would work together with the themeer is that the site builder would already pre-create such a tweak template and the tweak template by default comes with only print content. So this is the statement that print something and it would only print content like everything that is in the content but this way, while building the fields in the backend, like configuring which fields are available, when I then I immediately add them to its own template and then the frontend person can rearrange those fields into the appropriate regions for example and have full control over the markup. And what we've been hearing from our frontend teams is that the tweak is a lot better to use than the PHP templates done before. So they're all having quite a fun time working with it. So getting some nice stuff out of it and there's a lot that one can do in rewriting with the tweak templates including stripping out the something we discovered the other day actually only you can strip out all the defaults, triple markup that comes with it so that you can just rewrite some really simple straightforward templates with very, very clean markup. There's also the override system for the template. So something that not so easily achievable with site building tools here can really easily do it. You can have a suggestion that says, okay, there's a generic template, a node template and then based on the suggestion like on the node type I can have a specific template for the article or more specific template for the article teaser and so forth. So there's a lot of full control available when you use or when you go into tweak templates which is a bit away from site building but it's still a good option. So yeah, some real good examples. We've got two that we wanted to show you. So this is local search. We've been working on this in the Cape Town office. We've just done a relaunch of this in a couple of weeks ago. This page here is a great example. So this site we've built generally using paragraphs. I think we've got about 20 different paragraph types on this site and of that, about five or six are only used as sub or nested paragraphs. For this page, this is basic information page. The top section here with the image, we make a company visible and then button. That is all just the basic part of the node and everything else is part of a paragraph. So here, this one here is this highlights row. This we've got each of these items is a sub paragraph which is then grouped into a bigger one. It's sort of into a row. So you can add multiple of these items within that paragraph row. And then something here that we've been doing quite a bit of is providing a checkbox to be able to say whether you want a gray or white background, whether you want the image floated left or right. And that's the left or right that option is then added as a class on the twig template just be able to theme that in a very simple way. So these two rows here are actually the same paragraph just with different options set. And then this down here is the same thing, just a basic left and right that's written out into the template. Yeah, and then goes down to footer and stuff. But yeah, this is an example, as I say, with about 20 different types of paragraphs and the whole site is both on that and that and general blocks. So like a similar example would be the AMAC fleet portal. So it's also mainly based on paragraphs where there's different options. So for each paragraph, I can choose if it should be a big one, if like can choose from different categories to be highlighted. I can even choose like additional layouts options. And here we chose to separate content from presentation. So the paragraphs themselves are about the presentation logic like about the layouts and they reference teasers that are pulled from another content type. So that way we can maintain that the information is in one content type and that the layout thing of it is in the paragraphs for example so that we still separate those concerns. Those are the URLs. So, time for a wrap up. Yeah. So multi-lingual for amazing lab Zurich being Switzerland having four official languages and for us coming from South Africa where we have 11 official languages, multi-lingual is quite an important aspect for us in all the sites that we build. So yeah. Yeah, definitely. So that's also the reason why I mentioned for example paragraphs was difficult to choose. So usually most of the translation will happen on the content level. So for example, a block can be translated like content, the pages can be translated. But keep in mind like if you use something like the views approach where with the views header that might live that in configuration which the translator has to find in a different translation interface. And for paragraphs or in general when we talk about translations and layouts the question usually is dear client do you want to have the same layout on all the languages or do you want to have a different layout per language? And if you use the standard translation system the paragraphs module doesn't allow you to create different layouts because what the paragraphs module does is it only allows you to translate each of the text fields that you filled out but you're not able to change the structure. So we started working on a patch and we maintain our own branch the so-called outer level translation. If you want to play around with that or if you're interested in that there's an issue on Drupal.org and there's also a branch on our GitHub. Yeah, so in conclusion some of the new features aren't 100% usable yet. As I mentioned with context there seems to be a few bugs. I think with everything at the moment there's sort of 90%, 95% usability on everything that's coming out but it sounds though next week I don't know our lives will change again so we'll see what happens. One of the things is to balance the flexibility and consistency across the site as we've mentioned before giving your clients a certain amount of access but then at the same time not restricting them too much so that they feel as though they've got something that they actually can't use. And then the other thing is that there are a lot of options and so it's a question of considering the goal of what you need to achieve and who will be using it. So where that will be the site builder or content manager or loading a lot of content or the real user in the client who will be loading stuff up. I think one thing that I really find important is that also you together with your team, your developers just talk about the different opportunities like do we prefer to have everything in a template or do we want to have everything on the site being configured? Like figuring out that right workflow I don't think there's like one suggestion to make that every team should find their own best practices. And yeah, Confucius say, life is really simple but we insist on making it complicated and don't do the same to your website. As I said, choose one or two sets of modules to use for your layouts and don't do what we've done on our demo site and throw everything at it because I think if we try to actually work out how to theme it I think our team would be completely upset with us. But yeah, so just keep it simple I'll just kind of go with one or two. And the demo site only broke like four or five times. So that's, yeah, thanks a lot for your attention and we're very happy to hear questions. Yes, so maybe we should repeat the question for the recording or could somebody bring a microphone? Oh, there's a microphone in the center. So for the following questions, please use the microphone. The question was if there's a lot of block types and a lot of information gathered into those blocks would it be hard for migration later on? Did it? I would say one of the things that does make it easier for migration is if you are using a lot of fields so that you know where everything is especially when it comes to images if you are trying to migrate something if it is all field-based then it's easier to do that rather than using the WYSIWYG. Hopefully now with Drupal 8 and the way it's going any kind of migration will be more straightforward. In Drupal 7 we had Node Convert and Node Clone and various cool modules to be able to change things around. One of the great things that's kind of in views is the fact that you can convert a views page into a views block. So it's not necessarily just duplicating the same thing as the same type but you can change that. So based on that kind of initial change in Drupal 8 we might find that at a later stage and maybe something we put forward is that maybe you can convert a node into a block or vice versa and maybe some of those entities can change. So I think as long as it's a structured approach and you know why using a node type or content type as opposed to a block then it should be good for scalability. Yeah, I would agree that if you have it structured it's easier to migrate usually because if you have something in a blob in a WYSIWYG and then you figure out you want to split it up then it's always a manual process. So it gives you more flexibility and less hassle but copying a WYSIWYG field will be simpler than copying all the paragraph fields that's the trade-off that you make I think. Thank you. Another question. Maybe go to the mic. Yeah, it's free. Hi, thanks. Is there an easy way to reuse the content of a paragraph in another node? We know that there are other models that try to achieve this. So one thing that's really important we have made that mistake is reusing paragraphs is something that is possible but you shouldn't do it because paragraphs follows the composition pattern so a paragraph will always be part of the parent node. So when you delete that parent node wherever you have reused the paragraph in other places in the system will just disappear. It's... It's better to use another approach for the content that can be reused because I figure like an editor that says, ah, but I already did this part. So that's kind of the trade-off you have to make. I would strongly suggest to use something like blocks or something that is its own entity but you can like with inline entity form for example you could have the paragraph just be the placeholder for creating a block for example to be able to reference it. I haven't used it in that way but that would be the kind of balancing that I would see but it's from a usability perspective maybe it's not perfect yet but in terms of being able to maintain the content and not losing content, don't reuse paragraphs. So paragraphs again. So as a developer I really like paragraphs because I have all the control on how the page is structured and what I can do with what is produced in terms of markup and everything. And I noticed also the editors kind of like it because it feels like the page is structured from top to bottom in sections and that works well with a lot of designs that we have nowadays. But still I wonder it's a huge abstraction. It's totally the opposite of the outside in thing so you really have to think about that as soon as you start adding those radio buttons for left and right and some little things that make the paragraphs change and what is not visible in the back end. So the first question is how is your experience with the clients in this area and what did you do to make this a little bit better if you ran into problems that the client just didn't understand that? Well for our example is the local search project. The clients, I don't think I actually had to train them much at all on how to use it and load up the content. When we went through the site we kind of explained that this was the way that we're going to build it. We give you these options of how to do things and he went and just populated the site within a couple of days and off he went. There have been a couple of times where one of his colleagues has been trying to load content and been trying to do something different to what the template for each paragraph provides. So we have had to fiddle a couple of paragraphs to make them a little bit more flexible to have a different type of functionality. But that again is where it's that flexibility that you give the client and the control that you keep. So there's a bit of a juggle between that. But yeah, it's so far, people haven't had any questions about it in terms of editing the content. Well, the one thing that we have had to do though is to, as we've been building and testing each type that we've got, is just take screenshots of each one and label it and say, you know, as a kind of a user guide as to, especially for that one with 20 different types. You know, the highlights row, this is what it does. This is what it should look like. This is the purpose for it. So for a site that does have so many types you do need to be able to help the client with a bit of a user manual on what's what. Two quick questions. First of all, I'm kind of worried about the performance aspect of panels. Is that something that we should keep in mind or is that negligible? I don't have data. I think it's, to the extent we, yeah, I think it's, well, whatever the word is. There is definitely some overhead, but I don't think it's too big. Okay, all right. The second question is about translation of the paragraphs. I believe the outer level translation does that have to do with that you want content in one language to have different paragraphs than on the other language? Okay, perfect. We've actually also been working on this issue. There's quite a big discussion in one of the issues on the paragraph page. Actually, one of my colleagues wrote a similar patch. I was just wondering if that's based on it or related to it. We posted a patch like two months ago. I'm not sure, but let's take a look. Yeah, I think we need to see if we can merge it somehow. Yeah, cool. Sounds good. All right, perfect, thanks. Thank you. We're out of time. Thanks, everyone. Bye-bye. Thanks a lot.