 go ahead and get started and let a few of the stragglers from lunch come in as we get going. So if you're in the back of the room and having trouble seeing the slides, or you just want to jot this down for later to refer back to, the slides are available on GitHub. If you hit that URL, you'll be able to see the same version, hopefully the same version of the slides I've got here unless I forgot to push my last changes up. So about me, I've been building Drupal sites for just about eight years. I actually have an interesting story in that I didn't do it as a hobby beforehand. I actually showed up for the first day at a job and they said, we just standardized on Drupal and your first task is to learn Drupal. So eight years ago I started building professional websites on Drupal and I've been doing it pretty much ever since. Right now I'm the director of engineering at chapter three, so I've got a big team of developers and I manage those guys, talk a lot about Drupal sites, spend less time writing code these days, but try to do some patches when I can. And if you want to get in touch with me, mark at chapter three and I'm MRF on both Twitter and Drupal.org and probably message me on Twitter, you'll get a quicker response than if you email me. So to start out with a little bit of a controversial statement, everything you do about Drupal is wrong. And Drupal is not a content management system despite everything you've heard, everything you've read, everything you've seen, Drupal is not a content management system. So Drupal is a piece of software, like that's pretty fundamental, I think we can agree on that. But what it is, it's a piece of software for building content management systems. So you know that first time you go to Drupal.org, you click this link, you think you're getting a fully functional content management system that's going to solve all your needs. And what you're actually getting is a starting point. Like you've got to start building your own content management system. It does probably very little of what you need from that download and install step. So congratulations. You just became a software developer, whether you really wanted to or not. Question? Close? Okay, that's loud. We'll do the opposite. I'll move the microphone away. Is that better? Okay, we'll go 50-50. So we've got a room full of software developers and you can become a software developer now without writing a line of code. So with that kind of under our belts, you know, that's sort of the philosophy of the rest of this talk. So software developers think a lot about complexity. So what do we mean by complexity? So as all IT professionals, you know, love Dilbert, we're going to find out about complexity from Dilbert. So he came up with a really complicated project plan and, you know, he knows when he's talking to management that, you know, they're not going to be able to take his project plan in stride and, you know, of course they're going to just move up the deadline when they see how complex the working needs to complete is. So we all have to deal with complexity. It doesn't matter whether or not we write software or we're just a Drupal administrator's complexity is part of our lives. And so when it comes to the world of site building, complexity comes from a lot of different places. And it's not always clear where that complexity is going to be coming from. So what I did to try to get, just wrap my head around what makes a Drupal site complex, but I didn't really want to go into any, you know, customer's projects, you know, and throw those up on the slide. They might not be too happy about that. So I went to three of the more popular Drupal distributions and tried to do some comparisons, you know, from the command line to see what makes these complex or more complex or less complex. And so OpenATrium seemed to top the charts in all measures. So file count is where I started. Now, whether or not file count makes something more or less complex, it really depends on how much code you put in each one of those files and what each one of those files is doing. But, you know, setting all that aside, 8,000 files is a lot more than 1,000 files. If I wanted to step through everything OpenATrium is doing, it would take me eight times longer than it would take for me to step through everything that Drupal by itself is doing. And so, Monopoly falls somewhere in the middle there in terms of the file count measure. This is probably a little bit more accurate for the site builders in terms of how complex the site you're going to be getting when you install this CIS show is going to be. So with OpenATrium, just run the install and you have 210 modules enabled. As compared with Drupal 7, if you run the basic install in Drupal 7, you have 33 modules enabled. And once again, Monopoly falls right in the middle with 117 modules enabled. So I don't know about the rest of you, but I might know what a good majority of those 210 modules do, but there's a good chance that each one of those modules does something I'm not expecting in a way that I'm not expecting it. So when you start with an OpenATrium site, you have a lot more complexity there. And so, another way you can measure complexity is this is from OpenATrium's install page. And so, in the install requirements, it's saying your PHP memory limit, you should probably double that before you even install OpenATrium and maximum allowed packet size for my SQL. We'll probably double that as well. And, you know, your max execution time, I don't know what the default is, but I don't think it's 60 seconds. So we're going to bump that as well. And so what this is telling you is, like, we actually got some weight with those modules and with that file account. Like, all of a sudden our CMS is doing a whole lot more and a whole lot is happening at every request that wasn't happening before because Drupal's base install requirements are, I think you can do 128 megabytes of PHP. The packet size, I've never had to increase that for a Drupal, a plain Drupal 7 site. And the max execution time could be much lower. So we already know our, a lot more magic is happening. We're not sure what that magic is until we start clicking around OpenATrium, but that site is, inarguably, more complex than a plain install Drupal 7. So how do we get there when we're building our own sites? Like, how do we avoid creating our own copy of OpenATrium? You know, there's years of time invested in making sure all that stuff works together. So when we're building our own custom Drupal site, like, how do we avoid creating that kind of complexity? And so the architecture of the site is where we avoid this. So, you know, everybody goes into every project with good intentions. This comic illustrates it really well. You know, it's best of intentions. This time it's going to be perfect. I'm not going to make the same bad decisions I did last time, but requirements come in, deadlines creep up, and all of a sudden you end up with, you know, something that's, it's a usable house. Like, you can do lots of things in it, but it's probably not what you had in mind when you started working. And so, so in the world of site building, this happens when you're picking modules. So this is when you start to build that ladder, you know, build that next section of that house. Like, every time you download a module, you're bolting on another feature to your site, whether you needed it or not. So how do you go about picking good modules? And how do you go about picking as few modules as you need? So I actually borrowed this from a presentation I did a number of years back just saying, how do you interact in Drupal contrib space? And so there's a lot of information on that project's module page that you can decipher to kind of make your module decision. So this is from Views. And we all know Views is an extremely healthy project. And the way we can tell it's a healthy project is three hours ago, DeVayner was making commits, and he's made 2,000, over 2,000 commits in the five years he's been working on it. And not only is he been working on it, but we also have hundreds of commits, thousands of commits from other, other maintainers. So this, to me, says this is a very healthy project. This is bug-free or very bug, you know, very few bugs in this code. And I can probably guarantee that if they find something critical, it's going to be fixed soon because people are actively working on it. Another way to find out information on the Drupal project page is look at the number of installs and then the maintenance status. So they want more help. It's obvious from this page that there's a whole lot of work going on. So there's probably an infinite number of help, the amount of help they could get and still need more help. But the development status is under active development, which means they're not, they're still adding new features, they're still fixing things, they're still working on this project. And we can tell it's been installed a whole lot of times and that number would not have grown as large as it did if it wasn't working well for a lot of people. So that's a pretty healthy module that we can add to our stack and the complexity is probably worth bringing along. Another thing to look at is how often a release is coming out. How many releases, like have they been working on this thing since Drupal 6? Or did they just start working on it for Drupal 8? There's a lot of good information on this page as well in terms of the health of the module you're adding to your stack. So this is where we come to special cases. I was just showing the information for views. There's a lot of modules and the second you download and install them, your site, it just folded on a whole new section. The minute you turn that module on. So we're going to go through some of those special cases right now. So my favorite from this list is panels. So I started spreading this rumor and I don't know if it's made its way around the Drupal community, but panels was actually a fork of Drupal. We just never called it a fork of Drupal because it was done as a contrib module and nobody knew the difference. But it has its own display layer. It has a new structure that replaces blocks. It has visibility rules that don't have really anything to do with the rest of Drupal Core. And if you look at all those things together, it's like, well, we replaced huge chunks of Drupal with panels and we do it in an entirely different way. So you add panels to your site. All of a sudden you have this forking complexity. Is it done with Drupal Core? Is it done the panel's way? Is it done on these three pages of the panel's way? And is it done with Drupal Core on these three pages? And all of a sudden that has to be picked apart by the next person working on the site. So I would say of any module you add to your site, panels can probably, it can add a lot of complexity. But if you use it carefully, you can manage that really well. It's an extremely powerful tool for the exact same reasons why it adds a ton of complexity. So display suite it's guilty of the same thing as panels in a slightly less manner, which is that it takes over what usually happens in the theme layer, what usually happens in a module file or, you know, in an HTML, a chunk of HTML in your template. And what display suite does, it says that probably wants to get managed in the CMS itself. So then all of a sudden you have two places to check. Is this happening in display suite? Is this happening in my theme layer? Is this happening in my display suite theme layer and panels if we decided to go with the display suite panel's combination? And so every time we add a layer, you know, we're adding a new section to that house that we had in that first picture. So what you want to do is be really careful about every layer that you add. Is display suite offering something valuable to the people working on this site? Do they not know how to code in having a UI? Is that extremely valuable to the people I'm delivering this site to? So you need to start thinking of each feature in terms of does this bring value or does it only add complexity? Like, you know, what is this feature bringing to me? So views. You know, I just showed you it was a really well maintained module. It's a really stable module. But it also has its own rules for what gets displayed and how it gets displayed. So it suffers from the same issues that display suite does. Whereas am I within the views UI changing the output of a field instead of using a template to change the output of a field? You can do that with views and a lot of people do do that with views. Am I doing it consistently in views or only sometimes in views? So you need to think in terms of that I have this layer of complexity, do I want to use it? A lot of modules bring layers of complexity that you don't have to use. You can just use it for what it does best and not focus on the complexity. Domain access probably escalates this to a whole different level. How many people here have used this module? So what this allows you to do is build a Drupal site within your Drupal site. So all of a sudden you have another potential complexity which is which site does this feature apply to and how does this feature apply on this individual site? So it is this content type available on this site as well as this site. When I change a field on that content type does it change the field on both those sites? On all eight of those sites? On all 16 of those sites? Domain access opens up huge possibilities for setting up a really complex, fragile system. So when you add that to the stack you need to be really careful and deliberate about why did you add this? Why did you architect it this way? Like all those decisions need to be made really deliberately. Organic groups as similar to the ones we just discussed it creates a bunch of access rules. It does it in a really clean core compliant API compliant way but all of a sudden a piece of content is not showing to a particular user and you have a whole chain of things to check before you can figure out why that piece of content is not showing to that particular user. So the question is is this something I could have done with published and unpublished and I added organic groups to try to solve the problem or did the previous developer who was building this site add it to try to solve it is he using this model for the wrong use case? Organic groups is really powerful if you have a social site where there's a lot of different users and they do have access to different levels of content but you can use it on a site that doesn't have that requirement and add complexity without a lot of benefit. So rules, I think rules is probably the most interesting case. Does anybody know what touring complete means? So touring complete means basically any programming language that's touring complete is capable of solving any software problem. So rules is within Drupal and it's touring complete. So I can build any piece of software possible with the rules module because it allows me to do false and true values. So what that means is I have an infinite ability to add complexity to my site with the rules module and you can do all the same things you do in PHP code with the rules module and even without turning on the custom PHP filter within the rules module you can still do a whole lot of unexpected things with the rules module. So I press submit on my content type. I expect it to save the content edits I just made but the rules module can intercept right there and do a dozen other things. A dozen other unexpected things. So introducing the rules module to your site should be done deliberately. It should be I have a requirement that my client needs to go into the UI and be able to change the behavior of things like content submissions. Well rules module is perfect for that. It shouldn't be used as an excuse to avoid writing some clean custom PHP code that does that one condition. Like it shouldn't be used as a fallback for doing things in a much more clean way. So only add it if you need it and your requirements are driving it. So this is what we're trying to avoid as well. It's another image of what we might create if we're not careful. So this is somebody did a scale model of the Homer car from Simpsons so I don't know if anyone's seen this episode but Homer finds his brother who happens to own a car company. He lets him design a car and doesn't check in with him about what he's actually adding to the car. The car is so expensive to build it ends up bankrupting his company. It's got a lot of cool features. I would love a bubble to sit in on the back of my car in a giant horn and a giant spoiler but those aren't all necessary. A much planer car can get you from point A to point B and if that's all we really need you to do is get from point A to point B because we don't need everything this thing brings with us. Next up is data structures. So architecture data structures complexity that's something that software engineers think about all the time. So they spend a lot of time planning before they start writing code and I feel like with site building we suffer that Drush DL and listing out a half dozen modules it's really quick and easy to just start adding complexity really really quickly. So there's a lot of measure twice cut once. There's a lot of just cut cut cut cut cut cut until you have a site that works. Thinking about data structures is another spot where I feel like here is where planning serves you the best. So what do we mean by data structures in Drupal? First of all we have a problem here and it's apparently the hardest problem in computer science so we're not alone in trying to solve this problem because we need to figure out a naming system. Luckily with Drupal and especially Drupal 8 we don't need to worry too much about cache and validation but naming things still is the cross to bear for the site builders in the room and actually more so than the module builders because we're naming a whole lot of things when we're site building. So this is how a site builder thinks about data. They think about adding fields. They think about content types. There's a lot of data structures. Normally in historic software development used to be the developer. The developer was sitting here writing my SQL tables. They were looking at it from this angle which is, is it a long text? They're really thinking about this in a fundamental deep way and we've got check boxes. We've got autocomplete fields. We can add 10 of them in 5 minutes. So we're about 100 miles an hour and we're not sitting here. I mean this is slow to create this so you have to be more deliberate about it just because the process is slow but not so with adding fields and adding content types. So there's a lot of data structures in Drupal and content types is the most important one. So content types has been with us for I don't know. It was there in Drupal 4. That was the first version of Drupal I worked with. I'm guessing content types preceded Drupal 4 by a number of versions as well. And so content types, what we need to think of as we're stacking them up is, do they have a good name? Does that name make sense for now? Does that name continue to make sense in the way that content type gets used over time or should we rename it to make it more clear? Fields. Same rule applies here. Do we want to share fields across content types? Do we want them to have the same name? Do we want to create new unique fields for the content types? Do we want to prefix our field names with that content type name so it's obvious both in the database and in the content type that field when we're adding it from a view we know which content type it belongs to. So as you're adding these things you really need to think deliberately about how the whole system works. A lot of times we fall into that same trap. We're bolting something on here, we're bolting something on here, we're bolting something on down here and there's no sort of overall consistency in terms of what's getting built. Taxonomy as well it can be really complicated or really simple and it helps a lot to have this all figured out before you start building it out. You can fall into the trap where you have two taxonomies on your site have really similar content but they differ by like two or three terms. So you really need to think about the sub-front. You need to name it in a way that makes sense to both the back end content administrator as well as a future site builder that's going to come into the site and try to fix things. Menus as well. We're storing data and we need to think about is each sub-menu going to be broken off into its own menu to support our theme? Does that make the most sense when you're administering that site later on as a site builder? So you really need to think about, deliberately about when you're adding a menu, how you're adding a menu, how the menu is named and how it's stored in the database. So because we have the ability to create these things so quickly, sometimes we don't do it in as a deliberate fashion as we could be doing it. So upstarts. I first did a talk similar to this a couple of years ago and I thought it was funny then to call these modules upstarts but you'll understand why in a minute. So flag and flag-like modules have probably been around for five or six years but they kind of changed the way you were able to build Drupal sites. So in older versions of Drupal, like Drupal 5 and before, content types were really it in terms of places to store things. So people would rely on content types for everything. And all of a sudden in Drupal 7 especially we started to get a lot of other places to store things and modules that could change our storage module. So flag and flag-like modules, what those lie to do is just take an on-off checkbox on that content type. You can do the same thing in a field but what you want to think about is do I need to add another module to do what I can do in a Boolean field? Like maybe not. You need to think about your own site in terms of whether or not that makes sense. Reference fields. We just got a whole other way to complex the indoor site. So we all just need to start thinking about is this content type just a pseudo content type? And does it store data that's only linked to from other content types? And you can go down a huge chain of references that require references that require references and it might take somebody like a couple of hours to unpick all those deep references within your site. So it's another way we need to go into really deliberately and think about the storage and is there a better way to store this? Do I even need to reference this content here or can I just have views do the reference work for me? Field groups is another way to organize content. So it's kind of an alternative to references. It's like maybe these fields can be available on this content type and I don't need to reference them elsewhere. So you should be thinking deliberately about how my content is getting stored, how my content is getting used and what's that going to mean long term for my site? So just to sort of sidetrack for a minute here. A lot of the meat of this presentation came from inheriting a lot of sites and just building a whole lot of sites. At chapter 3 we sometimes launched 2 or 3 sites a month and so there's a lot of ability to experiment and see what works long term, what doesn't work long term. And what we've noticed is every time somebody tries to save a day's worth of work on the site building phase, they created 2 weeks worth of work in the maintenance side. And I didn't always early in my Drupal career get exposed to that because a lot of times I built a site for a client. I said here you go, here's your site and then that was it. I didn't really know long term how easy that site was to maintain or not. And working with distributions, working with modules like panels a lot of times you can work really quickly in the site building phase and that's good for a certain extent, but you need to think in terms of the long term how easy the site is going to be to maintain. So field collections is another one that just spidering complexity once again. Field collections allow you to have an entity that's referenced from your content type. So we don't need to store a separate content type, we're going to just have entities attached to our content types. And this all sounds well and good when you're building the site, when you're clicking check boxes, when you're working really quickly and everything seems to be going smoothly. And then three months down the road somebody says, you know what, we want to translate that site. And you start to realize that the translation interface it doesn't really take field collections into account. Field collections are a new edge case, it's not part of Drupal Core. And so all of a sudden we have one system that doesn't know about another system and we're doing a lot of work to make the two talk to each other. So we save half an hour in the site building phase and we ended up adding three weeks for the work in the bug fixing phase. So you got to think in terms of that, you know, do I really need this module just because it exists, just because Drush DL module name takes me 30 seconds, is it really worth adding it to my site? So another data structure, you know, when you're talking about programming they're always talking about lists. So in Drupal we've got our own way to store lists. Like I said, Drupal purely on the site building side, we could build almost any piece of software if we had enough time and enough people with a high enough pain threshold for clicking checkboxes. But with no cues and draggable views, we can order the content on our site, we can store that order, and then we can use that store to order wherever else we want to on the site. And so once again we have information that's crucial to the display of our site that's stored in a separate data structure. So how we use that data, how it's stored, that's all important and we want to make sure that taking between these two options that we're comfortable with how it's being stored. And second of all, is it really crucially important or with a simple, you know, that promoted field is feeling lonely. It's been there in Drupal forever and people don't always use it when maybe that's all they needed was to promote the one item to the top of the list. We didn't have to add a whole module to add that one feature. I had a co-worker who did a whole presentation about site building smells. So I wanted to give a shout out to this as a way to when you're inheriting a site begin to tell, you know, what kind of site is it and what kind of shape is it in. This comes from code smells. When people do code reviews, they talk about code smells. So it's like, it's this like tingle you get on the back of your neck when you're reading through the code and you're like something's wrong here, you know, there's something wrong in the universe and you start to get this sense of like it's not quite right and so this is people trying to put their thumb on it. Like this is what made me uncomfortable. This is what made me start to question the quality of this code. And so I've got some things that allow you to do that when you're inheriting a site as well. So these come straight from our site audit. We do a lot of site audits on new customers we're bringing on at Chapter 3 and so these questions come straight from our site audit and we try to use these to get like a flag of this needs more attention, we need to dig in more here and figure out what's going on. So the number of vocabularies like if I see a site with 50 vocabularies I'm going to start asking a lot of questions really quickly. Like what is so crucial that it needs to be powered by taxonomy in here or did this person not even know that content types existed and they used taxonomy for everything. So you've got to start asking a lot of questions if there's a huge number of vocabularies and then you start looking into them and you realize this has the same content as this other one. Did they just recreate this one because they didn't know how to reference the other one? Like if you start seeing a big complexity and a big number it's like you've got to start asking questions. With content types the same kind of questions apply. So how many individual content types are there? If I see a list of 50 or 60 content types that's usually a big head scratcher. Like most Drupal sites I've seen can get by with like 10 to 20 and sometimes you can get by with a lot less than that. And then when you go into the content type does it have 50 fields on a single content type? Are they using a module that controls access to those fields instead of just separating those objects to separate content types? Did the lines between the content types make sense? Like a lot of times when you go in you're auditing the site, you go into the database, you realize that only two copies of a lot of content types, like only two nodes were ever created for that content type. So it's like did that content type just, was it a relic of when somebody was doing some tests during the site building phase of the project? So I'm always asking these questions. It's like why is this here? What purpose does it serve? Is it even displayed anywhere in the site or is it just a relic of developer's past? And then the last one is a lot harder. It's a lot more opinion. And that's the thing about this whole presentation. There's a lot of strong opinion here. Which is that every module I listed in that first special cases section serves a valid purpose on a production site for someone and serves them really well. Otherwise it wouldn't exist. It wouldn't be maintained. It would have died on the vine a long time ago. So this is where you start to ask these big questions. Does it all make sense? Does it seem like it was done deliberately by somebody who was really thinking about what they were doing? Or was it done on accident over three years and ten different developers? And so when you're looking at a site you need to look at whether or not... I'm holding this from scratch today. It's always like, you know, hindsight's always 2020. But you know, is there a way that this could be done better? Is there a way that I can spend two days right now and clean this all up and make it better for the next person? So coming up to the next section, so when your software developer documentation is not optional. You're going to fail your first code review if you didn't provide any documentation with the code that you're writing. And unfortunately for the world of site builders, it seems like documentation kind of is optional. You're not doing standard documentation where you're doing a Word doc that you attach to the site. And there's a lot of opportunities for documentation within Drupal that are also being missed ignored, bypassed. So I'm going to step through some of those right now. So everyone here has probably seen this screen. It's rarely you build a Drupal site and you use the types that are provided to you. So a show of hands, how many people fill out that second massive field on here? So we got like half the room and that's probably based on what I've seen, you know, what you usually get. So you get a nice huge text area here where you could write a novel about what was in your head the moment you click this button and start creating this content type. And a lot of times you're lucky to get one line in here. And you know, the thing is you're not doing this just for the person coming after you. You're not just doing this for your boss when he's going through and reviewing your work. You're doing this for you two days later when you can't even remember which section of the site you were working on and where you left it. Because all of a sudden you know you're tapping into your own brain from the past. And you know the same rules that apply to software development apply here. Whereas great documentation is going to make it a lot clearer when you need to work on it again. And you know every developer that inherits the site after you is going to thank you for taking the 30 seconds to type out a little line of text here. So that's the content type screen. So unfortunately taxonomy gets a little bit of shorter description. You're going to have to wordsmith it a little bit. You can still have a non-optional field. You know this makes me think I should just write a contrib module that makes all of these description fields required. So it's an optional field. I could probably get turned this into a text area as well. That sounds like a good project for the rest of the week. But we can still give a little bit of information here. And we should, anytime we have the option to give a little bit of information we should provide that information. So menus, we get a nice big description field again. But once again it's optional. So we can leave it blank and we can still press submit. And never know what was in the person's head when they were creating that menu. Blocks, we get a tiny description. But this one actually shows up a lot. So on that block listing page this information is hugely important. And if you weren't really careful about your title, which a lot of times on the title it is being shown to the user so you don't have a lot of room for exposition there. So that description might be the only way you can actually explain to the person using the site what this block does. So use it carefully. Make sure it's filled out. Think about yourself when you're going back to the site and you're being asked to disable the block. And you have to click through the configure settings for 10 different blocks to figure out which one to disable. I was joking with a co-worker. I didn't actually know this existed. So I'm just as guilty of this as anybody in this room. So in views buried a level deep on that right hand column is we have a nice big comment section for a view and we can fill that out. And I feel like more than the content types, more than anything else, views a lot of times are real head scratchers in terms of why was this created, what does this do, which section of the site does this apply to, how come this view has multiple displays, how comes there's this other view that seems to do the same thing but it's not used as a display. So views, there's a lot of things you can write about and a lot of information you can provide here, but it's definitely not front and center and super easy to forget except when you're initially creating the view with the builder. So to wrap things up, I'll have some time for questions. Conclusion is we want to add complexity deliberately. So every time we're going, we're clicking, we're finding a new module, we need to do that for a reason. So we're not adding a module, we're not using it distro blindly, we're using it because we want everything that it offers and we're going to use everything that it offers. And we want to name things carefully and this is probably the most important which is those content type names, those block names, those field names. Those, if you're going to not fill out that description, that's the only waypoint the next person has. This was prefixed with that name so it obviously refers to that section of the site. So think about how you're naming things. Have a plan before you start creating things for how you're going to name them. And comment liberally. So every time you see a text area to start typing in it, when you're in the back in a Drupal it's just getting shared, it's not getting shown to the users but you're just leaving notes for yourself, you're leaving notes for the next developer on how the site was built, why the site was built the way it was and what you were thinking, what was going on in your head while all that was happening. So that's it. Any questions? Nope. Alright, thank you for coming out and enjoy the rest of your Drupal time.