 First of all, welcome everyone here in Dublin. Hope you have a great time here. Probably some of you already had a great lunch as well. This is a session about Drupal 8 Hidden Power, entity references, a component-based site builder. I will show you how I figured out to less entity references to create the rich, flexible websites. OK, I will be more loud. So this session is about entity references, which are now hopefully built in Drupal 8 Core. And I will show you how I utilize the Swam to build rich multilingual, multi-scaled, multi-layout websites. OK, let's go. This is actually a beautiful slide, not for the session, but for my bosses and for search engines. So let's keep it. Shortly, my name is Anton. I'm a UI leader in Acronis. And I'm working on the user interface development. And right now, as I wrote here, I'm working on the new concept of content management systems based on atomic design principles. So let's talk about it. And first thing we need to talk about is entity. Entity is in core now. That's great. That's really great. The only thing you should know about entity is simple. Yeah, but it's really simple, believe me. Here, we can see a part of internal structure of entity in Drupal Core. But my session is not about Drupal Core and internal structure. I want to talk more about site building site. So from this point of view, entity, it's simple set of fields. Nothing more. So let's look closer. What is entity? Entity, for example, node entity is just a title and body field. Nothing more. So node is entity with two predefined fields. Each field can be treated as atom of content. And the whole entity is kind of molecule. So you can define different kinds of add-ons, fields. You can mix them together in bundles. And you can define new entity types by defining different set of fields on them. This is a really basic principle, but it gives us really more power. And it's also well-known as atomic design. You can read more about atomic design using this link. But I want to focus more on Drupal application of these principles and how we can use entity references to get the power of atomic design right in Drupal. OK, we have built-in entities in Drupal, such as node entity, user, term, comment block, menu item, and many others. All of them are really simple. And as you can see, we are pretty similar, because we are just set of fields. Nothing more. If you want, you can define custom entities. For example, using ECK model, this is an entity construction kit. It's pretty handy. So for example, if you need some specific entity, you just can create it via Drupal admin interface. You can set custom fields and so on. You also have opportunity to create media entities. What is media entity? It's, for example, YouTube video or any other resource as the web. Right in the core, we have an ability to translate entities. So any of media entity, custom entity, or built-in entities can be easily translated using core mechanism. So you can create multilingual website and content. Let's see an example. For example, we have a user profile with a name and picture. We have another user profile with its name and picture. And now we have a node with title and body. And we can define a custom field which can hold references to user profiles. And here we have entity reference. So the next part is about references. Entity reference is now in Drupal with eight core. And that's great as well. Let's look a more complex example of using entity references. So, for example, we have a node and we have a user profile. And we want to have a user profile to be displayed inside the node. It could be not just a user profile who created this node. It could be just mentioned inside the node, or this node could be a biography of a user. So what we want to do, we want to nest one entity inside another entity. And we can do it by referencing to this entity. So this is another example of using references. Here we not just reference one entity from another entity. We want to nest one entity inside another entity and to render it as a hierarchical structure. Let's look what we will have using such mechanism. We can inline edit of nested entities. So for example, here, once node is rendered, we can switch to the inline edit in mode and edit user profile right on the node page. But it's pretty cool and handy to manage. We can also have contextual links inside Drupal core, which allows us not to edit inline, but to go directly to the entity edit form. We can also have inline entity form embedded right in the node editing page. So we can go to the editing page of this node and we can embed user inline form right in the node form. All of these examples are pretty straightforward. It's just the beginning. But let's go through so we can see this big picture. Entity pickers allows us to select existing entities and reference them inside another entity. So for example, here, we can fire entity browser for users and select the required user without searching it, without copy pasting its ID. Interesting thing that we can reference not just to entity, but to specific revision of an entity. So if you don't, for example, you have a user profile, you updated it, but you don't want to publish it on the node page yet. So we can just specify specific revision of this user profile and to render it on the node page. And interesting thing that you can specify different revisions on different pages, for example. So you can post updated user profile on the home page, for example, but you can post an older version of user profile somewhere else. It's possible because it's just entity reference and it's revision. Another interesting thing is the view mode. So using this contrib module, you can specify view mode in which to render reference in entity. So for example, when you are referencing to user profile, you can render it, you can create a new view mode and you can render it as, for example, an avatar or you can just display a username. Or for example, you can specify contact user view mode and render user profile as a contact button. It's really simple and it gives us really real power. Another thing you can do with entity references is live preview. So when editing one entity, which reference in another entity, you can preview what you will get. And this is done by entity reference live preview module. Everything sounds cool and pretty flexible, but we have a problem. We want to create rich pages like that. This is pretty simple, but anyway, it consists of many entities, many pieces of content. And entity reference is not just enough because we couldn't always reference menu item from menu, breadcrumbs, and so on. So we need to have something to help us here. We want to have entity references. We want to have its flexibility, but we also want to be able to create pages of any structure for any layout without dealing with references always. And here is where powers comes up. I call it entity tree. Entity tree is a kind of representation of our page. Let's look to it. For example, this page can be represented as a tree. We can define a page body. Yeah, let's start from this block of content first, not from all the page. Let's call it page body. Page body can be presented as two things, list of nodes and sidebar. We have a list of nodes on the left, and we have sidebar on the right. List of nodes consist of node teasers. Each consists of title field, body field, and embedded user profile. We are referencing each user profile as well consists of name, picture, and other fields probably. Sidebar consists of blocks. Each block has title and content. In terms of entities, this is some kind of such structure. So we have two-column layout entity. Using the ECK, for example, we can define new type of entity, for example, two-column layout. And we can then reference other entities from it. For example, list of nodes can be referenced. List of nodes is another type of layout entity, stack layout. Is it clear? I'm not sure, because I'm always thinking about pages in this way. So should I give some more comments? What do you think? Is this structure clear? Yes? OK, let's go. But this structure describes only the page body. But how about the whole page to be an entity tree? It's already, it also can be done easily. So we can define a page entity. Page can be split in menu, in header, and body, and in footer. And this is how it can be represented. So the whole page is stack layout. Menu is a special menu entity, consistent of link entities. Header is a custom entity. This is a special thing, because we can not just create it each new time. But we can use dynamic variables to render breadcrumbs and page title dynamically on every page. Body is our previous entity tree structure, and footer is just a piece of text. So what we have here? Here we can see that we are using layout entities. This is another concept. And it's really important to make all this happen. So I suggest to treat layouts as a content as well by using layout entities. This is a difference between, for example, this concept and panels, or something like this. Because once we define new custom entities as layouts, we can, of course, we can define custom layouts by defining custom entities. We have a layout translation out of the box, since this is just entity. We can have layout revisioning out of the box, since layout is just an entity, and so on, and so on. Of course, we can reference layout from layout. And this gives us ultimate flexibility. So once layouts are entities, we can highly reuse layouts through our website. Because this is just reference, nothing more. We can create different pages. I will show you an example right now. So yes, it's highly reusable. It's replaceable, since it's just reference, nothing more. And it's customizable, since it's just custom entity. We can create new entities. We can define new modes. We can specify fields, and it's up to us. No code we need to write down. And we can have more power using layout entities. First thing is a flat nesting. Let's show an example. This is a pretty common company page where we would like to display a list of directors and list of managers. So this is a stack layout. We have a title. We have two sections, directors and managers. Each section displays user profiles. So directors' user profiles and managers' user profiles are all the same. It's just user profiles. And we can reference user profiles right from our page using entity reference. So this is how it could be done. We represent this page as an entity tree. So root entity is a management team. It consists of two child entities, directors and managers. Each refers to user profiles. So this is how it could be achieved using entity layout entities. Layout entities, just layout entities. So management team is a stack layout. This is a whole other page. Directors is a three-column layout entity. And managers is a five-column layout entity. So to not to define custom entity each new time we need the custom layout, we can just define a multi-column layout entity and then create custom view modes. For example, one view mode could be three-column. Another view mode could be five-column and so on. So yes. This is how we can represent this page using entities and layout entities. But the thing is we can just not do it like this. So stack layout, reference to three-column layout, reference to user profile. Because this is three levels of nesting. And it will be rendered by recursion. So instead of doing this, we can do like this. So we can define a special kind of field on the page. It's a single field. And it holds references to another entities. The only thing we need to do to make it work, we need to be able to define three structures inside a field. For Drupal 7, it exists in module. It calls just a tree. So we can install it and tick a checkbox for any field. And it will be able to hold the tree structure. So using this method, we can define any layouts. And we can hold the references to other entities, such as layout entities, or just regular entities. The thing is, since this is a single field with items, we can just drag and drop these items. So for example, we can drag manager user profile up in this structure. It will be rendered in director's section. And vice versa. So this is a pretty straightforward example. But I would like to show how we can manipulate references in this way. So this will be rendered as a single pass without recursion. And another thing, we can drag and drop items on the whole page using standard Drupal mechanism. Another interesting thing we can achieve using entity references is dynamic reference. So let's look on this example again. I mean, this page. So what we would like to do, we don't want to specify reference each new time and new director in our company will appear. We won't just, for example, have a special tag field on the user profile. And for example, we can tag user profiles with managers or with directors at tech. And then it will be more convenient just to get a list of user profiles by this tag. So how this could be done? This could be done by a view field module. We can create a view entity using ECK, for example. We can give it a title. And we can create a special kind of field, view field. View field can hold a reference to a view. And we can pass different arguments to this field per each entity. So for example, yeah, this view will reference to user profiles marked by special tag. We can just define this view in using admin interface. And we can reference to this view from view entities passing different arguments. So using this technique, we can represent our well-known tree as a view structure. So our page is still a stack layout entity. And it consists of two view entities. First view entity displays all user profiles tagged by hashtag directors. And the second by hashtag managers. The thing here is everything on this page are just entities and entity references. So we can apply anything which supports entity reference. We can specify a vision. We can translate any part of this page. We can edit inline any of these entities. We can specify different view modes. We can create custom entities, and so on, so on, so on. It's pure freedom for us. And we can build any layouts and any type of data. The thing is the whole page is done in the same way using entities and entity references. And using this technique of flat nesting, it's not actually it's not a quite. It's just more convenient way to do things since you can rearrange items on the page using the single entity. And performance is much better because it will be rendered in a single pass because it's just a single field with many items. And using dynamic reference, we can create a dynamic structures but as well of entities. So we will be able to edit inline to specify revisions and so on as well. So finally, I would make some notes. I suggest you to be minimalistic. What does it mean? It means that we can try to build our websites without using the field collections module because the entity and entity reference built in core is almost the same functionality because you just can define new entity type if you want using ECK. And then you can embed it inside any other entity using entity inline form, for example. So this module is just to duplicate. Another thing at field group, it's also useful module but using entities and entity references, we can leave without it as well. Panels, of course, panels, by defining custom view modes and layout entities, we can leave without panels because we can create layout of any structure. We can reference and reuse layouts from page to page. We can do anything we want because we have entities, custom entities, view modes, and we can define templates and all of this is done by Drupal Core. We don't need any modules for that. Display suit is also a good module but we can leave without it because we have, again, a view modes and custom templates for view modes. So combining this technique, we can emulate the display suit behavior as well. Paragraphs is great. I like it, really liked it. But the thing about paragraphs doesn't give us full flexibility. For example, we cannot manipulate an entity tree. Sometimes it's hard to nest entities and to create complex structures because each new time you have to create a nested paragraph. It's not that easy and the paragraphs module is a huge bunch of code. But it can be achieved also by custom entities, view modes, and templates built in Drupal Core. Second note, stay flexible. What does it mean? But not too much, yeah, but not too much. This technique of using entities and references seems to be really quick and easy and flexible as it can be. But we need to understand what we are doing and what solution we use for a particular task. So let's look on this slide. We can split our content into types. We can treat some content as flexible content. What does it mean? It does mean that we have custom fields. We want a dynamic order and we have flexible layout. So for example, remember this is about the page with the list of directors and managers. It is a custom layout. And in most cases, we don't have such page on the website. It's only a single page on the website and it has custom layout, custom fields, and probably want to rearrange it from time to time. So it's not convenient to create a structured content. It's better to go with a flexible layout. And here, entities and nested entities and references is a good thing to do. So because we can have pure entity customization, so we can customize only this page, we can nest entities inside it to not duplicate content. And we can translate specific vision and view mode for each entity, which is pretty cool. And we can have layout entities, which will help us to manage our layouts without additional modules and templates. We can just create an entity and treat it as a layout by view mode and template for view mode. But on the other side, we can have a structured content on our website. Structured content is a content with constant fields and constant order and predefined layout. For example, if we have a car selling website and we want to have a car details pages, all of these pages will be the same content of same structure in the same layout. So in this case, it's better to go with a standard way and Drupal will handle it pretty cool. We can have per bundle customization, so we can define new entity bundles. We can define custom field spirit. It will be just single level of entities, so we are not required to nest entities inside the car entity because car is simple object and we can represent it with just the fields. And we can have simple layout solution. For example, we can define a tick template or we can use a display suit as well. It works really nice with a structured content. But the classic problem of Drupal is to deal with flexible content. That's why such models appear like panels, penalizer, display suit, and so on. Because all of them are trying to solve this problem. Problem of flexible content, which is customizable, which should be customizable, it should be reusable. And now we can do it using entities and entity references right in core. Don't be afraid and experiment what does it mean. For example, we have flexible content, okay. We have structured content, okay. But why not to include flexible content inside structured content? In example, if you have a car details page, why not to define a car description field which could be a flexible content so it can hold nested entities and we can specify any layout in the car description. For example, you can make it to column layout or you can nest slide show inside. But the whole page will be structured and it'll be rendered using the standard mechanisms. I like to experiment. So I created this contribution module. It's really small. It just gives a power of flat nesting so you can rearrange items inside one entity. And I will continue to support it and to add more features I talked about today because initially this module was for Drupal 7 but I would like to continue support it for Drupal 8 as well. Finally, I would like to see on this slide and I would ask you to always remember that we are not designing just pages. We are designing a system of components so every page is not just a content, it's a structure of some data and the structure could be represented in a tree, for example, and tree can be easily managed and rendered using entities and references and nesting, of course. Okay, it's time to repeat briefly, really briefly. We are at Drupal.com Dublin. You are listening to my session. My bosses are happy. Entity is simple. We can nest entities by referencing one from another and these give us a power. But please be minimalistic, stay flexible. Because, of course, yes, you are minimalistic but we don't lose the flexibility because instead we have more flexibility when we are using references. But not too much because of structured content and standard mechanisms of managing and rendering it. Don't be afraid and experiment. And yeah, thank you. Yeah, just one moment. Finally, please love Drupal, discover entity references like me and do backup with my company. This is a sponsor, it's like, that's it. It's time for questions. Yes. I'm a demo. Demo? Actually, I have a demo but I'm not, I can try. Yeah, we have time, actually. I can show my real website. It's powered by Drupal 7 but I can show how all of these can be achieved. Okay, this is my real website. It's not up-to-date probably but it's using this methodology. So this is the whole of this page is an entity, just note. If we go to the edit mode, we can see a body field. A body field is with magic field of using flat nesting. So you can see here, yeah. Body field holds three entity references. So here we have layout entity, columns of columns type. Here we have two text block entities and you can specify a view mode here per each of entity. I can, yeah. You can edit, not in line because I'm, I like to rate it in a pop-up but you can use it, it looks like here. So you are on the same page but each entity will fire up in the pop-up and here you can, this is a column entity, it doesn't hold data. Yeah, this one. Yeah, this is just references dialogue and you can edit the whole entity inside pop-up and you can went back to the this management page. So here we can use inline entity form instead and not edit entities in a dialogue but for me it's just much more convenient way of editing in the pop-up. So this page stays fast without all this entity inline entity stuff. We also can specify CSS classes per entity. It's convenient way, for example here you can see modifier which will center the text inside the whole page. We can, we can drag, we can reorder entities on this page. For example, yeah, I also have a contextual links here so I can edit each entity separately without going to edit mode of the whole page. Yeah, the whole site is built on top of this technology and I can show you a more complex example. For example, yeah, this page consists of a lot of entities and layout entities. Here we have a tab view so we can switch between tabs. We can navigate by this scroll spy navigation and the whole this page is done by, I can, I should out-rise once again. Yeah, now we have edit button. So it's a more complex tree. You can see four sections here. This is a live sandbox, requirements, references, and bricks each consist another tree structure inside. For example, first section consists a root entity is a tabs and it holds two entities. Drupal 8, Drupal 7, which holds another entity inside. And so you can see how a tabs is rendered. So we can add another entity here and it will create another tab for it. We can try it, yeah. So I just created another child item inside tab entity layout and it's rendered. And we can nest any content inside it. We can rearrange this tree structure. And as you can see, I'm not just holding the whole tree inside this page. I splitting it in sub entities. So it's just more manageable because a long, long tree is not that handy to manage at least for now. I mean by flat, I mean not a simple list of items. I mean that the whole tree is stored inside one field as a flat structure. So in the page is starting to render, it's just loads one field from database. And in database, I defined a new column which holds a level inside the tree. But anyway, this is just one single field, a flat tree structure. That's why I called flat nesting. So yeah, it could be shown here. So this is just a standard entity reference field. We have six items inside. And it is stored in database as a flat structure. So this is just regular items. That's why performance is much better and you can rearrange the whole tree in the single interface. For example, with paragraphs, you can do things like that because it's always nested. You can drag one nested entity inside and now the nested entity. But here you can because it's a flat structure and you can manipulate it in a single place. And that's module that does that? This is just a tree module. It's for Drupal 7. It's just allows you to make this tree structure on any type of fields, especially on entity references. It uses entity behaviors to define a custom column in database. It's existing entity functionality in entity core. So it's just adds a special database column and enables this tree manipulation for entity reference multi-field. That's it. It's really, it's around 100 lines of code. But it's only Drupal 7. Now it's Drupal 7, but it's porting to Drupal 8. Yeah? I think it's a very interesting approach, but I'm thinking if a customer wants to create a new simple page, it seems a bit more complex than it is necessary. Do they then have to select an entity, a layout entity before they can create a new page, or how, what would the procedure flow? No, no, no, no, no. Just look, this is a good question. Probably you should talk more about simple cases. So this field is just entity reference field. By default, it just holds references. So if, for example, wants to create a text page, you can just create a text entity without any layout entities and it will be rendered as a text block inside page. So another thing, you can use inline entity form to embed entity form inside a page creation. So you can just, here, you will not see things like that. This is for more complex layouts. Here, you will see inline entity form out of the box and you will able to put text inside. So it's really flexible and you can configure it up to you. So you can do things like that like me because I like complex structures. But as well, you can cover basic cases by simply using inline entity form. So it will look like paragraphs model, almost. So, any other questions so far? I can show you a different, more examples of site I've built using this methodology. For example, interesting is how you can manage slide shows. This is another real production website. Interesting thing is on top of it, this is a slide show. So the whole of this stuff is just layout entity of type Carousel and it holds five entity references inside it and I just defined custom template. And from now, I can create any slide shows throughout the website. All of them can be customized and can hold different entities. How it looks like, let me do sign in. So yeah, now we can see contextual links right here in the slide show and we can edit any of this entity separately. Yeah, it's just an entity of type image. It consists of single field of type image and we can edit it separately but we can as well edit the whole page. Yeah, you can see here that this is entity of type slide show. It consists of one field, slides and it can hold references to other entities. And here we can also specify view mode, CSS classes and so on and we can of course rearrange slides easily using this entity reference thing. So it's almost up to you which type of content, which type of layout you want. It's kind of Lego constructor. So you can define new type of bricks, you can define new type of modes, you can specify any type of template and this is done, all of this is done by Rupal Core mostly. So the only thing you can do yourself is flat nesting but it's not required, you can leave without it. Just a little bit more convenient and faster. So it's the thing, I discovered it several years ago once I created, I could show you our website. We were working on rebuilding our website, just one note. You can see it's a really complex layout consisting of many, many, many columns, blocks and so on and this is all through the website. It also multilingual so every piece of content should be translated and I started thinking how we can achieve that and several years later I came up with this idea. Maybe I miss a point but why didn't I just use a lagging image field for your gallery and have multiple values and field format of type course or something? Because you can, you can. It's not something special, of course you can but it's a much more convenient way because you have a contextual menu for each entity. You can reuse images from slide show to slide show so for example you can define two slide shows and to post the same image to both. If you will use a field, you cannot just reuse a field item between two entities because it will be inside every entity. But that way I have to create a new node entity just for having one single image. No, no, no, just image entity. It's not node. But you've created like a node type of type image and that holds one field for one image. So we have like. Why not, why not two or? I don't see the point but maybe I miss something. The point is that node module is good for creating pages because it handles stuff like page URL creation date and it just extended entity. For these entities we just define a custom entity type image. It's really simple, it just holds one field and but you can reuse images throughout website. You can post the same image inside slide show. You can post the same image inside a page. It's super flexible. But use the same thing or same strategy for the text field you just created. Yeah, you can, okay, you can but. No, I just ask you, so you have a node type text which holds a simple text field. Yeah, I can show you actually, types I have. So, entity type, yeah. Entity type, so you're creating a lot of different entity types. You can see, you can see this page. This is, it lists. Okay, that's what I'm also looking for. These are the different types defined throughout the interface. You can create new types right here. Yeah, yeah, it's not content type. It's just entity type, it's lightweight. It's very lightweight. Okay, thank you. But the thing is, the whole site is the same. You can manipulate it any way. You can translate any part of it. You can even have different layouts per different languages because it's just entity. You can translate entity and you can translate layout. You can have different layouts. You can have different sections in different languages. It's super flexible. And all of these can be done via admin interface and with core modules, almost. That's a thing. Another quick question. So the layout is the first entity and for example, a three column layout and then you have nested or indented the three columns. So basically how does the layout know which columns come afterwards? Or how is the template structured? Because it's all a multiple field, right? You have a multiple field which holds multiple entities and how do you put the three columns inside the actual columns? It could be done, it could be done two options. You have two options here. We can define a view mode, three column and we can when in template access to this view mode and to render columns in a three column or two column and so on. Another option, you can just have dynamic number of columns. We can just display the whole items as a columns. Or a question about template, how are accessing the child entities? Yeah, if you have a normal multiple field, then it just renders one template for each field top down. Yes, yes, yes, yes. So you now have three column layout, then the three columns, then a five column layout, then the five columns. So it won't render everything. Yeah, yeah, yeah. A good question. Yeah, I got it, I got it, I got it. Yes, this is a good question and this is those 100 lines of code of customization in tree module which scans the list of items in the field and then create a nested structure from it by the single pass. Yes, this is done by third party module. This is about flat nesting. But if you don't use flat nesting, if you just nest entities inside entities using reference entity already inside another entity, you can access it directly. Yes, but about this layout, yes, it's customization, it's customization. Okay, if you have no questions anymore, thank you for coming, thank you for listening to me.