 Okay. I'll get started. I can see outside everyone's moving into their rooms, so no point waiting. I'm Simon Hobbs, little engine, and I'd like to present today on Drupal and content modeling. And if you want to ask me a question, I have got my Drupal Slack open on my phone and I will try to look at it, wave at me if I'm missing it. But yeah, also join the Drupal Slack because it's nearly 300 people and so do that anyway, right? So you can message me at Simon, Simon, Americans call me Simon from that, in Drupal Slack. Okay. Content modeling. We love content modeling. I love people who love content modeling. I love working with people who love content modeling. And then they ask me what I do and I like Drupal. And at that point, they ask me if this is the bad place. So this whole presentation, the good place, if you haven't seen the good place, that could be a bit tricky. Some of the jokes will be in, slightly in. But yeah, I know at least like one person Caitlin knows the good place. So I'm fine. All right. I've got a lot of slides and hopefully my timing is good. I've been thinking about content modeling and thinking about all the things I forgot to put in this presentation as well. Great. So we'll get there. So Drupal is complex and it's powerful and it's mysterious to the content modeler, to the content expert. And I like to think of Drupal as being Janet from the good place, right? Because Janet is complex and powerful and mysterious. This is Janet. So the problem that I usually face when I work with a content expert, or that's probably the easiest way to call it, someone who's interested in delivering content and might be putting content together for a Drupal site, is there's a reluctance and a desire not to really have to learn Drupal. And it's tricky because Drupal really is opinionated if you want to use it right. So you've got your content modeling and you've got the overlap there between the Drupals, which I like to break the ice with, and content modeling. And that person's job is smack bang in the unfortunate middle of that. So the good place is where they want to be and the bad place is Drupal. So I want to start by just breaking down the anatomy of content, right? So let's just try and just deconstruct this. And let's not talk about Drupal for a second. Let's just break some content down. So I realize I've got a lapel mark, but because I've got so many slides, I have to stand here anyway. So I should have one of these clickers. Anatomy of web content. So I'm going to break this down to about seven different things. So we've got a page that's really, really obvious. Everyone understands a page. I've got an about page on the internet. Sweet. So there's sort of aspects of this, right? It's going to have like a clean URL, like an SEO friendly URL. It's going to be something that appears in the search result. It's going to want to have SEO. Some business department might want to own this page, right? It's probably going to appear in the site map. So there's a pretty easy to understand concept. And then you've got HTML markup, which it's the thing we all need to understand these days is markup no matter what our job is in the web. We work with it all the time. So we're talking about unmodeled but semantic HTML. So it's sort of opinionated in terms of the structure, but still has a structure, right? The third is like the fixed properties of a page, right? So something that's a fixed property that you can think of with the about page is like, you know what was the date it was updated, right? These are fundamental things to the content. So these are things that all content kind of has, all pages sort of have. And we don't really think about it as being a choice that we make in terms of adding that. We probably don't even put it in the spreadsheet when we're doing our content modeling, right? So these are some examples of those things, right? We don't typically even describe them. If we do describe them, it's overkill. And we start getting into the juicy stuff, right? So we've got user defined properties. So we've got things that are really optional to the content model, the things that are really going to change from business to business. So it's better to define these separately because these are the things that when you're describing your content for a business, these are the things you're going to put in the spreadsheet. These are things like the event. It's going to have a from date or maybe this type of event won't have a to date because it's like only ever on one day, right? So you're starting to get into really specific definitions. So as I'm going along with these things, I'm trying to build up a little bit of a visual map here. So you've noticed that the colors are going on here. So I'm going to use the blue for this top level page. And I've got these blue properties here at the top on the left to describe those things that are fixed. And then I'm highlighting it with the yellow here, these green ones that are now our user defined properties, right? So I haven't got into Drupal here, but if you're Drupal, you know where I'm going with some of this stuff, okay? Then we get into complex properties. We get into things that it's not just a piece of text. It's like things that might be a whole bunch of combinations of texts. There might be multiple of them. And really good examples of these on the right there is an address. It's the line one, line two. And you've got the ingredients of a recipe. It's like there might be five ingredients of a recipe. And some of them need numbers, and some of them don't, and some of them don't. Did I hear that? And then number six is embedded content. So this is more a concept of being able to embed markup within a narrative, like within a flow of text. So it's a little bit different to that complex property that I'm trying to describe, but I'm more trying to say you're breaking out a piece of content within the flow of the text. So I'm going to be calling that sort of embedded content in a very generic sense in this talk. It's very similar to the structured content, to the complex content. And then the final one I want to touch on is relationships, right? So it's relationships between one page and another, relationship between a media release and a publication, a relationship between a page or like an about page and then some of the key landing pages that you want to get the user to. And those relationships are described in formal ways, in markup in HTML and also formal ways. So the references you see here, I've got little arrows. And the thing about relationships is they can turn up in any one of these parts of your content, right? So like in terms of the author of a page, that's a relationship to an author, what that author is, whether it's a piece of text or whether it's something more complex is another story, but getting to the Drupal bits. Okay, so then we get to the anatomy of Drupal and this is where we start getting into the jargon. And this presentation is targeted at people who aren't Drupal developers, right? So I've got this thing where I've started saying right. I'm not sure if it's because I've been looking at so many good place memes. Okay, so the anatomy of Drupal. And it's the complex, powerful, mysterious Janet. So in Drupal, most things are Janet. Most things are what we call entities. And I'm coming right in at the jargon top level here. Most things are entities in Drupal. So you've got all these different types of entities. And they're kind of all Janet. So they're all the same. They actually, like a node and a block and a tag and a tag or a term have these fundamental things that are the same about them that we, when you're talking about a tag in a Drupal website, you're talking about an author in a Drupal website, you don't think about them as being the same. But this, when you hit entity, entity means that they share a lot of fundamental similarities. So most things in Drupal are Janet's entities and the things that aren't probably fields except there's like an issue in Drupal to make fields fieldable, in which case they'll probably be in entity two. So you hear a lot about entities in Drupal. You hear a lot about fields in Drupal. So what I want to do here is I want to just break some of these Janet's down, right? So here's like a bunch of the really common entities that you will see when you're discussing Drupal. There's like heaps more. There's heaps more in Drupal core. There's ones that no one ever talks about or needs to talk about. They have like their internal, they don't matter. And then there's ones that other modules provide. So I'm focusing on the ones, the bolded ones here just to keep it real, right? Otherwise it'd be a bit crazy. Too many Janet's entities. So entities have superpowers, right? So we can distinguish them by their superpowers. So if you take, for example, the concept of something being accessed by a URL and going back to that page. So the key one that is accessed by a URL, and when I say it's not, it's not that it's not possible to access all entities by URLs using various means, but I'm saying something that's actually designed to be accessed by a URL, that the whole thinking of it and the people who develop it think this is going to have a URL. So, and node is that thing. Node is the primary piece of content in Drupal. And this main superpower is that it wants to be accessed by a URL. Now, other things can be accessed. I've highlighted media and user because they can be accessed by a URL, but I've highlighted them red because it's not really about a technical ability. It's more about what your intentions are with your website, right? So most websites, you don't tend to access a user page by user slash 123. But you can, right? So it's just a little bit about going, there's a little bit in Drupal about going, you know, when you start adding other modules into the mix and stuff that suddenly all entities can be all other types of entities, and everything can be accessed by a URL. Or, for example, you know, everything you can write, you can get a module that'll do something with a file, but there's this file entity in Drupal that it's responsible for interfacing with the files that get uploaded to the website. So that's the superpower of the file. And just I'll call this out, but you've got the media. There's a distinction between media and file, and the media is more the entity that you interact with, and the file is more the thing that interacts with the file system. And that's that separation. The media can be a YouTube URL, right? Might not be a file. The concept of reusable content is pretty big in Drupal. So like blocks and media and tags want to be reusable. They're itching for you to browse for them and to add them somewhere, okay? They're itching for you to maintain them long term and have that same, you know, contact us block that you always edit and you always go back to, and you can place it somewhere and reuse it somewhere across your page. So reusable content is really important. And then single use content is like the other end of the spectrum there. And this is where this paragraph concept comes in, which is a contributed module. So it's not in Drupal core. I talk about it a fair bit. It's a very common site building concept, so we'll talk about it a bit. But, you know, a paragraph is designed, is out of the box designed to be single use. And I've asked Rick's that because there's a paragraph library module you can install, and all your paragraphs are available in a library similar to the block library, but you start getting into a bit of a weird anti-pattern where your blocks already do that. And all core is moving towards using blocks in your layout and stuff. So again, all of this is like squish your eyes a little bit, squint. And then there's other superpowers like translatable things and, you know, I've had people call out and go, well, technically piles are translatable because there's this patch and stuff like that. Again, translatable, revisionable is the other one is another big one. And most things are revisionable in Drupal core. They keep adding things like there's an issue to, I'm sure there's an issue to make users revisionable, right? But is your password revisionable? Like do you keep all of someone's old passwords as different revisions? It gets weird. So when we bring this all together and mush the content modeling with the, how am I going for time, just by the way? Halfway? Yeah, cool. All right, I'm going out. So when we mush it all together, like, we start talking about how that content designer is coming in and saying to the Drupal developer, okay, right. So here's all my content, here's all my designs, here's all my systems. How am I going to lay out my content? And then the Drupal developer, paragraphs. That's where it starts to get weird for the content designer, right? So rich media embeds, how is that going to work in Drupal? And then the Drupal developer, well, on the last slide, I used paragraphs. We just do that again. So what's, I mean, what is paragraphs? It's this thing we all know as Drupal developers. So just going back to the color coding system, we'll break down a page. We're talking about a node here. It's the page. It's got its base fields of properties, which we don't usually talk about as being properties in Drupal. We just say it's the last updated date. It's sort of straightforward. The green of the fields. So if someone's talking about a field, they're talking about user defined properties. So you can say, I want a field that captures this type of data. I haven't really put multiples in here. Like, you might have a field that you can put more than one of that thing. I'm not really describing that in this diagram here. I'm just sort of keeping it very high. And then paragraphs is paragraphs and blocks are two ways of doing that complex content, right? Paragraphs being the single-use one and box being the reuse one, generally. And then we look at, like, the concept of, like, the different ways we've got to embed and so forth. So, like, there's a module called entity embed. If someone's talking about embedding content within the text flow, we're talking about something like entity embed. HTML is usually a field of some sort. And you'll see that I've got a complex block there, but it sits outside of my content, because usually blocks are, like, make this appear on this page, usually. Whereas an entity embed could be, well, rather anything technically, okay? So I'm trying to just do this visual language. And then let's talk a little bit about relationships. Because this, how do you describe this? Because every site's completely different. But here's a hypothetical site where we've got some content, and we've got that content, it's got some fields which are green, and those fields point to other entities, other janets. So nodes are janet, users are janet, tags are janet, midis are janet, and they all have different superpowers. Paragraphs are janet, and paragraphs, superpowers, one of paragraphs's, use cases is adding fields to it so that it can point to things. So I want to be how to have a reference to another node, and then a reference to another file inside my node, and I want to be able to add that as a thing called a paragraph. Generally speaking. So the interesting thing about the file people, we have their problem with Drupal, which is like, if you don't want me to edit my files, why don't we have a files tab in my admin page? But really files are really supposed to be very low level things. So that's distinguished them. If you ever wanted media files, what's the difference? The media is really the thing that we want you to be interacting with as content editors. And that's the thing we want you to be describing when you're content modeling and not the file entity. And then the end result is your Drupal site is a wonderful collection of paragraphs. So, you know, and I do use paragraphs just so you know, but I think paragraphs is kind of this maligned, very much used and very much maligned thing. So the fun fact is janet is me, right? I'm the Drupal guy. So I'm the Drupal guy in the project, and you're the person saying, hey, I want to do all this really cool stuff with my content. And I'm going, well, we could do a paragraph for that. Well, that's just a reference to another thing. Or, no, you wouldn't use the media for that because we really don't really want to have a URL for that. We want to have the media in a publication node, right? That would be better because then the publication nodes are searchable through the normal content search. So that's janet is me. So I wanted to touch on this. And I'm not going to, and I've got a few things that slides at the end which is some anti-pattern stuff, but I just want to, I'm going to flick through these ones because I think there's like, this is like one of the things I really try to tell people to take care with. So Marge pointed out in her presentation around field naming is she searched some really, some problems with field naming. So I think field name is really important. And the reason for that is like, if I type this and then I hit save, I get that field underscore is underscore field underscore naming underscore important. And this plays out in so many ways in my system as a, for developers, right? It might not affect you as a content editor so much. But it's affecting my database. My tables are going to be called that. It's affecting all of my admin URLs. My admin URLs are going to have these very long, ungainly names that I can't predict. I can't go to field page body and then predict that the other one's going to be called something else. I can't remember it. All of my exported configuration is going to be named that. So if I'm doing, if I'm looking at my code in Git and I'm comparing it that decision that person made when they created the field is affecting those files. You notice in this case, I've got, and this is really important, but I've got all of, I can actually see that there's fields that I wanted to only ever be on an article and there's fields that I only ever wanted to be on a page and they're all sorted beautifully. Except field underscore naming important is just annoying, visually annoying, right, when you're looking through a large number of files. It affects my JSON API. So the front-end developer making that beautiful React application, something that comes along to the API and has field is field underscore naming under something important and just thinks it just is just lazy on behalf of those Drupal developers. We're like, we didn't do it. That dude who set the site up, he just made all the fields. And like is an example of filtering. Like that's a really annoying interface for a front-end developer. Sorry about my fingers. And then it affects your tweak templating as well. So it becomes, it affects so many parts of your website. So you do get the, it's just a personal preference, right? You know, you seem to be really opinionated about naming your fields. You know, if Drupal wouldn't let me do it if it was wrong. And this is my second site, so I know. So yeah, it's kind of like one of those things where I'm trying to like, I try and push people to think carefully. And so we're talking to someone before about make it spreadsheet before you start creating fields or make sure your first site's a throwaway site, you know? Don't make your first site the site. Never make your first site the site. You are going to change all your fields. Someone called out about, all right, I've got a location field. It was text and then later they wanted it to be a lat long, right? So you feel many naming important, yes. So I just want to talk about field naming and the one I like to do with my field naming is I like to be really stingy. This is my content type, right? I'm creating a new content type called a blog. I don't call it blog underscore post, I don't call it blog post. Neither of those adds any real value. Just call it blog, keep it stingy, keep it small. Try and keep my field like I keep basically minimized and semantic is what I'm going for whenever I say something. I definitely don't want Mike's rant because that's like the business is like, we're going to have this cool thing called Mike's rant on the website. And then I go, yes, cool, I'll create a content type called Mike's rant. Semantically, it's a blog or an article, right? It's not a Mike's rant. So you just want to change it later. You want to change the labels but not the machine name. So try and keep those pithy. Here's a few examples like be really concise with, you know, like your underscores, right? Be like promo. I don't mind acronyms. I don't mind a CTA call to action because it becomes a very common thing that the business refers to. People say let's add a new CTA in the system. It's got a CTA. Promo. I don't really care. Like I don't expect it to be promotion. There's a bit of like good practice to use full words. But we actually have got a limited number of characters in our field names. So being stingy is fine. But underscore promotion is fine as well, okay? And then I'm a big fan of using underscores wisely. Now in this situation, someone's created two fields, one's called open and close. And I try and say think about how that's going to sort in the database or in the file system or in the YAML files. It's okay. It doesn't really matter. But think about how that's going to group together. Open and close. Semantically have a lot of meaning together with each other, right? And it flows into this discussion of like when do I reuse the field is another really big content modeling thing. I'm probably going to get a wind up at some point. So let's say I have two node types. I've got an event and I've got a freedom of information request content type. So anything that shares style and meaning, try and reuse the field and try and keep the name of the field as pithy as possible to that meaning. So in this case, all the designs have this summary. And most of the content types have the summary. And we're going to try and share summary because we want it to be styled the same way all the time. Whereas these events, the event has a start and end date and then if a Y has a requested date and a release date. So in theory, they're just two dates, right? But sharing those fields would be semantically not right. They don't mean the same thing. So just because you can share those date fields doesn't mean you should in this case. And specifically, you can call out to the fact to other developers. I specifically want FOI to have a requested and a release date and I don't want you to share this field on your blog content type. So you can call that out by sticking the content type in the name of the field. So there's a bit of a language going on in terms of naming. So there's two problems. So we've got an example where you've got two set of tags, taxonomy terms. You've got two fields and you notice that the tags have a lot of overlap, right? So this is where it's kind of you're suddenly getting all this slippage between your two taxonomies. So in this situation, that would have perhaps been a more semantically meaningful thing is that you've actually got, they've got two very similar tag clouds essentially. They are really just one and they really equate to what the business describes as their audience for, say, in this case, a media website. So people who are interested in television content, print media content and so forth. So you're actually consolidating the two things and it becomes a single tag system that you're actually managing and you don't get the slippage, you don't get the drift between the two tag systems. So value of consolidation is a bunch of different things that where you get value like having actually made that decision. And there's like, you know, it's a play to argue this is a good pattern. Three is field tag. It's awesome. So always share fields is the takeaway that I've got. I literally did not just say always share fields. Problem two is we actually have like three content types and they're sharing a field called field image. And this field image is completely different in meaning on all three types. And I do not think that that's useful to other developers going forth in the three or four years or whatever this website is going to live. So in this, you've overloaded the meaning and you've got conflection functionality. You've got twig template. They're all using the same twig template and the developer has to go in and has to have logic that says, wait, no, but this time I'm doing the image on this thing or that thing or whatever. So split them out. Whether they're single use, whether it's a single use field or whether it's going to be potentially a shared field like field hero, which I like to do. I like to do a field hero because there's always sort of often one in those designs and that becomes shared across all the content types because it's always treated the same, right? It means the same to the business every time. So value of separation. You know, you're not accidentally breaking other people's use cases. You know, it's clear in the JSON API and so forth. It avoids overloading meaning. Just a quick one on references. So we've got this. We've got two types of references I want to talk about. We've got related content. It becomes a bit like a bit like a cloud of content and best to just use tags or terms for that, right? Don't use a reference, entity reference field, which you would have heard of. But this one's a bit different. This is a hierarchical reference and you end up making a field either on the page or even on the child to the parent or from the parent to the child. So which one do you do? There's actually value to both of them. So this is what it might look like is I've got a parent field where I'm on some content and I'm just basically describing its parent, its landing page parent, or I'm defining all of the children that live below that, okay? So I've got those two ways of doing this field, this entity reference field. There's just an entity reference field. It's the same type of thing in the database, but one comes from the other, one from one to the other. So in this case, we've got a field child on the landing page and we've got three child pages. And so they're all the same field. Sorry, my fingers. They're all the same field and there's just one, two, three of them. So when you've got a field going from the parent to the child, the value is that you can, the editors can easily out of the box control the order of the children is one big one because they edit the landing page and they've got all the children there and they can drag and drop those around. You can also limit the number of children really easily, right? So you can say there's only over three children, maximum of three. But the other way where you've got a field on a page pointing to a parent, you get this kind of model. And the value of that is you can ensure that no child has more than one parent. And that can be really, really useful if you're designing like breadcrumbs and stuff like that. You don't want to, you want to keep the hierarchy really clean. So you want to make sure that there's no page has more than one parent. And this is a really easy way to do that. And it also can be a preferred, and some of these things are just really about what do you, where do you want the editors to go when they're editing? So think about that. You don't want them to have to jump between two nodes in order to set up their landing page. You want them to have all their pages, create the landing page, do all the children, blah, blah, blah, depends on the workflow. And then just a couple of really quick ones on the difference between paragraphs and embedded content techniques. So the paragraphs concept is where you're actually chunking out your components of content. Something that's really good to say, it really works really well for linear components on a page. And when you start getting into layouts, you really, there's new core ways that are emerging around layouts. So people use paragraphs and they'll create a paragraph type called a container and like three column thing and they'll put things inside it. So paragraphs does work really well if your content is very linear. It works quite well on government sites that don't have like four page news spreads, right? Four column news spreads and stuff. It's content, bit more content, content, content, content. It works well from an editorial experience. It's really good for enforcing structure where you want to control the types of components and things that people are putting on the page and you can really control that structure. You know, like on an event page, you'll never put a call to action, stuff like that. But the downside is the text flow is interrupted. So you've, semantically, the text on this page is the top part and the bit at the bottom and the rest is just, you know, beauty, right? And so in the database, that's been disrupted. It's not, there's not text flow. And so the, using like something like entity embed where you're actually embedding that within the text, it's good from a content modeling point of view because you're not disrupting the text flow. So they're sort of, they're kind of like really key, sort of key differences. There's a really good post that I was going to have by Eaton from Lollabot and Jeff Eaton and he describes this in heaps detail around content flow. So ask me afterwards and I can get that link for you if you're interested. I just want just a couple of really small handy patterns. Be careful on display suite for layout. It's starting to get replaced by Drupal core for layout. Paragraphs for layout, as I said before, be really careful when you start getting into that for a complex. If you're doing content modeling and you're doing your content modeling in the spreadsheet, it's probably going to be a big site, right? If it was a small site, you can probably get away with just making a couple of content types, you're going to be fine. If you are designing your content and you start using paragraphs for layout, you're probably red flagging, okay? Be careful about, like I said before, paragraphs library and as I've been talking to people before, I've had so many ideas around this. Be careful about content types that are just for single use. So you want to have a landing page, so you create a new content type for that and when we go, we often get these sites where we order the site and there's 92 content types, you know? And you look at it and 80% of them are only like one or two nodes, all right? So it's a big, that's a common pattern that Drupal doesn't really scale. I can do it in Drupal, so it must be fine, right? No, not really. So just be aware of other strategies for that. And then at the end of the day, I really like to tell people, like, there's no one way of doing your content modeling in Drupal. You just be really mindful that different scales, different methods work better. And different development teams will be able to follow new emerging features better than other development teams or no developing team, development teams, okay? Patterns that are going out of fashion are still probably going to be valid for four years. So just be really, really, really careful that there is no answer but the answer is paragraphs, okay? Just, I like paragraphs. So are we all okay? No, we're not okay. It's going to still suck. It's going to be hard. We're going to make bad fields and we're going to have to try and rename fields, machine names, which is really hard. But I hope that maybe if you're a developer, you take some of these conversational pieces of wave with you when you're talking to condo people and I hope we all make really cool websites. So thank you. I have a couple of questions. Oh, the timing actually went really well. I was going to have to do that. Thanks. I was wondering if you have a preferred approach to what sort of entity or structure you use for landing pages? My preferred approach for landing pages, I do like the linear paragraphs concept as opposed to the embedded content concept because I would like to, I like the embedded, I like the idea that I could create a landing page, put content on it and then just embed all the things that I want. And I don't feel comfortable with the tools like the CK editor tools completely around doing it that way. I tend to have a paragraphs approach that's linear. You're working on a lot of government sites. It tends to be okay to do that. So I'm really like, I really want the editor to go, here's a chunk of HTML. Here's perhaps like a called action or here's like, you know, related content block or something like that. Here's a chunk of HTML. So the question was in terms of doing that layouts, did you say? So I generally do, yeah, so I generally have been doing paragraphs, but I'm pretty much lining up myself to jump as soon as possible into picking up the core, dribble core layouts, doing the text with embeds. So they keep the flow of the text using any type of embed that I want to. So basically designing those embeds so that they can use like a CK editor to be entering those, then they can switch to the layout and then they can, I'm a big fan of like just distinguishing the content of the page from this peripheral content of the page, right? And making sure that everything that's, I want to be indexed in search or everything that I want to come over an API is part of the node and everything that's visual and not strictly part of that content is using core layout builder. So that's where I'm kind of positioning. But I find for me, because I know how to use, and I think for anyone like you do use what you know. So I know how to set up a nice editing experience of paragraphs. So if it's okay for the net is to be going, I want a chunk of HTML, I want to then do one of these core widgets and then another core widget and then another chunk of HTML, it works really well with the design type of designers that I work with who are doing components. So they'll design a component and doing avoiding like the nightmare of paragraphs and components and stuff. I would love to be able to cover that. Should do a workshop and have a talk. Answer it all. That's where I'm positioning. I was just wondering, do you have a preferred approach or hard and fast rules on managing configuration of shared fields and paragraphs to avoid that dependency? So when it comes to paragraphs, I'm similar to the content types. So I'm trying to keep it really, really like I don't want different things. So an accordion, for example, it's like a title body, title body, title body, title body. And then you get another component which is title body, title body, title body. It's like, how can I just have one paragraph that describes those things in that semantically? And it usually comes down to a HTML concept of a data definition and a data term and a data definition. So I'll try and have a paragraph there and then use like, say, another field where the editor can choose how they want to display it. So that pattern is basically taken to the extreme with modifiers. So Murray would talk about, Murray knows modifiers, I've seen him present on that. So it's the same concept. So I want to, the paragraphs I want to keep saying by semantically understanding the distinct structural types that the paragraphs are. And then reuse, I often actually use a concept of where I'm using like a field underscore content that can have certain paragraphs added to it. And then by, if you can get all that planned up front, because what usually where it goes wrong is if you've got new components coming in and you haven't designed for them in the content model, you really want to try and get 80% of your components known up front. So then you can plan all your paragraphs. If you don't do that, that's where it just gets out of control. Especially if you don't get to be on the project to write and someone else has got to come in and do it. So you'll carefully curated content types. So it's a little bit, yeah. Fully cover the question? Yeah, yeah, I guess. I mean, config it's, at the end of the day, I just export. No, I just, I totally rely on core config, import and export. I realize that, no, I don't want to, I don't want to pick that up and go to another site and do it. I know, I think you can, if you wanted to literally just take a con, like you can take your configuration into another site to a large degree. And like, yeah, but I'll usually just reset it up. I'm always like improving and changing. And there's something else I've spoken to Mari about. It's like, we change all the time. We try and improve that concept. So I don't, I don't use features for that. Now I'm scared. I just want to get a shameless plug in for the entity hierarchy module, which is the mix of the two things that you displayed there. So it's a entity reference field with an extra column for the weight order. And you, you add a parent field to your content types and you reference the parent. When you actually reference the parents, some stuff happens under the covers. So it lets you reorder them. So it adds a reorder children tab to every page. So you get that best of both worlds. But it also stores it in the database in a way so that you can retrieve the whole tree or a subset of the tree in a single SQL query for performance sake. So we're building some pretty fun things around that. We'll probably have a bof about that tomorrow if people want to come talk about it. Because we're doing some fun things like making microsites out of it. And yeah, it's, it's really cool. So shameless plug over. Is it this one, Lee? Yeah, this is something else that I'm woefully sure on this thing is like I had started putting in together a collection of modules and stuff. And yeah, basically like Lee's got some really good patterns around, you know, display suite chains and things like that, which are really cool. So, yep. So that's a call out I've discussed with Lee. It's definitely worth looking at. Anymore? No? Thank you. Cheers.