 Okay, let's start. Welcome to Drupal Architectures and flexible content. Thanks for coming. Just a short bit about myself. My name is Ernani. I'm a technical team lead for Acvia in Europe. I am Portuguese and I've been involved with Drupal for a long, long time. So I ended up doing a lot of things with Drupal. Most of what I do these days is about Drupal Architecture and that's what I want to talk to you about today. You have my personal website and my Twitter feeds if you want to follow me. So let's start with the basics. So what's a typical website? And why do we use typical websites or why do we use CMS to manage those typical websites? So you have two types of content. You have structured content. You can think about news items or job posts or something that has a structured, a fixed structure and a fixed layout. So content editors typically do not change them. You create content and it just appears as it is. And then you have flexible content. So things like home pages or landing pages, collection pages, rich pages. Those are the ones that are very complex to build and those are the ones that can change per item. So you can have a content structure and you can have layout that changes according to those items. And today I want to talk to you mostly about the second one. That's where we find some problems. So today's session in a resume, we can find it as architectures and patterns when we need to build flexible content that we need to worry about regarding content architecture, regarding layout architecture, regarding workflow. And most important, how do you create a unified experience to manage all these? And when you think about the unified experience that you want to create, you want to create this experience not only for who is visiting your site, but most important to who is going to manage your site. And the person that is going to manage your site is supposed to be the content editors. So content editors can vary in terms of demandings, can vary in terms of requirements, but they are typically a major stakeholder in websites where content is in skink. So imagine media, imagine entertainment, imagine corporate websites. Those websites have content that change pretty often. For those websites, content editors want to change all the details, all the content that appears on the website. So it's not just required that the content can appear in the way that you designed it, but the things are going to change over time. So they want those flexible pages to be adapted. They want to be able to create rich pages. And they want to do all that without involving us, without involving techies, without involving site builders. Another important aspect that you need to think about the content editor is that typically someone that is technologically savvy in his own way. So he knows that he can do stuff. He knows that he has done previously stuff in other ways, in other systems. He comes from a technological background that might be different from Drupal. And you want to do exactly the same thing with Drupal. So that's another challenge. So if you find a demanding content editor, what are the typical demands that you can find and you might struggle with? So one is changing the website look and feel. So I want to have several available options and I want to change it as I want. The other one is I want my content to be reusable anywhere. And that's a major flexibility of using something like a CMS that can create my content and then it can appear anywhere where I want as long as I include it. More important, whenever I'm doing some changes, as I'm doing changes on very important pages on very important sites, I want to be able to review. I want to be able to preview. I want to be able to approve. I might even have more people involved in the creation of this content than just a content editor. It might be someone that is just creating content and someone that is approving that content. So they are different people and sometimes they don't have the background of how that content got created. Sometimes you want to approve batches of content and you need to make sure that you preview it exactly as it's going to appear. If not, the experience is going to be a bit broken. Some other times they want to schedule content. So they want to say I want to prepare a special edition on my newspaper for next Sunday. So I can prepare everything and I can just schedule it and I can approve it and when it's ready to be published, it's going to be published at that time. Another major need that content editors have on these types of websites is to readapt the site if there is a special event. So imagine if there is a major election or if there is a major sports event. At that time, you need to be able to add more content to the site and re-propose the way that your homepage was done to bring more traffic to certain sections of your site that you want. And finally, the CMS should be easy to understand. It needs to be very easy to create content, it needs to be very easy to reuse content and it needs to be very easy to understand where is that content going to be and how do you change the layout of that content? So if you think about all these typical demands and if you look to Drupal, you can find a couple of problems. So one of the problems that you have is that's typically there's a disconnection between content and layout. You create a content type, then you create your nodes and then the way that those nodes get rendered, it's a bit different. You also have a disconnection between site building and content addition. So the way that sometimes you create at a certain section, if it's not very flexible, then it's very hard to change afterwards. So the way that you build a site and the way that you edit a site is not the same. Then you have another problem, which is this old mentor that we used to have in Drupal where you create first the content and then automagically it appears somewhere else. So you first create the content and it appears either using views or either using any other type of display solution that content would appear in some sections of the site that have been configured to recognize that section. The other major issue, and that's especially connected when you think about all these demands about being able to review, being able to approve, Drupal lacks revisioning in many pieces of the puzzle. So you cannot do any revisionings on things like blogs or menus or taxonomies. So if you are doing changes there, it's quite hard to do the change as the whole and making sure that it's easy to preview and you can see what's going on afterwards. So these are the typical problems that we are going to look to there and to solve those problems, as good engineers you should be able to break them. So if you look to the different problems, I think we can look to four different types of problems that we have here. First one is content architecture. Second one is layout architecture. Third one is how do you combine the two and you can provide some workflow and some preview on them. And the fourth one, and I think it's as important as the other three that are techies, the fourth one is non-tech. So what you need to worry about when creating this whole experience so then in reality, when you deploy and when your site goes live and after two months, your content editors are happy and they don't say, well, this new system doesn't really work for us. We really prefer what we had before. So let's look to the first one. Let's look to content architecture and let's look with a very easy problem which is how do I create a rich page? So what do I mean with a rich page? So basically a page that has a structure that is a bit flexible. So we mentioned that I'm creating a page and I'm creating a recipe page. So in the recipe page I can have images, I can have ingredients, I can have more images, I can have videos or tutorials, I can have all the instructions all to prepare this recipe. So when you think, and depending on the recipes, I can have more images or I can have more videos or I can have more ingredients and maybe they don't even want the same layout for everything. So if I am creating a recipe for a dessert, it's different from creating a recipe for a large dinner for instance. So the page is really flexible and ideally what they want to do is just to be able to have a couple of things that they can add to the page when I want and it's just a bit different than what you are usually expecting from just creating a note and having the note appearing somewhere. So what options do you have if you want to create these types of rich page? So there's first option, you create a free form HTML. Somehow you configure that HTML with a WYSIWYG. Second option, you structure your content and you say, well it's a recipe, so a recipe is gonna have ingredients, it's gonna have videos, it's gonna have images, it's gonna have instructions. Third option is saying I structure it but I'm more interesting on what I'm referencing than really the content itself. So I'm saying I need to first structure the ingredients then I need to structure what is an image, what is a video, and then what I basically do is I reference from there. Or you have the fourth option which is I don't reference at all from a content structure point of view. What I'm just creating is a rich page, is a white page and what I want to have is widgets and I just drag and drop those widgets on my page and I don't really need to worry about if they are somehow connected or not from a content structure. So let's look to all of them. So first one, free form HTML. Typically this is never a good solution. Well there's some options where you can have WYSIWYGs and then you can embed things from the WYSIWYG and then you can configure this WYSIWYG. In theory this can give you a lot of flexibility. What happens in practice is that it ends up being very hard to manage that content in the WYSIWYG. WYSIWYGs are not perfect and they do have some usability problems as well. It's very easy for the content editor to break the whole page just by using the WYSIWYG. So it's hard. It's also hard to maintain the consistency. So by one side it's nice that you give the whole flexibility so it's just a wide page. You can put there what you want but it's hard to maintain the consistency. It's hard in the future if you wanna say I want all my ingredients to be linked to a supermarket page. That's hard to be done because everything, there is no structure there. It's hard to reuse content because there's just inputting content inside your major areas of text or major areas of fields. And yeah, it's very hard to avoid errors. It's typically hard to reuse. You even replace holders even if embedding entities. It's not that easy to make sure that the structure is okay. The preview is okay. The editing works okay. It has the advantage that everything ends up being in the same block, in the same bucket. So it's a bit easier to manage the content as a whole but it's very hard to do changes there. Second option, you create a content type and that content type includes pretty much all the things that you need that content time to have. So all the content details are stored in the content item itself or in entities or in atoms of content that are referenced from that content but only exists on the context of that content. So typically if you want to go with this approach you have the typical implementation you'd have is either you create a custom field and you can use field API to create the custom fields and have a field that is just a multi-field. You'd have ingredients and images or you can have something that is in ingredients and the ingredients has an ingredient plus the quantity or you do other models that allow you to do exactly the same but in a much better way in the way that you are creating that content type or that content structure. And that's when you use things like field collections when when you use paragraphs. Which is basically they are compound fields. They are fields that do have several values or several types of sub-fueled let's say and they are very easy to create. You can create them from the UI and you can export them from the UI and they typically have better connections as well with other models that control their layout and their workflow as well. So one of the options that you'd have in this case would be to use a model called paragraphs for instance that was built for this use case. So in this case you can add paragraphs to your content and you say I have different types of paragraphs that I can add. I can add either text, I can add images, I can add videos, I can add a collection of ingredients. All of those paragraph types they are entity types so they can have as many fields as you want and they can have behavior as you want. At the same time they can have also the layout that you want and you just need to think about it as a paragraph as an atom of content that I'm going to add to my pages and then I can reorder and then I can change the way that they behave and they all behave in the database with a structure so it's quite easy to integrate them with views. It's quite easy to use it as content that is structured. At the same time you can maintain the same user experience. You can maintain the same user experience for all the types of content that you have as a paragraph. I don't know if everyone use paragraphs here. Any fans? Good. It's a model that is not very old but got a lot of traction in the last years. So third option and this one is not very different from what we were talking about. The main difference here is that you instead of saying that the entity or the atom of content that I'm creating instead of living on its own and here it lives on its own while when you use things like field collections and paragraphs you are basically saying that content atom works or exists in the context of the whole entity that you are creating. So most like you have a host entity and that host entity has several sub entities. Here you are creating entities that are not connected directly with the main entity but some however reference there. So for doing things like these, you typically use things like invited entity form. There's an entity reference between the two types of contents that you are talking about and then you have some blue models. So you might want to have some back reference as well from the sub item or sub from the atom that you are creating. You want it to reference also the main entity and you have models like quantity and content extra reference which basically lose back to what you have. So a good example of these is for instance if you are managing a football match and you want to have players and those players have the time that they enter and the time that they exit the game then you can have just references and all of the addition seems to be happening in the context of the match itself but in reality all of these are sub entities which allow it to afterwards to do some queries on the database to see how many matches is the player play and things like that. So it's a bit more flexible if you want to have more definitions on the sub items, more definition on the sub items that you are creating as part of the main content. So these are basically the four options that you have to structure the content. I'm ignoring here the ability to just add widgets or just to add content that is not referenced because that's not really related with content architecture. So let's look to our second problem. So layout architecture. How do I create a rich-based layout in Drupal? Again the same problem. You have created the content, you have created the content type, you know it's going to be displayed. Now you need to think how I'm going to style it, how I'm going to display it and how I'm going to allow people to change it afterwards. So a couple of options that you might have. First one is just use the core template system so you prepare your templates. You have very good control on what you're going to show in your markup and somehow you pick those templates and somehow you assign the content to those templates. Second one, you use something like this play suite. So you create the same concept, you prepare different templates but then you can just drag and drop the fields where you want and you have control over the different view modes on those templates that you just created. Third option, it's getting more and more popular as well is to use panels and to use something like panelizer to just provide some default templates that you have on your content but at the same time allow it to override when you want. So let's look to the three of them again. Template system, like this is supported by Drupal core. You do have different templates and then somehow you pick the right template for your content. So you can have custom field or you can have a custom attribute on your content and depending on that custom field or custom attribute then you pick the right template that you want to use. It's a bit limited like it's very hard to preview those when you are selecting them, you'll need to create some more custom logic here. And here just when you just use what is default by Drupal core and just use display modes and templates. Second one, this play suite. So basically the idea with this play suite is that it allows you to easily customize different view modes. So you can create for different entities, you can create view modes and the view modes can be afterwards picked in what you want to show depending on you can prepare the whole templating system, I can say a recipe. When I include in the slide show in the homepage looks like this. When I'm looking to it in a full page, it looks like that. Whenever I'm creating a grid of recipes, it looks in a different way. So I can prepare different visualizations for my same amount of content. And then afterwards it's quite easy to maintain consistency across the different locations where this content appears. All of these can be done by South builders. So it's a bit easier to create new templates or create new view modes and just allow them to be selected afterwards by content editors. So I don't know if anyone here use this play suite. Very popular as well. This is an example of using this play suite. So in this case I'm creating a custom layout for a recipe and I can say I want to pick the three columns layout and that is already customized. So when I'm creating the content, the editor can say I want to use three columns or I can use two columns. I want to use a big banner with some content behind. So it's also easy to create this type of content but you are more restricting in terms of flexibility that you are giving to your editors. It's hard for them to change this. You are not expecting them to change this. So if there's a special event and they are asking for a new template that you didn't prepare, then you need to be involved at that point as well. So that's the third option which is panels. Any panel fans? So panels can be considered as customized layouts that you can use for different means. It's basically a way of creating custom layouts for pages or for sections in Drupal. They do have a good friendship with a suite of models that extends their behavior in terms of recognizing passes, in terms of customizing certain passes as well. And what they allow is to create very easily a page with the layout that you want and just on that page drag and drop different components. So they are quite easy to be created. They are quite easy to be customized. And it fits very well when you start thinking in an approach where what you want to create for your content editors is a set of widgets. And those widgets can be just drag and drop on different pages as they want. So if they want to create a recipe, they can just drag and drop components. And, or if they want to create a homepage of recipe, they can drag and drop components and then customize as they want. So, but if we look to panels, there's not also a very straightforward way of creating a page with panels. You can actually look two different ways of creating a page with panels. You can create independent panels. So they are just panel pages. You can create a page manager and have variants. So I can create a page manager, a variant that overrides the nodes, the node view variants. And I can create different variants on that page manager. And then depending on an attribute, it picks one of the, or another. I can have panel nodes which are just panels that the node that is attached with a panel. Or I can use one of the most recent additions to the panels which we see is panelizer. Any fans of panelizer? Okay. So the basic idea with panelizer, it's just a way of gluing a panel to an entity or to an entity view mode as well. So you basically create your panels, you create your displays and then you can say, I want anytime I'm viewing certain entity in a certain view mode, I want it to be rendered through this panel. So, and also the other thing that it provides by default is that you can define several templates, you can define several displays, and those displays can be used as templates. So I can say for recipes, I prepared you all these five templates, but if you want to override it, if you want to create it your own, you can do it as well. It's, what it does, it's basically panelizes an entity. So whenever you are viewing an entity, instead of going to the normal render of that entity that you would, that you use normally, instead of that, it's gonna render a panel. And then you have all the benefits that you'd have from using panels, just rendering that entity as well. It has a very sleek interface. When you combine these with panels IP, so panels in place editor, which provides you a different types of interface to manage your panels. So if you have to think, I want to expose the panels interface, the default one that you get to reinstall the model to your content editors, that's not gonna work. It's a very complex interface. You have this notion of variants. You have this notion of having the different widgets, the different widgets that appear is a long list. It's very hard. But if you start playing with things like panels IP, which is just in place editor, you have just a quick button that says I want to customize my page. And here is your list of widgets that you can add. And you add those widgets to the page and then you can configure those widgets. So you can say, I want to have a slideshow or I want to have a grid. And then I want to pick node one or node two or node that goes through a browser and then I pick the right node. That's much easier to expose to a content editors. That's much easier to explain to content editors than going through the normal panels interface. So and you can try all these notion in distributions like Panopoli. They were the first distribution to glue all really this concept together and having this concept of I can create rich pages with panels and panelizer. And I can override when I want and I can still have templates available for them when I didn't override. And I do have a list of very well-prepared widgets that they cannot mess up. So they can have a gallery, they can have a slideshow, they can have a map, they can have a list of links. All of that is sought from the beginning and that's how the widgets that they are going to add to the rich page that they want. Or lightning as well. Lightning is a distribution from Acquia that glues a couple of things together in terms of a CMEX experience that Drupal Alt of the Box does not provide. One of them is panelizer and it also integrates very well with panelizer and workflow which is the next topic that we'll talk about. The other missing piece on this puzzle of using panels and using panelizer is paints. And paints you can think of them as widgets. So things that you add to your pages. In technically there are C tools content types and so there are constants or boxes that you can add to your pages and you can customize them. They can have configuration. That configuration is also per instance. So anytime that you drag a box or a widget or a pane to the page, you can configure that widget and that configuration is by page. So anytime that you create the same widget in another page you can have more configuration. And that's very important when we start thinking about workflow and you'll see why in a bit. You have other interesting models that glue very well with this whole concept of paints and using panelizer to add those paints to the pages. Fiddle panel paints, it's a model that allows you to create entities that are very easy to be customized in panelizer concepts. So they're just normal entities. You can create bundles on those entities and then you can just drag and drop them in the pages. So if you look to Panopoli or if you look to Lightning all of those things like maps or slideshows or list of links, all of them are Fiddle panel paints. And they are very easy to be created. They are normal entities. So you have all the nice things that you have when you use entities. Panos in place editor we already talked about. Two other things that I wanted to talk about that came from Panopoli. One is Panopoli Magic. What it allows you to do is whenever you are editing or whenever you are adding a paint to a page, Panopoli Magic allows you to preview it automatically as you type. So basically you are typing, I want to create a list of links and I want to customize a map and you type on it and you just, you can see on the right side of the widget you can see how is it going to appear. So it's very easy as well to create a very good experience for your editors. They can see what they are creating. They don't need to create the content first, save it, preview it, no, they can create the content and as they do it, they can see how is it appearing. And that works out of the box with Panopoli but as itself it's just a country model that you can just use on its own. The other one is Panopoli Widgets. So if you want to create your own widgets and if you want to drive your editors and you drive your content strategy to grow with this Panopoli or with this widget approach, then you have couple of widgets in Panopoli that you can use as base, as things that will guide you to see how they have done it and how could you do it as well. So for the ones that never used Panolizer, this is an example of how would you customize a page in Panolizer. So you just have a little bar in the bottom that says I want to customize this page. The page is already a panel but they can add more things there. And then in the left sidebar, whenever you want to add a widget, you have a bunch of new widgets that you can add, namely tables, namely maps. Any type of widgets that you can think about, you could customize it that way. So it's very easy for them instead of thinking about I want to create some text and that's very complex. No, I can just go there and create the entity directly on the content of the page. It's much easier for them to understand that than create the content elsewhere and then just referencing it somehow, especially using an entity reference that's just as an autocomplete. It's a very different experience and it can break our old mantra of saying, you create first the content and then reuse it. No, you can create everything in the same place and it kind of makes more sense from a content edition perspective. So this is nice from a layout perspective. And so we do have several options in terms of layout. We do have several options in terms of content. But the third thing that's typically these type of content editors want and these type of sites want is a good workflow. It's in a newspaper, in a magazine, in a TV, typically all those content needs to be reviewed. Typically all those content needs to be curated. Sometimes there's content that is just sitting on a CMS for months and it's published because it's just prepared for a special occasion, for instance. So it's very important that you also think about the workflow and you also think about the preview experience. So whenever you are creating this type of pages or these collections of pages, you also think about how are you going to approve it, how are you going to preview it, and if you need to revert or if you need to reject some changes, that does not change what is in production. So how do we workflow content and layout together? So content is easier. Content has been something that we have been working in Drupal and workflow in Drupal is something that came from a very long time ago. So you have models in Drupal 7, like Workbench Moderation that appeared first or Workflow that appeared later, that provide a very good solution on how do you workflow that content. So you do some changes that change gets to a certain stage. Some role in Drupal would look at that content and see, okay, this is good to go, this is not good to go, and if it's approved, it gets published and it starts appearing on a certain site. Layout, it's a bit more difficult. So if you start thinking about, I have all these concept of widgets and I added this to a panel and or I do have some changes on the layout between one revision and another revision, it's a bit more tricky. And you don't have many models that would work well together and here are where the problems could start to appear. Also, if you do have content that is not really exist as a whole, if you are thinking about flexible content and the content on that page can appear from many, many locations, it's a bit hard to preview because you need to make sure that you are pointing exactly to the right direction. You need to be pointing to the right division. So if there was a change on the certain piece of the content in some sub-item of content, that needs to be reflected only in the page that you are seeing, not in the ones that have not been approved yet, for instance. And then you have all these problems of reusable content. So if I have content is reused across different pages, I need to alert users or I need to alert editors that whenever there is a change, that change can be appearing as well in other pages and maybe that's not what they want. Maybe they just want to change it on that specific instance. So typically, if you want to preview content, it's much easier to preview it if the whole content exists as a single unit. So just one single unit of content and whenever the node is being load or whenever that entity is being load, it all belongs together. It's much harder to achieve if you have a lot of entity references, for instance. Entity references do not reference revisions in Drupal. They reference entity IDs. So it's much harder to say, I want to reference the change that I have done that is not published yet. I want to reference the change that is happening for the elections of Sunday. It's much harder to do that. It's also easier to achieve if whenever you are customizing your layout, how is the change that you want to do, how the change that you are doing on the configuration of certain entities or certain widgets in this case, they do exist in the context of the widget itself, of the instance of that widget in that page. And that's why I'm defending that using panel panes, it's typically a good solution because that configuration is safe per pane. So it's any safe per page. So it's much easier to interact with that pane and it's much easier to make sure that whenever you are looking to the next revision, that configuration is changed there. There is no cross references basically between the two panels. And also if you think about workflow, there's typically two solutions to do this in CMSs. And if you look to different CMSs over history, you have systems like Drupal where typically you end up doing directly in production. And so you go to the production website, you create the article there or you create some content there and that content can be revision, can be approved, can be published. Or you can have different environments. You can have systems that defend, well we should have a pre-production environment or a content production environment. And then that's where I create my content and after they've done a couple of changes, then I can just press a button and that goes to production magically. So both are possible in Drupal and there are clients that have explored those possibilities using different models. The first one, it's more limited. If you don't address it well, you need to think about the whole concept of the workflow, the whole problems of revisions, the whole problems of references. And you need to be looking to models that integrates well with each other or models that work well from an holistic point of view. So if you work to panelizer and workbench, then you start having a problem because typically what you are approving with workbench moderation is just a change on the note and the reference to the panelizer is unique, it's single. But then you do have some work done on the community and you have some patches that would get you that behavioral of the box as well. If you went to different environments, it's a bit cleaner, like whenever you are looking to an environment, that environment contains all the changes that you are doing, but then it's not that easy to deploy that content to the next environment. You don't have that huge support on many entities and many dependencies on those entities to make sure that you have done a change in a pre-production environment and you click a button and magically that appears on the production environment. So if you are doing directing productions, models like quick edits and enhancing places gives you a lot of editing context behavior and that's interesting whenever you are looking to get an experience where you want editors to go directly to the content where it's appearing and fast to change it and do not worry about what's behind it. And if you are working in the same environment then you'd be working with models like workbench or workflow, workbench moderation or workflow and that would guarantee you that behavior in terms of revisioning and that behavior in terms of approving different content. Then you have some experiences and some projects like the site preview system that try to glue the whole thing together and tries to get you also some more support for things like I want to create a section or I want to create a batch of pages and I want all those pages to be approved at the same time and changing everything at the same time. So you would always depending on the revisioning system and then some custom or some contrary models that would customize the experience around it. If you are looking for different environments then you typically are looking to move information from one environment to another. So there are different ways of doing that again. One of the options is to use the deploy model. It contains very interesting support for dependencies. So you can do things like I want to push my node and somehow I want to push also the reference of my node or I want to push the images that attach to my node. But then it might lack support in some other areas. So it's harder to export things that are not content that are not entities. And it's harder to support things like panels that are associated with certain content. So it's a bit harder to pick the second environment or the second approach. Using different environments is possible which is a lot of work. And you need to be thinking again in your architecture very, very closely from the beginning. Okay, so we look to preview, we look to workflow. The last bit is even if it's the last I think is one of the most important. It's all about non-technical considerations. So I think the most important part here and where I sometimes I see struggles from content edition teams that they are not usually exposed to the project since the beginning. And they are the ones that are going to use the site every day, they are the ones that know what kind of content are they going to create. They are the ones that have the needs. So they need to be involved from the discovery phase. They are one of the major stakeholders to be involved since the beginning. And not only new AT, it's very hard for them to just be trained after you create a concept that it might exist on someone that was driving the solution from the client or from your heads or from your peer-based experience. But all the content edition teams have different requirements. They do have different ideas. Sometimes they can be adapted but it's important for them to be involved since the beginning. So then your system really captures what they want to achieve. That's the only way that your system is gonna last four, five, six years is to make sure that it supports pretty much all the requirements that they had from the beginning. Another important item in this slide is making sure that you understand what they care about is what they see. They don't really care what's in the back. They don't really care about how Drupal does revisions, how Drupal does the workflow, how Drupal does inclusions of content. The most important part for them is to be able to quickly create content, quickly manage that content, quickly edit the content that appears in a certain page. It's important to consider history as well. So they come from a certain background, they come from certain platforms. They might come with an environment that used to have a pre-production environment then you are trying to move them to a new world where everything is gonna be managed in production directly. It's important to make sure that they understand those implications and they are comfortable with those changes. The other thing that is very important and it's a very good advice that I typically give to my clients is to power it and PLC as much as possible. So try to expose them to power. Let's try to expose them to the way that you are suggesting that their new world is gonna be. Create a quick PLC, create a quick pilot, make sure that they are comfortable with using panels and panelizer, even if the experience is not the same that they're gonna have in full production. Make sure that they are comfortable with what you are going to see. And it's also important that that same experience is the one that you demo from the regional interactions with the client. So that's one of the reasons why AQUI created something called Demo Framework, why we created the same, it's a one solution that we show to clients that's where they can recognize what people can do out of the box and drive them as well in the way that they manage content. And that's the same expectation that they're gonna have when we deliver. And these solutions are like lighting up and up only. I think they are great inspirations or models to start with. If you wanna go with a panels approach and there are other ways or there are other models that you can fall. But again, don't try to reinvent the wheel. Typically, you need to look to the whole problem as a whole. And there are people out there that already solved it. So make sure that you look to those examples as well. And that concludes my presentation. So this is basically the idea that I want to pass you here. Is that whenever you are creating and whenever you are analyzing this type of problem, you need to have a holistic view. You don't need to worry, not only worry about the content structure, but think about the whole implication. Structure, layout, workflow are the three major ones that you need to think when creating and managing content. Fourth one is important as well. And Drupal sometimes lacks this nice editor experience or this nice user experience. It's an area where we are somehow behind from other systems. But somehow, sometimes it's quite easy to just do a quick trick, just do a quick change. Make sure that you hide buttons. Make sure that you just provide editors what you need to see. And make sure that their experience when managing this site is as flexible as possible. Just to finish a couple more about my work, I'm a technical architect in Acre is responsible for designing solutions like this from beginnings to the end of the projects. So we typically involve from the discovery to definition of the solutions, to development phases, to deployments. Most of these examples that I gave you here was projects that we work in the past. So if you are interested in working with us, we are hiring, come to the site, see what positions we have available in different departments and come to talk with us. And that finished my presentation. So open for questions. I'll ask anyone that has a question to go to the mic if possible. Hello, my question is about using paragraphs and panels and one solution, I mean one website. Have you wisdom together and how? And is that actually a good idea or not? Well, you can combine different approaches that you have here. You can combine panels in this play suite and you can combine paragraphs and panels. Typically when you give too many options to your editors, it's very easy to confuse them as well. But you can think of ways of creating paragraphs as a certain amount of content and then just using panels to combine rich pages. So maybe the way that you are creating recipes or the way that you are creating stories or news stories, for instance, is different from the way that you are creating a homepage. And what you want to have in a way to manage the homepage is very different from what you want to use to create a story. But typically I try to stick with one approach. I try to make sure that the approach is holistic. It's easy to explain, it's easy to document, it's easy to train people. And the complexity of the overall solution that you are creating is also lower. So if you need to update the amount of models that you have, it's much easier if you just drive everyone in the same direction from the beginning. But again, it really depends on the use case that you have really depends on the flexibility that you want to have in landing pages versus the creation of things like stories. Hi, so you're an architect and you figure out the structure and architecture of different pages, fields and so on. So where do you feel that your job ends and the developer's job begins and in your daily job do you work hand to hand with the developer every day or do you give like a larger piece of architecture for development team and then sort of step away from that? Thanks. Thank you. Yeah, an architect needs to follow the solution that he designed. The solution that he designed most of the times is gonna change over time. There's new fields that come come. There's new requirements that we have not been discovered during the initial phase. So it's very important for him to be very close to the architect, to the development team as well and to be close also with the end client or the people that he is owning the product itself. I think it's very important to follow up the solution. It's very important to see what's the end result and it's very important to be involved in situations where the original solution is gonna change and over time the solution always change. It's very hard to define your content structure in the beginning of a project. You don't know you are gonna miss areas. So it's very important to prepare for favor, making sure that you prepare for that complexity and making sure that you are there as well when those changes will come. First of all, let me to thank you for this session because this was a really huge problem, Drupal, for all of the time about creating rich content I mean. So what about my question? I don't really have a question. I want to propose a solution to let me to do so. Yep. But could you please move back your slide to option B? In layout or content? In the first part. So content I guess. Yeah, yeah, yeah. So I want to suggest to not to split option B and option C. So if you can switch slide please. Option B is about including content right in the node or entity and option C is about referencing content on the page. So what I suggest to do, I suggest to combine all of two options together so you can reference content at the same time and include it in the page. So it gives you flexibility so you can reuse content, you can manipulate it, and using references dialog module, you can edit an inline. So it's really, it could be really easy to manage your content in the way you want. Yeah, I think the flexibility that you have when you go with option B is that in reality of those compound fields or those sub fields, they are just normal fields, they just depend on field API. So one of the fields that you have there as part of your sub item can be a reference. So you can do a paragraph that references other paragraph or a paragraph that references an entity that is somewhere different. It's a bit harder to combine the same behavior of inline entity form with something like paragraphs or field collections. It's a bit different. And one more aspect of that. So we can try to do not separate a layout and content. So we can treat content and layout both as a content. And it will allow us to use the same things for layout and for content. So instead of separating this thing, we can treat both of them as one thing. And for example, use paragraphs or something like that for designing your layout and pages and it could be really easy to do. Actually, I just implemented a module on top of entity reference module and the ECK admin UI. The name of the module is just atoms. And it combines option B, option C and all your part about the outer architecture. What's the name of the module so then people understand again? Atoms. Okay. So if you're interested, you can join my booth. It will be in 132 right after this session. Okay. So anyway, thank you for your session. It covered many things. And maybe you know about Atomic Design Concept. This is about not just about Drupal, not just about content management systems. This is about new concept in design overall. So it's really, it's a good concept which describe everything we spoke about today. Thank you. Thank you. Yeah, I was just going to say, I worked with paragraphs and also with inline entity form for the same purpose. And the main difference from the user perspective is just that in an entity form, you need to save each sub entity. But internally, even paragraphs and I think also field collection just stores separate entities for each item. They are different entities. Technically it's just kind of the same. It's just a different integration with the field API I think. Yeah, it's a different interface that you have to edit those. But I think it's a good idea to choose just one of those two things. Either your fields are entity references or they are paragraphs. You can combine them. You can make nested structure which some of them use paragraphs, some of them use entity reference but I think it's probably easier if you just stick to one. Yeah. Agree. Hello, Ernani. My question's kind of simple. Basically, I hate all of you that you just spoke about. It looks freaking ugly. It's, they're basically all acts on top of Drupal which is option A. Yeah. And we're going to have Drupal 8. So how would people that are here working with Drupal 7 better prepare their sites using those options to move to Drupal 8 because it's going to be a nightmare. A lot of what you do there might not have an upgrade path. True. Thanks. I think most of the solution that you have here in Drupal 8, you'd have them, you'd have similar solutions. It's very hard to predict an upgrade path but if you look to what's happening in panels, if you look to what happens in this place suite, you'd probably have upgrade passes on those ends. The other thing that is interesting in Drupal 8 if you look to all the media initiative is the way that you're going to have much easier to integrate other entities in a easy week via placeholders which is a solution that right now in Drupal 7 is a bit weak, I would say. But yeah, one of the problems that you have when you think about migrations is if you don't save the structure of your content if you don't know from the main content what are your referencing, then or if that's referencing something that is weak saved in the C tools content type or something like that, it's much harder to migrate in the future. So I would say that at this point in Drupal 7 there's a couple of options that are very well defined. I wouldn't try to move away from any of those options. For Drupal 8, it's hard to predict what will happen. I think both display suite and panels and panels and panelize eventually will depend from the same rules, will depend from the same layout plugin. So it's a bit easier to understand and to prepare for that if you go with that approach. And I think things like paragraphs and field collections will still be there. They're providing exactly the same thing that they provide in Drupal 7. And just quick question, which entity type do you use with entity reference? Do you use nodes or something different? You can reference any type of entity. So it really depends. You might want to have an entity reference that reference your custom entity or you can have entity reference that reference any node or any that you want. It depends on what you're trying to reference. Thank you, Renany. Just to answer your question before, there's tomorrow a session which is called Building Sites in Drupal 7 with an I on Drupal 8, which might be interesting for many of you. Okay. Hello. I can show one more remark based on my experience working with some compound fields, like multi-field, not always is a good idea. And let's see. I forgot. Sorry, add one more. It's okay. First of all, great presentation. Yeah, stuff for the mind. We use a lot of paragraphs together with references. I want to say that the paragraphs module fixes a lot of stuff, field collection, content handle. It's a Dutch company that did it, VDMI. He ported it for Drupal 8. It's gonna be there. It's gonna be great. You use it. We have like an extra cool thing we did. When you create paragraphs, it's the editor just wants to see how it will look. So we made like a button that displays, this is like three paragraphs, side-by-side or pictures, and you can just click on the button. It will create it. They fill it. That works awesome. That's cool. Thank you. Okay. It came back. So for people who are moving from Drupal 6 to 7 and are planning to Drupal 8, well, regarding panels, some components are currently being deprecated. That's great. For example, panel nodes. Yep. And also custom content panes, which can be replaced by fieldable panel panes. So that's just it. Just wanted to give you this remark. Yeah, typically when you evolve from one major version to another, you need to think of what are the things that are deprecated and just move them. Some of them will need to be rebuilt. It's gonna be hard to move things like something that you have done in the custom implementation of panels. Okay, so when I started with entity reference and in an entity form approach, I wanted to have an entity type that is really lightweight and not like nodes which kind of commands and everything. So I created a small model that just defines this kind of entity type and I called it nested box. I just wanted to mention that. But at the moment, I cannot really say if I recommend the paragraphs or the other approach. Paragraph seems to be more defined for this problem. Yeah, and so maybe I just stick to that and then I don't have to care about this other model. But it kind of, I think it works, so yeah. Okay. No more questions? I think we can finish. Thank you.