 Welcome to Semantic Site Architecture. Welcome to Semantic Site Architecture. In Semantic Site Architecture, we're going to talk about how to name things and how to respect the way things are already named. And so because we're talking about semantics, the format is going to be like a dictionary. A lot of the definitions, I got from Drupal.org slash glossary and some of them I got from a dictionary and then a lot of them I just made up so they'll seem really legitimate when they're mixed in with the other ones. My name is Jodi Hamilton. I'm the CTO of ZivTech, which is a Drupal agency in Philadelphia which I've been running for seven years, eight years. I'm a Drupal architect, developer, site builder, trainer, contributor. And the reason I like to do this talk about site building is that I think that site building is sort of treated a lot of times the Drupal community as something for beginners and not treated as something that you could really master and be a professional in. And I feel like because it's sort of easy to get started, a lot of people think, oh yeah, that's just sort of like a baby step, but what's really interesting is DevOps or like some serious back end coding. And to me, I'm really a generalist and I do all of those different things. And what I find in Drupal is that site building is kind of a very important part of Drupal. It's kind of what really makes the architecture of your site and makes the difference between good and bad sites most of the time. And it's really something that we need to be talking about at a higher level instead of just leaving for the beginners. And so the reason I got interested in thinking about semantics with site building is that semantics sort of, when you talk about the semantic web or semantic URLs, semantics really describes a system where you think about meanings and words. And when things make semantic sense, they kind of are really easy to understand. And when they don't make semantic sense, it's like you can kind of never understand them. So I see in a lot of projects where there were bad naming decisions that you can kind of never get past those bad naming decisions. Every time you're on a project and you wonder what this one section means with this strange word that no one understands, I have a very bad memory, so I have to ask the same question every time. If it makes semantic sense, I never have to ask a question. It's just obvious to begin with. So as long as things are making semantic sense, everything is very simple. You don't even realize that there's an issue. I also have this guy, Drew Plippi, which I will get to some of his features in a little bit. So I'm gonna split this talk into two sections, and the first section is about when we as site builders have to do the naming. And the second section is thinking about the names that already exist. So we actually do lots of naming as site builders, and here's just some of the things that we have to name on a regular basis. So, get some sparkles here. So these, we're constantly having to come up with names for things. And if you're leaving this naming up to the most junior person on your team, you're not necessarily going to get great naming. Or if you haven't thought about the fact that the names are actually very important, you might just think, oh, you just write anything in those blanks, and let's move on with things. But they're extremely important. So one of the main things to think about when you're naming something is consistency. So just imagine that you're naming a content type or an image style, or a field, or a view mode, or anything in the, or a view, or anything in the Drupal interface. You wanna pay attention to just regular grammatical consistency that your singular and plurals match whatever else is already there, that you use a consistent case, that your spelling is correct, that your punctuation is consistent, and that your use of abbreviations are consistent. This just makes things look more polished. But also, when things look polished, it gives people the impression that you thought about the naming. And that creates confidence in the people who are looking at this system, because people who don't think about naming, it kinda feels like they're not really thinking too hard about anything. Redundancy is another big problem in naming. So the example here shows somebody added a news content type and they added a description for it, a content type for adding news. You may as well not even add a description if your description doesn't give any additional information. The other way that you see people doing redundant things is the name of their theme, ACME theme. And then you have to use hook theme, ACME theme theme. And their link field is called link field. So it's like field data, link field, link field data. And then they'll make a view called the related content view. So it's a related content view view. You don't need to add redundant data. In fact, it's a problem in naming to put things that are redundant. So like if you had a child, don't name him Roger Child. Just go with Roger. Seems like obviously he's a child. I'm just trying to teach some common sense here. I don't know. People call them ACME theme all the time. Extensibility is a big issue in Drupal. So a lot of times when we're naming things, the really difficult part of the naming is that what you're naming is going to change in the future. So you're actually naming a bucket. So this happens a lot of times with views. It happens with modules, with features. All different types of things like where what they're used for can expand. For example, you might make an image style that you call home page image style. But then next week you realize it would make sense to use that on the news page. So now you're using the home page image style, not on the home page. This happens all the time. But you can prevent that kind of thing from happening by thinking about it more when you're naming it. Because once you have the home page image style on the news page, every single time somebody has to look at that and figure out which image style to use or make some modification, they have to go wait. That's the image style? The home page one? Sure, that's right. It just takes extra time. And if you just name things right, things go so much smoother. So when you're naming something in Drupal, think about not just what you're doing right now, but what you're going to be doing potentially in the future. So this example is that some developer created a module called custom staff page filters. It's a custom module that provides a form alter function. A module is not a function. If you need a module to add a function, great. But don't name it after the single function that it has in it. How about naming it staff, or since it's used on the staff page, or filters, something more general that at least has the possibility, or I mean you would name space it with whatever your project was, but something that at least has the possibility to be able to expand. So like when you're naming features, you would want to name them, say you would name, if your site was called foo, you would have foo news, and foo user, and foo video, instead of just very specific things. Because you're always starting out, you're always, when you start out, you're only adding one thing. But a lot of times you are adding more. Another example of this is, you always find, oh by the way the reason that I have all of these thoughts about why things are so bad, is it like a lot of people in the Dribble community? A lot of my work is rescue sites. So a lot of times people come to me and they say like our site is all screwed up, can you help us? And it's like, yeah this is like a huge disaster from all the way down to how every single thing is named. So there's really no value here at all. So what you'll see all the time is there'll be a view that's called homepage related news. And so you're trying to figure out what, where the view is coming from that outputs the news on the profile pages. And you can't find which view it might be. You finally realize, oh it's just a sub-display of homepage related news, right? You're like well that's super annoying, right? It's like why didn't they just name the view news instead of naming it for such a specific thing? So related to extensibility is malleability. And so this has more to do with the fact that not only do things, not only do you end up adding more to your view and your feature and your module, but you also might change them. So for image styles, it's actually a really nice thing that goes on here. But on the surface of it, the problem is that people name their image styles for the dimensions of the image style. But the dimension of the image style is actually the main thing that you might change. There really is nothing else that you might change in the image style other than the dimensions. So when you name it by the dimensions and then you change the dimensions, you create a problem. But you've set yourself up for that problem at the beginning when you named it that way. It wasn't the change, change is inevitable. The change wasn't the problem. It was the naming at the beginning. But image styles actually found out the default way that they're named is actually a good pattern to follow, which is that the human readable names here include the sizes, but the machine names don't. So the machine names are just like thumbnail, medium and large. And that's another big thing you need to think about in Drupal is actually machine names in a lot of places are more important to name properly than the human readable names because the human readable names a lot of times are easily changed and the machine names aren't. So you can actually be a little bit more specific and less malleable in your human readable name and just be more careful in your machine name. So the reason that all of this naming is so important is because of usability and maintainability. You don't have to worry about usability unless you have humans that are interacting with your website in some way. If you're making websites for other computers, you don't have to worry about it, but for those of us who make them for humans, it's really all about usability and maintainability is really just usability for the other developers and other people who are maintaining the site. So it actually is a usability concern because not only is it the public who is looking at the site, it's also the editors that are maintaining the site and it's also other software developers that are maintaining the site. And so when you make a system where everything is named well, it almost by definition is more usable for the staff that's using it because they don't have to go look up some manual where you wrote in what all these different things mean and which node queue it is that you have to change when you do this. Like everything just kind of looks more obvious and that's really the point. It's like making a system that's so intuitive and obvious that they don't even really realize all the value that you put into it and they don't never occurs to them that they should ask for documentation because it seems obvious. So actually, I think it's sort of, you wouldn't really expect that everybody on your team would be able to make really good naming decisions that are consistent with each other and make them every single time they have to do some site building and never have a problem and consistently use the same voice in all of their help texts. All of that is kind of not very realistic. So what I do instead of relying on everyone on my team of making the good naming decisions is to make an architecture plan for what the site building is going to be and how everything needs to be named ahead of time because it really emphasizes how important the naming and the help texts and all of that text actually is. So the architecture plan that I use, I actually got from Palantir and you can go to this blog post. There's a Palantir blog post about developing Drupal site to plan or perish. So my little assistant is going to show the template. Boo, no, okay. So here is my template. It's just slightly altered from the Palantir one. And the nice thing about this is it shows you, it has blanks where you have to think about the naming things. And it's much better to think about all of your naming at the same time while you're mentally on this naming track than to have to like keep on switching back into that mode. And it also makes it much easier to keep everything consistent when you see it all next to each other. So you can, these are just like some example things that are in there to begin with, but it focuses on human readable and machine name. It has help text. It shows which fields are in there but it has an additional section for fields because fields could be reused between different bundles and different entity types. So it also has this tab just for fields where you can put in what the help text is going to be. It's a lot faster to get all your help text in at the beginning than to just let somebody build the system and then gradually you get QA feedback to change this help text and that help text. View modes here. I'll talk about view modes in the next section. You can have flags that you name. Node queues get named, image styles, whole bunch of stuff, vocabularies, field collections, views. So this can take in user roles. So this can take maybe 10 hours for a complicated site to fill this out. It might take longer if there's discovery that's going on as part of figuring out what goes in here but it will definitely save more time than that. When people actually go to build the site from this, they can build it out really fast. Okay, so my second part is thinking about the names that already exist in Drupal. And thinking about the way things are named and what those meanings are really helps you to slow down when you're making architectural decisions and to really give more thought to what's gonna be obvious and what's gonna be intuitive and what's gonna be the simplest way to architect something because architecting something is about making it so simple that nobody has to ask you questions about it later. It's not about, look at this crazy fangled thing I made that nobody else could have possibly come up with. That's not good architecture. So the first word I wanna talk about in Drupal is entity, which is sort of like an alien entity. So an entity is any defined chunk of data in Drupal and this is sort of one of those like non words. Like in Philly, we have a word John and it just means whatever, anything can be a John, anything could be an entity. It's not a great choice of words. The only thing that I kind of like about the word entity is that it sort of seems to describe a being. So it's like these entities in Drupal, they're sort of like the most important citizens of your site, like they have a sort of lifelike situation. You know something's an entity in Drupal if it has the manage fields tab and display fields tab, although it is possible to have entity types that aren't fieldable. One of the problems with the word entity in the Drupal world is sometimes people are not clear whether they're talking about an entity or an entity type. So a node is an entity type. A node is an instance of an entity type so it's actually an entity. But sometimes people say entity and they really mean entity type and that to me creates a lot of confusion until you know that people just use them interchangeably, which is kind of annoying. Like one time I did a discovery on a project and in the discovery meeting I asked the client, I said in all these documents that you gave us it seems like there's a couple different things that you use the same word for. So what actually does that word mean? Does it mean this or does it mean that? And he says, well in the documents if somebody else wrote them or if you're talking to anyone else on my team it means this, but when I'm talking or if I wrote the document it means that. So you just need to reverse it in your head when you're talking to me. And I said like okay, I mean that was kind of the end of that project for me because obviously someone who thinks that way is getting to be a problem for the entire project because it makes no sense. So anyway, the next thing I'm gonna talk about is a content type which in a developer terminology would be a bundle of the node entity. Oh, see, I just made the same mistake I was just complaining about. It's a bundle of the node entity type or it's a type of content. You can also think of it as a set of fields and other settings appropriate to a set of site content. The most important word in content type is content. Do not use a content type if it's not a type of content. That's a super common thing that people do in Drupal. They did it even more in earlier versions of Drupal because there were no other entity types. So the only thing that was really fieldable were nodes. And there's still some carryover to that kind of sentiment that hey, if I'm trying to make some type of form for people to add data into, I'll just make a content type. Well, that's really problematic. So I see this kind of stuff all the time. So yesterday I was at a talk where they were talking about content staging and in order to make a new content staging environment, like you could have live and you can have editorial, in order to make a new staging branch, you would just add a new node of the type branch. But a branch isn't a type of content. It's a completely separate idea from a type of content. And so now when somebody goes to node add and they try to figure out what type of content they should be adding, they see these choices in there that aren't even types of content. It kind of makes you be like, I don't really understand. I thought I was adding a type of content, but now there's all these other weird things that are just Drupal things that are in the list. It creates just a strange feeling. And there's really no reason other than laziness and not believing that it's really a big deal to function that way because you can always create a new entity type using entity API. You can find some instructions and examples that you can copy and have your own entity type that you could just call the branch entity type and have like a separate UI for that. Okay, so node obviously is like the most useful, common Drupal term. We actually had a client that makes folding bikes. They're called Tern and they have, I saw one of their bikes down the street and it's called the node D7. Now it's like, wow, they really are super into Drupal now. But yeah, you can actually buy this node D7. It's a cool bike. So the word node is almost like one of those non-words again. These are a couple definitions. One is a regular definition of a node, the number three, a point at which lines or pathways intersect that comes from the Oxford dictionary, essential or connecting point. And I think that definition is interesting because sort of the whole point of nodes and of having a content management system is this connecting nature between content and between users and between like other entities on your site. So you can almost think of these entities as these beings who are connecting to each other in this web. So when you have a node, it automatically is connected to an author which is a user entity and it might be connected to some taxonomy term entities that it references and it might be connected to some other nodes that it has an entity reference toward. It might be part of a node queue or it might be part of an organic group and an organic group is actually another entity type. So there are all these connections between things and that's one of the things that you see a lot of times on good Drupal projects is that it highlights the connections between content and between people because that's not something that you could easily do on in a lot of systems because they're not as well structured. So just like a content type, I don't think that people should use nodes where they are not adding a piece of content. A node is a piece of content. And I see people who have been site builders in Drupal for six years or more and they're shocked to find out that there are other ways to add pages to Drupal than to just add a node. That's sort of like the beginner's hammer is you wanna add a page to Drupal, so just add a node. Well, there's a lot of a page. It doesn't say that the definition of a node is a web page on your website. It's a piece of content. If you're not trying to add a piece of content that has a title and probably other fields, then there are other ways to add pages to the site. So one way is you could make a custom page with hook menu. Another way is to get into page manager and panels, which just lets you make kind of arbitrary pages instead of just shoving a whole bunch of picky HTML into a node and then hoping that nobody has to edit that. So view modes are pretty nice. Does anybody use display suite in here? How about entity view mode? Pretty good split. So I kind of understand why people like display suite, but to me it's just like the last thing I kind of want in my life is more Drupal settings. But entity view mode is kind of a similar idea, but there's less to it. Like all you can do is create additional view modes for your entity types. And these are super nice to use because although they're hard to name for, you have to really plan out the names of things for these view modes. So sometimes I'll name a view mode mini or I'll name one search result or I'll name one micro and then of course you have full. And then you can set up these view modes or display modes for all your different content types. And then when you use, and then when someone says that they want a new view on the bio pages that shows all of their related content, you can make that super fast because you can just tell it to display all of the mini view modes for all the different content types. Now you don't have to do a lot of fussy styling to figure out, yeah, the events need to show the date differently and they need to all show the thumbnail this size. It just becomes a lot faster to set things up and also to make changes where everything still looks consistent. So one of the naming tricks I like to do with view modes is I like to use similar names in view modes as in image styles. So if I have an image style that's called, or if I have a view mode that's called mini, then I might have an image style that's also called mini. And then it'll be very clear that the mini image style is used in the mini view mode because it's really easy to have a bunch of image styles that are like thumbnail, thumbnail one, smaller thumbnail. And then you have these view modes that you have tons of those too. And then somebody asks you, okay, it seems like on this site, the image styles aren't all what they were in the designs. There seems like some things are off and now you have to go on this huge mission to figure out for every view which image style they use and which image style they should have used. And none of this will happen if you keep things straight from the beginning. Role is another thing that people misuse not quite as often as content types, but that obviously there's a meaning to the word role. It's the part that someone plays in a situation. So if you're just trying to group users, don't use a role. Like I see a lot of times that people, there's some reason that they need to group users. There's something that they wanna do with just those users, but those users don't have any different permissions on the permissions list. And the entire purpose of roles in Drupal is which permissions they have. So you can find other ways to group users if that's what you're trying to do. Because the last thing you need is more roles on that permissions page. Okay, I wanted to show you what happens if you have too many roles on the permissions page. You can get my permissions fabric or you can also get wallpaper. And that'll remind you what will happen to you if you get too many roles that you didn't need. So one time I had a client, they had a role that was called like James' role for their boss. Obviously it's not the name of a role, but James' role was just that it would only have permissions that had names that seemed like administrative, but really didn't give her any power. So she would kind of feel like she could see the dashboards and things like that, but then she couldn't actually do anything. But yeah, I don't think you, I just think a lot of times when you, if you set this line at no, I'm not going to name things badly. That means no, I'm not gonna have James' role. And that means I'm gonna have to actually deal with the real issue, which is that we wanna fire Jane. Like if you set a boundary somewhere, then it can force you to do things the right way instead of working around them. Paths and breadcrumbs, kind of interesting in the Drupal world, I've always been amazed at how poorly Drupal core handles paths and breadcrumbs over the years, but I will teach you a work around. So a path, we use it to mean a URL alias. And weirdly in Drupal, we have a lot of these terms like that where there's like a developer term and then there's like the, I don't know, more human readable term. So URL alias and path mean the same thing and node and content mean the same thing and the interface isn't always consistent about showing one or another at different points. So path obviously is like a trail that people walk on. And so when you think about that our URL aliases are paths that people would walk on, then it makes you think that they are sort of supposed to be navigating you somehow, that you should perhaps be able to take away part of the path and be back somewhere else. And then a breadcrumb is a very similar idea. It's something that you throw onto the path, I guess, or no, it's something that you use if you don't have a path. It's like a make do path, I guess. But the breadcrumbs in Drupal are, or on any website, are those usually kind of towards the top and they kind of show the levels above where you are. And both of these concepts, they're very much the same. And so I really believe that you should have paths that are sort of hackable. So even though Drupal doesn't actually have a directory structure of pages in it, although a lot of clients seem to still have that as their mental model, that's actually not a bad thing that a lot of people have that as their mental model. Because that's, like, having files that are inside of directories is a model that everyone kind of understands in terms of computing or even just filing things. So we want to make our paths, even though we are now responsible for the paths like they're sort of, they can be whatever you want, we want to stick to that and we want to make it a path that actually would lead somewhere if you took away parts of it, that there were actual real places within that path that you could go to. And a breadcrumb, I feel, should be exactly the same as the path. Of course, it won't have hyphens in it where there were spaces, but both of them should represent the same exact tree and that tree should be the menu that you're in. And so they should say the same thing. And so I'll show you how I get, you would think that Drupal would kind of be able to handle that, but it doesn't really do that for you out of the box. So I'll show you a couple things that you can do to make that work. Here we go. Okay, so yeah, so I have, yes, it's crazily enough. I have, Drew Plippi actually is, he'll will pop up on your site as well. There's like a service you can subscribe to. It's really, I just, I wouldn't recommend doing it. It's more like, I just like to pretend like somebody someday would do that. But you can actually subscribe at drewplippy.com and you can get my advice that pops up right when you're naming things. But it's really supposed to be more like jokes but they're just not funny. So anyway, if you wanna get the perfect paths and breadcrumbs, my advice is set up your default path pattern to be node menu link parents join path slash node title. And what that'll do is put the path based on the menu position. So if the page is in a menu, it'll match the path to where it is in that tree. So you're kind of keeping the path based on the menu. And then for other content types, you might have more specific things. So I'll show you on a real site. So for this site, that's the default that we're gonna base it on the menu. But of course, lots of things don't go directly in the menu. So if it's a specific type of type, a content type, like event, we might say, okay, all the events go under news events events. And very careful that these are all real places. So news dash events is a real place and so is news dash events slash events. So usually these landing pages are plural that might be a view that's above. So you have to make sure that it matches. So now you have your menus consistent with your paths. And then the next thing I do is I've tried like every possible combination of Drupal module, Drupal modules for breadcrumbs and paths and stuff. That one's not set up very well, let me see this one. So I finally decided that the one I like is this breadcrumbs by path. And so what breadcrumbs by path does, and it doesn't really take any setup, you can just turn it on. It just figures out if there are pages that match what's in the path, then it just puts them in the breadcrumb. And you can exclude certain pages, so exclude admin and things that just don't work very well like that. And so that way your pages are based on the menu position and the breadcrumb, the paths are based on the menu position and the breadcrumbs are based on the paths. So now everything's kind of together. So I can show you how that ends up. So if I go to research centers, I'm at research slash research centers and here I'm also at research slash research centers. So the breadcrumb matches just all anybody ever wanted. And then here I'm at research research center so I can actually go back up the breadcrumb and I can also do the same thing in the path. Seems like not a big deal, but it's been years of suffering. Okay, so resourcefulness, I think a lot of times when people are fairly new to Drupal site building, they see resourcefulness as a value. But Drupal code is not a finite value. So really being resourceful kind of just makes things into a frankincite just because you know how to make content types, you know how to make nodes and rolls does not mean that you should be making more content types and nodes and rolls. Like you should take the extra time to try to figure out what's the better way to do this rather than only using the tools that you know and just trying to cobble some strange thing together with those tools. You can always just ask an IRC or your Drupal Meetup or someone that you know that would have that answer and they can tell you some advice really quickly and you can learn something but just kind of like trying to put one of the tools people used to use very creatively in Drupal was taxonomy. They don't do it quite as much in Drupal 7 as it used to be because it used to be that taxonomy was like the best part about Drupal and you could use it for access control or you could use it for grouping things and all kinds of strange ways or you could use it as your navigation and they're all these weird modules and some of them are still out there and I can't complain too much because I just endorse breadcrumbs by path which is two Drupal words in the module name but I kind of have a beef with modules or you kind of have to be suspicious with modules that have two Drupal words in the name like comment node taxonomy access workflow content like there's so many Drupal modules like that and a lot of times what they're doing is they're taking two different concepts and trying to munch them up in some weird way and the result is not necessarily that great. Content profile and then there's like endless workarounds like oh content profile isn't working with CAPTCHA or content profile isn't working with search or there's always like a million like side issues when you try to do something weird like that. Okay so then what happens is regret. So basically the real issue with this naming and the reason that I make such a big deal about it is that it's really difficult to fix it. It takes a second to not really think about it and just go ahead and make a sloppy decision. It could take a week to undo that decision right? So like the amount of effort that it takes to get it right at the beginning is so much smaller than the undoing like it's like you can't fix the problem at the level that you created it on. Like once you have made this mess now they're gonna eventually have to hire some expert to clean it up because they're gonna have to say oh my gosh look we have five different content types for BIOS and then you say okay well could we maybe get rid of BioTest to be deleted? They say oh I'm not sure. I don't think we can and I say well can we merge BIOS 2013 with BioBlurbs 14 and just call it BIOS maybe we could merge all of these? And they'll say oh I don't know I mean I think there was a reason why they were made differently. Cause nobody remembers and everybody's afraid to lose something that was important. So now I have to go on some huge hunt and explain how each content type is used everywhere on the site and what the differences are and which fields aren't used and which ones no one had permission to make and which ones don't have any nodes in them and finally make a plan for which ones I'm gonna delete and which ones I'm gonna merge and I have to write a script and I have to make new fields so that everything will fit together and go through all the content to make sure that we can get rid of this field and then we have to make a deployment script and move everything over. It's a big project so in fact it would be it's almost always less money to just rebuild a site like this because when you see something like this the guy and I say guy because I'm a sexist the guy that made this like this wasn't the only thing he made he touched every part of this site right? So if it takes a week or two to clean this up where is it gonna end right? So when you see this you know it's not gonna get better but they don't wanna throw it away so they're gonna sink good money after bad and so I do a lot of these site cleanups and I guess I'm trying to turn the bitterness into action of saying hey everyone let's do a better job from the beginning. Let's not just name these things anywhere it's really easy to type text into these fields it's really easy to add a content type it's really easy to add a role but the hard part is not putting the text in and hitting submit the hard part is doing it well so that it's maintainable and it actually has value because a lot of these clients or even if it's for your own site they've been through one bad site after another let's give them a platform where they can actually keep this for a long time and they can upgrade it and they can use this as a base where they're gonna stay on Drupal and they're gonna say okay with the Drupal 7 site it's like really great I'm gonna eventually update it to Drupal 8 and maybe we'll keep our organization on this forever but why would they want to keep it on there forever if it was just kind of all put together with like tape and silly punny. So one of the other ways beyond the architecture plan that at my organization that I try to make sure that things like this naming and quality site building actually happen every time is through having quality standards. So before I came to Drupal I was a chemist and I was like a QA like quality chemist and we had a lot of quality chemists because we were in pharmaceuticals so our whole job was just quality and then when I came to web development it was kind of like wow is quality not a thing that we're worried about because it seems like a problem. I mean it seems like a serious problem but when we come to these Drupal clients it's not like we don't have a quality track it's not like a major thing that people are talking about it's just something we just have the PMs worry about they'll go do like some QA with the clients and it's like oh we'll just have them do it and then we'll make some fixes. Quality is so important it kind of baffles me. So what I do the main way that I set quality standards and there's a lot of ways but the most useful I think for our team has been code review and we extend code review to every site building task so if somebody were to do something that was not a good naming decision it would immediately come to someone else for code review and they would say whoa that was a bad name what are you gonna do when we use that view for something other than that why don't you name it this and when you change the name right away in the development process it's not hard to change because they haven't added lots of content and you haven't forgotten why things were that way so if you catch things early on it's not a big problem. So that is it for my talk. You should go to drewplippy.com if you want to subscribe to drewplippy but don't really do that because it's actually pretty stupid. So yeah any questions? You have to go to the mic sorry. Yeah we have in Drupal core we have basic pages. Is that a good semantic words if you say it's about content? I mean I think that's okay I mean you are gonna have certain pages on your site like the about page is gonna be a basic page I don't sure that the word basic is necessary seems kind of a little bit confusing but on some projects we have multiple types of general pages so we'll have like a basic page and then we'll have a landing page and the landing page might be a fancier setup and the basic page might just be like oh it's just gonna basically just be text. So in that case it's okay but if it's I don't know I guess I would slightly prefer if it was just called page. Basic part seems to just leave you wondering what the advanced page is which doesn't exist. With the separate content types for very kind of quite similar things would you advocate for having content types that would have lots and lots of fields on them and then use something like conditional fields to show and hide them on the form depending on something rather than lots of different types? Yeah that's a good question. There's definitely a gray area there where you have to make a judgment call of whether something should be two content types or one and how similar the fields really are but sometimes if you start off thinking oh well I need some conditional fields it might be more likely that in the future you need even more than that you need less. So you might be starting yourself down a tough path when you make that decision at the beginning because you kind of already know that they sort of are two content types if they are being displayed in different places and the fields are different so usually I would split that into two content types but one thing that I do is if multiple content types use a bunch of fields that are in common with them. So for example I did a project where they had a bunch of different types of events and the events had very different fields but they all had this core group of fields like they all had the location and the time and some disclaimer text and the contact person. So then I put all of those fields that were in common into a field collection and then just added that as one field to all the content types because that way if I needed to change anything in those fields I only had to change it once and it would just pick up on all of them and I could trust that they would always be consistent and not have to worry about that so. Thank you. Okay thanks everybody. Oh sorry, sorry bonus question. Next to naming conventions for fields do you also have guidelines or use standards for the order of the fields? Yeah in terms of ordering the fields I try to do it sort of put yourself in the mindset of the person who's filling out the form as much as you can and also I like to put in general I like to put the smaller fields at the top because I think if you put a giant body field and then like a little text field underneath it that it kind of gets lost visually but if there's some kind of strategy to what order would make sense as you fill it out then that would be more important. And what about changing interface text in the back end to be more meaningful for example a save button or some buttons that are not always clear? Is that often done? Yes so sometimes you mean like just like using like a string override to change some text in the back end? Yeah it depends on how much your clients are using that back end. So no, most of our clients aren't doing much more than editing content. Thanks everyone.