 Welcome, everyone. It looks like we are almost ready. First of all, welcome to VIA. This is amazing city and I wish you a good time here. Let's start for the session. Today we will talk about content modeling in Drupal and particularly in Drupal 8. First of all, let me to briefly present myself. My name is Anton and from October 9 I will work for Closer. Okay. And from October 9 I will work for Vandrus, a digital agency which is based in Basil and I will work as design system architect for them. Exactly what we will talk about today. Vandrus team located in Basil, as I said, and we do corporate platforms, service experiences mobile web, essential continuation of previous talks which were made in Drupal and Drupal double and designed for Drupal bus and earlier this summer. Today we will talk more about Drupal 8 application of these things and about practical implementation of these concepts. First of all, let's talk about what we have today in Drupal and around it. Let's briefly review what we have and what opportunities do we have right now. Of course, we have panels. Panels is really popular module with us for a number of years. But what about panels? First of all, panels is not a content entity. That means that it's tricky to revision, it's tricky to translate and it's tricky to workflow, et cetera, et cetera. All of this because of panel is a special thing, not just a content entity. And another important point here is nesting. It's really complicated to put panel inside panel and control the overall layout. It increases complexity of the whole thing. And it also breaks the relation between inner data and the host layout, like a page. You can say, ah, sorry, sorry about that. Something with the cable. Okay, let me to briefly repeat pros and cons of panels. First of all, panels is not a content entity, which means we don't have standard functionality like revisioning, translation, workflows, and so on. And panels are really poor with nesting, so putting panels inside panels becomes hard. It breaks the relation between content itself and layout. And it increases complexity, of course. Another module we have are paragraphs. It's really popular today and it's popularity increasing from day to day. First of all, about paragraphs. Conceptually, it uses a composite software pattern. That page and all of its data is a single whole. Its components couldn't be reused from page to page. And also nesting is a problem here because nesting paragraphs inside paragraphs are not that easy to manage. Another bad thing about paragraphs is the custom entity. That means you cannot mix paragraphs with another standard entities like nodes, user profiles, taxonomy terms, custom blocks, and so on. It's really hard to create a page from different type of data. And another thing about paragraphs is it's not really friendly to contribution models like in line entity forms, like dynamic entity references, and so on. The way you're using paragraphs usually is you're using the paragraphs completely or you switch to another thing. Let's look outside of Drupal. What we have not inside Drupal but around it is something called atomic design. Atomic design is a great concept and it will help to solve various problems around design, components, and complex content building. But it's just for design. It's not for implementation. It's not for content creation. It's not for site architecture. It doesn't help you to nest components, to provide data to these nested structures, to use templates for organisms if you know about atomic design terms. Also, it's hard to differentiate pages and organisms and molecules and organisms. So what I would try to say is that atomic design is good for designers. It's good for style guide creation, but it doesn't help you a lot when things come to a real implementation, real project with multiple pages with various layouts. Also, if you start working through atomic, you will fail with maintainability of multiple similar pages. It's also important when you're building a complex and huge website with various content with various layouts. Okay, let me summarize this small introduction. We have really powerful thing. We will be happy with them. Why? Let's look deeper what we are working with. We are using Drupal. Drupal is content management system, right? But what is content? What is content? Can anybody guess? Okay, I will help you. Actually, content is everything, right? Everything that end user sees on its screen is content. Layout is content. Styles are content. And the data structures behind what user sees are also content. Let's look at this pretty simple example. Let's say we have a simple page describing our team and representing our team members' profiles, like Mike, Lisa and Alex. What we have here, at least we have heading, which is a data type text, and we have user profile, which is a data type profile. So first of all, content is some data model behind it. We have images. We have objects to be shown on our pages and so on. But also, we have different styles for our data. So we can have different colors. We can have different font sizes and so on and so on. So content is empty screen. Okay. Content is data model, of course, and content is a style or style gate. But that's not enough. Let's look at this simple example again. We have heading and we have three column layout here. So where is something behind styles, behind data model? This is something we can call building blocks. Let's look deeper at each point of content. First of all is data model. Really good news about data models. I'm sorry about that. I didn't expect it. Okay. Good news again. Good news about Drupal that Drupal is all about data models, right? Everything we do in Drupal is modeling the data. Styling is a bit harder, building blocks, another way of complexity, but data models are really easy. Okay. About data model again. We have entity and we have fields and we can compose any data models we want using entities and fields. Like on this example, we can compose a product entity which will consist of several attributes like product ID, revision ID and so on. We can also have several bundles of products like a default product and t-shirt. Each can have its own set of fields like here price, image and size and so on. So Drupal gives us a really flexible way to describe our data models and we can do it directly in the admin interface without any changes to the code. So Drupal is really powerful at data models. Also we have entity reference which is now in Drupal core which allows us to model a complex nested or referenced content. Like here we can reference, for example, node entities to user entities and so on. We can create a complex data models describing multiple references and relations between various subjects. That's pretty easy now. It's much harder to show my slides on the screen. It also has advanced things in Drupal. We can create different entity types directly in admin interface using entity construction kit, for example. We can have revisions for our content which is provided by entity revisions which is in Drupal core. Also we have translation opportunities and moderation opportunities and so on and so on. Again, Drupal is really good about data modeling. So let's go to the different section about style guide. Style guide a bit more complex with Drupal because it requires you a lot of knowledge of female system or rendering system and so on. First of all, we need some global styling. Thank you, sir. First of all, we want... First of all, we want slides. Okay, let's go further. First of all, we want global one-out. The most interesting part is in the next section. So, yeah, probably we'll not see it. I will try to talk. First of all, we want global styling for our website, right? It's some kind of global styles affecting the whole components with the header styles, paragraph styles, link styles and so on. Everything we want in the global scope. Also, we want to have some components on the style layer. Like here, some description of a cart component. And actually, the most important thing about it is a markup because style can be in global scope, but markup is unique for each component. Layouts is also important thing. It's a bit different from components because it doesn't hold any data. It can be for buttons, for hero blocks, for anything actually. So it's kind of reusable mixings or utilities. It's not a component, it's not a layout, it's something different. It's small pieces of styles we can apply throughout our website. And it's also a part of our style guide. A good thing about style guide, we can now automate the process of maintenance of style guide, of creation style guide and so on. For example, we can use a fractal component library, which will help us to create new components, to create documentation, to create example pages. So it would be really easy to adopt components through our website and to create new components. But wait, we talk about styles, about tools, but where is Drupal? Where is Drupal in style guide? Drupal is everywhere, of course. Let's go one by one. Global styling is something like we include in our theme a CSS bundle. So from the style guide point of view, the output of it will be a single CSS file or a set of files, doesn't matter. But in the Drupal, we include the whole CSS file. We don't know about internal structure, how it's built, it doesn't matter. For Drupal, it's important to have these files somewhere in theme. Components are exposed to Drupal via tweak templates or via UI patterns model, which is relatively new on the Drupal landscape. Layouts are also tweak template files, which can be directly in Drupal or can be exposed to Drupal via layout API. Utilities are also can live in tweak templates. We can just put CSS classes there and so on. Or we can put our utility CSS classes in the admin interface if we have such functionality. For example, we can set up a special CSS class for each view element when creating a view. Okay, we have a data model, which allows us to have a huge structured database. We have a style guide, which contains all of our patterns, styles, and templates, and it's independent from Drupal itself. And we want to combine both of things. We want to get some data and to apply styles from our style guide to get a content instance. So each of our pages on the website is content instances, which has some data behind them and some styles applied to them. And we need some place where we can control this process. We need some place where we can get data and apply styles. Let's call this place a building block. It's something which can get the data and apply style to create some content instance in the end. Okay, here is the most interesting part of this talk. It's about building blocks. Building blocks is a key layer in all of this concept. Let's go step-by-step. First, how to render a simple data. It's pretty simple with Drupal. We can just create a tweak template and to render some data from database using tweak template, like we do for nodes, blocks, user profiles, and so on. That's pretty easy. But how to render the same data with the same data model a bit slightly differently? Like here, we have two user profiles, one we want in pink and another we want in blue, for example. We can use CSS modifiers. We can include them directly in the tweak templates or we can put them somewhere in admin interface. But how to render data quite differently? Like here, if we want the same user profile to be shown completely different in different parts of our website. Again, the data is the same. The data model is the same. The only difference is its layout and styles. We also have an opportunity here. We can use display modes. It's a built-in mechanism. We just need a way to use it on our pages. We also can render a list of dynamic lists of our objects using views, for example. And now let's talk about how to compose the complex data, not just to render what we have in database, because initially Drupal is all about just rendering what is in database. We get node, we render it. We get user profile, we render it. We get taxonomy term, we render it. Nothing special about it. When things come more complex, when we need to combine various data on our pages, it's getting more hard. So with simple example where we can combine a heading, an image, and some text, let's look closer to it. One simple solution is to use multi-value entity reference field for this. We can reference a various data described by data models in our database. And we can re-order them. We can reuse components. We can reuse our data through our website. So we can combine our various data using this multi-value entity reference field, which is also in Drupal Core now. By the way, this is exactly what paragraphs module does. Paragraphs module is just multi-value entity reference field, and each paragraph is a separate entity. We can create separate bundles for paragraphs, paragraph types. We can mix them together to combine a complex data. But let's look deeper at this simple example. What is it? It's a simple single column layout, right? We have heading, we have image, we have a paragraph of text, and all of this is just a single column layout. Pretty simple thing. But what if we want a more complex layout? What if we want the two columns here? It's getting more hard. Paragraphs way is to create a special paragraph type, for example, two column paragraph, which will hold two columns inside it, and when we can place this new paragraph type inside our page with a heading. So, in the end, we will have at least four paragraph types, and we have two layers of nesting here. Okay, but what if we want two columns inside second column? It's as well, again, this is a pretty simple example of a really simple layout, but things getting more hard. Again, we need paragraph type of two columns here. We can create, we should create another paragraph and place it in place in second column. And you can see how this structure is complex and the complexity is rising each time we make any change to the layout. It's not that flexible, actually. It requires you additional instances of paragraphs and several layers, levels of nesting. Pros of this solution is each paragraph is self-contained. It can be edited separately. It can be viewed and accessed separately. But on the other side, each time you use two column layout like we just saw in the example, a new entity is created and the complexity and the amount of data stored in database is rising. Another con of paragraphs is that data should be loaded recursively because we nest one paragraph inside another paragraph inside another paragraph. We couldn't just load the data at once. We should load one paragraph when all child paragraphs and so on. It's also a complexity for us. But what's more important, it's pretty hard to manage the raw layout. Let's look at this again. We have several layers of nesting and to change anything in this structure, we have to go inside each paragraph to change something there and then go out. It's really hard to manage complex layout built on top of paragraphs. And another con is hard to associate data to host pages because paragraphs are nested one inside another. We can lose a relation between the host page and the inner paragraphs. Why so many cons of so handy and popular module? Because the layout should be a responsibility of the host page. Not a responsibility of each separate paragraph, but a responsibility of the host page. Because we have data, we have some images and paragraphs, and we want it to be layouted in some particular layout. I don't want to create special entities and to nest one inside another. I just want a particular layout and to place content inside it. Let's find an alternative way of doing this. I created a small module which named bricks and I will show what we can be achieved. Let's think of layout as a single thing, not separate entities one inside another, but is a single thing. Okay, we have a layout and we have a data in the database, and now we can put this data in this layout. It's a pretty simple thing, and it's something used throughout the Drupal, but let's use this on the field basis. When we create a new page, we can change the layout of each page, of each field, actually. But what's more important, that would be really great to allow to nest layouts one inside another, not to create separate entities, separate instances of data, but just to nest layouts to combine them, like on this picture. We can only have two layouts, single column layout and two column layout, and we can create almost anything from just two layouts. We just need a nesting for that. So the process of this way is quite huge. Layouts are totally independent from data, which means we can reuse the layouts through our website. Layouts can be stored as content, and that gives you a way to translate them, to revision them, and to use everything we can use for content. Data in this way can be stored as a flat structure, so it can be loaded without any recursion, because the whole layout is a single thing, not the nested entities. And managing the raw layout becomes deadly simple, because, again, this is a single whole. The data is separated from layout, but layout is a single structure. And the data is directly associated to the page because there is only one thing between data and page, which is the layout, which is single. There are some cons as well. Page should be viewed and edited as a single whole, because the knowledge of each layout is only in the single page, in its layout. Best practice here is to split the page in smaller components, so you will have more control for the long pages. Another cons that this is not popular yet, because it's relatively new thanks to entity reference and inline entity forms, but you can change it. You can try it and to adopt it into your projects. Okay, let's stop talking about the concept. Let's look at the demo. Okay, we can do it. So, what we will do, we will open a Simply Test Me, which is a playground for Drupal modules, and we will launch a sandbox for Bricks module. Bricks module itself is really small pieces of code. It's around 20 kilobytes of code. It's just some integrations between entity reference, between Drupal core and between inline entity forms, and so on. The key thing about it, it allows you to manipulate with nesting layouts to create the layout you want on the fly without templating and so on. I will show you soon. Actually, you can play with demo during I will show it. You can just open the page of Bricks module on the Drupal.org, and you can click the link in the vslive demo section. It will be installed in a few minutes, and you can play on your own. So, once we click on this link, we click install, and when we go through the standard installation process, without any changes, it will install standard Drupal and several additional modules. Okay, Drupal installed. Let's configure it and start playing around. Okay, we have Drupal installed. First of all, we need to enable the module. I have a special demonstration model for that. It's also a part of package. Let's look closer what we have inside. Inside, we have a bootstrap kit. Bootstrap kit is just a set of layouts for bootstrap framework. So, yeah, in this demo, we will use a standard Drupal installation. We will use a bootstrap framework as our style guide. It could be your own, but for this example, we will use a bootstrap, since it's pretty simple to use. We will use Bricks module, which will allow us to nest layouts. We will use inline entity form to be able to edit the data inline on the Node Edit page. We will use entity construction kit to be able to create different type of data on the flight in the admin interface. And we will use a layout discovery to be able to consume layouts registered in Drupal system. Okay, let's continue. And we also need some theme, some bootstrap-compatible theme, which will provide us a CSS. Let's check that everything. Okay, we are ready to go. Let's go to the content section on the website and create some content. There is some special type of page Brickie, which is preconfigured to use these nested layout structures. Okay, let's give it a name. Let's create a simple content. Let's add some text. So you can see that this interface is pretty the same to paragraphs. The only difference is built on top of standard entity reference and inline entity form. Okay, we now created a simple page with a single component of type text in it, inside it. Let's add some more content. For example, image. Okay, we now have a text block inside page and we have an image above it, under it. So what we would like to do now, as in my example during the slides, let's put it in the different layout. Let's put it in two-column layout. We can select a special layout entity type, which will allow us to select, I will zoom it in. Okay, we have a text component, we have an image component, and we have a layout component. And here we can select any layouts registered in Drupal. Let's use equal columns, which is provided by bootstrap kit module. So what we are going to do now, we need something to put our text and image inside this layout. We can just drag and drop, and we can put components one inside another, exactly like we do for menus and for taxonomy terms. It's the same mechanism. So what we should have now, is a layout of type equal columns, and we have two components inside it. Let's look what we have. Yeah, we have two columns on our page. It's pretty easy. So let's try to create something we discussed in the previous talk. Let's put two columns inside second column, like we see in the example. What we need here, we need some kind of wrapper, some kind of container for second column, which will hold the inner content inside it. We also need a layout thing again. I can zoom it. We also select equal columns here, and let's add two images inside. One, and another one. Okay, what we have now? We have overall equal columns layout, which hold image as the first column, and wrapper as the next column, which will hold a text, and two columns under it. You can see how it's easy to manipulate the data. We only have an image and text blocks defined. We have several layouts registered in Drupal, which is pretty simple now. And we can compose the layout of any structure directly in the admin UI. And the powerful thing about it, it's not limited in any way. You can use it on your own. You can define your own process around it. You can define your own components. You can nest components, one inside another. You can nest layout, one inside another. Let's try to use CSS classes here. For example, let's give this text a big size. Lead CSS class. You can see that we can control, first of all, we can control the whole layout of this page by nesting of various layouts, one inside another. We can control styling of this page by providing CSS modifiers directly here. And we can also select a view mode right here for each referenced piece of content, which gives us an opportunity to create really flexible content with ease. And of course, we can change everything here. For example, we can put these two columns as a third column of the whole page. So it's really simple to manipulate the data now. Why? Because we separated the data and the layout, and we don't try to put layout inside entities and put entities inside entities. Forget about it. We can control the whole layout in the single place. We can store it in the single place. And it's completely separated from the data. Data is completely reused through our website. And layout as well is also reused through our website. So things can be really easy. Okay, let's finally make some final notes about this talk. First note is about entity reference. As you just see, entity reference can be used for both data model, like when we can reference from node to the user, which is created with node. Or we can use it for nesting like we just did now. So we can put one data inside another data, or we can put layout inside layout. And this is done also by entity reference model. So it's multi-purpose. Second note is about atomicity. So working with things like I just shown is super flexible. It gives you a lot of freedom. But if you will start working to atomic, if you will start to build each page from the ground, you will find out that maintaining of the complex structures on different pages, which are pretty similar, requires you additional time. So keep the balance. Don't be too atomic. Define your own blocks for your own design and for your own website. So you will not repeat the same actions from page to page. So atomicity gives you freedom, but on the other hand, it requires you more time to control it. Also note about paragraphs. In the demonstration I just shown where was no paragraphs. It was a simple ECK and Entity Construction Kit and inline entity form. So my question is why should we use paragraphs if we already have things like Entity Construction Kit and inline entity forms, which allows us to do the same things. And actually we can do even more because we can reuse entities through our website. Paragraphs couldn't be reused from page to page. So a note about paragraphs is next time you will try to use them, but think about do you really need them because ECK and inline entity form is the same functionality and more flexibility actually. Note about layouts. Layout can be treated as an entity. The difference between entity and layout is that layout doesn't hold any data. Layout is for representation of data. So it doesn't matter where you put two-column layout, it's always the same. It's just two columns. So layout can be treated as an entity type or entity bundle and there is a small difference between all other components and layouts because layouts are data less. So let's summarize and wrap all it up. First of all, separate data styles and building blocks. Data is what you store in database. It's what represents your real data objects. Styles is what in your style guide is what your brand is about and it's look and feel. And building blocks is the most important thing because it allows you to combine your data and your styles to build your unique content instances. Define your own blocks. Define, set up your own workflow process for building blocks and you will success. Another note and takeaway is that paragraphs doesn't work well for all cases. For example, for nested layouts. So next time you will think about them, try to set up Drupal without them. And of course you can try bricks for complex cases. It will give you a control for the whole layout. It will allow you to separate data and layout and you can control precisely which piece of content how it will look like. You can give CSS modifiers, you can select the view modes and you can compose your data in the way you want. Thanks for attention. Finally, if you want to contribute, you can drop me an e-mail with a subject let's content model. You can just share your thoughts or ideas regarding the session or regarding this concept. It doesn't matter. I'm always happy to receive some feedback. You can also describe your own complex case. For example, if you are building a complex website and you are thinking about its architecture, you can drop me an e-mail and we can discuss how it's better to create a content strategy for your new project. Or you can just list your Drupal skills and we will think together how you can help to adopt this new concept to Drupal community. Also, it would be great if you spend several minutes and evaluate this session so next time I will be more prepared and bring with myself several cables. And also, please take a survey for Drupal Conviano to help organisers to organise everything on the perfect level. Thank you again. Thank you to visit in Vienna and I wish you a really great Drupal Con here and now I'm ready for your questions if you have ones. Sure. Sorry, you can go to the microphone so everyone in the room will hear. Do you feel going forward that BRICS will offer things that the layout example that Rhys gave this morning, will BRICS offer anything that that won't be able to provide? Can you repeat this? So the layout example that Rhys gave this morning, do you feel going forward that BRICS will be able to offer anything that that won't provide? Yes, I think it can... Looking forward, we can use BRICS in various cases. It can be a replacement for layout builder, for example. So, short answer is yes. Long answer, again, it's super flexible and it's up to you how to use it. You can use it for layout manipulation. You can use it for component manipulation. You can even create layouts on the fly and register them via layout API to provide them to other modules. So, the use cases, a bunch of use cases. I've actually got two questions, if that's okay. One was you didn't show but I teased the displays of content. Would that be stuff that you would normally do via other fields? Sure, sorry. So, if you want to do a teaser display of your content, are you using fields that aren't what's part of BRICS or can you use the BRICS fields for the teaser display? Okay, BRICS is a just field type. Actually, internally, this is an entity reference. Behind it is extended entity reference. So, you can use BRICS everywhere. You can use the fields. You can use for teaser, for body. You can have multiple fields of type BRICS on the page. That doesn't matter. It's just a field which can hold the data of any structure inside it. So, you might have a field for your teaser that you can build up the BRICS. Sure, you can have a teaser, you can have a body and you can control as usual. But the thing is inside these fields can be any data of any structure of any layout. Okay, thank you. And the other one was just about the styles text field. Would there be, like, I thought a value add there might be to have a dropdown of predefined styles for any of these? I have actually issue in the queue about it. Yeah, it would be more useful. The next step is to work on user experience. Now, I was focusing on the data storage and the whole concept and architecture. Okay, thank you. But yeah, you're right. My question is about, you've said you can reuse the layouts and I didn't quite get where and how you would do that. Yeah, yeah. The short answer is, like, when you're using paragraphs, for example, when you create a paragraph type two column layout and when you put some data inside this paragraph of two column layout, you couldn't reuse this paragraph on other pages because it holds its data in this layout. So layout and data are not separated with paragraphs. But with Bricks, it is because layout is in one place and the data reference it to layout. So you can reuse layouts because it doesn't hold data anymore. Yeah, I just didn't get where would you do where in the user interface or where is the... Yeah, yeah, yeah. I can show you briefly, actually. Okay. So in this demo, here you can just select a layout from dropdown, equal columns, and here you also can select the same equal columns. So you can reuse, you can nest, combine from page to page, from place to place. Doesn't matter. With paragraphs, you have to create a paragraph each new time you want to use it. So it's not reuse it, actually. It's created also. So I was thinking of the overall layout which is what this story now is representing. It has two columns and then a nested thing. Yeah, yeah, yeah. But you cannot apply that thing then again to another story. So yeah, yeah, yeah. This is my note about atomicity. Yeah. This is pink is for creating unique layouts. So when your data is flexible and different from page to page. But it can be applied. It's the next step. So with Bricks, you can create a layout and to register it in Layout API. I'm working on it right now. So later it will be possible to reuse this structure on various pages. It's the next step. Is it supporting translations and search? Yeah, sure. As I said, this is a simple and standard entity reference field internally. So everything works with entity reference. It's working with Bricks too. So the whole structure is a single multi-value field. And as any usual multi-value field, it can be translated, revision it, everything. So yes, it's working. First, thank you for addressing a real problem with a real solution. My question is, can you limit the flexibility to like limit how far you can nest and what you can nest? Yeah, yeah, yeah. This is a good question. And every time I talk about it, this question comes up. So the answer, no limitations. No limitations because this is a flat structure. It's stored internally as a single multi-value field. No matter how deep you go, this is a single multi-value field. So you can deep and deep. It can be 10 or 20 levels, doesn't matter. The only limitation is UI because it just couldn't hold all of these levels and to represent this structure. But internally, no limitations. And no performance issues because there is no recursion. It's loaded once because this is a single multi-value field. So yeah, I think you are going to ask. What about mobile content? So when I want to have a special layout for mobile? It's a next step. We should work because this is for internal representation of the layout and to reference the data, which can be used. But how precisely to control the layout? It's up to us. And it's the next step. When I talk about user experience, I meant this as well. How about for integration of the layout with feuds? So something like panelizer. So let's say I have a product. And the product has feuds that are not just like text, but meaningful data, like price, for instance. Is there any plan to integrate with that? Or is that not the right use case? Actually, it's not the right use case for that because this thing is to manipulate the data inside the field. So when you are going to combine several fields together, panelizer is what about panelizer is? So internally, it's the same mechanism, layout API, panelizer using layout API now, and bricks also using layout API. When you select in the layouts here, it's provided by layout API. So internally, it's the same mechanism, but use case is different. Panelizer for layout in fields, and this thing for composing the data of any structure inside field. This is the replacement for visa week, actually. Okay, I think we are finished. Thank you for attention again. Have a great DrupalCon. I'm happy to answer any questions afterwards. You can find me and ask about anything. Thank you very much.