 All right, last project management talk for the day. Really keen to get you out of here on time for drinks. So please welcome Scott from Technocrat. Take it away, Scott. Hello, everyone. My name is Scott, and I'm from Technocrat. And we are going to spend the next 30 minutes or so talking about how to do a site audit in 45 minutes. So as humans, I find we are very good at assessing situations. It's an instinct that I think people have. So let me give you an example. Imagine you're walking through the city at night, and you come across a particular laneway, and it's dark, and there's a stream of blood flowing down the gutter. And in the distance, you hear screams. Then as a human, you would probably instinctively assess danger. And if you did that, then hopefully you would think, I shouldn't go down that laneway because it might not be safe. And that's something that we do without even thinking. We make assessments of things rapidly in certain situations. Another example is that as humans, we assess each other. So for those of you who don't know me, you're probably assessing me right now without even realizing it subconsciously. And you're making, as the presentation goes on, you'll make assessments like, I wonder if he really knows what he's talking about. And is he a good communicator or is he boring? And that's OK. You can make those assessments because we all do those things all the time. But what we want to talk about today is how to make that kind of quick assessment on a Drupal project. So let's continue. So the main thing that I want to communicate in this presentation in the short period of time is, is it possible to complete a useful site order of a Drupal code base in 45 minutes? The answer is yes. So why is a site order useful? Well, the situation I'm talking about is when you are presented with a Drupal website, a project that you have inherited or that has come into your agency or into your care as a freelancer, and it's not one that you built. So somebody else built this site, built this project, and it's been handed over to you. And so what you need to do is try to assess, and hopefully in a shorter period of time as possible, where on the spectrum this project lies? Is it a dumpster fire or is it a beautiful work of art? Most likely, in most cases, the project will fall somewhere in the middle of those two. And the reason we want to figure this out is because often what happens is a client will come to you and they'll hand over their Shiny Drupal site, and they already have a list of bugs that they want fixed urgently, need to be in production tomorrow, ideally, and they'll already have a feature backlog that they want you to start working on ASAP. But what I've found is that a lot of clients have very high expectations for how quickly you take ownership of that code base and how quickly they can then blame you for the bugs that were there before you got there. So that's why a site audit is important. We want to review the current state of the Drupal site so we can identify potential problem areas and we can determine a path forward towards maintenance and feature development in a short period of time. So obviously in 45 minutes, you can't do everything. So just quickly, what would be in scope and out of scope for this audit? Obviously, we're not gonna do any kind of load testing. We wouldn't have time to thoroughly review custom code, particularly if there is a large amount of custom code. We wouldn't have time to thoroughly review external integrations or API integrations and understand how they work. And we don't have time for any kind of extensive security testing or penetration testing or anything like that. What is in scope, however, is an opportunity to get a feel for the code quality and particularly the custom code that might exist in the project. An opportunity to look at the security settings that affect Drupal's code base. An opportunity to look at performance configuration, to look at the documentation that's available in the site and also to look at the config and settings. One of the quickest ways to get a feel for how big a Drupal site is, what it does, how it's been used is to look at settings files and look at exported configuration and see what's there and what isn't there. So how is it possible to conduct a site order in 45 minutes? Well, the way we do it is we start with the plan. So here's an example plan. You can come up with your own but you can borrow this one if you like and we just allow a period of time for a few different tasks and then we keep moving. The reason you need a plan is because it's very easy to fall down rabbit holes. If you discover something that's really quite odd in this project you've inherited, normally our own curiosity would tend to make us wanna drill down into that and find out what the heck is going on but we have to resist that temptation if we want to get through a broad site order in a short period of time. So we start with the plan and we use a template. There's a template there if you can be bothered and you wanna note that down that you could download as an example and I won't flick across to it now because then I'll never get back to my PowerPoint but I will flick across to it later. The benefit of starting with a template is that you don't have to mess around with all that initial setting up the document, structuring it. So in this template there are subheadings for security, for code base, for performance and then what you can do is as you're going through your audit, as soon as you find something you can basically copy and paste. Put a heading in, put a section in, go back to your audit, keep looking at the site, find something else, copy and paste into your template and it speeds things up. One thing I normally include and which I can show you later is whenever I do a site audit I try to put an icon or a flag in to indicate how important a particular item might be. Is this thing that we've identified critical? Is it a security issue that could result in the site being hacked very soon? Is it a critical performance issue or is it just like a nice to have and something that we should be aware of but is not critical for the site's day-to-day operation? So first item in our plan is we will run the Drupal site audit module. What this module does is you can use Drush to generate a report that gives you a snapshot of the code base's size or the Drupal website's size and its configuration. It flags potential issues. I would suggest if you're using a current version of Drupal 8, which it should be then you should use the dev version of this module for running this report so you don't run into issues and that's an example Drush command that you can use to generate the report. It basically just says run all the available reports, output the report in HTML, include everything, even things that aren't broken, format it using the Bootstrap CSS framework and redirect the output to a HTML file. So once you've done that, what you actually get if you open up that HTML file is quite a long report and it's color-coded with different green, blue, red. What you wanna do is look for the red sections. Anything that's in red has been flagged as a potential issue but a few other things to keep a lookout for that are always important. How is the caching configuration, how is caching configured? Is it switched on? Is Drupal's page cache set to have a reasonable expiry time? Is views configuration switched on? Your CSS and JS files aggregated. And yeah, so all those things. Another thing to look out for and which this module provides you is to give an indication of the size of the website. So it tells you the size of the project route and whatever might be in the public file system but also the size of the database. There's a few reasons why that could be useful. Some websites you inherit could be enormous. So if you have a 20 gigabyte database, then one of the first things you might wanna think about if you're asking some of your developers to onboard to that project is there a way for us to sanitize this database or remove some of the bulk of it so that you can set up your local development environments more quickly without having to sync 20 gigabyte databases? Another thing you may wanna consider is if backups are your responsibility, it's rather than the hosting providers, then you do wanna have an idea about the size of the project, whether it's database or file system. If it's very large, then the time it takes to back things up and to transfer backup files is always worth considering. And one more thing, logging. The very bottom thing in the site order report is any logging that's configured in the Drupal website, if there is no logging, obviously that's an issue. And but what you wanna know is what logging is enabled and where are those logs found? And because as soon as the client wants you to start fixing bugs, you probably need to find those logs quickly. So moving along, the next part of our plan is the hacked module. Once again, easy to install. If you use the dev version, then you can also use that patch file which provides Drush 9 command support. And the benefit of that is you don't have to use the Drupal UI to look at the report. You can run that Drush HLP command. And what it would do is give you a list of all the modules that are contrary modules and core that are enabled in the website and then give you a count of the number of changes in those modules. So basically what you wanna see is that any modules that are flagged as changed also have corresponding patches in your composer file. If there weren't, then that would obviously be something you wanna look into. And one example of that, which we found recently while conducting a site audit was a particular contrib module that had been moved outside its normal location and so was committed to the repo and had been modified. But those modifications weren't tracked or could document it in any way. And also the problem with that is that later on if that particular module has security updates that get released, you can't easily apply them because basically that module is existing outside your normal composer workflow. So yeah, basically what to look for just making sure that everything that's flagged as changed makes sense. That it matches up with what's in your composer file. So moving along, the next step in that plan is the security review module. This one also generates a report but it's available through your Drupal UI and basically what it gives you is a list of green or red items. And what I'd recommend is copy all the green ones across your report as well because you can flag those as okay, these are the things that have been checked and they're okay. And then take a look at what the red ones say and determine whether they need further investigation whether they should be flagged as problems in your report. One of the things to be aware of is that if you're running this report locally which you probably are at least initially rather than in the production site, just keep an eye out for things that get flagged as issues which may be issues locally but may not be in production because it may be in production and the configuration is slightly different and you're not showing errors on screen whereas locally that's not set, so you are. Just so you don't flag anything incorrectly. Okay, the next thing in our plan is code base review and so what we wanna do is take a quick look at the code base as a whole and get a feel for whether things make sense from a Drupal perspective. So I think for anyone who's been working with Drupal for a while, you've got already an idea in your head about what the directory structure should look like. So you're looking at things like the country modules in a separate directory to the custom ones, the same with themes, I think there are contrary themes directory and a custom themes directory. You might look for things like are there front-end assets outside the, are they like inside the custom theme directory or are they outside the web root which I've seen quite frequently. You might also wanna take a look at where is the config sync or where is the configuration directory where YAML files are exported to, is there one and is it committed to the repo? You can quickly have a look at how many custom modules are there are, are there four or are there 100? And, but the other thing that's also worth doing is digging into your custom modules, opening up the code and having a bit of a look through and once you've done this a few times you can really get a quick feel for something that looks scary versus something that looks like it's been well looked after. So a couple of things to keep your eyes out for. One is commenting, are there proper comment blocks? Is it clear, is it clearly formatted? One of the red flags that I often find in code bases that haven't been well maintained are debugging lines of code that have been left in there so maybe there's print lines. It's say, error and printing to the screen and then a die command or something else like that but basically looking for things that people have been using to try to write their code but then left in the repo. Another thing to look out for is like large sections of commented out code. So maybe, you know, things have been refactored instead of actually removing it and using Git to manage the changes that things have just been commented out and left in the code base. Another thing to look out for is direct SQL queries. I've found a lot of times in custom modules if there's a lot of direct SQL queries in the module it can often be an indication that things are not being done in a Drupal kind of manner. Maybe data is either being read or stored in a way that's not best practice for Drupal. And next step in the plan is configuration review. So, as mentioned before, the sync directories making sure they're in the repository. One thing you can often see quickly is is there just one sync directory or is the config split module used? And so maybe there's a separate directory for a production or a testing environment. Another thing that's worth looking at is settings files and services.yaml files. So there's often a lot of things to look for in here that you can find in a really brief amount of time. So for example, are there any if or switch statements that per environment in the settings files? What is the method used to determine which environment you're in, whether you're in production or testing or local? Is it trying to import a local settings file? And if so, is there a default one in the repository? Other things to look for are other services that might be configured. So often you'll see if there's memcache or reticin use you might see configuration for that in settings files. You might also see configuration for external APIs to give you an indication of any integrations that may exist. And you may also see configuration for logging. So for example, if you use monologue the configuration for that is normally in your services.yaml file. One thing to look out for is any situation where there's potential for the production environment to be flagged incorrectly. So what you don't want is someone developing locally and somehow hitting a production API for some external system. And hopefully there's additional safety measures in place to prevent that like IP whitelisting or whatever else there might be. But it's always worth checking because you can get yourself into some dangerous situations if suddenly you take over a code base, you're not familiar with it, you set up locally and then you find that your local setup is able to write data to an external API that's meant to be used for production only. One other thing to check is the Cron settings. I would say that in quite a significant percentage of Drupal sites that we've taken over at some point one of the most common sources of bugs has been Cron settings. So either Cron not running correctly or not running frequently enough or all kinds of things. But basically tracking that down as the source of a bug or a performance issue is quite often something that we need to do. One example of that is a site that we maintained which had Cron being triggered in a default manner. So basically via page request. And this particular site had a very heavy Cron load at particular times of day. We're processing a lot of data that had come in from an external system. And so when some poor sucker hit the site at a particular time it triggered the Cron process and basically overloaded that particular server and they got some pretty terrible response times. So what I would suggest then instead is always where you can always trigger Cron via your Linux Cron tab service. And if you can use Drush Cron to trigger it so that it doesn't have to go through your web server. Last step in the plan is the documentation review. So being aware of any documentation that may have been provided to you outside the repo itself but also in the repo, is there a readme file on the route and is it up to date? Is there a readme file in your custom theme? Are there any readme files in your custom modules? And also just in the custom code itself is it well documented? Can you easily go in there and get a feel for what specific functions do or for what a particular module is meant to do? So hopefully if you follow that plan and cover those topics and keep moving then what you can do is every time you find something and it's something that could be an issue jump across to your template, put it in, flag it whether it's high or medium or low priority and then at the end of that process then hopefully what you've got is like a fairly rough site audit that you can then review, polish up, fix the spelling mistakes and get into a useful state. So that's your 45 minutes up. What would you do if you had the luxury of an additional 15 minutes or an additional hour or two? Next steps to things to check would be your front-end build process. If it's documented then you can jump straight in and see whether it works. Is there a goal file and does that run? Is there anything that's not documented about that build process? And then from there reviewing other things like hosting environments, SSH access and deployment procedures. So what I'm going to do now is quickly jump out of this view, maybe. Oh, maybe not. No, okay, not sure. Does anyone have any questions? The, which side? Yeah, sure. Thanks, God, that was very interesting. Question is about automating all this processes. Do you, is there a service or the automating goal? Is there a service or have you thought about it creating one? I mean, in some ways it's, there's people have gone part of the way to automating already. So using those modules gives you quick snapshots and flags, particular issues. So I guess probably the best way to automate would be extending on those. And maybe the closest one already that I've used is that site audit one. So if you were to take that and add a few more things to it and improve the quality of the output, then you'd be 90% of the way to automating. And have you heard of Drugini? I have, and I haven't used it extensively so I can't say whether I'd prefer it over site audit. But what I do know about site audit is I've been able to get it running in like five minutes and producing a report. And so I found it to be quite efficient for the as a tool. Sorry, last question. Can you use site audit or add tools without the strapping triple, like without uploading using database at all? I don't think, well, so site audit, no. And hacked, not sure actually, never tried. All good. Well, the question? We still have time for your demo. Can you get it back? Well, I'd have to figure out how to get my screen back. No, no, not that. I wanna go to the terminal. Kill it. Yeah. Oh, yeah, maybe. What if I close Chrome? That is the output of Drush-HLP, which is the hacked module. And if we can scroll. Here we go. That's the final report. This one I definitely think had some issue with the Drupal Core check because there was no reason for that 454 changes. But the other ones were, those other modules were an accurate reflection of the patches that were in the composer file. But the rest of them were unchanged. And one other thing, hopefully we can show. Well, maybe not. Let's see. Okay, that is the site audit output. So breast patches are green, but then scrolling down for this particular site had some caching configuration issues that you can see there. Code-based size was 200 megabytes. It gives you some pretty useful information about content types and fields, knowing how many there are, and like how many nodes there are, how many content types there are, and field usage. Database as well. Database size was not particularly big this one. This has one table, which has a different engine to the rest of the database. So, and lots of other things. And logging at the bottom. Views caching. So definitely worth checking out. And, oh, the final thing is the template. Let's see. Oh, yeah, no internet. Okay, never mind. All right, we have to look at that myself. That's all. Thank you. Thank you.