 All right, we're at 15 after. Wake everybody up here. Everyone's probably had some lunch and probably a little sleepy right now. It's cold in here though, so that might keep you awake. This is a short talk and this was originally a 45 minute talk that I've made to go into 25 minutes. So we're gonna try to go fast. I also cut out a lot of things that were in here before. So we're gonna just go over some of the things that you shouldn't be doing. So hopefully you're in the right place. This is understanding the dark side. A little louder? Really? Okay. Is that better? No. Wow, I sound really loud up here to me. Is that better? Yes. Wow, okay. I'm gonna have to be, they sound like I'm yelling. All right, so my name is Kristen. I work at Hook 42 and I've been doing Drupal since 2004. So 13 years in April. That's me. So I thought this was a good slide to start with. Drupal is a very complex CMS and kind of dangerous if you don't know what you're doing. So if you got it and you're not really sure what Drupal's all about, you can definitely shoot yourself in the foot. The first section I'm gonna talk about is some general and Drupal specific worst practices in kind of your DevOps and your processes. So some of this stuff might sound super obvious but it's also super important and I've seen it happen time and time again where people forget certain things that seem like, well of course you're gonna have backups. Well it's happened to me. I have the Kristen.org domain name and I thought it would be an interesting learning experience to have a junior developer take that domain at the site and move it from line node to Pantheon is just sort of a learning exercise. Well he contacted me and said, do you have a copy of that code, the code? And I'm like, why? Oh cause I accidentally deleted it. And I'm like, well I haven't touched that site in like five years. It was just sort of it's been there forever. I wasn't really paying attention. And fortunately I had a copy of the code just lying around on my computer. So it was fine but it was like, oh shoot, that was probably not the best idea. So there, you know when you're doing backups make sure you have a copy of the code ideally in a repository like Git. You have a copy of your files and you have a copy of your database. So that's the magic three for Drupal. So this also illustrates a little bit more problem with that website. Now I wasn't really developing it on anymore so it wasn't that big a deal but there wasn't really a development workflow he was just taking stuff from live and trying to plunk it over somewhere else. There was no Git repository, there were no backup. So it kind of illustrates a number of problems. When I talk about development workflow what I'm talking about is you don't change stuff on live. If you've got code, your database and stuff you don't just start manipulating things on live. You're gonna wanna have some sort of development workflow. I've inherited sites where there's no Git, there's no Dev site, the people are just doing stuff on live and that's very dangerous. So you're gonna want at minimum, do your development on local, have at least a development site that the client or whoever needs to see it can see when you push up that code from your local and then after that then you can push it onto live. Now if you have to roll your own if you're on some sort of system like BlackMesh or Linode or something like that then sometimes you're gonna have to roll your own but there are other hosted solutions like Pantheon and Aquia and PlatformSH and things like that where you can use those tools to have a good workflow. Another problem I see is you get this site and there happens to be hundreds and hundreds of errors. No one's been paying attention. They've been going on for months and months and months. There's just errors going on. So having some sort of monitoring of your errors on a regular basis is super important. Something that I like is to use logging and alerts and what it will do is actually email me the errors and believe me that gets really irritating and you'll really wanna fix them super fast. Fortunately I have other people on my team that I have it emailed them now and I am filtering them and not looking at them anymore but someone needs to be looking at those errors every single day and trying to deal with them as fast as possible. Likewise having something like Pingdom or something like New Relic in order to check your speed and your uptime is super important. Another common thing that we see is you get a new project, you inherit a site and then wow, there are 80 modules that have not been updated in forever and this is a bad thing not only for security reasons because there's probably some security updates that need to happen if there's that many but just bug fixes in general, keeping your site healthy and once you have that many it just becomes a very daunting task to try to update all of these in one go because usually if you're gonna try to update 80 at one time it's probably not gonna work so doing them in a more slow cadence of like okay maybe I'm updating two modules a week or depending on the size of your site but just having some sort of cadence so that you're always keeping your stuff up to date. So this is something that I've done on occasion it's an easy one to forget. If you do have your development workflow and you're pushing your stuff up to development and maybe you have a test site or staging and then you push up to live you always if you're using the features modules this tends to be more relevant in Drupal 7 or before some people are using features in Drupal 8 but it's not as needed with all the configuration management available but reverting your features on live and running up DB if you're using Drush or going in the URL and running the update PHP so it's very common for someone to forget that step and all of a sudden they have new modules on their site that have been updated but maybe there was some database changes that were associated with that update and they haven't run the update script in order to make those things happen and things can get kind of wonky. Now if you check your logs you might see some of those problems. Another thing if you are using the features module for Drupal 7 or I mean this would apply to 8 as well but a pretty common thing is if the developer goes on to live and makes some change to a content type which you shouldn't be doing on live or a view or something like that and that information is in features so it's saved in a module then all of a sudden your live site says that your features are overridden and this is kind of a common thing. Maybe there's like some emergency and you have to fix something quick and you're like oh well I have to do it live because you know I just have to do it right the second but I'll get it into features later. You just have to make sure if for some reason you end up doing that you have to do the same change on your local and then push it through your development workflow so that when you push that out all of a sudden everything is back and not overridden and back on track. So these are just some of the things that you can do wrong when you're doing sort of your development processes and workflow. So we'll talk a little bit about documentation. No one likes to do documentation. So one of my pet peeves is I download a contrib module from Drupal.org and there's no readme file and I'm sure everyone's done this right. I immediately go and look for a readme file because I want to know, you know I usually probably know what the module's supposed to do but I might not know like what are the configuration steps or a little bit more about the project. So you can do this with your own custom code as well. If you have custom modules you can create readme files for each of those and that way people will know what it's supposed to do and what configuration is needed or any kind of dependencies on other things, other modules and that sort of thing. We actually have a project that we're doing for my company, Hook 42, where we actually as part of our community contribution is we find modules that don't have readme files and we create a patch with a readme file that has instructions on how to configure the module and then we upload as a patch and try to get those accepted in the community. So that's a great way to be able to contribute to the community with really, I mean you just need to know how to use the module and it's pretty simple to do. So similarly, getting code, especially if someone else's code, even your own code, right? I mean we've all gone back later and looked at our code and was like, what was I trying to do there? Why do I have this weird special case? Do I really need that? I don't know, I don't understand. So for your future self, really awesome to write some comments. I'm in the mind of writing too many comments. I've had comments that are like this long for some complex code and that's okay, right? Because as long as the comments are clear, then that's gonna help somebody, either you or someone else that inherits the code. This is a very, very common issue, patch information. So you can patch, you know, contribute modules, you can patch core, you know, wouldn't normally patch your own custom code because it's your own custom code, right? You would just make the changes. But anytime you're doing patches for core or contribute modules, you really need to track that information and there's so many different ways you can track it, but the most important thing is that you're tracking it. So the way we usually do it is we'll have a directory which is called patches and we'll put, actually I like to have the physical patches myself, it's just a thing. Some people won't, they'll just link off to the issue queue and that kind of thing. But if you have a custom patch, then you'll need to keep track of the patch. So you can have a directory and then a readme file that says, okay, did this patch on this date and this is why and, you know, link off to the issue queue if that's relevant. So this is super important in something that I see a lot that people don't do. If you don't keep track of those and you update your contrib module, you update core and you have three patches and you forgot all about them, boom, you're back to not having that code patched and you can have problems. Just in general, it's sort of obvious, you know, if you name things weird or inconsistent and people aren't gonna necessarily know what you're talking about or you might not remember what you're talking about later. So good naming conventions is obviously important. This is one from the themeers is having a style guide and, you know, it's very common to have a project and there's no style guide and the style guide is useful if you want to show whoever owns the site or whoever's involved in making the site, you know, the designer that, you know, people involved in the design process, what are the things that are possible now with the theme? Like, oh, I can choose from this style or this style or this style and it helps you make things a lot more consistent and this has been a big gap. You'll get a lot more kind of one-off things. Like, oh, can you just do this one? It's sort of like this but something else, whereas if they're actually choosing from an existing style guide, it's much better. This is sort of documentation but just Drupal coding standards in general. The closer that you get to Drupal coding standards when you're doing your code, it'll be easier for other people to consume that information and understand what you're trying to do. I know for me, if I see a lot of weird formatting, like I can't even read the code, right? I'm just distracted by all the formatting. So this is something to help for other developers to be able to read things properly. All right, so we'll talk a little bit about giving too much control to people. PHP filter, don't use it. So you probably heard this before in terms of security talk or whatever, best practices. Time and time again, I see it enabled, I see it being used. People are adding PHP to views or adding PHP to blocks or whatever. Just don't use it. Oop, I skipped. I put them out of order. So another one is I had this one project where they were using a JavaScript injector and the marketing team was just putting whatever JavaScript they wanted just right in there. Like, oh, that looks fine, let's just, bad idea, very, very bad idea. You can use something like Google Tag Manager if you want to let your marketing team use something that's got a little bit more control for them but is a little bit saner in terms of adding things that are kind of vetted and shouldn't hopefully tank the site. So along those lines, just permissive text filters in general, just letting your editors do whatever they want in the text editor. Oh yeah, just unfiltered HTML and just go to town which kind of goes to the next one. Don't just let them put whatever they want inside of the body field or any text field, right? Just going to town and putting everything in there. Or even if you don't let them do the HTML, I've seen the kitchen sink WYSIWYG, right? There's like 50 million buttons there. Why do they need all that? For one, it's confusing but also it's gonna add all sorts of things to your market that I mean, really, do you really need that? So try to figure out what they really, really need. Talk to them. Try to limit them down to just kind of the basics. And this is one of my biggest pet peeves. Do not give them, if you have content editors on your site, if clients on your site, unless they happen to be Drupal developers which happens sometimes, I have worked with other teams where the business owner was a Drupal developer. That is rare, that is the exception. But if otherwise, do not give them admin access. I've seen this so many times where why are you logging in? You can change views. Do you know anything about views? No, I don't know. What are you doing? That doesn't make any sense. You're just giving them the gun, say shoot yourself, getting the lightsaber and cutting themselves up. Likewise, for user one, I know all of the developers here, I'm sure you've logged in as user one, right? So easy, you can dress ULI and just be like, I'm user one, I can do anything. You know, try not to do that. Just because that way if you have your own account and everyone on the team has their own account and there's logging, you can see, oh, so and so did X, awesome. I know I can go talk to so and so. If user one did X, you know, was it Joe or Sarah? I don't know. Like somebody logged in and did something they shouldn't have been doing it. So please, please, if you take one thing away from this, do not let people that shouldn't be admins be admins and don't use user one. All right, so kind of a big last bucket I'm gonna talk about is having too many things. That's a technical term. So one of the things might be just, just having too many architecture things, I'm gonna try that one and try that one and try that one and put them all together and just like, oh, layout, well, I could lay out this one this way and this one that way. So a common one is like, oh, display suite with panels and contacts, sure, I'll just use all the things, right? I'll throw the core blocks in there as well. So think about your architecture, try to minimize, try to standardize and don't go too crazy. Another thing is having too many fields. So try to think, having more fields is a performance problem. I've had sites that's got hundreds and hundreds of fields and sometimes most of them are legitimate but why are there five image fields when really they're all pretty much the same thing? Okay, then have one and reuse that. This is a pretty common one is having too many files at kind of one level, right? So they might just dump them all at the top level or they might have a folder and it's got like thousands and thousands and thousands of files. So you wanna have enough folder structures that you can have a little more sane number of files. You don't wanna have one file per directory but you also don't wanna have many thousands. And when you have files or your backups or things like that, these really big things, do not check them into your repository. Git is great for code and keeping track of that but you do not want to be putting in stuff that's really meant for users to dynamically generate. And just in general, I've seen projects where there's just a gazillion views and you're not even sure which is which and why are these like five things kind of the same? There's ways of consolidating and adding contextual filters or making a different display for certain cases using view modes. You can try to not just copy another one, copy another one, copy another one and do another thing. Try to think of how you can consolidate. And my favorite one here is installing all the modules, right? You get a project and you're like, there are 300 modules on this site. You gotta be kidding me. And I've had that project. I've had more than one of those projects. Like why did they install everything? And there's stuff that was probably not used and if there's no documentation and there's all this stuff and you don't know, you're like, you gotta be kidding me, why did you do that? So that's sad, just don't do that. If you wanna test stuff out, test it out on your local, try it out, decide if you like it or not. If you like it, great, push it through the process. If you decide later you don't really like it, you need to disable it, uninstall it. Very important, uninstall. That's another thing, don't forget to do that. And then until you've done that uninstall process, don't delete it from your code base because if you don't uninstall and you delete it from your code base, then all of a sudden there's nothing to uninstall but all the data is still there and the variables and all that kind of stuff. So that's a bad one. All right, so those are the kind of big four buckets that I have here. But there's one more thing that I wanna talk about which is something called hacking core. And I researched this, why do they call it? They say if you hack core, then you kill a kitten. And I was like, who started that? I don't know, does anyone know who started that phrase? Cause I was trying to find the originator of that phrase and I don't know if this is just a Drupal thing or if other communities use this but it's so sad. But I thought that was like the perfect image. It's like, oh, of course that kitten's just gonna eat that stormtrooper so it's okay. But so you don't wanna hack core. And I've seen it, you get a site from someone and they've hacked core, they didn't document it, they hacked contrib and you're like, I have no idea. And I have a confession, I have hacked core. I started Drupal in 2004, okay, it's a long time ago. I started with Drupal 4.6, I think. I didn't know what I was doing so I wanted to change some stuff so we'll just change the code, right? I mean, that's just how it works. So, but I learned and after that project I learned that was a big no-no, I'm not supposed to do that so I stopped doing it. But you can patch core, even a custom patch as long as you document it, you can patch contrib. If it's something that you think the greater community is gonna want then you should go through Drupal.org and upload the patch and document it. But there are occasions actually where you're like, I just wanna add some logging, I'm getting this weird behavior, I have no idea what's going on. No one wants this patch but I still patch it, I keep track of it, I put it in my patches-readme file and then I know, okay, I made a change, it's just maybe it's a temporary thing, I'm just gonna have it for a while to gather some information and then I'll go from there. So, that's super important. No hacking, gotta save those kittens. All right, and we've all been there. Who's here, who here is kind of new to Drupal? Should have hands, oh, all right, welcome. So, when you're new to Drupal you're gonna do things wrong. And even if you're not new to Drupal you're gonna do things wrong, right? So, if you don't know Drupal or kind of how this whole thing works you're gonna make mistakes just the way it happens. And that's why you're here, right? To learn what's going on. So, just keep calm, use the Drupal force, use the community, come to these presentations and read the blog post and just try to keep up with what's going on because things change all the time. And at that note, I'll open it up for just a couple questions if anyone has anything, there's a mic there. And I went really fast. Yeah, there's a mic because it's being recorded. Or I can relay it, right? Okay, so I'll repeat the question. So, if you're looking for some contrib module and there are 10 of them that seem to do the same thing and you're like, I don't know, which one? So, some of the things I look for, I look how long the module's been around. I look at when it was last updated. So, I look at the development, you know, when it was last developed. So, there's usually a dev version, like when was that last updated. Also, if there's a, you know, official release so when was that less updated. Sometimes the dev versus official release, there could be a gap there. Doesn't necessarily mean that's a bad thing, you still might want to use it. You might want to use the dev version, you know, with caution, but the other thing I look at is the issue queue. Are there a gazillion issues? Is the maintainer like just out to, you know, they've just left and they're not really paying attention. So, those are some of the things that you should look at. And then just Googling and seeing, you know, are people talking more about certain things? One other thing is you can see the usage of modules. So, there's at the bottom, you know, click on usage and get an idea of where it ranks kind of in the grand scheme of all the different modules. Sure. What exactly do you consider core and what is the difference between hacking and tweaking? Yeah, tweaking, yeah. Okay, so core is when you go to Drupal.org and you go to project slash Drupal and you download that, right? That's core. Then all the other projects are all the contrib modules that you can tack on and augment core. It's pretty standard. I mean, there's no project where you only have core. You're gonna have core plus some number of contributed modules. The number is gonna vary. Hopefully not 300, but it's not uncommon to have 100 contrib modules on a D7 site. On D8, I've noticed that that number is going down a bit because there's a lot more built into core. As far as, you know, what types of things you might tweak in core. If it's anything that's really like new functionality, then you should be going either writing a custom module and using either plugins or the hook system and augmenting it that way rather than going in and tweaking core. The only time I would recommend possibly doing a custom core tweak or patch is really, it's like logging or something really super benign. Like you're just trying to collect information. It's so rare that your use case has it where you need to tweak core and it's not something that the greater community would want. If you need that much functionality, you should have a custom module doing it. You shouldn't be messing around with the core code. Okay, well then to quote Emily Latella, nevermind. Sorry? Nevermind. Okay, thanks. I had a question about, you had mentioned JavaScript injection and a red documentation on Drupal and how to set up jQuery using the themes.info. So my question to you is, what do you mean by JavaScript injection? There is actually a module you can have, which of course there's a module for everything. So there's a module called JavaScript JS Injector and it'll just let whoever's got permission to go and do stuff, just put whatever JavaScript they want in there. So I don't recommend that. That's a bad thing and I've seen it happen. So I think that the next speaker should be coming up and start plugging in. If anyone has any more questions, I'll be around the rest of the Drupal con. So feel free to come up and ping me.